You need no experience for this lab. Open R1’s console, climb from user EXEC to privileged EXEC to configuration mode, give one interface an IP address, switch the interface on, and prove it works with a ping.
R1 is already working, so nothing here can break it. Practise moving: up with enable and configure terminal, one level back with exit, all the way out with end, and running a show command from inside configuration mode with do.
What you type changes the running configuration, which lives in memory and is lost when the router restarts. Name R1, set up its interface, save, restart it, and watch your work come back.
A switch joins the devices of one network. It needs no IP address to do that. Give both PCs an address on the same network, ping between them, then look inside the switch to see how it learned where they are.
A switch joins devices on one network. A router joins different networks. PC1 and PC2 have addresses on different networks and no way out. Set up R1 between them, then tell each PC where its way out is: its default gateway.
A router only knows the networks it touches. R1 and R2 each have one network the other has never heard of. Teach each router the way there with a static route, then deliver a ping from PC1 to PC2.
All three PCs use the same network, and by default they could all talk. Put PC1 and PC3 in VLAN 10, PC2 in VLAN 20, and carry both VLANs between the switches on a trunk. PC2 is then cut off, even though nothing changed on the PCs.
You need no experience for this lab. Open R1’s console, move from the user view into the system view, give one interface an IP address, switch the interface on, and prove it works with a ping.
R1 is already working, so nothing here can break it. Practise moving: into the system view, into an interface view, one level back with quit, and all the way out with return.
What you type changes the running configuration, which lives in memory and is lost when the router restarts. Name R1, set up its interface, save, restart it, and watch your work come back.
A switch joins the devices of one network. It needs no IP address to do that. Give both PCs an address on the same network, ping between them, then look inside the switch to see how it learned where they are.
A switch joins devices on one network. A router joins different networks. PC1 and PC2 have addresses on different networks and no way out. Set up R1 between them, then tell each PC where its way out is: its default gateway.
A router only knows the networks it touches. R1 and R2 each have one network the other has never heard of. Teach each router the way there with a static route, then deliver a ping from PC1 to PC2.
All three PCs use the same network, and by default they could all talk. Put PC1 and PC3 in VLAN 10, PC2 in VLAN 20, and carry both VLANs between the switches on a trunk. PC2 is then cut off, even though nothing changed on the PCs.
Connect a Cisco branch to a Huawei branch. Interfaces and hosts are ready; add a static route in each direction to deliver the first ping.
Build single-area OSPF between three routers. Then adjust interface costs to choose between the direct path and the path through R3. This is a simplified routing exercise.
PC1 and PC2 share VLAN 10 on different switches. Move the host ports into VLAN 10 and configure a trunk between Cisco and Huawei. SW2 starts with its host port in VLAN 20, so connectivity is broken.
Configure the XR branch using a candidate configuration. Verify that nothing changes until commit, then route to the Huawei branch.
Build directly connected IPv4 eBGP between Cisco AS 65001 and Huawei AS 65002. Advertise each branch LAN, then check the AS path.
Exchange branch prefixes between IOS XR and Huawei. Apply an explicit pass policy in both directions on XR, then commit.
Both branch routers run Huawei VRP-style CLI. Configure static routes using system-view and verify two-way reachability.
Routing already works. Create an ICMP deny policy on R1, observe the failed ping, then remove the binding and restore reachability.
Harden R1 the Cisco way: hostname, enable secret, console and VTY passwords, a banner and SSH with local users. Save when done.
PC1 (VLAN 10) and PC2 (VLAN 20) share one switch. Route between the VLANs with 802.1Q subinterfaces on R1 over a single trunk. R1 G0/0 starts shut down.
Route between VLAN 10 and VLAN 20 inside the switch using switched virtual interfaces. Cisco switches route only after ip routing.
Three switches form a loop. Spanning tree blocks one port. Choose the root bridge deliberately, run the rapid protocol and mark host ports as edge ports.
Two parallel links join SW1 and SW2. Bundle them with LACP so both links forward, then carry VLAN 10 across the bundle as a trunk.
R1 serves addresses for both LANs. PC2 sits behind R2, so R2 must relay its broadcast to R1. Routing between the routers is already in place.
The ISP has no route back to 192.168.10.0/24. Give R1 a default route and translate the inside hosts to its public address so replies return.
PC1 uses 192.168.10.1 as its gateway, but no router owns that address yet. R1 and R2 share it as a virtual IP. R1 is preferred; when its uplink fails, R2 takes over. OSPF already runs on all three routers.
LAN B (192.168.20.0/24) must not reach the server; LAN A still must. A standard ACL only matches the source, so apply it close to the destination: outbound on the server interface.
Four routers share one Ethernet segment, so OSPF elects a designated router (DR) and a backup (BDR). Router IDs 1.1.1.1–4.4.4.4 make R4 the default DR. Use interface priorities to choose your own.
R1 sits in area 1, R3 in the backbone, and R2 is the area border router. Build the areas, then summarize area 1’s 172.16.x networks at the ABR.
Three Cisco routers form a triangle. Run EIGRP, slow down the direct R1–R3 link and find the successor and the loop-free backup (feasible successor) R1 keeps for 192.168.3.0/24. EIGRP is Cisco-proprietary; Huawei VRP does not run it.
R1 runs EIGRP, R3 runs OSPF, and R2 runs both. Redistribute in both directions on R2 so each side learns the other as external routes.
R1 (AS 65001) peers with R2 over eBGP. R2 and R3 (AS 65002) form iBGP between loopbacks; OSPF inside AS 65002 already carries the loopbacks. R3 will learn R1’s network with an unreachable next hop until R2 changes it.
R1 (AS 65001) is dual-homed to ISP-A (R2, AS 65002) and ISP-B (R3, AS 65003). Both reach 8.8.8.0/24 in AS 65004. Send outbound traffic via ISP-B with local preference, and pull inbound traffic to ISP-A by prepending your AS toward ISP-B.
PC1 uses 192.168.10.1 as its gateway, but no router owns that address yet. R1 and R2 share it as a virtual IP. R1 is preferred; when its uplink fails, R2 takes over. OSPF already runs on all three routers.
OSPF is configured on all three routers, but PC1 cannot reach PC2. Three configuration faults stop the adjacencies. Find them with the neighbor and interface show commands; the RouteBuddy diagnostic lines point at mismatches.
Harden R1 the Huawei way: system name, console password, AAA users, SSH-only VTY access and a login header. Save when done.
PC1 (VLAN 10) and PC2 (VLAN 20) share one switch. Route between the VLANs with 802.1Q subinterfaces on R1 over a single trunk. Huawei dot1q termination subinterfaces also need arp broadcast enable.
Route between VLAN 10 and VLAN 20 inside the switch using VLANIF interfaces. Huawei switches route between VLANIFs by default.
Three switches form a loop. Spanning tree blocks one port. Choose the root bridge deliberately, run the rapid protocol and mark host ports as edge ports.
Two parallel links join SW1 and SW2. Bundle them with LACP so both links forward, then carry VLAN 10 across the bundle as a trunk.
R1 serves addresses for both LANs. PC2 sits behind R2, so R2 must relay its broadcast to R1. Routing between the routers is already in place.
The ISP has no route back to 192.168.10.0/24. Give R1 a default route and translate the inside hosts to its public address so replies return.
PC1 uses 192.168.10.1 as its gateway, but no router owns that address yet. R1 and R2 share it as a virtual IP. R1 is preferred; when its uplink fails, R2 takes over. OSPF already runs on all three routers.
LAN B (192.168.20.0/24) must not reach the server; LAN A still must. A basic ACL only matches the source, so apply it close to the destination: outbound on the server interface.
Three Huawei routers in a chain. Run RIP version 2, advertise the classful networks, disable summarization and keep updates off the host LANs.
Build OSPF area 0 across three Huawei routers with fixed router IDs, keep the host LAN silent, and let edge router R3 advertise a default route toward the ISP.
Four routers share one Ethernet segment, so OSPF elects a designated router (DR) and a backup (BDR). Router IDs 1.1.1.1–4.4.4.4 make R4 the default DR. Use interface priorities to choose your own.
R1 sits in area 1, R3 in the backbone, and R2 is the area border router. Build the areas, then summarize area 1’s 172.16.x networks at the ABR and turn area 1 into a totally stubby area.
R1 runs RIP, R3 runs OSPF and R2 runs both. Use import-route on R2 in both directions so each domain learns the other.
R1 (AS 65001) peers with R2 over eBGP. R2 and R3 (AS 65002) form iBGP between loopbacks; OSPF inside AS 65002 already carries the loopbacks. R3 will learn R1’s network with an unreachable next hop until R2 changes it.
R1 (AS 65001) is dual-homed to ISP-A (R2, AS 65002) and ISP-B (R3, AS 65003). Both reach 8.8.8.0/24 in AS 65004. Send outbound traffic via ISP-B with local preference, and pull inbound traffic to ISP-A by prepending your AS toward ISP-B.
Two parallel links join SW1 and SW2. Bundle them with LACP so both links forward, then carry VLAN 10 across the bundle as a trunk. LACP is a standard, so a Cisco port-channel and a Huawei Eth-Trunk interoperate.
PC1 uses 192.168.10.1 as its gateway, but no router owns that address yet. R1 and R2 share it as a virtual IP. R1 is preferred; when its uplink fails, R2 takes over. VRRP is a standard, so Cisco and Huawei routers can form one group. OSPF already runs on all three routers.
R1 runs EIGRP, R3 runs OSPF on Huawei VRP (which has no EIGRP), and R2 runs both. Redistribute in both directions on R2 so each side learns the other as external routes.
R1 (AS 65001) peers with R2 over eBGP. R2 and R3 (AS 65002) form iBGP between loopbacks; OSPF inside AS 65002 already carries the loopbacks. R3 will learn R1’s network with an unreachable next hop until R2 changes it.
OSPF is configured on all three routers, but PC1 cannot reach PC2. Three configuration faults stop the adjacencies. Find them with the neighbor and interface show commands; the RouteBuddy diagnostic lines point at mismatches.
A Cisco access switch, a Huawei core switch that routes and hands out addresses, a Cisco edge router with PAT, and a Huawei ISP. Build every layer so both VLANs get DHCP leases and reach 8.8.8.8.
Bring IPv6 up between two branches. Address both routers, fix a link-local address for a clean next hop, add static routes both ways, and let PC1 configure itself from router advertisements (SLAAC).
Bring IPv6 up between two branches. Address both routers, fix a link-local address for a clean next hop, add static routes both ways, and let PC1 configure itself from router advertisements (SLAAC).
IPv6 addressing is in place; the routers have no IPv4 at all. Run OSPFv3 with area 0 between R1 and R2 and area 1 between R2 and R3. Neighbors form over link-local addresses, and the router ID still has to be a 32-bit value.
IPv6 addressing is in place; the routers have no IPv4 at all. Run OSPFv3 with area 0 between R1 and R2 and area 1 between R2 and R3. Neighbors form over link-local addresses, and the router ID still has to be a 32-bit value.
IPv4 and OSPFv2 already run across Cisco R1, Huawei R2 and Cisco R3. Add IPv6 next to it and run OSPFv3 across both vendors. The Cisco routers borrow their IPv4 router ID; Huawei needs one configured.
Service providers run IS-IS in the core. Give three routers a NET, run them as one Level-2 backbone, advertise each router’s loopback, and confirm R1 learns R3’s loopback through IS-IS.
IS-IS already connects PE1, P and PE2. Turn the core into an MPLS network: give each router an LDP identity, enable LDP on the core links, check the sessions and labels, and follow the label-switched path from PE1 to PE2’s loopback.
A customer in AS 65100 connects to your PE in AS 65000. Bring up eBGP, send the customer your Internet prefix, and accept only the customer’s own /24, even though the CE also advertises a private 10.99.0.0/16 by mistake.
Build a two-area IS-IS design. R1 is a Level-1 router in area 49.0001, R2 is the Level-1-2 border of that area, and R3 sits in the Level-2 backbone in area 49.0002. R1 never learns the backbone’s routes: it follows the default route that R2’s ATT bit creates.
Three PEs hang off one core router, and IS-IS already carries the loopbacks. Instead of a full iBGP mesh, every PE peers only with the route reflector, and the RR reflects each customer prefix to the other PEs with the original next hop.
The provider core already runs IS-IS and LDP. Connect customer A’s two sites through it: create the VRF on both PEs, attach the CE links, carry the customer routes in MP-BGP VPNv4 between the PE loopbacks, and prove the P router never sees a customer route.
Customer A’s VPN was handed over “finished”, but CE1 cannot reach 192.168.2.1. Three faults are hidden in the core and on PE2. Use the VPN, BGP and MPLS show commands to find each one, fix it, and prove the service works.
Build a two-area IS-IS design. R1 is a Level-1 router in area 49.0001, R2 is the Level-1-2 border of that area, and R3 sits in the Level-2 backbone in area 49.0002. R1 never learns the backbone’s routes: it follows the default route that R2’s ATT bit creates.
IS-IS already connects PE1, P and PE2. Turn the core into an MPLS network: give each router an LDP identity, enable LDP on the core links, check the sessions and labels, and follow the label-switched path from PE1 to PE2’s loopback.
Three PEs hang off one core router, and IS-IS already carries the loopbacks. Instead of a full iBGP mesh, every PE peers only with the route reflector, and the RR reflects each customer prefix to the other PEs with the original next hop.
The provider core already runs IS-IS and LDP. Connect customer A’s two sites through it: create the VPN instance on both PEs, attach the CE links, carry the customer routes in MP-BGP VPNv4 between the PE loopbacks, and prove the P router never sees a customer route.
Customer A’s VPN was handed over “finished”, but CE1 cannot reach 192.168.2.1. Three faults are hidden in the core and on PE2. Use the VPN, BGP and MPLS show commands to find each one, fix it, and prove the service works.
The provider core already runs IS-IS and LDP. Connect customer A’s two sites through it: create the VRF on both PEs, attach the CE links, carry the customer routes in MP-BGP VPNv4 between the PE loopbacks, and prove the P router never sees a customer route. PE1 runs Cisco IOS and PE2 runs Huawei VRP: the RD and route targets must still match.
IS-IS sends PE1’s traffic for PE2 over the short top path through P1, but those links can reserve only 50 Mbps. Build an MPLS TE tunnel that asks for 100 Mbps: CSPF must find the bottom path through P2 and P3, RSVP signals it, and autoroute announce puts PE1’s traffic into it. P1, P2, P3 and PE2 already run MPLS TE.
Every router runs MPLS TE. Pin Tunnel1 to the top path through P1 with a strict explicit path, and keep a dynamic path option as the fallback. The top links can reserve only 50 Mbps, so the tunnel first comes up on the fallback. Raise the RSVP bandwidth along the top path and watch the tunnel move back to its preferred path option.
Tunnel1 on PE1 should run over the bottom path (P2, P3) on explicit path BOTTOM, but it stays down and PE1’s traffic still takes the IGP path. Read the tunnel’s failure reason, fix each fault, and bring the tunnel up.
IS-IS sends PE1’s traffic for PE2 over the short top path through P1, but those links can reserve only 50 Mbps. Build an MPLS TE tunnel that asks for 100 Mbps: CSPF must find the bottom path through P2 and P3, RSVP signals it, and autoroute announce puts PE1’s traffic into it. P1, P2, P3 and PE2 already run MPLS TE.
Every router runs MPLS TE. Pin tunnel-te1 to the top path through P1 with a strict explicit path, and keep a dynamic path option as the fallback. The top links can reserve only 50 Mbps, so the tunnel first comes up on the fallback. Raise the RSVP bandwidth along the top path and watch the tunnel move back to its preferred path option.
tunnel-te1 on PE1 should run over the bottom path (P2, P3) on explicit path BOTTOM, but it stays down and PE1’s traffic still takes the IGP path. Read the tunnel’s failure reason, fix each fault, and bring the tunnel up.
Replace label distribution by LDP with segment routing. IS-IS already runs on all five routers. Give each router a prefix-SID on its Loopback0 (index = router number) and turn segment routing on in IS-IS. Every router then programs label 16000 + index toward each loopback, and PE1 reaches PE2 on an SR label-switched path, with no LDP anywhere.
Segment routing was rolled out on the core, but PE1 has no SR label-switched path to PE2. Two faults hide in the configuration. Use the label tables and SID tables to find them.
The core runs segment routing, and the top path through P1 has TE metric 100 per link. PE2 advertises two customer LANs over iBGP. Mark LAN 20 with the BGP color 10. On PE1, build SR-TE policy GREEN for color 10 toward PE2: a dynamic candidate on the TE metric, then an explicit one. Traffic to LAN 20 rides the policy; LAN 10 has no color and keeps the default path, the IGP shortest path through P1.
No BGP route carries a color here. To move PE1’s traffic for PE2 onto the bottom path anyway, build an SR-TE policy with an explicit segment list through P2 and P3 and let autoroute include all steer every route through PE2 into it, as autoroute announce does for an RSVP-TE tunnel.
Policy GREEN on PE1 should carry the traffic for LAN 20 (color 10) over P2 and P3, but PC1’s traffic to PC3 still takes the default path through P1. The policy is up. Find out why no route is steered into it, and fix both faults.
Three providers carry one end-to-end LSP between PE1 (ISP1, AS 6001, IOS XE) and PE3 (ISP3, AS 6003, IOS XR), across the transit provider ISP2 (AS 6002, IOS XR). Each ISP runs its own IS-IS and LDP, and nothing of that crosses the borders. Stitch them with BGP labeled unicast: iBGP inside each ISP, eBGP between the border routers. ISP2’s P2 runs no BGP at all; it forwards the traffic only because it is label-switched.
BGP labeled unicast is configured across ISP1 (AS 6001, IOS XE), ISP2 (AS 6002, IOS XR) and ISP3 (AS 6003, IOS XR), but PE1 and PE3 still cannot reach each other’s loopbacks over a label-switched path. One fault breaks each direction. Use the BGP label tables on the border routers to find them.
The network is split into three IS-IS domains: area 49.0001 (PE1, ABR1), the Level-2 core (P) and area 49.0003 (ABR2, PE2). LDP runs everywhere, but a Level-1 PE only has a default route toward its ABR, so LDP cannot build a path from PE1 to PE2’s loopback. Stitch the domains with BGP labeled unicast. Each PE advertises its loopback with a label to its ABR. The ABRs reflect the routes with next-hop-self, so every BGP next hop stays inside one LDP domain.
BGP labeled unicast is configured across the three IS-IS domains, but PE1 still has no label-switched path to PE2’s loopback. Two faults are left: one on ABR1 and one on PE1. Find them from the BGP label tables and fix them.
Every core router runs LDP, segment routing and MPLS TE at the same time. That is how operators migrate from LDP to SR. Check which transport PE1 uses for PE2’s loopback, make SR the preferred one, and then put an RSVP-TE tunnel with autoroute announce on top. The tunnel wins over both, because autoroute rewrites the route itself.
The network is split into three IS-IS domains: area 49.0001 (PE1, ABR1), the Level-2 core (P) and area 49.0003 (ABR2, PE2). LDP runs everywhere, but a Level-1 PE only has a default route toward its ABR, so LDP cannot build a path from PE1 to PE2’s loopback. Stitch the domains with BGP labeled unicast. Each PE advertises its loopback with a label to its ABR. The ABRs reflect the routes with next-hop-self, so every BGP next hop stays inside one LDP domain.
BGP labeled unicast is configured across the three IS-IS domains, but PE1 still has no label-switched path to PE2’s loopback. Two faults are left: one on ABR1 and one on PE1. Find them from the BGP label tables and fix them.
Every core router runs LDP, segment routing and MPLS TE at the same time. That is how operators migrate from LDP to SR. Check which transport PE1 uses for PE2’s loopback, make SR the preferred one, and then put an RSVP-TE tunnel with autoroute announce on top. The tunnel wins over both, because autoroute rewrites the route itself.
Replace label distribution by LDP with segment routing. IS-IS already runs on all five routers. Give each router a prefix-SID on its Loopback0 (index = router number) and turn segment routing on in IS-IS. Every router then programs label 16000 + index toward each loopback, and PE1 reaches PE2 on an SR label-switched path, with no LDP anywhere.
Segment routing was rolled out on the core, but PE1 has no SR label-switched path to PE2. Two faults hide in the configuration. Use the label tables and SID tables to find them.
The core runs segment routing, and the top path through P1 has TE metric 100 per link. PE2 advertises two customer LANs over iBGP. Mark LAN 20 with the BGP color 10. On PE1, build SR-TE policy GREEN for color 10 toward PE2: a dynamic candidate on the TE metric, then an explicit one. Traffic to LAN 20 rides the policy; LAN 10 has no color and keeps the default path, the IGP shortest path through P1.
No BGP route carries a color here. To move PE1’s traffic for PE2 onto the bottom path anyway, build an SR-TE policy with an explicit segment list through P2 and P3 and let autoroute include all steer every route through PE2 into it, as autoroute announce does for an RSVP-TE tunnel.
Policy GREEN on PE1 should carry the traffic for LAN 20 (color 10) over P2 and P3, but PC1’s traffic to PC3 still takes the default path through P1. The policy is up. Find out why no route is steered into it, and fix both faults.
Two Nokia SR Linux leaves connect two host subnets over a /31 link. On SR Linux an address works only when its subinterface has IPv4 enabled and belongs to a network-instance. Set that up, add a static route each way with a next-hop group, and commit.
Two spines (AS 65000) and two leaves (AS 65101, 65102) run SR Linux, and every link is addressed and in network-instance default. Build the eBGP underlay. SR Linux rejects every eBGP route in and out until a policy allows it, so the policies are part of the job.
A Nokia SR Linux leaf (AS 65101) peers with an Arista leaf (AS 65102) over a /31. Both links and hosts are addressed. Bring up eBGP so each side learns the other host subnet. Arista accepts and advertises by default; SR Linux needs policies.
Two Nokia 7750 SR routers connect two LANs. SR OS ports start administratively down and nothing changes until you commit. Enable the ports, create the router interfaces, add a static route each way and commit.
Three SR OS routers in a chain are addressed, with system interfaces 1.1.1.1–3.3.3.3. The refreshed NRS I uses IS-IS rather than OSPF: run IS-IS instance 0 in area 49.0001 as Level 2, keep the system and LAN interfaces passive, and let PC1 reach PC2.
R1 (AS 65001) and R2 (AS 65002) are addressed. Bring up eBGP with a peer group, and advertise each LAN. On SR OS, BGP advertises nothing local until an export policy accepts it, so build a prefix list and a policy statement too.
PE1, P and PE2 already run IS-IS. Build label-switched paths between the PE system addresses: run LDP on every core interface, check the sessions, and find PE2’s system address in PE1’s tunnel table.
PE1 and PE3 hang off RR, and IS-IS carries all system addresses. Instead of a full mesh, every PE peers only with RR between system addresses, and RR reflects each customer LAN to the other PE with the original next hop.
The core already runs IS-IS and LDP. Connect customer A’s two sites with a VPRN service: iBGP VPN-IPv4 between the PEs, the service with its route distinguisher and route target, a SAP towards each CE, and a static route to each customer LAN. P never sees a customer route.
A Nokia 7750 SR and a Huawei router are addressed. Run IS-IS Level 2 in area 49.0001 between them, in each vendor’s own syntax, and let the LANs reach each other. Both derive nothing automatically except Nokia’s system ID.
Two OmniSwitches each have a host that belongs in VLAN 10. AOS has no configuration mode: you create the VLAN and assign ports to it with global vlan … members commands. The host ports are untagged members; the link between the switches is a tagged (802.1Q) member.
One OmniSwitch connects a host in VLAN 10 and a host in VLAN 20. On AOS you route between VLANs by binding a named IP interface to each VLAN; routing between IP interfaces is on by default.
Two OmniSwitches are joined over VLAN 100 and each has a host LAN. The VLANs and ports are already set. Give each switch its IP interfaces and add a static route in each direction.
Three OmniSwitches in a chain already have their VLANs and IP interfaces. Run OSPF area 0.0.0.0 on every IP interface so PC1 can reach PC2. On AOS the OSPF software must be loaded before it can be configured, and the protocol, the area binding and each interface are all enabled separately.
Two OmniSwitches are joined by two links (1/1/1 and 1/1/3). Bundle them into LACP link aggregate 1, so they act as one logical link, and carry VLAN 10 over the aggregate tagged. The host ports are already untagged in VLAN 10.
An OmniSwitch serves a campus LAN and hands off to a Cisco router over VLAN 100. The switch VLANs are already set. Address both sides and run OSPF area 0 so the two LANs learn about each other.
Two Arista switches each have a host. Put both host ports in VLAN 10 and carry it over an 802.1Q trunk between the switches. LEAF2 starts with its host port in VLAN 20, so the ping fails until you fix it.
One Arista switch connects a host in VLAN 10 and a host in VLAN 20. Route between them inside the switch with VLAN interfaces (SVIs). Like Cisco, EOS routes only after ip routing.
Two Arista switches act as routers between two LANs. Turn the links into routed ports, address them in prefix notation, and add a static route in each direction.
Three Arista switches are routed in a chain and already addressed. Run OSPF area 0 with fixed router IDs, keep the host LANs passive, and let OSPF find the far LAN.
A small leaf-spine fabric: two spines in AS 65000 and two leaves in AS 65101 and 65102. The point-to-point links are addressed. Build the eBGP underlay so each leaf learns the other leaf’s host subnet through both spines.
Two Arista distribution switches are joined by two links and share the users’ gateway. Bundle the links into a LACP port-channel that trunks VLAN 10, give each switch an SVI, and run VRRP so 192.168.10.1 stays up if one switch fails. DIST1 must be master.
An Arista data-center leaf (AS 65101) hands off to a Cisco WAN router (AS 65000). Address the link in each vendor’s own syntax, bring up eBGP, and exchange the two LANs. The router interfaces start shut down on the Cisco side.
SRC streams to group 239.1.1.1. OSPF is already running. Turn on multicast routing and PIM dense mode, let PC3 join the group, and watch dense mode flood the stream everywhere and then prune the branch toward R4, where nobody joined.
Sparse mode sends a stream only where it is requested. Make R2’s Loopback0 (2.2.2.2) the rendezvous point for every group, have PC3 and PC4 join 239.1.1.1, and follow the stream from the shared tree through the RP to the shortest-path tree.
Sparse mode is running, but no router knows an RP, so PC3’s join goes nowhere. Instead of typing the RP on every router, make R2 the bootstrap router (BSR) and R4’s Loopback0 the candidate RP. The BSR floods the RP to every PIM router.
With SSM there is no RP at all: the receiver names the source it wants, and its router joins that source directly. Enable SSM for 232.0.0.0/8, give PC3’s LAN IGMPv3 so it can name a source, and receive (10.1.1.10, 232.1.1.1).
Sparse mode with RP 2.2.2.2 is configured and PC3 and PC4 have joined 239.1.1.1, yet neither receives the stream. Use the RPF and PIM show commands to find the two faults and fix them.
Two PIM sparse-mode domains each keep their own RP: R2 (2.2.2.2) for domain A, where SRC sends, and R3 (3.3.3.3) for domain B, where PC4 has joined 239.1.1.1. RP-B never hears about SRC, so PC4 gets nothing. Peer the two RPs with MSDP so RP-A announces the source in a Source-Active message and RP-B joins it across the border.
RP-A (R2) and RP-B (R3) are configured as MSDP peers, but PC4 in domain B still receives nothing from SRC. Find out why the MSDP session stays down and fix it.
Three Huawei routers run OSPF. Turn on multicast, run PIM-DM on every routed interface, and enable IGMP on R3’s LAN so PC3 can join 239.1.1.1. Huawei runs IGMP only on interfaces where it is enabled, separately from PIM.
Run PIM sparse mode on three Huawei routers and use R2’s LoopBack0 (2.2.2.2) as the static RP, configured in the PIM view. PC3 joins 239.1.1.1 and SRC streams to it.
On VRP the range 232.0.0.0/8 is source-specific by default, so no RP is needed. Run PIM-SM, enable IGMPv3 on R3’s LAN, and let PC3 receive the channel (10.1.1.10, 232.1.1.1).
IOS XR turns on PIM and IGMP together: multicast-routing with interface all enable runs both on every interface. Add the static RP under router pim, commit, and stream 239.1.1.1 to PC3.
On IOS XR, 232.0.0.0/8 is SSM and IGMPv3 is the default, so enabling multicast is all it takes for a source-specific channel. No RP is configured.
Three Arista switches route with OSPF. On EOS multicast routing lives under router multicast, PIM is enabled per interface with pim ipv4 sparse-mode (which also enables IGMP), and the RP is set under router pim sparse-mode.
EOS answers IGMPv3 by default, but treats 232/8 as SSM only once you say so: ssm range standard under router pim sparse-mode. Build the channel (10.1.1.10, 232.1.1.1) without any RP.
Three 7750 SRs run OSPF. Add the router interfaces to PIM, set R2’s system address 2.2.2.2 as the static RP, and enable IGMP on R3’s LAN interface. SR OS runs IGMP only on interfaces listed under igmp.
SR OS treats 232.0.0.0/8 as SSM and speaks IGMPv3 by default. Add the interfaces to PIM, IGMP on R3’s LAN, and receive (10.1.1.10, 232.1.1.1) with no RP.
On SR Linux, PIM and IGMP are protocols of the network-instance, enabled per subinterface with admin-state enable. Make 2.2.2.2 (R2’s system0) the static rendezvous point.
SR Linux’s default SSM range is 232.0.0.0/8 and its IGMP default is version 3. Enable PIM and IGMP and receive the channel (10.1.1.10, 232.1.1.1) without an RP.
Three OmniSwitches route between VLAN IP interfaces with OSPF. On AOS, IGMP (IPMS) is switched on globally, PIM is loaded, each IP interface is added to PIM, and then dense mode is enabled.
Run PIM sparse mode on three OmniSwitches with SW2’s "to-sw1" address (10.0.12.2) as the static RP for 224.0.0.0/4.
R1 is a Cisco router (Loopback0 1.1.1.1), R2 a Huawei router and R3 an Arista switch, all running OSPF. Build one PIM sparse-mode domain with the Cisco loopback as the RP, each device in its own syntax.
A Nexus switch routes between two VLANs. NX-OS hides the SVI commands until feature interface-vlan is enabled, routing is always on (there is no ip routing), and addresses are written in prefix form.
Two Nexus switches are joined by a routed link (Ethernet1/1, 10.0.12.0/30); each has a routed LAN port on Ethernet1/2. Run OSPF the NX-OS way: there is no network statement, each interface joins the process itself.
N1 and N2 both carry VLAN 10 (SVIs 192.168.10.2 and .3 are configured). Give PC1 one gateway, 192.168.10.1, that survives the loss of either switch. NX-OS configures HSRP in its own sub-mode under the SVI.
Two Nexus switches are cabled with Ethernet1/3 and Ethernet1/4. Bundle both links into port-channel 10 with LACP and carry VLAN 10 over it as a trunk, so PC1 and PC2 (both in VLAN 10) can reach each other over both links.
NX-OS has no ip multicast-routing: feature pim turns multicast on. Run PIM sparse mode on both switches with N1’s Loopback0 (1.1.1.1) as the static RP, and stream 239.1.1.1 from SRC to PC3.
NX-OS treats 232.0.0.0/8 as SSM by default, so no RP is needed. The receiver joins a specific source, which needs IGMPv3 on its SVI-facing port (NX-OS defaults to IGMPv2).
SW3 already bundles its two uplinks into Port-channel10 with LACP, one to N1 and one to N2. Without vPC that bundle cannot form across two switches. Turn N1 and N2 into a vPC pair so SW3 sees one partner and forwards on both links.
The vPC domain is up: N1 is primary, N2 secondary, and SW3 forwards on both uplinks. PC3 hangs off N1 and PC2 off N2 on single, non-vPC ports. Break the peer-link and watch what each switch does while the keepalive is still alive.
The vPC domain is formed, but vPC 10 is only half working: SW3 bundles just one uplink, so all its traffic squeezes through N1. Find the mismatch with the consistency checker and fix it.
N1 and N2 have a vPC domain, a working peer-link and vPC 10, yet show vpc says the peer adjacency is not formed and SW3 bundles neither uplink. The keepalive is cabled on Ethernet1/8 and both ends have addresses. Find out why the peers cannot hear each other, and fix it without moving the cable.
The vPC domain is formed, but vPC 10 is suspended on N2 and SW3 bundles only its N1 uplink. Every per-vPC parameter matches. Look at the parameters the two peers must share for the whole domain.
The vPC pair works, but each peer is still its own spanning-tree bridge: whichever wins is the root, and if it fails SW3 has to elect a new one. With peer-switch both peers send the same bridge ID, so the pair itself is the root and losing a peer changes nothing for spanning tree.
N1 (192.168.10.2, 192.168.20.2) and N2 (.3) route between VLAN 10 and VLAN 20 with plain SVIs, no HSRP. PC1 uses N2’s own address 192.168.10.3 as its gateway. PC1 and PC4 sit behind the same vPC on SW3, yet PC1 cannot reach PC4 (192.168.20.40). Find out why, and fix it in the vPC domain.
Two data centers both use VLAN 10 (192.168.10.0/24), but they are joined only by a routed core. Extend VLAN 10 between them with OTV in unicast-only mode, so PCA reaches PCB at Layer 2 while spanning tree stays inside each site.
The core router already runs PIM sparse mode with 3.3.3.3 as the RP. Use it as the OTV control plane: the edges find each other through a shared control group instead of an adjacency server.
OTV is configured on both data centers and the overlay adjacency is up, yet PCA cannot reach PCB. Find out why the edges refuse to extend VLAN 10 to each other and fix it.
Two spines and two leaves are cabled as a full mesh. With classic spanning tree half of those links would be blocked. Build a FabricPath fabric instead: every link forwards, and each leaf reaches the other over both spines.
SW3 is a classic Ethernet switch with one uplink to each leaf. The FabricPath edge switches act as one spanning-tree bridge (c84c.75fa.6000) toward it, but SW3 currently has the better bridge ID, so the leaves block their edge ports and PC3 is cut off. Make the fabric the root.
SW3 bundles its two uplinks into Port-channel20 with LACP, one to each leaf. Inside a FabricPath fabric the leaves pair up with vPC+: a vPC domain whose peer-link is a FabricPath port and which is known to the rest of the fabric as one emulated switch-id.
The fabric is cabled and FabricPath is enabled everywhere, yet PC1 cannot reach PC2. There are two faults. Find them with the FabricPath show commands and fix them.
L1 and L2 are leaves joined only by a routed underlay (OSPF through S1). Both have hosts in VLAN 10. Stretch VLAN 10 across the underlay with VXLAN: map it to VNI 10010 and replicate broadcast and unknown traffic to the other VTEP by unicast.
The underlay already runs PIM sparse mode on every link and loopback, with S1 (3.3.3.3) as the RP. Let the underlay replicate VNI 10010’s broadcast and unknown traffic: both leaves join one multicast group for the VNI.
Replace flood-and-learn with a control plane. S1 becomes an iBGP route reflector for the L2VPN EVPN address family; each leaf advertises its VNI (a type-3 route) and its hosts (type-2 routes), and the leaves find each other from those routes.
BGP EVPN is configured on the fabric and every BGP session is up, but the leaves do not list each other as NVE peers and PC1 cannot reach PC2. There are two faults, one on each leaf.
The BGP EVPN fabric carries VLAN 10 (VNI 10010) on L1 and VLAN 20 (VNI 10020) on L2, but nothing routes between them. Add a tenant VRF with a Layer 3 VNI: each leaf is the anycast gateway of its subnet, and traffic between subnets is routed into VNI 50000, carried to the other leaf and routed again there (symmetric IRB).
L2 is also the border leaf: in VRF TENANT it reaches an outside network, stood in for by loopback100 (10.100.100.0/24). Hosts have type-2 routes, but a whole prefix needs a type-5 (IP prefix) route. Advertise it into EVPN.
The tenant VRF is configured on both leaves and each host reaches its own gateway, yet PC1 cannot reach PC2 in the other subnet. One piece of the Layer 3 VNI is missing on each leaf.
XR1 (an NCS 5508) connects to R2 (an ISR 4451-X running IOS XE) and to XR3 (a Cisco 8808). IOS runs CDP by default, but IOS XR does not: CDP must be enabled globally and on each interface, and LLDP is off everywhere until you turn it on. Make every router see its neighbors in both protocols.
XR1 is an NCS 5508 with two route processors (0/RP0/CPU0 active, 0/RP1/CPU0 standby), two line cards, fabric cards, system controllers, fan trays and power modules. After maintenance the standby RP never came back, one line card is out of service, and line card 0/0/CPU0 was swapped for a spare from the depot. Find the problems with the platform show commands, bring the spare’s FPD images up to the release, and put the chassis back to full redundancy.
R1 is a Cisco 2911 running IOS 15.7(3)M8. Upgrade it to 15.9(3)M9, which waits on the TFTP server at 10.0.0.100. Classic IOS boots one bundle image: copy it to flash:, check that it arrived intact, point the boot variable at it, save, and reload. The published MD5 of c2900-universalk9-mz.SPA.159-3.M9.bin is d4d4724eeab343dfa86596645a7135c5.
R1 is an ISR 4451-X running IOS XE 17.09.04a in bundle mode (it boots the .bin file directly). Upgrade it to 17.12.04 and move it to install mode, the mode Cisco recommends: the image is expanded into packages and the router boots bootflash:packages.conf. The published MD5 of isr4400-universalk9.17.12.04.SPA.bin is d1171f3e593a0cd9f0d667acf1ff5177.
XR1 is an NCS 5508 with two route processors, running IOS XR 7.9.2. Upgrade it to 7.11.2 from the TFTP server at 10.0.0.100. IOS XR upgrades in three steps: install add puts the packages in the repository, install activate runs them (here a reload of both RPs), and install commit makes the new version survive the next reload. The new release also carries newer FPD (field-programmable device) images for the cards, which you upgrade last.
XR1 is a Cisco 8808 with two route processors, running IOS XR 7.10.1. The Cisco 8000 uses the XR7 install model: you stage a whole new software set from an ISO with install replace, apply it, then commit. Upgrade XR1 to 7.11.2 from the TFTP server at 10.0.0.100, then bring the cards’ FPD images up to the new release.
A colleague tried to upgrade R1 (Cisco 2911) from 15.7(3)M8 to 15.9(3)M9 and gave up: the copy failed, and the boot system line they saved has a typo. R1 still runs 15.7(3)M8. Finish the upgrade. The published MD5 of c2900-universalk9-mz.SPA.159-3.M9.bin is d4d4724eeab343dfa86596645a7135c5; the TFTP server is 10.0.0.100.
Last night XR1 (NCS 5508) was upgraded from 7.9.2 to 7.11.2. This morning it runs 7.9.2 again, and the change ticket says the standby route processor “did not come back”. Use the install log and the redundancy status to find out what happened, then finish the upgrade so it survives the next reload.
N7 is a Nexus 7704: two N77-SUP2E supervisors, N77-C7704-FAB-2 fabric modules, an N77-F348XP-23 48-port 10G card in slot 1 and an N77-F324FQ-25 24-port 40G card in slot 2. N9 is a Nexus 9504: two N9K-SUP-A supervisors, N9K-C9504-FM-E fabric modules, system controllers, an N9K-X97160YC-EX in slot 1 and an N9K-X9788TC-FX in slot 2. A cable joins N7 Ethernet2/1 to N9 Ethernet1/49, but the link stays down: during maintenance someone powered off a line card. Read the hardware with the show commands, bring the module back and route over the link.
Five Nexus switches (9504 and 7704 chassis) already run IS-IS Level-2 under tag CORE, with the MPLS feature set enabled. Turn on LDP: every router needs the feature, a stable router ID and mpls ip on its core interfaces. PE1 then reaches PE2’s loopback on a label-switched path.
Replace LDP with segment routing on the Nexus core. IS-IS already runs on all five switches. Give each one a prefix-SID on its Loopback0 (index = router number) and turn segment routing on in IS-IS. Every switch then programs label 16000 + index toward each loopback, and PE1 reaches PE2 on an SR label-switched path, with no LDP anywhere.
Segment routing was rolled out on the Nexus core, but PE1 has no SR label-switched path to PE2. Two faults hide in the configuration. Use the label tables and SID tables to find them.
The core runs segment routing, and the top path through P1 has TE metric 100 per link. PE2 advertises two customer LANs over iBGP. Mark LAN 20 with the BGP color 10. On PE1, build SR-TE policy GREEN for color 10 toward PE2: a dynamic candidate on the TE metric, then an explicit one. Traffic to LAN 20 rides the policy; LAN 10 has no color and keeps the default path, the IGP shortest path through P1.
No BGP route carries a color here. To move PE1’s traffic for PE2 onto the bottom path anyway, build an SR-TE policy with an explicit segment list through P2 and P3 and let autoroute include all steer every route through PE2 into it, as autoroute announce does for an RSVP-TE tunnel.
Policy GREEN on PE1 should carry the traffic for LAN 20 (color 10) over P2 and P3, but PC1’s traffic to PC3 still takes the default path through P1. The policy is up. Find out why no route is steered into it, and fix both faults.
IS-IS sends PE1’s traffic for PE2 over the short top path through P1, but those links can reserve only 50 Mbps. Build an MPLS TE tunnel that asks for 100 Mbps: CSPF must find the bottom path through P2 and P3, RSVP signals it, and autoroute announce puts PE1’s traffic into it. P1, P2, P3 and PE2 already run MPLS TE.
Every switch runs MPLS TE. Pin tunnel-te1 to the top path through P1 with a strict explicit path, and keep a dynamic path option as the fallback. The top links can reserve only 50 Mbps, so the tunnel first comes up on the fallback. Raise the RSVP bandwidth along the top path and watch the tunnel move back to its preferred path option.
tunnel-te1 on PE1 should run over the bottom path (P2, P3) on explicit path BOTTOM, but it stays down and PE1’s traffic still takes the IGP path. Read the tunnel’s failure reason, fix each fault, and bring the tunnel up.
PC1 and PC2 share one subnet, 192.168.100.0/24, but sit on opposite sides of an MPLS core. IS-IS and LDP already run on PE1, P and PE2. Build a pseudowire between PE1 and PE2 with VC ID 100: every frame entering a customer port leaves the customer port at the far end, as if the core were one long cable.
Three customer sites share one subnet. A pseudowire joins only two points, so VPLS builds a virtual switch on each PE: a full mesh of pseudowires, one bridging table, and MAC learning. IS-IS and LDP already run. Build VPN 100 on PE1, PE2 and PE3, so that all three hosts reach each other.
PC1 and PC2 share one subnet, 192.168.100.0/24, but sit on opposite sides of an MPLS core. IS-IS and LDP already run on PE1, P and PE2. Build a pseudowire between PE1 and PE2 with VC ID 100: every frame entering a customer port leaves the customer port at the far end, as if the core were one long cable.
Three customer sites share one subnet. A pseudowire joins only two points, so VPLS builds a virtual switch on each PE: a full mesh of pseudowires, one bridging table, and MAC learning. IS-IS and LDP already run. Build VPN 100 on PE1, PE2 and PE3, so that all three hosts reach each other.
PC1 and PC2 share one subnet, 192.168.100.0/24, but sit on opposite sides of an MPLS core. IS-IS and LDP already run on PE1, P and PE2. Build a pseudowire between PE1 and PE2 with VC ID 100: every frame entering a customer port leaves the customer port at the far end, as if the core were one long cable.
Three customer sites share one subnet. A pseudowire joins only two points, so VPLS builds a virtual switch on each PE: a full mesh of pseudowires, one bridging table, and MAC learning. IS-IS and LDP already run. Build VPN 100 on PE1, PE2 and PE3, so that all three hosts reach each other.
PC1 and PC2 share one subnet, 192.168.100.0/24, but sit on opposite sides of an MPLS core. IS-IS and LDP already run on PE1, P and PE2. Build a pseudowire between PE1 and PE2 with VC ID 100: every frame entering a customer port leaves the customer port at the far end, as if the core were one long cable.
Three customer sites share one subnet. A pseudowire joins only two points, so VPLS builds a virtual switch on each PE: a full mesh of pseudowires, one bridging table, and MAC learning. IS-IS and LDP already run. Build VPN 100 on PE1, PE2 and PE3, so that all three hosts reach each other.
A colleague configured a pseudowire between PE1 and PE2, but PC1 cannot reach PC2. Three different faults hide on PE2. Each one only shows once the one before it is fixed, so read the reason after every change.
VPLS was rolled out on PE1, PE2 and PE3 for VPN 100, but the sites do not all reach each other. Find the faults: read the state of each pseudowire and of the attachment circuits, then fix them.
A customer’s three sites land on three different PEs: PE1 runs IOS XE, PE2 runs IOS XR and PE3 runs Huawei VRP. LDP-signaled VPLS is a standard, so they can share one VPN. IS-IS and LDP already run. Build VPN 100 on all three, each in its own commands, so that the three hosts reach each other.
Six NCS 5508 PEs, each with two route processors, carry VLANs 10 and 20 across an MPLS core between three sites. The core (IS-IS and LDP), the BGP sessions and Sites 2 and 3 are already configured, so you build Site 1 end to end. Each site has two PEs and two Cisco CE switches. Each CE has one LACP bundle to both of its PEs: the shared ESI makes the two PEs look like one partner. Every PE has the same gateway IP and MAC on a BVI, so hosts always use a gateway at their own site, and the gateway MACs must stay local.
Six Huawei PEs with dual MPUs carry VLANs 10 and 20 across an MPLS core between three sites. The core (IS-IS and LDP), the BGP sessions and Sites 2 and 3 are already configured, so you build Site 1 end to end. Each site has two PEs and two Cisco CE switches. Each CE has one LACP bundle to both of its PEs: the shared ESI makes the two PEs look like one partner. Every PE has the same gateway IP and MAC on a Vbdif, so hosts always use a gateway at their own site, and the gateway MACs must stay local.
The same three sites as the LDP lab, with six NCS 5508 PEs. The core runs segment routing with IS-IS and no LDP at all: a prefix-SID on each loopback gives every router the label 16000 + index for it, and EVPN rides those labels. The core (IS-IS and LDP), the BGP sessions and Sites 2 and 3 are already configured, so you build Site 1 end to end. Each site has two PEs and two Cisco CE switches. Each CE has one LACP bundle to both of its PEs, and every PE has the same gateway on a BVI. Turn on SR on Site 1, then build its EVPN.
The same three sites as the LDP lab, with six Huawei PEs. The core runs segment routing with IS-IS and no LDP at all: a prefix-SID on each loopback gives every router the label 16000 + index for it, and EVPN rides those labels. The core (IS-IS and LDP), the BGP sessions and Sites 2 and 3 are already configured, so you build Site 1 end to end. Each site has two PEs and two Cisco CE switches. Each CE has one LACP bundle to both of its PEs, and every PE has the same gateway on a Vbdif. Turn on SR on Site 1, then build its EVPN.
Sites 1 and 3 use IOS XR PEs, Site 2 uses Huawei PEs, and a Nexus 7704 and a Nexus 9504 are the P routers. The core runs segment routing with IS-IS and no LDP at all: a prefix-SID on each loopback gives every router the label 16000 + index for it, and EVPN rides those labels. The Nexus switches run SR but know nothing of EVPN. Sites 1 and 3, the core and the BGP sessions are already configured. Build Site 2 so that it joins the same SR domain and the same EVPN.
Sites 1 and 3 use IOS XR PEs, Site 2 uses Huawei PEs, and a Nexus 7704 and a Nexus 9504 are the P routers. The Nexus switches only swap labels: they run IS-IS and LDP, and know nothing of EVPN or the customers. Sites 1 and 3, the core and the BGP sessions are already configured. Build Site 2 so that it joins the same EVPN.
OS10 starts like an industry-standard CLI, with its own habits: a VLAN exists once interface vlan creates it, ports are named ethernet1/1/1, and the configuration is show running-configuration. Two switches share one cable, with a host on each. Carry VLAN 10 between them.
SW2 is a Layer 2 access switch with hosts in VLANs 10 and 20. SW1 is the gateway. Bundle the two links between them with LACP, carry both VLANs, and route on SW1.
VLT (Virtual Link Trunking) makes two switches look like one to a third device, so CE can bundle one link to each of them with ordinary LACP, and both links forward. CE is ready. Build the pair on L1 and L2, then the port-channel to CE.
A leaf-spine fabric: every leaf connects to every spine, and no leaf to another leaf. Each leaf is its own BGP AS, both spines are AS 65000, so an equal-cost path exists through each spine. OS10 peers on numbered links here, and one session on each link carries both the routes and the overlay that follows.
Dell Enterprise SONiC has a Linux shell underneath, and sonic-cli (the Management Framework CLI) on top. This lab works in sonic-cli, with standard names such as Eth1/1. Two switches share one cable, with a host on each. Carry VLAN 10 between them.
SW2 is a Layer 2 access switch with hosts in VLANs 10 and 20. SW1 is the gateway. Bundle the two links between them with LACP, carry both VLANs, and route on SW1.
MCLAG makes two switches look like one to a third device, so CE can bundle one link to each of them with ordinary LACP, and both links forward. CE is ready. Build the pair on L1 and L2, then the port-channel to CE.
A leaf-spine fabric: every leaf connects to every spine, and no leaf to another leaf. Each leaf is its own BGP AS, both spines are AS 65000, so an equal-cost path exists through each spine. SONiC needs no link addresses: ipv6 enable gives a port a link-local address, and neighbor interface peers over it.
The underlay is up, and each leaf has a host in VLAN 10. Stretch VLAN 10 across the routed fabric. OS10 uses a virtual network as the Layer 2 domain: it has a VNI, and a VLAN is bound to it. Without a control plane, each leaf lists the other as a remote VTEP.
BGP on each link already carries the L2VPN EVPN family. Turn on EVPN so each leaf advertises its VNIs and hosts, and the leaves find each other from those routes. auto-evi creates an EVPN instance per virtual network, with automatic route-distinguisher and route-targets.
VLAN 10 is stretched, but PC3 sits in VLAN 20 on L2 only. Route between them in a tenant VRF. Each leaf is the gateway for its subnets, using one shared virtual address and MAC, and traffic between leaves crosses in the VRF’s L3 VNI.
The underlay is up, and the peer-groups already activate L2VPN EVPN. Build the VTEP: one interface vxlan with a source address and a VNI per VLAN. advertise-all-vni then announces every VNI, so the leaves find each other in BGP.
VLAN 10 is stretched, but PC3 is in VLAN 20 on L2 only. Build a tenant VRF: every leaf has the same gateway address and MAC, and traffic between leaves crosses in the L3 VNI.
A fabric rarely stands alone: older racks with classic switches and bare-metal servers must join it. PHY1 is such a classic switch, with hosts in VLANs 100 and 200 and two uplinks in one LACP bundle. The fabric already carries both VLANs in VNIs 10100 and 10200. Attach PHY1 to the L1 and L2 VLT pair so those VLANs reach the far rack.
Everything together, from blank switches: two Z9264F-ON spines, two VLT leaf pairs of S5248F-ON, and a border pair of S5232F-ON. Tenant T1 has web and app VLANs, tenant T2 a database VLAN, kept apart in their own VRFs. A classic switch is the physical domain. The cables are in, and the configuration is yours.
A fabric rarely stands alone: older racks with classic switches and bare-metal servers must join it. PHY1 is such a classic switch, with hosts in VLANs 100 and 200 and two uplinks in one LACP bundle. The fabric already carries both VLANs in VNIs 10100 and 10200. Attach PHY1 to the L1 and L2 MCLAG pair so those VLANs reach the far rack.
Everything together, from blank switches: two Z9264F-ON spines, two MCLAG leaf pairs of S5248F-ON, and a border pair of S5232F-ON. Tenant T1 has web and app VLANs, tenant T2 a database VLAN, kept apart in their own VRFs. A classic switch is the physical domain. The cables are in, and the configuration is yours.
CE has one LACP bundle to the L1 and L2 pair. To the rest of the fabric, those two must look like one tunnel endpoint, or remote leaves would see PC1’s MAC move between them. So both leaves use the same VTEP address on Loopback 1. L3 and L4 are done. Build L1 and L2.
L2 is also the border leaf. In Vrf-T1 it reaches an outside network, stood in for by Loopback 100 (10.100.100.0/24). A host route says where one host is, but the outside is a whole prefix, which needs a type-5 route. The VRF’s BGP instance already redistributes connected routes and advertises them, so give it the network to announce.
The fabric was working before a change window. BGP is up on every switch, but PC1 reaches neither PC2 in its own VLAN nor PC3 in VLAN 20. There are three faults, on L1 and L2.
BGP is up everywhere, yet PC1 cannot reach PC2. There are two faults: one breaks the VLT port-channel on the second switch of a pair, and one stops L3 importing the VNI.
A SONiC spine connects a SONiC leaf and an OS10 leaf. EVPN is a standard, so one VNI can span both operating systems. The underlay and BGP sessions are ready. Turn on the overlay on each leaf with that OS’s commands.
A Nexus leaf joins the Dell fabric of the previous lab. The two Dell leaves already share VNI 10010. Nexus does not match automatic route-targets on the VNI, so write one route-target on all three leaves. L3’s underlay is up.
The same design as the ACI capstone, on Dell OS10, so you can compare the two: an ACI fabric takes policy from one place, and here every line goes on a switch. PUBLIC reaches the internet router over BGP. INTERNAL reaches the campus router over OSPF, and its hosts sit behind a classic switch on a VLT pair. DMZ must go through ASA1 before the internet, so it has its own VRF, with a default route to the firewall, and the firewall’s outside is in a separate VRF. Only the outside routers and PHY1 are configured.
The same design as the ACI capstone, on Dell SONiC, so you can compare the two: an ACI fabric takes policy from one place, and here every line goes on a switch. PUBLIC reaches the internet router over BGP. INTERNAL reaches the campus router over OSPF, and its hosts sit behind a classic switch on a MCLAG pair. DMZ must go through ASA1 before the internet, so it has its own VRF, with a default route to the firewall, and the firewall’s outside is in a separate VRF. Only the outside routers and PHY1 are configured.
A firewall straight out of the box has no configuration. Open ASA1’s console: like a real ASA, it offers to pre-configure itself through interactive prompts. The wizard asks for the mode, a password, the clock, the inside address, a name and the management host, and writes real configuration from your answers. The setup command in configuration mode runs the same dialog later.
A new firewall passes nothing. Each interface needs a name and a security level: traffic flows freely from a higher level to a lower one, and needs a rule the other way. PC1 is inside, SRV on a DMZ, and R1 is the provider, with 198.51.100.0/24 behind it and no route back to your private addresses, so the inside must be translated.
The provider must reach the web server SRV in the DMZ, but only it, and only by its public address 203.0.113.10. On an ASA a static NAT publishes the server, and an access rule on the outside interface lets traffic in. Since ASA 8.3 that rule names the server’s real address, not the public one. Use objects so the names say what they are.
An ASA checks NAT rules in three sections: manual rules first, then auto (object) rules, then manual rules marked after-auto. R1 now has a route back to 192.168.1.0/24, so traffic there can keep its real address. PC1 must reach R1’s 198.51.100.1 by a second address, 10.99.99.1, which only this firewall knows.
SRV in the DMZ may send web traffic (TCP 80 and 443) and DNS (UDP 53) out, and nothing else. The simulator only sends pings, so test the rule with packet-tracer, which walks a made-up packet through the same steps as real traffic: route lookup, access rule, NAT, inspection and flow creation.
This firewall worked before a change. Now the provider cannot reach the published server at 203.0.113.10, and the inside cannot ping out. There are three faults. Read each ping’s reason, then show nat, show access-list and show service-policy.
Three tenants share one firewall, and all three use 192.168.1.0/24 inside. Security contexts make that possible: each context is a virtual firewall with its own interfaces, routes and NAT. The system execution space creates contexts and sub-interfaces and gives each context its interfaces; everything else is configured inside the context. Tenant k is on VLAN 100+k inside and VLAN 200+k outside, where R1 has 100.64.k.254.
A provider’s firewall carries ten tenants, every one with 192.168.1.0/24 inside. The system space is done: ten contexts, each with its own inside and outside sub-interface. Tenants 1 to 7 are fully configured. Finish tenants 8, 9 and 10, then prove that all ten work and stay apart.
Three tenants, three contexts, and none of them can reach the provider since last night’s change. Each context has its own fault. Work in the system space and in each context, and read the ping reasons.
PC1 and its router R1 are in 192.168.1.0/24, and nobody wants to renumber. A transparent firewall goes in the cable between them: it bridges, so neither end notices, but it still applies security levels and access rules. Its only address is on the BVI, for managing it.
ASA1 is configured and working. ASA2 is new and empty, cabled beside it, with a direct cable between the two Gi0/3 ports. Make them an active/standby pair: ASA2 copies ASA1’s configuration, keeps its standby addresses ready, and takes over if ASA1 fails.
ASA1 and ASA2 were set up as a failover pair, but each one says it is active, and ASA2 never copied ASA1’s configuration. The failover link runs through switch SWF. There are three faults, and show failover names one at a time: fix it, and read show failover again.
ASA1 runs two security contexts, C1 for tenant T1 and C2 for tenant T2, and both work. ASA2 is new and empty, cabled beside it, with a direct cable between the two Gi0/3 ports. Make them an Active/Active pair: put C1 in failover group 1, which is active on ASA1, and C2 in failover group 2, which is active on ASA2. Both units then carry traffic, and either one can carry both tenants if the other fails.
Two sites, each behind its own firewall, both translating their inside to the internet. Join 192.168.1.0/24 and 192.168.2.0/24 with an IPsec tunnel over the provider R1, using IKEv2 and a pre-shared key. The provider knows nothing about either LAN, so the only way between them is the tunnel.
Two sites, each behind its own firewall, both translating their inside to the internet. Join 192.168.1.0/24 and 192.168.2.0/24 with an IPsec tunnel over the provider R1, using IKEv1 and a pre-shared key. The provider knows nothing about either LAN, so the only way between them is the tunnel.
The IKEv2 tunnel between the two sites stopped working after both firewalls were changed. There are three faults. Each ping from PCA gives a reason, and show crypto ikev2 sa on FWA repeats the last one.
alice works from home on LAP1, behind the provider R1. She needs the office server SRV, which is only reachable inside. Publish AnyConnect on the outside interface: users log in, get an address from a pool, and only office traffic goes through the tunnel. Any host here can act as the client, with vpn connect.
Contractors get no tunnel and no address, only a web portal with bookmarks: the firewall fetches the page for them. (This is the classic clientless SSL VPN. Cisco removed it from ASA software in 9.17, so you meet it on older firewalls and in older course material.) Give user carol the portal, with one bookmark to the intranet on SRV.
Build a company’s whole edge on four empty firewalls. HQ has an active/standby pair (HQ1, HQ2) with inside, outside and a DMZ web server. The branch firewall BR joins the branch LAN to HQ over an IKEv2 tunnel. alice works from home on LAP1 with AnyConnect. The hosting firewall DC carries two tenants in security contexts, both using 10.0.0.0/24. R1 is the internet, with 198.18.0.1 behind it. Site-to-site and remote-access VPN run in single context mode, which is why the tenants live on their own firewall.
Select ASA1 and press Open Buddy SDM Manager. Build this firewall from its screens, previewing the commands each form will send before you send them. The console at the bottom of the page is the same session as the main console, so you can type any step instead and watch the screens change. Nothing here depends on which way you choose.
Both firewalls already translate their inside to the internet. Use the wizards on the VPN screen to join the two sites, then let alice and carol in from home. Before each Send, read the preview: one form sends the same long list of commands you would otherwise type. The console on the page is the same session, so you can type any step instead.
ASA1 is working. ASA2 is new and empty, cabled beside it, with a direct cable between the two Gi0/3 ports. Use the High availability screen to make them a pair, then move the active role by hand and watch traffic and the log follow it.
Two tenants share this firewall, and both use 10.0.0.0/24 inside. A single firewall could not tell them apart, but two contexts can. Create the contexts on the Contexts screen, then choose each one at the top of the page: every other screen then shows that context alone.
An FTD-style firewall is managed. Its console shows and tests, and its policy comes from a manager. Before anything else, the two must find and trust each other, over a separate management network: MGR1 and FTD1’s Management0/0 are both on switch SWM. Try configure terminal on FTD1 first, and read why it refuses.
FTD1 is registered and empty. Build its policy on the manager, and notice that nothing reaches the firewall until you deploy. The Deploy screen shows the exact firewall lines first. They are ASA-style configuration, because that is what a deployment produces.
PC1 already reaches the internet through FTD1. Now put SRV on a DMZ and publish it as 203.0.113.10. Rules name the server’s real address, because the firewall undoes NAT before it reads them. Then use Analysis to see which rule let the traffic in, and the packet tracer to test a port that a ping can’t.
Two branches, registered and empty, wired differently: F1 uses Gi0/0 and Gi0/1, F2 uses Gi0/2 and Gi0/3, and they name their interfaces differently. You still write one policy. Zones are why: a rule says INSIDE to OUTSIDE, and each firewall says which of its interfaces those are.
Someone built this policy and went home. PC1 can’t reach the internet, and the manager’s screens look nearly right. There are three faults: one in the rules, one in the routes, and one in what the firewall is actually running.
MGR1 refuses to add FTD1. Both have addresses, and someone typed the manager’s details on the firewall from memory. Try to add the device, and read each refusal: it names the next thing to fix.
SRV is published on port 80, and the access rule allows port 80 from anywhere. An access rule looks at addresses and ports, so it cannot tell a normal request from an attack on the same port. Snort reads what is inside. On LAP1, the command traffic sends one TCP packet with the text you give it, along the real path.
A scanner announces itself with BadBot in its requests, and no built-in rule knows it. Write a rule, and try it safely: detection mode reports what a rule would do without dropping anything, so you can see whether it would break real traffic before you trust it.
The security team says the server is protected: there is an IPS policy, and it is on the rule. Yet this request still reaches SRV: traffic tcp 203.0.113.10 80 payload "GET /etc/passwd". Three settings are each enough to let it through.
Malware on PC1 must find its command server before it can do harm, and it does that with an ordinary DNS lookup. Rule DNS-OUT lets PC1 ask the DNS server outside (198.51.100.1) on UDP 53, so the lookup leaves like any other. This time the IPS goes on an outbound rule.
SRV now also serves HTTPS, and rule HTTPS-WEB already carries the IPS policy BRANCH-IPS. Yet the same attack that is dropped over port 80 gets through on 443: TLS hides the request, and Snort cannot read what it cannot see. SRV is your own server, so the firewall can hold its key and decrypt.
WEB-IPS is already on HTTP-WEB, in prevention mode, yet a SQL injection against the search page reaches SRV. Before you write any rule, check what the policy actually turns on: the base policy decides which built-in rules run.
A Shellshock probe hits SRV’s CGI page. Write a custom rule that catches it, and make it precise: a rule that matches too little text blocks real users too. Two content options must both match.
The help desk complains: since WEB-IPS moved to Balanced, nobody can download cmd.exe-cheatsheet.pdf. Rule 1000105 drops any request naming cmd.exe, and it also catches a real attack. Let the one download through, and keep the attack dropped.
A colleague wrote rule 1000050 for the bad bot, set it to drop in BOT-IPS, attached the policy and deployed. The bot still reaches SRV, and there is not a single intrusion event. Three separate mistakes each keep the rule from firing.
F1 is working, and F2 is registered and empty, with a direct cable between the two Gi0/3 ports. On an ASA you would type failover lines on each unit. Here, one form describes the pair, and a deployment sets up both.
HQ-PAIR is configured and deployed, but its failover link runs through switch SWF, and something on that switch keeps the two units apart. With no mate, each unit makes itself active: F2’s show failover says Failed - No Switchover, Mate Unknown, and the other host Failed, as on a real pair whose link is broken.
No FTD Manager here: each firewall uses its own device manager, as a small site does. F1 is configured and working. F2 has only finished its setup, and a cable joins the two Gi0/3 ports. You make the pair from each device manager’s Device › High Availability page: the primary first, then the secondary, which takes its configuration from the primary.
The order used on a real FMC: first each firewall points at the manager (configure manager add), then the manager adds both devices, then F1 gets its interfaces and policies, and only then do you make the High Availability pair. The manager already has its address, Evaluation Mode, and the policies ACP1 and NAT1. F1 (10.0.0.1) and F2 (10.0.0.2) have their management addresses, and nothing else.
Both firewalls work and are on the same manager, and the provider R1 knows nothing about either LAN. On an ASA you would build each end by hand, and any small difference breaks the tunnel. Here, one form describes both ends, and each firewall gets its own lines.
Three registered, empty firewalls and one manager. HQ is an active/standby pair (HQ1, HQ2) with an inside and a DMZ with the web server SRV. BR is a branch, joined to HQ by an IKEv2 tunnel. One access policy and one NAT policy serve all of them, because zones make that possible. R1 is the internet, with 198.18.0.1 behind it, and LAP1 is somebody out there.
A small site has one firewall and no FMC. An FTD-style firewall can manage itself: select FTD1 and press Open Device Manager. You build the same zones, policies and NAT as on a manager, and you still deploy. A firewall has one manager at a time: registering with an FMC ends this, as on the real product. MGR1 is here unused, so you can see that nothing needs it.
Staff on PC1 can reach any web server, because WEB-OUT allows all TCP from INSIDE to OUTSIDE. A port number can’t say what a site or an application is: social networks and ordinary sites all use port 80, and file sharing uses any port. Rules that name an application or a URL read the packet to find out. On PC1, the command traffic sends one packet with the text you give it.
A prefilter runs first, by addresses and ports alone. Use it for traffic you can decide without reading it. Requests to SRV go through an IPS policy, which is what you want for strangers. But the backup system at 100.64.10.10 (LAP1) sends data that looks like an attack and must not be inspected, and 100.65.0.0/16 is a network you never want to hear from.
alice works from home on LAP1, behind the provider. PC1 is only reachable inside. On an ASA you would type about thirty lines. On the manager, one wizard describes the connection, and a deployment sends those lines: read them in the preview.
A manager has no screen for everything. FlexConfig adds configuration lines directly, for the rare case that needs it. It is sharp: the manager refuses lines it owns, and a line the firewall rejects fails the whole deployment.
FTD1 is registered over its Management0/0 port. Many branch firewalls have no separate management network, so the manager reaches them through a data interface instead. MGR1 sits behind R1, so it can reach FTD1’s outside interface. Move manager access to outside, in the order the move must happen: change the manager, deploy while the old path still works, then switch the firewall and the manager’s address for it.
Someone moved FTD1’s manager access to its outside interface and then unplugged Management0/0: this branch has no management network. Now MGR1 shows FTD1 as unreachable, and nothing can be deployed. Find out why from FTD1’s own console, and fix it there.
FTD1 runs from its own device manager, and traffic works. But a firewall also needs names and the right time: licences, certificates and log times depend on the clock, and NTP servers are often given by name. Out of the box its DNS and NTP servers are on the Internet, and this lab has no Internet. NS1 (10.0.0.53), on the management network, is a DNS server for lab.test and an NTP server.
The partner’s server is known by name, www.partner.test, and its address can change. An access rule can name it with an FQDN object: the firewall looks the name up and the rule matches the address it gets. The lookup uses the DNS group of the data interfaces, and FTD1 has none yet. NSO (198.18.0.53), on the Internet side, is a DNS server for the partner’s names.
A new firewall for a small office, set up the way the device’s own manager expects: with the Device Setup wizard, then its pages. Select FTD1 and press Open Device Manager. Every page shows the commands it sends before it sends them, and the console under the pages takes the same lines. PC1 is on the inside, and R1 is the ISP router (198.51.100.1 is behind it).
The firewall side is ready: FTD1 has its management address and names MGR1 as its manager (configure manager add, on its console, because a managed firewall has no screens). Everything else happens in FTD Manager: select MGR1 and press Open FTD Manager. Each screen shows the commands it sends, and the console under the screens takes the same lines.
FTD1 must move from 10.0.0.2 to 10.0.0.12 on the management network, and stay managed by MGR1. Cisco’s documented order: on the manager, turn Management off for the device, edit its Remote Host Address, change the address on the firewall’s console, then turn Management on. The firewall stays registered the whole time. Select MGR1 and press Open FTD Manager.
A new management center starts with a default address (192.168.45.45) that is not on your network, and its web interface can be reached only once it has the right one. As on an FMC 10.x, its > prompt has no command for the address (configure network has only dns): you set it from the expert shell, as root, with configure-network, which asks its questions one at a time. MGR1 is the new manager, and ADM is your admin PC on the management network. RouteBuddy skips the login and passwords.
One manager is a single point of failure for every change and deployment (traffic keeps flowing without it, but nobody can change a rule). Two managers can work as a pair. One is active: it takes every change and deploys. The other is the standby: it copies the active one and is read-only. MGR1 (10.0.0.5) already manages FTD1 and has its policy. MGR2 (10.0.0.6) is new and empty. On a real management center you build the pair on Integration › Other Integrations › High Availability, and there are no console commands for it: the manager-ha lines here are RouteBuddy’s own, so that you can see what each click sends.
A PAN-OS-style firewall keeps two configurations. Your changes go into the candidate, and the firewall keeps running the old one until you commit. Traffic moves between zones, so an interface does nothing until it has an address, a zone and a virtual router. Select FW1 and press Open Web Interface, or type: the console takes the same lines.
Rule OUT allows everything. Replace it with rules that name applications. App-ID reads a packet to name its application, and service application-default adds a second check: the application must be on its usual port. So web browsing on port 8080 is not the same as web browsing on port 80. On PC1, the command traffic sends one packet with the text you give it.
Publish SRV as 203.0.113.10. PAN-OS has a rule that catches almost everyone: a security rule names the address before NAT and the zone after NAT. The NAT rule goes from untrust to untrust, because before NAT the public address is out there. The security rule goes from untrust to dmz, because that is where the packet really goes, but it still names the public address.
A rule that allows web-browsing allows an attack inside web-browsing, and any site. Security profiles read what an allow rule lets through. A vulnerability profile looks for known attacks, and a URL filtering profile looks at where a request is going. A profile does nothing until a rule uses it.
Someone published SRV and went home. LAP1 can’t reach it, and PC1 has lost the internet too. There are three faults: a rule written the way it looks right, a block above a good rule, and a change that was never committed.
On an ASA, a crypto access list picks what goes in a tunnel. Here a tunnel is an interface. Traffic goes through it because a route says so, and the interface sits in a zone, so a security rule has to allow traffic into and out of that zone. There are two things to forget, and each fails differently.
alice works from home on LAP1. PC1 is only reachable inside. GlobalProtect gives her an address from a pool, and puts her in a zone of her own through a tunnel interface, so the rules decide what she can reach. The client is stood in for: no software is installed.
F1 is working. F2 is new and empty, cabled beside it, with a direct cable between the two ethernet1/4 ports. Make them a pair. The passive unit copies the active unit’s configuration, and keeps its links quiet. The addresses move with the role, so PC1’s gateway never changes.
F1 is working, with high availability configured. F2 was set up beside it, with a direct cable between the two ethernet1/4 ports, but F1 still says its peer is not connected. There are three faults on F2, and show high-availability state names one at a time.
F1 and F2 are a working active/passive pair. Before you trust a pair, test it: move the role to F2 on purpose, check that traffic still flows, and move it back. A suspended unit can’t take the role, so it must be made functional first.
The tunnel between the sites was built in a hurry. PCA can’t reach PCB. There are three faults, each with a different symptom: one sends the traffic the wrong way, one stops it at a rule, and one stops the tunnel coming up.
Build a company’s whole edge on three empty firewalls. HQ is an active/passive pair (HQ1, HQ2) with an inside and a DMZ with the web server SRV. The branch firewall BR joins its LAN to HQ over a route-based tunnel. alice works from home on LAP1 with GlobalProtect. R1 is the internet, with 198.18.0.1 behind it.
A manager runs many firewalls from one place. Before anything else, the two must find each other over the management network: MGR1 and F1’s mgt port are both on switch SWM. Each side says who the other is, and each side commits, because both have a candidate.
F1 is connected and empty. Build its network in a template and its policy in a device group. There are two steps now: commit saves on the manager, and push sends what is committed to the firewalls. Until you push, F1 knows nothing about it.
Head office writes rules that a site can’t get around: pre-rules. It also writes a catch-all that the site’s own rules come before: post-rules. In between sit the firewall’s local rules. F1 already has a pushed rule OUT that allows everything, and the site wants to allow one thing of its own.
Two branches share a policy but not addresses. So they share one device group, and each has its own template. Shared holds what every device group gets. Change one rule on the manager, push once, and both firewalls have it.
Someone configured the manager and went home. PC1 can’t reach anything. There are three faults: a local rule hiding what head office intended, a change committed on the manager and never pushed, and a change that was never committed there at all.
A manager that is down stops every push. Two managers can work as an active/passive pair: only the active one pushes, and the passive one holds a copy of the running configuration. Each manager names the other as its peer, one is primary and the other secondary, and each firewall names both. MGR1 (10.0.0.5) already manages F1. MGR2 is new: it has no address yet.
A Check Point-style deployment splits in two. The gateway handles its own interfaces and routes, in its Gaia-style console, and they change at once. Its policy comes from a separate manager, which must first be trusted: a one-time password sets that up. Select GW1 and press Open Gateway Portal, or SMS1 and Open Buddy Security Console. The consoles take the same lines.
GW1 trusts SMS1 and still runs InitialPolicy. There are three steps to changing it. A change stays private in your session. Publish moves it into the manager’s database. Install Policy sends it to a gateway. PC1 can’t reach anything until the last step.
Publish SRV as 203.0.113.10. NAT lives on the host object, and that object stands for both addresses, so a rule names the object and you never write the public address. Then protect the gateway itself. A gateway’s own addresses are just destinations here: a stealth rule near the top drops anything aimed at it.
A gateway’s features are blades, and each is turned on per gateway. A rule can only name an application if Application Control is on, or a URL category if URL Filtering is on, and installing one without the other fails. IPS reads what your rules let through.
Someone built this and went home. Install Policy fails, and PC1 can’t reach anything. There are three faults: a rule that hides another, interfaces with their topology swapped, and changes never published.
SMS1 refuses to add GW1. Both seem to be set up. Try to add it, read each refusal, and fix what it names. Then look at why someone would use fw unloadlocal, and why you shouldn’t leave a gateway that way.
You don’t write tunnels here. Each gateway has a VPN domain, the network behind it, and a community says which gateways talk. Traffic between two domains in a community gets encrypted. Gateways on one manager trust each other through its certificates, so there is no key to type. R1 knows nothing about 192.168.x.x, so a packet that isn’t encrypted can’t get across.
GW1 is headquarters, and GW2 and GW3 are branches. A meshed community would link every pair. A star links each satellite only to a center, which suits branches that need headquarters and not each other.
The community is built and the rules are there, and PC1 still can’t reach PC2. There are two faults. Follow what the ping’s reason says, and read vpn tu tlist.
A cluster is two gateways sharing virtual addresses. Each keeps its own address on every interface. The active member answers on the virtual ones, and PC1 and R1 use those, so they never see a failover. A direct cable, the sync interface, lets each member see the other. Here that’s eth4.
Someone built CL1 and left. Installing fails, and once it works both members think they’re alone. Read each message: there are two faults, both on GW2.
Put it all together. Headquarters is a cluster. A branch, GW3, connects to it through a community, and the tunnel ends on the cluster’s virtual address, so a failover doesn’t move it. PC1 still reaches the internet hidden behind the cluster, and nothing reaches the gateways themselves.
So far you typed each switch’s lines yourself. A fabric controller holds what you want, and works out the lines. FC1 is such a controller: a RouteBuddy teaching page, not a Dell product. The fabric mixes SONiC and OS10 leaves, because it compiles per OS. Use the page (select FC1, then Open fabric controller) or its console. Compare the plan with what you typed in earlier labs, then deploy it, and download the files for real switches.
The fabric from the last lab is running. Add a tenant with two routed VLANs, and carry VLAN 10 from the classic switch too, by changing the intent once and deploying again.
The fabric was working until someone made a change directly on a switch, and PC1 has lost PC3. A controller knows what each switch should have, so it can find the difference without you reading every configuration.
An ACI fabric is run from a controller, the APIC, not switch by switch. A new switch announces itself, and stays out of service until you register it with a node ID. The APIC only finds what it can reach through switches already registered, so registration works outward: first the leaf next to the APIC, then the spine, then the other leaves.
A tenant is a container for one customer’s or team’s policy. Inside it, a VRF is a routing table, and a bridge domain is a Layer 2 flood domain, tied to a VRF, with subnets for its gateways. Nothing reaches a switch yet: a policy only lands where a host needs it.
An endpoint group (EPG) is a set of hosts that share policy, whatever their subnet or port. A static path says which leaf port, on which VLAN, belongs to the EPG. Access policies (VLAN pool, physical domain, AEP, policy group) are ready; the next labs build those. Put PC1 and PC2 in one EPG.
In most networks everything can talk unless something blocks it. ACI starts the other way: EPGs cannot talk until a contract allows it. PC1 is in EPG WEB and PC2 in EPG APP, and each reaches its own gateway. Allow WEB to reach APP with a contract: a filter says what traffic, a subject groups filters, and one EPG provides the contract while the other consumes it.
The contract exists, but the bridge domains have no subnets, so neither host has a gateway. Add them. The fabric then routes between the bridge domains in VRF V1, using one gateway address that exists on every leaf with hosts in that bridge domain.
A VLAN only works on a port if a chain of policies allows it: the EPG names a physical domain, the domain names a VLAN pool holding that VLAN, and the port’s policy group names an AEP attached to that domain. The tenant and paths are in place, but nothing passes, because the chain is missing. Build it, reading show faults at each step.
PHY1 is a classic switch with bare-metal hosts in VLANs 100 and 200, and one LACP bundle with a link to L101 and a link to L102. Bring those racks into the fabric, one EPG per VLAN: the classic hosts then reach PC3 and PC4 on L103. A bridge domain facing a classic switch must flood, because silent hosts there can only be found by flooding.
R1 is outside the fabric, with the network 10.100.100.0/24 behind it. An L3Out is how a VRF reaches the outside: a routed port on a border leaf, a next hop, and the external subnets. To policy, the outside is one more group of endpoints, so a contract is needed there too.
Build everything from a blank fabric for an application called SHOP: web, app and database tiers, each its own EPG and bridge domain. Web may reach app, and app may reach the database, but web must not reach the database directly. That rule is the reason for contracts.
Two data centers, two different fabrics: Location A runs Dell SONiC and Location B an ACI-style fabric. Each has two physical domains: a classic switch in VLAN 100, and one in VLAN 200. The fabrics share no control plane. Instead, each hands its VLANs on a tagged, all-active LACP bundle to a pair of IOS XR routers, and those join the sites with EVPN over an MPLS core. Both fabrics’ underlays and the IOS XR core are up. You attach the physical domains, build the hand-offs, and build EVPN.
Inside the fabric, each leaf knows its own hosts, but a route learned on an L3Out is known only to its border leaf. Fabric BGP (MP-BGP in the infra tenant) carries those routes: pick one ASN for the fabric, and make spines route reflectors, so every leaf peers with the spines and not with every other leaf. Here L104 already learns 10.100.100.0/24 from R1 over OSPF, but L101, L102 and L103 have never heard of it.
This fabric worked before a change. Start with show faults on the APIC, then fix each cause. PC1 and PC2 are in one EPG on VLAN 20, on leaves 101 and 102, and neither can reach the other. There are three breaks in the chain from the EPG to the port.
This fabric worked before a change. Start with show faults on the APIC, then fix each cause. show faults is clean this time, because a contract is not a fault: the fabric is doing what it was told. PC1 in EPG WEB cannot reach PC2 in EPG APP. The ping’s own reason is your clue, and it changes as you fix things.
This fabric worked before a change. Start with show faults on the APIC, then fix each cause. PC1 (192.168.10.10, gateway .254) sits in EPG WEB and PC2 (192.168.20.20, gateway .254) in EPG APP, with a contract between them. Three tenant settings are wrong, and hosts can’t reach their gateways.
This fabric worked before a change. Start with show faults on the APIC, then fix each cause. L104 runs BGP with R1, and PC1 on L101 has no way out. Someone started on fabric BGP and left it wrong.
This fabric worked before a change. Start with show faults on the APIC, then fix each cause. Fabric BGP is fine, and the L3Out to R1 is built, but PC1 can’t reach 10.100.100.1, and R1 has no route to PC1. Three settings are wrong.
Build an entire fabric from blank switches for three tenants with three kinds of exit. PUBLIC reaches the internet router over BGP. INTERNAL reaches the campus router over OSPF, and its hosts sit behind a classic switch on a vPC. DMZ must send everything through ASA1 before the internet, so its VRF is split in two, with a service graph between them. Only the outside routers are configured. Their addresses, and the tenants’ subnets, are in the tasks.
