Repository navigation
Expand file tree
/
Copy pathlearn-3d.js
More file actions
65 lines (65 loc) · 7.57 KB
/
Copy pathlearn-3d.js
File metadata and controls
65 lines (65 loc) · 7.57 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
/* 3D teaching paths for the Learn tab (used by learn3d.js). One entry per Learn page id:
lab the lab whose topology is drawn (its scenario's target routers are highlighted automatically)
path routers a packet follows, in order (a router may repeat: hub and spoke goes through PE3 twice)
captions one line per router of the path, shown next to the packet while it is there
note one sentence under the view
Every path follows physical links of the lab; the captions say what the scenario changes at each hop. */
window.LEARN_3D = {
"01_weight": { lab: "01_weight", path: ["SITE-R1", "LOCAL-ISP", "INTERNET"],
captions: ["SITE-R1: weight 300 on routes from the local ISP", "LOCAL-ISP: the branch now exits here", "INTERNET (content)"],
note: "Weight lives on SITE-R1 only. It is never advertised, so HQ-EDGE and everyone else keep their own choice." },
"02_local_pref": { lab: "02_local_pref", path: ["CORE", "EDGE2", "ISP-B", "CONTENT"],
captions: ["CORE follows the LOCAL_PREF 200 it hears in iBGP", "EDGE2 sets LOCAL_PREF 200 on ISP-B routes", "ISP-B", "CONTENT"],
note: "LOCAL_PREF travels inside the AS, so one router's policy moves the exit of the whole AS, EDGE1 and CORE included." },
"03_as_path": { lab: "03_as_path", path: ["CONTENT", "ISP-B", "ENT"],
captions: ["CONTENT compares AS_PATH lengths", "ISP-B: the short path, so inbound traffic arrives here", "ENT prepends its AS three more times toward ISP-A"],
note: "A prepend makes the ISP-A path longer, so the content network chooses ISP-B to reach the enterprise." },
"04_origin": { lab: "04_origin", path: ["ISP", "EDGE2"],
captions: ["ISP: ORIGIN is equal now, so router-ID breaks the tie", "EDGE2: redistribution with set origin igp"],
note: "Redistribution gives ORIGIN incomplete (?). Setting origin igp removes EDGE2's disadvantage." },
"05_med": { lab: "05_med", path: ["ISP-W", "ISP-E", "DC-EAST"],
captions: ["ISP-W: traffic for DC-EAST's prefix", "ISP-E: MED 50 for DC-EAST's own prefix wins", "DC-EAST: the prefix's home"],
note: "Both paths come from the same neighbor AS (the enterprise), so the provider compares MED: each prefix is delivered where it lives." },
"06_next_hop": { lab: "06_next_hop", path: ["ISP", "EDGE", "CORE", "CLIENT"],
captions: ["ISP: the route starts here", "EDGE: next-hop-self, so the next hop is reachable inside the AS", "CORE (route reflector)", "CLIENT learns a route it can use"],
note: "Without next-hop-self the reflector sees the ISP link address, which the IGP does not know, and marks the route inaccessible." },
"07_atomic_aggregate": { lab: "07_atomic_aggregate", path: ["CE-LAN", "EDGE1", "ISP-A"],
captions: ["CE-LAN: the /24 networks", "EDGE1 summarises to 10.10.0.0/16 (summary-only)", "ISP-A hears the /16 with ATOMIC_AGGREGATE"],
note: "The summary loses AS_PATH detail, which is what the ATOMIC_AGGREGATE flag warns about. EDGE2 must summarise too, or the /24s leak." },
"08_aggregator": { lab: "08_aggregator", path: ["SUB-A", "HQ-EDGE", "ISP"],
captions: ["SUB-A (AS 65010)", "HQ-EDGE aggregates with as-set: AGGREGATOR names this router", "ISP sees {65010,65020} in an AS_SET"],
note: "The components come from two ASes, so as-set keeps both in the path and the atomic flag disappears." },
"09_community": { lab: "09_community", path: ["EDGE", "ISP-A", "CONTENT"],
captions: ["EDGE tags the route 65001:120 and no-export", "ISP-A honors the tag and keeps it inside its AS", "CONTENT is behind both ISPs"],
note: "A community is a request to the neighbor's policy. no-export is understood everywhere; 65001:120 only means something to ISP-A." },
"10_originator_id": { lab: "10_originator_id", path: ["C1", "RR", "C3"],
captions: ["C1 originates the prefix", "RR reflects it and adds ORIGINATOR_ID = C1", "C3 learns the route with the originator's router-ID"],
note: "The reflector stamps the router-ID of the client the route came from, so a client can reject its own route coming back." },
"11_cluster_list": { lab: "11_cluster_list", path: ["EU-1", "RR-EU", "RR-TOP", "RR-US", "US-1"],
captions: ["EU-1 originates the prefix", "RR-EU adds its cluster-ID to CLUSTER_LIST", "RR-TOP adds its own", "RR-US: a clashing cluster-ID here would drop the route", "US-1"],
note: "Every reflector adds its cluster-ID. A reflector that finds its own ID in the list discards the route, which is what a clash triggers." },
"mp_families": { lab: "12_mpls_l3vpn", path: ["PE1", "P", "PE2"],
captions: ["PE1: one BGP session to PE2 carries two families", "P: no BGP here, only labels", "PE2: IPv4 unicast and VPNv4 on the same session"],
note: "The BGP session runs between the two PEs (loopback to loopback). The core router in the middle never sees a customer route." },
"mp_vpn": { lab: "13_mpls_overlap", path: ["CE-A1", "PE1", "P", "PE2", "CE-A2"],
captions: ["10.1.0.0/24 (customer A, same prefix as B)", "PE1: VRF CUST-A, RD 65000:100, push VPN label + transport label", "P: forwards on the transport label only", "PE2: VPN label selects VRF CUST-A", "customer A site 2"],
note: "Customer B uses the same 10.1.0.0/24 through the same routers: its RD, route-target and label are different, so the two never mix." },
"12_mpls_l3vpn": { lab: "12_mpls_l3vpn", path: ["CE1", "PE1", "P", "PE2", "CE2"],
captions: ["CE1: an ordinary IP packet", "PE1: push VPN label 19 and transport label 17", "P: acts on the transport label only", "PE2: VPN label 19 selects VRF CUST", "CE2: an ordinary IP packet again"],
note: "Labels 19 and 17 are the ones captured from this lab. The scenario mistypes PE2's import route-target, which removes the route at PE2." },
"13_mpls_overlap": { lab: "13_mpls_overlap", path: ["CE-A1", "PE1", "P", "PE2", "CE-A2"],
captions: ["customer A site 1", "PE1: VRF CUST-A (RD/RT 65000:100)", "P", "PE2: exports customer B with A's route-target too, the leak", "customer A site 2, and now B's 10.3.0.0/24 as well"],
note: "One extra export route-target on PE2 makes customer B's second site appear in customer A's VRF." },
"14_mpls_shared_services": { lab: "14_mpls_shared_services", path: ["CE-B", "PE1", "P", "PE2", "CE-SVC"],
captions: ["customer B", "PE1: VRF CUST-B now imports 65000:900", "P", "PE2: VRF SHARED exports 65000:900", "the shared service"],
note: "Both directions need a route-target match. The scenario adds the customer's half, import 65000:900." },
"15_mpls_hub_spoke": { lab: "15_mpls_hub_spoke", path: ["CE-S2", "PE2", "P", "PE3", "CE-HUB", "PE3", "P", "PE1", "CE-S1"],
captions: ["spoke 2 sends to spoke 1", "PE2: only the hub's summary 10.0.0.0/8 matches", "P", "PE3: VRF HUB-IN receives it", "the firewall inspects it", "PE3: VRF HUB-OUT sends it back", "P", "PE1", "spoke 1"],
note: "The scenario adds one import route-target on PE2: spoke 2 then learns spoke 1 directly and this detour through the firewall disappears." },
"16_mpls_vpnv4_rr": { lab: "16_mpls_vpnv4_rr", path: ["CE1", "PE1", "RR", "PE4", "CE4"],
captions: ["CE1", "PE1 learned PE4's route from the reflector", "RR: reflects VPNv4 routes, holds no VRF", "PE4: the next hop stays the originating PE", "CE4"],
note: "In this lab the reflector is also the core router. The scenario takes client status from PE1 and PE4, so they stop hearing each other." },
"17_mpls_as_override": { lab: "17_mpls_as_override", path: ["CE1", "PE1", "P", "PE2", "CE2"],
captions: ["CE1 (AS 65100)", "PE1", "P", "PE2: as-override rewrites 65100 to 65000 toward CE2", "CE2 (AS 65100) accepts AS_PATH 65000 65000"],
note: "Without the fix, CE2 sees its own AS 65100 in the path 65000 65100 and drops the route as a loop." },
};