jramos/isp-backbone-course
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add all 8 course modules with converted markdown links

Browse Source 
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Garvis
2026-02-27 10:28:45 -07:00
parent 73dfd80247
commit 9fb54fcbd4
8 changed files with 867 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

144
modules/01-isis.md Normal file
View File

@@ -0,0 +1,144 @@
# Module 1: The Underlay — IS-IS
> **Course**: [ISP Backbone Lab Course](../README.md)
> **Next**: [Module 2: MPLS](02-mpls.md)
---
## Network Diagram
![IS-IS Level 2 Topology](../diagrams/Module1_ISIS_Topology.png)
*IS-IS Level 2 domain — all P and PE routers with NET addresses and link subnets*
---
## Why IS-IS and Not OSPF?
Every major ISP on the planet runs IS-IS as their IGP (Interior Gateway Protocol). Here's why:
1. **IS-IS runs on Layer 2** — it doesn't need IP to function. OSPF runs on top of IP. This means IS-IS is more resilient; if your IP config is broken, IS-IS still forms adjacencies.
2. **Protocol-agnostic** — IS-IS carried IPv4, IPv6, and MPLS labels long before OSPF could. It was designed to carry *any* protocol (it originally carried CLNS).
3. **Scales better** — IS-IS uses a flat TLV (Type-Length-Value) structure, making it trivially extensible. Adding Segment Routing support to IS-IS was easy. Adding it to OSPF required new LSA types and was messy.
4. **Faster convergence** — IS-IS partial route calculations (PRC) are more efficient than OSPF's.
5. **Convention** — When everyone uses IS-IS, interop is easier. It's the industry standard for SP networks.
## IS-IS Key Concepts
**Levels:**
- **Level 1 (L1)** = Intra-area routing (like OSPF's intra-area routes)
- **Level 2 (L2)** = Inter-area / backbone routing (like OSPF Area 0)
- **Level 1-2** = A router that participates in both (most PE routers)
For our ISP: **Everything runs Level 2 only.** This is standard practice in SP networks. We're one big backbone — no need for L1 areas. Keeps it simple and fast.
**NET (Network Entity Title):**
This is IS-IS's address format. It looks weird but it's simple:
```
49.0001.0000.0000.0001.00
│ │ │ │
│ │ └──────────────┘── System ID (unique per router, often based on loopback IP)
│ └── Area ID
└── AFI (49 = private, always use this in labs)
```
**Metric:**
IS-IS uses a flat metric (default: 10 on every link). We'll use **wide metrics** (mandatory for Segment Routing) and set costs based on link speed to influence traffic paths.
## Lab 1 Config: IS-IS on the Core
**Goal:** Full IS-IS adjacency across all P and PE routers. Every router can ping every other router's loopback.
**Addressing Plan:**
| Router | Loopback0 | IS-IS NET | Role |
|--------|-----------|-----------|------|
| P1 | 10.0.0.1/32 | 49.0001.0000.0000.0001.00 | Core P |
| P2 | 10.0.0.2/32 | 49.0001.0000.0000.0002.00 | Core P |
| P3 | 10.0.0.3/32 | 49.0001.0000.0000.0003.00 | Core P |
| P4 | 10.0.0.4/32 | 49.0001.0000.0000.0004.00 | Core P |
| P-CORE | 10.0.0.5/32 | 49.0001.0000.0000.0005.00 | Core P / RR |
| PE-EDGE1 | 10.0.0.11/32 | 49.0001.0000.0000.0011.00 | PE (AS65000 border) |
| PE-EDGE2 | 10.0.0.12/32 | 49.0001.0000.0000.0012.00 | PE (AS65000 cust) |
| PE-EDGE3 | 10.0.0.13/32 | 49.0001.0000.0000.0013.00 | PE (AS65100 border) |
| PE-EDGE4 | 10.0.0.14/32 | 49.0001.0000.0000.0014.00 | PE (AS65100 cust) |
**Link Addressing (point-to-point, /30s):**
| Link | Subnet | Router A IP | Router B IP |
|------|--------|-------------|-------------|
| P1 — PE-EDGE1 | 10.1.1.0/30 | .1 | .2 |
| P1 — P-CORE | 10.1.1.4/30 | .5 | .6 |
| P1 — P2 | 10.1.1.8/30 | .9 | .10 |
| P2 — PE-EDGE2 | 10.1.1.12/30 | .13 | .14 |
| P2 — P-CORE | 10.1.1.16/30 | .17 | .18 |
| P3 — PE-EDGE3 | 10.1.1.20/30 | .21 | .22 |
| P3 — P-CORE | 10.1.1.24/30 | .25 | .26 |
| P3 — P4 | 10.1.1.28/30 | .29 | .30 |
| P4 — PE-EDGE4 | 10.1.1.32/30 | .33 | .34 |
| P4 — P-CORE | 10.1.1.36/30 | .37 | .38 |
| PE-EDGE1 — IXP | 172.16.0.0/24 | .1 | — |
| PE-EDGE3 — IXP | 172.16.0.0/24 | .3 | — |
**Sample Config — P1 (IOS-XE / IOSv):**
```
hostname P1
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
ip router isis YOURSP
!
interface GigabitEthernet0/1
description TO PE-EDGE1
ip address 10.1.1.1 255.255.255.252
ip router isis YOURSP
isis network point-to-point
isis metric 10
no shutdown
!
interface GigabitEthernet0/2
description TO P-CORE
ip address 10.1.1.5 255.255.255.252
ip router isis YOURSP
isis network point-to-point
isis metric 10
no shutdown
!
interface GigabitEthernet0/3
description TO P2
ip address 10.1.1.9 255.255.255.252
ip router isis YOURSP
isis network point-to-point
isis metric 10
no shutdown
!
router isis YOURSP
net 49.0001.0000.0000.0001.00
is-type level-2-only
metric-style wide
log-adjacency-changes
passive-interface Loopback0
```
## Verification Commands
```
show isis neighbors ! Are adjacencies UP?
show isis database detail ! What LSPs do we have?
show ip route isis ! Are all loopbacks in the table?
ping 10.0.0.5 source 10.0.0.1 ! Can P1 reach P-CORE?
show isis topology ! Visual of the IS-IS graph
```
## Understanding Check
Before moving on, you should be able to answer:
1. Why does the ISP use Level 2 only?
2. What's the System ID in the NET, and why do we derive it from the loopback?
3. Why `isis network point-to-point` on every link?
4. What happens if you forget `metric-style wide`? (Hint: Segment Routing won't work)
---
> **Next Module**: [Module 2: MPLS — Labeling the Backbone →](02-mpls.md)

81
modules/02-mpls.md Normal file
View File

@@ -0,0 +1,81 @@
# Module 2: MPLS — Labeling the Backbone
> **Course**: [ISP Backbone Lab Course](../README.md)
> **Previous**: [Module 1: IS-IS](01-isis.md)
> **Next**: [Module 3: iBGP](03-ibgp.md)
---
## Network Diagram
![MPLS Label Switched Path](../diagrams/Module2_MPLS_LabelPath.png)
*MPLS label switched path showing Push → Swap → Swap → PHP Pop → IP Lookup*
---
## What Is MPLS and Why Do ISPs Use It?
MPLS (Multi-Protocol Label Switching) is the **heart of every modern ISP backbone**. Here's the key insight:
> **Core routers (P routers) don't need to know about customer routes.**
Without MPLS, every P router would need a full routing table — millions of routes. That's slow, expensive, and a security risk. Instead:
1. PE routers push an **MPLS label** onto packets entering the core
2. P routers only look at the label — a simple number — and swap/forward it
3. The PE on the other side pops the label and delivers to the customer
Think of it like shipping containers. The cargo ship (P router) doesn't care what's inside the container. It just reads the shipping label and moves it to the right port.
## LDP (Label Distribution Protocol)
LDP is how routers agree on which labels to use. It's simple:
1. Router A tells Router B: "If you want to reach my loopback 10.0.0.1, use label 24"
2. Router B remembers this and tells its own neighbors: "To reach 10.0.0.1, send it to me with label 30" (its own locally assigned label)
3. This builds a **Label Switched Path (LSP)** across the network
## Lab 2 Config: Enable MPLS/LDP
**On every P and PE router (add to existing config):**
```
mpls ip
mpls ldp router-id Loopback0 force
!
interface GigabitEthernet0/1
mpls ip
!
interface GigabitEthernet0/2
mpls ip
!
interface GigabitEthernet0/3
mpls ip
```
**That's it.** MPLS is beautifully simple to enable. The magic is in what it *enables* (VPNs, TE, etc.)
## Key Concept: PHP (Penultimate Hop Popping)
When a packet is one hop away from its destination, the second-to-last router **pops the label** instead of swapping it. Why? So the destination router only has to do one lookup (IP) instead of two (label + IP). This is called PHP and you'll see it as `implicit-null` or label `3` in the LFIB.
## Verification Commands
```
show mpls interfaces ! Which interfaces have MPLS enabled?
show mpls ldp neighbor ! LDP sessions established?
show mpls ldp bindings ! What labels are assigned to what prefixes?
show mpls forwarding-table ! The LFIB — the actual label switching table
traceroute 10.0.0.14 source 10.0.0.11 ! Should show MPLS labels in the path!
```
## Understanding Check
1. Why don't P routers need customer routes?
2. What is the LFIB and how is it different from the RIB/FIB?
3. Explain PHP — why does the second-to-last hop pop the label?
4. What would break if you forgot `mpls ldp router-id Loopback0 force`?
---
> **Next Module**: [Module 3: iBGP — The Brain of the ISP →](03-ibgp.md)

120
modules/03-ibgp.md Normal file
View File

@@ -0,0 +1,120 @@
# Module 3: iBGP — The Brain of the ISP
> **Course**: [ISP Backbone Lab Course](../README.md)
> **Previous**: [Module 2: MPLS](02-mpls.md)
> **Next**: [Module 4: L3VPN](04-l3vpn.md)
---
## Network Diagram
![iBGP Route Reflector Design](../diagrams/Module3_iBGP_RouteReflector.png)
*iBGP Route Reflector design — P-CORE reflects routes to all PE clients, eliminating full mesh*
---
## Why BGP Inside the ISP?
IS-IS carries infrastructure routes (loopbacks, point-to-point links). But customer routes, internet routes, VPN routes — all of that rides on **BGP**. Specifically, **iBGP** (Internal BGP — same AS number on both sides).
## The Full Mesh Problem
iBGP has a rule: **A route learned via iBGP cannot be advertised to another iBGP peer.** This prevents loops but creates a problem — you need a full mesh of iBGP sessions. With 9 routers, that's 36 sessions. With 100 routers, that's 4,950 sessions. That doesn't scale.
## Route Reflectors to the Rescue
A **Route Reflector (RR)** breaks the full-mesh requirement. RR rules:
- **Client → RR**: Reflects to all other clients and non-clients
- **Non-client → RR**: Reflects to clients only
- **RR → RR**: Reflects to clients
We'll make **P-CORE** our Route Reflector. Every PE peers with P-CORE only. P-CORE reflects routes between them. Simple, scalable, elegant.
## Why Peer Using Loopbacks?
iBGP sessions use **loopback addresses** (not physical interfaces) because:
1. If a physical link goes down but an alternate path exists, the BGP session survives
2. Loopbacks never go down unless the router itself is dead
3. This is why IS-IS (Module 1) was so important — it provides reachability to loopbacks
## Lab 3 Config: iBGP with Route Reflector
**P-CORE (Route Reflector):**
```
router bgp 65000
bgp router-id 10.0.0.5
bgp log-neighbor-changes
no bgp default ipv4-unicast
!
neighbor PEERS peer-group
neighbor PEERS remote-as 65000
neighbor PEERS update-source Loopback0
neighbor PEERS route-reflector-client
!
neighbor 10.0.0.11 peer-group PEERS
neighbor 10.0.0.12 peer-group PEERS
neighbor 10.0.0.13 peer-group PEERS
neighbor 10.0.0.14 peer-group PEERS
!
address-family ipv4 unicast
neighbor PEERS activate
neighbor PEERS send-community both
neighbor PEERS next-hop-self
exit-address-family
!
address-family vpnv4 unicast
neighbor PEERS activate
neighbor PEERS send-community both
exit-address-family
```
**PE-EDGE1 (and similar for all PE routers):**
```
router bgp 65000
bgp router-id 10.0.0.11
bgp log-neighbor-changes
no bgp default ipv4-unicast
!
neighbor 10.0.0.5 remote-as 65000
neighbor 10.0.0.5 update-source Loopback0
!
address-family ipv4 unicast
neighbor 10.0.0.5 activate
neighbor 10.0.0.5 send-community both
exit-address-family
!
address-family vpnv4 unicast
neighbor 10.0.0.5 activate
neighbor 10.0.0.5 send-community both
exit-address-family
```
## Key Design Notes
- `no bgp default ipv4-unicast` — Best practice. Forces you to explicitly activate neighbors per address family. Prevents accidental route leaking.
- `send-community both` — Critical for MPLS VPNs. Route targets are carried as BGP communities.
- `address-family vpnv4` — This carries VPN routes (Module 4). We enable it now so it's ready.
- `next-hop-self` on the RR — Ensures PE routers don't need to resolve each other's next-hops through the core (the RR rewrites it to itself).
## Verification
```
show bgp summary ! All neighbors Established?
show bgp ipv4 unicast summary ! IPv4 session status
show bgp vpnv4 unicast summary ! VPNv4 session status (should be empty for now)
show bgp ipv4 unicast ! What routes are in BGP?
show ip bgp neighbors 10.0.0.5 ! Detailed neighbor info
```
## Understanding Check
1. Why can't iBGP routes be re-advertised to other iBGP peers (without a RR)?
2. What's the difference between `address-family ipv4` and `address-family vpnv4`?
3. Why `update-source Loopback0`?
4. What would happen if P-CORE went down? (Single point of failure — how would you fix this in production?)
---
> **Next Module**: [Module 4: L3VPN — Customer Isolation with VRFs →](04-l3vpn.md)

129
modules/04-l3vpn.md Normal file
View File

@@ -0,0 +1,129 @@
# Module 4: L3VPN — Customer Isolation with VRFs
> **Course**: [ISP Backbone Lab Course](../README.md)
> **Previous**: [Module 3: iBGP](03-ibgp.md)
> **Next**: [Module 5: eBGP](05-ebgp.md)
---
## Network Diagram
![L3VPN End-to-End Flow](../diagrams/Module4_L3VPN_Flow.png)
*L3VPN end-to-end flow — CE→PE→MPLS Core→PE→CE with VRF isolation and dual label stack*
---
## The Business Problem
You're an ISP. Customer A and Customer B both use `10.0.0.0/8` internally (because of course they do). If you put both their routes in your global routing table, they collide. **VRFs solve this.**
## What Is a VRF?
A **VRF (Virtual Routing and Forwarding)** instance is a completely separate routing table on the same physical router. Think of it as running multiple virtual routers on one box.
Each VRF has:
- **Name** — just a label (e.g., "CUST_A")
- **Route Distinguisher (RD)** — Makes routes globally unique. 65000:100 + 10.0.0.0/8 becomes a unique VPNv4 route
- **Route Targets (RT)** — Controls which VRFs import/export routes. This is the magic that connects customer sites across the MPLS core
## How L3VPN Works End-to-End
1. **CE-CUST1** advertises `192.168.100.0/24` via eBGP to **PE-EDGE2**
2. **PE-EDGE2** puts this route into VRF `CUST_A`, adds RD `65000:100`, and exports with RT `65000:100`
3. The route is carried via **MP-BGP (VPNv4 address family)** to the Route Reflector
4. **P-CORE (RR)** reflects it to **PE-EDGE4**
5. **PE-EDGE4** sees RT `65000:100`, checks its VRF import policy, and imports it into VRF `CUST_A`
6. **CE-CUST2** now sees `192.168.100.0/24` and can reach Customer A's other site
7. **All transit through the core is MPLS-labeled** — P routers never see customer routes
## Lab 4 Config: L3VPN
**PE-EDGE2 (Customer A facing):**
```
! Create VRF
vrf definition CUST_A
rd 65000:100
address-family ipv4
route-target export 65000:100
route-target import 65000:100
exit-address-family
!
! Assign customer-facing interface to VRF
interface GigabitEthernet0/4
description TO CE-CUST1
vrf forwarding CUST_A
ip address 10.100.0.1 255.255.255.252
no shutdown
!
! BGP config for VRF
router bgp 65000
address-family ipv4 vrf CUST_A
neighbor 10.100.0.2 remote-as 65001
neighbor 10.100.0.2 activate
exit-address-family
```
**CE-CUST1 (Customer A):**
```
hostname CE-CUST1
!
interface Loopback0
ip address 192.168.100.1 255.255.255.255
!
interface GigabitEthernet0/0
description TO PE-EDGE2
ip address 10.100.0.2 255.255.255.252
no shutdown
!
router bgp 65001
bgp router-id 192.168.100.1
network 192.168.100.0 mask 255.255.255.0
neighbor 10.100.0.1 remote-as 65000
```
**PE-EDGE4 (Customer B / also imports CUST_A routes):**
```
vrf definition CUST_A
rd 65000:100
address-family ipv4
route-target export 65000:100
route-target import 65000:100
exit-address-family
!
interface GigabitEthernet0/4
description TO CE-CUST2
vrf forwarding CUST_A
ip address 10.100.1.1 255.255.255.252
no shutdown
!
router bgp 65000
address-family ipv4 vrf CUST_A
neighbor 10.100.1.2 remote-as 65002
neighbor 10.100.1.2 activate
exit-address-family
```
## Verification
```
show vrf ! VRFs configured
show ip route vrf CUST_A ! Customer A's routing table
show bgp vpnv4 unicast all ! All VPN routes across the core
show bgp vpnv4 unicast vrf CUST_A ! VPN routes for this specific customer
ping vrf CUST_A 192.168.100.1 source 10.100.1.1 ! Cross-core VPN connectivity
traceroute vrf CUST_A 192.168.100.1 ! Should show MPLS labels through core
```
## Understanding Check
1. What's the difference between RD and RT? (Common interview question!)
2. If Customer B also uses `192.168.100.0/24`, why doesn't it conflict?
3. What MPLS labels are used for VPN forwarding? (Hint: there are TWO labels — why?)
4. How would you give Customer A internet access in addition to their VPN?
---
> **Next Module**: [Module 5: eBGP — Peering with the World →](05-ebgp.md)

106
modules/05-ebgp.md Normal file
View File

@@ -0,0 +1,106 @@
# Module 5: eBGP — Peering with the World
> **Course**: [ISP Backbone Lab Course](../README.md)
> **Previous**: [Module 4: L3VPN](04-l3vpn.md)
> **Next**: [Module 6: Segment Routing](06-segment-routing.md)
---
## Network Diagram
![eBGP Peering at the IXP](../diagrams/Module5_eBGP_Peering.png)
*eBGP peering at the IXP — route filtering, local-pref tiers, and the Big 9 best path selection*
---
## Peering Types at an ISP
| Type | What It Is | Relationship | Money |
|------|-----------|-------------|-------|
| **Transit** | You pay a bigger ISP to reach the full internet | Customer → Provider | You pay them |
| **Peering** | Two ISPs agree to exchange traffic for free | Peer ↔ Peer | Free (settlement-free) |
| **Customer** | Someone pays YOU for connectivity | Provider → Customer | They pay you |
| **IXP (Internet Exchange)** | A shared switch where many ISPs peer at once | Many ↔ Many | Small port fee |
## Our Lab Setup
PE-EDGE1 (AS 65000) and PE-EDGE3 (AS 65100) peer at the IXP. This simulates **settlement-free peering** between two ISPs.
## Lab 5 Config: eBGP at the IXP
**PE-EDGE1:**
```
! IXP-facing interface
interface GigabitEthernet0/5
description TO IXP-SWITCH
ip address 172.16.0.1 255.255.255.0
no shutdown
!
router bgp 65000
neighbor 172.16.0.3 remote-as 65100
!
address-family ipv4 unicast
neighbor 172.16.0.3 activate
neighbor 172.16.0.3 route-map PEERING-IN in
neighbor 172.16.0.3 route-map PEERING-OUT out
neighbor 172.16.0.3 prefix-list PEER-IN-FILTER in
exit-address-family
!
! Only accept their customer prefixes, not the full internet
ip prefix-list PEER-IN-FILTER seq 10 permit 10.200.0.0/16 le 24
ip prefix-list PEER-IN-FILTER seq 999 deny 0.0.0.0/0 le 32
!
! Set local-pref lower for peering routes (prefer transit/customer)
route-map PEERING-IN permit 10
set local-preference 100
!
route-map PEERING-OUT permit 10
! Only advertise your customer routes, not routes learned from other peers
match community CUSTOMER-ROUTES
```
**PE-EDGE3:**
```
interface GigabitEthernet0/5
description TO IXP-SWITCH
ip address 172.16.0.3 255.255.255.0
no shutdown
!
router bgp 65100
neighbor 172.16.0.1 remote-as 65000
!
address-family ipv4 unicast
neighbor 172.16.0.1 activate
neighbor 172.16.0.1 route-map PEERING-IN in
neighbor 172.16.0.1 route-map PEERING-OUT out
exit-address-family
```
## BGP Best Path Selection (The Big 9)
This is **THE** most important BGP concept. When a router has multiple paths to the same prefix, it picks the best one using this order:
| Priority | Attribute | Higher or Lower Wins? | Who Controls It? |
|----------|-----------|----------------------|-----------------|
| 1 | Weight (Cisco-proprietary) | Higher | Local router only |
| 2 | Local Preference | Higher | Entire AS (via iBGP) |
| 3 | Locally originated | — | Prefer routes this router originated |
| 4 | AS Path length | Shorter | Neighbors (can be prepended) |
| 5 | Origin code | IGP > EGP > ? | Route origin |
| 6 | MED (Multi-Exit Discriminator) | Lower | Neighbor (suggestion only) |
| 7 | eBGP over iBGP | — | Prefer external routes |
| 8 | Lowest IGP metric to next-hop | Lower | Interior routing |
| 9 | Oldest route / Router ID | Varies | Tiebreakers |
## Understanding Check
1. Why do ISPs filter inbound routes with prefix lists? What could go wrong?
2. What is AS-path prepending and when would you use it?
3. Why set a lower local-preference on peering routes?
4. What is a BGP community and how do ISPs use them for traffic engineering?
---
> **Next Module**: [Module 6: Segment Routing →](06-segment-routing.md)

86
modules/06-segment-routing.md Normal file
View File

@@ -0,0 +1,86 @@
# Module 6: Segment Routing
> **Course**: [ISP Backbone Lab Course](../README.md)
> **Previous**: [Module 5: eBGP](05-ebgp.md)
> **Next**: [Module 7: Traffic Engineering](07-traffic-engineering.md)
---
## Network Diagram
![Segment Routing SID Assignments](../diagrams/Module6_SegmentRouting.png)
*Segment Routing SID assignments (SRGB 16000+) with Prefix SIDs and Adjacency SIDs on all nodes*
---
## The Evolution: LDP → SR
Remember how LDP assigns labels? It works, but it has problems:
- LDP creates a **full mesh of label bindings** — every router gets a label for every prefix
- LDP is a **separate protocol** that must stay in sync with IS-IS (if they disagree, traffic blackholes)
- No built-in traffic engineering
**Segment Routing (SR)** fixes all of this by embedding labels directly into IS-IS (or OSPF). No more LDP. No more synchronization issues.
## How SR Works
Instead of LDP negotiating labels between neighbors, each router advertises a **Segment ID (SID)** via IS-IS:
- **Prefix SID** = A label for reaching a specific router's loopback (replaces what LDP does)
- **Adjacency SID** = A label for a specific link (used for traffic engineering)
The SID is an **index** added to a globally configured **SRGB (Segment Routing Global Block)**. Default SRGB: 16000–23999.
Example: If P1's Prefix SID index is 1, its label is **16001** everywhere in the network. No negotiation needed.
## Lab 6 Config: Enable Segment Routing
**On every router (replace LDP):**
```
! Remove LDP (optional — SR and LDP can coexist, but pure SR is cleaner)
no mpls ldp router-id Loopback0 force
!
! Enable SR in IS-IS
router isis YOURSP
segment-routing mpls
segment-routing prefix-sid-map advertise-local
!
interface Loopback0
ip router isis YOURSP
isis prefix-sid index <UNIQUE_NUMBER>
```
**SID Index Assignments:**
| Router | Loopback | Prefix SID Index | Resulting Label |
|--------|----------|-----------------|----------------|
| P1 | 10.0.0.1 | 1 | 16001 |
| P2 | 10.0.0.2 | 2 | 16002 |
| P3 | 10.0.0.3 | 3 | 16003 |
| P4 | 10.0.0.4 | 4 | 16004 |
| P-CORE | 10.0.0.5 | 5 | 16005 |
| PE-EDGE1 | 10.0.0.11 | 11 | 16011 |
| PE-EDGE2 | 10.0.0.12 | 12 | 16012 |
| PE-EDGE3 | 10.0.0.13 | 13 | 16013 |
| PE-EDGE4 | 10.0.0.14 | 14 | 16014 |
## Verification
```
show isis segment-routing prefix-sid-map
show mpls forwarding-table ! Labels should now be 16xxx
show isis database detail ! Look for SR TLVs in the LSPs
show segment-routing mpls state
```
## Understanding Check
1. Why is SR simpler than LDP? What failure mode does it eliminate?
2. What's the SRGB and why does it need to be the same on every router?
3. What's the difference between a Prefix SID and an Adjacency SID?
4. Can SR and LDP coexist? When would you want that?
---
> **Next Module**: [Module 7: Traffic Engineering →](07-traffic-engineering.md)

64
modules/07-traffic-engineering.md Normal file
View File

@@ -0,0 +1,64 @@
# Module 7: Traffic Engineering
> **Course**: [ISP Backbone Lab Course](../README.md)
> **Previous**: [Module 6: Segment Routing](06-segment-routing.md)
> **Next**: [Module 8: Attack & Defense](08-attack-defense.md)
---
## Network Diagram
![SR-TE Explicit Path Steering](../diagrams/Module7_TrafficEngineering.png)
*SR-TE explicit path steering — default shortest path vs policy-driven SID stack path with Flex-Algo*
---
## Why TE?
By default, IS-IS picks the shortest path. But what if:
- The shortest path is congested?
- You want to send VoIP traffic on a low-latency path and bulk data on a high-bandwidth path?
- A fiber cut takes out the shortest path and you need a pre-computed backup?
**Traffic Engineering** lets you define explicit paths through the network.
## SR-TE (Segment Routing Traffic Engineering)
With SR, TE is just a **stack of SIDs**. Want traffic to go P1 → P2 → P-CORE → P4 instead of the direct path? Push labels `[16002, 16005, 16004]` onto the packet. Done. No RSVP tunnels, no signaling protocol, no state in the core.
## Lab 7 Config: SR-TE Policy
**PE-EDGE1 (force traffic to PE-EDGE4 via a specific path):**
```
segment-routing traffic-eng
segment-list PATH-VIA-P2-PCORE
index 10 mpls label 16002 ! P2
index 20 mpls label 16005 ! P-CORE
index 30 mpls label 16014 ! PE-EDGE4
!
policy STEER-TO-PE4
color 100 end-point 10.0.0.14
candidate-paths
preference 200
explicit segment-list PATH-VIA-P2-PCORE
```
## Flex-Algo (Advanced)
Flex-Algo lets you define **multiple topologies** on the same physical network. For example:
- **Algorithm 0** (default): Shortest path by metric
- **Algorithm 128**: Low-latency path (uses delay metric)
- **Algorithm 129**: High-bandwidth path (avoids congested links)
Each algorithm creates a separate set of SIDs, so you can steer traffic into different topologies without explicit path lists.
## Understanding Check
1. How does SR-TE compare to RSVP-TE? What makes it simpler?
2. What is a SID stack and how does it define a path?
3. What is Flex-Algo and when would you use it over explicit SR-TE?
---
> **Next Module**: [Module 8: Attack & Defense Labs →](08-attack-defense.md)

137
modules/08-attack-defense.md Normal file
View File

@@ -0,0 +1,137 @@
# Module 8: Attack & Defense Labs
> **Course**: [ISP Backbone Lab Course](../README.md)
> **Previous**: [Module 7: Traffic Engineering](07-traffic-engineering.md)
---
## Network Diagram
![Attack Surface Map](../diagrams/Module8_AttackDefense.png)
*Attack surface map — 5 attack vectors from Kali box with corresponding 5-layer defense strategy*
---
## Red Team / Blue Team on Your Own ISP
This is where it gets fun. You built this ISP — now **break it**.
---
## Attack 1: BGP Hijacking
**Scenario:** Kali box (connected to PE-EDGE2's network) sends BGP updates pretending to own Customer A's prefixes.
**The Attack:**
On Kali, run a BGP speaker (ExaBGP or FRRouting):
```
# ExaBGP config — advertise someone else's prefix
neighbor 10.100.0.1 {
router-id 6.6.6.6;
local-as 65001;
peer-as 65000;
static {
route 192.168.100.0/24 next-hop 10.100.0.2;
route 192.168.100.0/25 next-hop 10.100.0.2; # More specific = wins!
}
}
```
**The Defense:**
```
! On PE-EDGE2 — filter what CE-CUST1 can advertise
ip prefix-list CUST-A-ALLOWED seq 10 permit 192.168.100.0/24
ip prefix-list CUST-A-ALLOWED seq 999 deny 0.0.0.0/0 le 32
!
router bgp 65000
address-family ipv4 vrf CUST_A
neighbor 10.100.0.2 prefix-list CUST-A-ALLOWED in
neighbor 10.100.0.2 maximum-prefix 10 80 ! Alert at 80%, tear down at 100%
```
---
## Attack 2: IS-IS Adjacency Flooding
**Scenario:** Inject a rogue router into the IS-IS domain to poison the SPF tree.
**The Defense:**
```
! IS-IS authentication on ALL links
router isis YOURSP
authentication mode md5 level-2
authentication key-chain ISIS-AUTH level-2
!
key chain ISIS-AUTH
key 1
key-string S3cur3ISISk3y!
```
---
## Attack 3: MPLS Label Manipulation
**Scenario:** Craft packets with forged MPLS labels to reach VRFs you shouldn't have access to.
**The Defense:**
- **CoPP (Control Plane Policing)** — Rate-limit protocol traffic to the CPU
- **iACL (Infrastructure ACL)** — Only allow known sources to send labeled traffic
- **TTL propagation disabled** — Hides internal topology from traceroute
```
no mpls ip propagate-ttl
!
ip access-list extended INFRASTRUCTURE-PROTECTION
permit tcp 10.0.0.0 0.0.0.255 any eq bgp
permit udp 10.0.0.0 0.0.0.255 any eq 646 ! LDP
deny ip any any log
```
---
## Attack 4: OSPF/IS-IS Route Injection
**Scenario:** A compromised CE router attempts to inject routes into the ISP's IGP.
**The Defense:** This is why IS-IS runs on **P and PE routers only**, never on CE links. CE routers speak BGP, which is filtered. The IGP is completely isolated from customer influence. Architecture *is* the defense.
---
## Attack 5: DDoS Against the Control Plane
**Scenario:** Flood a PE router with spoofed packets targeting BGP (TCP 179).
**The Defense:**
```
! CoPP — protect the control plane
ip access-list extended COPP-BGP
permit tcp 10.0.0.0 0.0.0.255 any eq bgp
permit tcp any any eq bgp established
deny tcp any any eq bgp
!
class-map COPP-BGP-CLASS
match access-group name COPP-BGP
!
policy-map COPP-POLICY
class COPP-BGP-CLASS
police rate 500 pps burst 100 packets
conform-action transmit
exceed-action drop
class class-default
police rate 1000 pps
!
control-plane
service-policy input COPP-POLICY
```
---
## Key Takeaways
- **Offense informs defense** — You can't protect what you don't understand how to attack
- **Layered security** — No single defense is enough; combine prefix filtering, authentication, CoPP, and architectural isolation
- **Architecture IS security** — The IS-IS/BGP separation, MPLS label isolation, and VRF design are all security features by nature
---
> **Back to Course**: [ISP Backbone Lab Course ←](../README.md)