From 9fb54fcbd4a487dd3176d45f224d68b2010e3232 Mon Sep 17 00:00:00 2001 From: Garvis Date: Fri, 27 Feb 2026 10:28:45 -0700 Subject: [PATCH] Add all 8 course modules with converted markdown links Co-Authored-By: Claude Opus 4.6 --- modules/01-isis.md | 144 ++++++++++++++++++++++++++++++ modules/02-mpls.md | 81 +++++++++++++++++ modules/03-ibgp.md | 120 +++++++++++++++++++++++++ modules/04-l3vpn.md | 129 ++++++++++++++++++++++++++ modules/05-ebgp.md | 106 ++++++++++++++++++++++ modules/06-segment-routing.md | 86 ++++++++++++++++++ modules/07-traffic-engineering.md | 64 +++++++++++++ modules/08-attack-defense.md | 137 ++++++++++++++++++++++++++++ 8 files changed, 867 insertions(+) create mode 100644 modules/01-isis.md create mode 100644 modules/02-mpls.md create mode 100644 modules/03-ibgp.md create mode 100644 modules/04-l3vpn.md create mode 100644 modules/05-ebgp.md create mode 100644 modules/06-segment-routing.md create mode 100644 modules/07-traffic-engineering.md create mode 100644 modules/08-attack-defense.md diff --git a/modules/01-isis.md b/modules/01-isis.md new file mode 100644 index 0000000..d169e1e --- /dev/null +++ b/modules/01-isis.md @@ -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) diff --git a/modules/02-mpls.md b/modules/02-mpls.md new file mode 100644 index 0000000..99b510d --- /dev/null +++ b/modules/02-mpls.md @@ -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) diff --git a/modules/03-ibgp.md b/modules/03-ibgp.md new file mode 100644 index 0000000..7b8dd91 --- /dev/null +++ b/modules/03-ibgp.md @@ -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) diff --git a/modules/04-l3vpn.md b/modules/04-l3vpn.md new file mode 100644 index 0000000..e20c4d3 --- /dev/null +++ b/modules/04-l3vpn.md @@ -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) diff --git a/modules/05-ebgp.md b/modules/05-ebgp.md new file mode 100644 index 0000000..0e75d1d --- /dev/null +++ b/modules/05-ebgp.md @@ -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) diff --git a/modules/06-segment-routing.md b/modules/06-segment-routing.md new file mode 100644 index 0000000..e376677 --- /dev/null +++ b/modules/06-segment-routing.md @@ -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 +``` + +**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) diff --git a/modules/07-traffic-engineering.md b/modules/07-traffic-engineering.md new file mode 100644 index 0000000..ad25e14 --- /dev/null +++ b/modules/07-traffic-engineering.md @@ -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) diff --git a/modules/08-attack-defense.md b/modules/08-attack-defense.md new file mode 100644 index 0000000..bf29c74 --- /dev/null +++ b/modules/08-attack-defense.md @@ -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)