# lab05-VxLAN-L2 ### Task VxLAN. L2 VNI Set up an Overlay using VXLAN EVPN to provide Layer 2 connectivity between host-clients. Configure BGP peering between Leaf and Spine nodes using `address-family l2vpn evpn`. Establish Layer 2 connectivity between clients in Zone 1, and verify that it is operational ### Network diagram ![stand-plan](https://content.gitbook.com/content/t770ZYQYIfz1HzwklrwS/blobs/avGInTKIKjahgMdNgh11/stand-plan.png) The lab is built using the following role-based device mapping host- linux, leaf - frr, spine - arista **Underlay IP Address Allocation** • Underlay addressing follows the format 10.x.y.z, where: ⁠◦ x = Data Center ID ⁠◦ y = Spine switch ID ⁠◦ z = Sequential host address per leaf connection • Host addressing uses the 172.16.x.z/24 format, where: ⁠◦ x = Leaf switch ID ⁠◦ z = Sequential host address ⁠◦ Each leaf switch uses .1 as its own IP in the corresponding subnet • Loopback addressing uses 192.168.a.b/32, where: ⁠◦ a = 1 for spine switches ⁠◦ a = 2 for leaf switches ⁠◦ b = Spine or leaf ID (assigned sequentially) • IPv6 addressing uses fd00::\[IPv4] Interconnect ipv4 ipv6 | Device A | Interface A | IPv4 A | IPv6 A | Device B | Interface B | IPv4 B | IPv6 B | | -------- | ----------- | -------------- | -------------------- | -------- | ----------- | ---------------- | ------------------ | | Spine-1 | Eth1 | 10.1.1.0/31 | fd00::10:1:1:0/127 | Leaf-1 | Eth1 | 10.1.1.1/31 | fd00::10:1:1:1/127 | | Spine-1 | Eth2 | 10.1.1.2/31 | fd00::10:1:1:2/127 | Leaf-2 | Eth1 | 10.1.1.3/31 | fd00::10:1:1:3/127 | | Spine-1 | Eth3 | 10.1.1.4/31 | fd00::10:1:1:4/127 | Leaf-3 | Eth1 | 10.1.1.5/31 | fd00::10:1:1:5/127 | | Spine-2 | Eth2 | 10.1.2.0/31 | fd00::10:2:1:0/127 | Leaf-1 | Eth2 | 10.1.2.1/31 | fd00::10:2:1:1/127 | | Spine-2 | Eth2 | 10.1.2.2/31 | fd00::10:2:1:2/127 | Leaf-2 | Eth2 | 10.1.2.3/31 | fd00::10:2:1:3/127 | | Spine-2 | Eth3 | 10.1.2.4/31 | fd00::10:2:1:4/127 | Leaf-3 | Eth2 | 10.1.2.5/31 | fd00::10:2:1:5/127 | | Host-1 | Eth1 | 172.16.1.11/24 | fd00::172:16:1:b/116 | Leaf-1 | Eth3 | access vlan red | access vlan red | | Host-2 | Eth1 | 172.16.2.12/24 | fd00::172:16:2:c/116 | Leaf-2 | Eth3 | access vlan blue | access vlan blue | | Host-3 | Eth1 | 172.16.1.13/24 | fd00::172:16:3:e/116 | Leaf-3 | Eth3 | access vlan red | access vlan red | | Host-4 | Eth1 | 172.16.2.14/24 | fd00::172:16:4:d/116 | Leaf-3 | Eth4 | access vlan blue | access vlan blue | loopback | Device | Loopback ipv4 | loopback ipv6 | | ------- | ------------- | ----------------- | | Spine-1 | 192.168.1.1 | fd00::192:168:1:1 | | Spine-2 | 192.168.1.2 | fd00::192:168:1:2 | | Leaf-1 | 192.168.2.1 | fd00::192:168:2:1 | | Leaf-2 | 192.168.2.2 | fd00::192:168:2:2 | | Leaf-3 | 192.168.2.3 | fd00::192:168:2:3 | Network based on ospf(underlay)+ibgp(overlay). Area ospf 0, bgp as 65500 ### **Launching a lab in the Netlab** It all seemed straightforward, but I spent a long time troubleshooting FRR access behavior. If you assign connected interfaces out of order, it causes mismatches — FRR ends up configuring interfaces that don’t match the actual bridge interfaces inside the Alpine Linux container running FRR. Additionally, I wasn’t satisfied with the default behavior where a BGP session is created between spine nodes acting as route reflectors, even though there’s no direct link between them. This session seems unnecessary in topologies where spine nodes are only meant to reflect routes and not peer directly. So I dove into the code — specifically into: `/usr/local/lib/python3.10/dist-packages/netsim/modules/bgp.py` While reviewing it, I discovered that when route reflectors are present, Netlab does not build a full mesh. Instead, it creates sessions only from RR nodes, but doesn’t handle peering between multiple RRs. I added a conditional check to support RR-to-RR sessions — and Netlab promptly broke. After revisiting some Python basics, I realized the issue was indentation-related. Once I fixed the formatting, Netlab launched successfully. Everything seemed fine, but I realized that my change unconditionally disables the RR-to-RR session. Polling fellow network engineers didn’t yield a clear reason why such a session might be needed — but I figured someone might find it useful in specific topologies. So I added a control parameter to the handler: `/usr/local/lib/python3.10/dist-packages/netsim/modules/bgp.yml` This parameter allows users to toggle RR-to-RR session creation. Default value: False. I had to restart the lab a couple of times to validate the logic and ensure the change didn’t break anything. I’m attaching the modified bgp.py and bgp.yml files here, in case someone stumbles upon this before I get around to contributing it upstream to the Netlab project. [bgp.py](https://github.com/aeangel/otus-DC-net/blob/main/lab05/bgp.py) [bgp.yml](https://github.com/aeangel/otus-DC-net/blob/main/lab05/bgp.yml) File [Topology](https://github.com/aeangel/otus-DC-net/blob/main/lab05/topology.yml) For quick reference, here’s the inline listing:
topology.yml ```yml --- provider: clab module: [ vlan,vxlan,ospf,bgp,evpn,bfd ] plugin: [ bgp.session ] #bgp bgp.bfd: True bgp.as: 65500 tools: edgeshark: graphite: nodes: s1: device: eos id: 1 bgp.rr: True loopback: ipv4: 192.168.1.1/32 ipv6: fd00::192:168:1:1/128 s2: device: eos id: 2 bgp.rr: True loopback: ipv4: 192.168.1.2/32 ipv6: fd00::192:168:1:2/128 l1: device: frr id: 3 loopback: ipv4: 192.168.2.1/32 ipv6: fd00::192:168:2:1/128 l2: device: frr id: 4 loopback: ipv4: 192.168.2.2/32 ipv6: fd00::192:168:2:2/128 l3: device: frr id: 5 loopback: ipv4: 192.168.2.3/32 ipv6: fd00::192:168:2:3/128 h1: id: 11 device: linux h2: id: 12 device: linux h3: id: 13 device: linux h4: id: 14 device: linux #vlan vlans: red: mode: bridge prefix: ipv4: 172.16.1.0/24 ipv6: fd00::172:16:1:0/116 blue: mode: bridge prefix: ipv4: 172.16.2.0/24 ipv6: fd00::172:16:2:0/116 links: #spine1-leaf1,2,3 - interfaces: - node: s1 ifname: eth1 ipv4: 10.1.1.0 ipv6: fd00::10:1:1:0 ospf: password: 'spine1' bfd: true - node: l1 ifname: eth1 ipv4: 10.1.1.1 ipv6: fd00::10:1:1:1 ospf: password: 'spine1' bfd: true prefix: ipv4: 10.1.1.0/31 ipv6: fd00::10:1:1:0/127 - interfaces: - node: s1 ifname: eth2 ipv4: 10.1.1.2 ipv6: fd00::10:1:1:2 ospf: password: 'spine1' bfd: true - node: l2 ifname: eth1 ipv4: 10.1.1.3 ipv6: fd00::10:1:1:3 ospf: password: 'spine1' bfd: true prefix: ipv4: 10.1.1.2/31 ipv6: fd00::10:1:1:2/127 - interfaces: - node: s1 ifname: eth3 ipv4: 10.1.1.4 ipv6: fd00::10:1:1:4 ospf: password: 'spine1' bfd: true - node: l3 ifname: eth1 ipv4: 10.1.1.5 ipv6: fd00::10:1:1:5 ospf: password: 'spine1' bfd: true prefix: ipv4: 10.1.1.4/31 ipv6: fd00::10:1:1:4/127 #spine2-leaf1,2,3 - interfaces: - node: s2 ifname: eth1 ipv4: 10.1.2.0 ipv6: fd00::10:1:2:0 ospf: password: 'spine2' bfd: true - node: l1 ifname: eth2 ipv4: 10.1.2.1 ipv6: fd00::10:1:2:1 ospf: password: 'spine2' bfd: true prefix: ipv4: 10.1.2.0/31 ipv6: fd00::10:1:2:0/127 - interfaces: - node: s2 ifname: eth2 ipv4: 10.1.2.2 ipv6: fd00::10:1:2:2 ospf: password: 'spine2' bfd: true - node: l2 ifname: eth2 ipv4: 10.1.2.3 ipv6: fd00::10:1:2:3 ospf: password: 'spine2' bfd: true prefix: ipv4: 10.1.2.2/31 ipv6: fd00::10:1:2:2/127 - interfaces: - node: s2 ifname: eth3 ipv4: 10.1.2.4 ipv6: fd00::10:1:2:4 ospf: password: 'spine2' bfd: true - node: l3 ifname: eth2 ipv4: 10.1.2.5 ipv6: fd00::10:1:2:5 ospf: password: 'spine2' bfd: true prefix: ipv4: 10.1.2.4/31 ipv6: fd00::10:1:2:4/127 #host1 - interfaces: - node: h1 ifname: eth1 - node: l1 ifname: eth3 vlan.access: red #host2 - interfaces: - node: h2 ifname: eth1 - node: l2 ifname: eth3 vlan.access: blue #host3 - interfaces: - node: h3 ifname: eth1 - node: l3 ifname: eth3 vlan.access: red #host4 - interfaces: - node: h4 ifname: eth1 - node: l3 ifname: eth4 vlan.access: blue ```
### Validating What was our intended outcome? Establish connectivity between h1 and h3, and between h2 and h4, respectively — and ensure it works via VXLAN. We launch the lab and start verifying with ping tests.
h1 pings ```txt lh1:/# ping h3 PING h3 (172.16.1.13): 56 data bytes 64 bytes from 172.16.1.13: seq=0 ttl=64 time=0.786 ms 64 bytes from 172.16.1.13: seq=1 ttl=64 time=0.965 ms 64 bytes from 172.16.1.13: seq=2 ttl=64 time=0.914 ms 64 bytes from 172.16.1.13: seq=3 ttl=64 time=0.975 ms ^C --- h3 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.786/0.910/0.975 ms h1:/# ping6 h3 PING h3 (fd00::172:16:1:d): 56 data bytes 64 bytes from fd00::172:16:1:d: seq=0 ttl=64 time=1.686 ms 64 bytes from fd00::172:16:1:d: seq=1 ttl=64 time=0.852 ms 64 bytes from fd00::172:16:1:d: seq=2 ttl=64 time=0.905 ms 64 bytes from fd00::172:16:1:d: seq=3 ttl=64 time=1.057 ms x64 bytes from fd00::172:16:1:d: seq=4 ttl=64 time=0.860 ms ^C --- h3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.852/1.072/1.686 ms ```
h4 pings ```txt h4:/# ping h2 PING h2 (172.16.2.12): 56 data bytes 64 bytes from 172.16.2.12: seq=0 ttl=64 time=1.647 ms 64 bytes from 172.16.2.12: seq=1 ttl=64 time=0.915 ms 64 bytes from 172.16.2.12: seq=2 ttl=64 time=0.883 ms 64 bytes from 172.16.2.12: seq=3 ttl=64 time=0.848 ms 64 bytes from 172.16.2.12: seq=4 ttl=64 time=0.971 ms ^C --- h2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.848/1.052/1.647 ms h4:/# ping6 h2 PING h2 (fd00::172:16:2:c): 56 data bytes 64 bytes from fd00::172:16:2:c: seq=0 ttl=64 time=1.910 ms 64 bytes from fd00::172:16:2:c: seq=1 ttl=64 time=0.982 ms 64 bytes from fd00::172:16:2:c: seq=2 ttl=64 time=1.177 ms 64 bytes from fd00::172:16:2:c: seq=3 ttl=64 time=1.105 ms 64 bytes from fd00::172:16:2:c: seq=4 ttl=64 time=1.021 ms ^C --- h2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.982/1.239/1.910 ms ```
Ping traffic between hosts is flowing — which means it's time to inspect what's happening on the leaf and spine nodes. We’ll check routing tables, EVPN advertisements, and other control plane details. Since EVPN is up and running for both IPv4 and IPv6, things might get interesting. To keep track of MAC-to-host mappings, let’s introduce a MAC address table for all devices. | Host | MAC | ipv4 | ipv6 | ipv6 local | vlan | vni | | ---- | ----------------- | -------------- | -------------------- | ---------------------------- | ---- | ------ | | h1 | aa:c1:ab:0d:85:f0 | 172.16.1.11/24 | fd00::172:16:1:b/116 | fe80::a8c1:abff:fe0d:85f0/64 | red | 101000 | | h2 | aa:c1:ab:a5:c3:48 | 172.16.2.12/24 | fd00::172:16:2:c/116 | fe80::a8c1:abff:fea5:c348/64 | blue | 101001 | | h3 | aa:c1:ab:cb:d4:25 | 172.16.1.13/24 | fd00::172:16:1:d/116 | fe80::a8c1:abff:fecb:d425/64 | red | 101000 | | h4 | aa:c1:ab:60:b1:45 | 172.16.2.14/24 | fd00::172:16:2:e/116 | fe80::a8c1:abff:fe60:b145/64 | blue | 101001 | Here’s what spine-1 reports about our EVPN state:
spine-1 show evpn ``` s1#show bgp evpn vni 101000 BGP routing table information for VRF default Router identifier 192.168.1.1, local AS number 65500 Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP c - Contributing to ECMP, % - Pending best path selection Origin codes: i - IGP, e - EGP, ? - incomplete AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop Network Next Hop Metric LocPref Weight Path * >Ec RD: 192.168.2.1:1000 mac-ip 52dc.cafd.0300 fe80::50dc:caff:fefd:300 192.168.2.1 - 100 0 i * ec RD: 192.168.2.1:1000 mac-ip 52dc.cafd.0300 fe80::50dc:caff:fefd:300 192.168.2.1 - 100 0 i * >Ec RD: 192.168.2.3:1000 mac-ip 52dc.cafd.0500 fe80::50dc:caff:fefd:500 192.168.2.3 - 100 0 i * ec RD: 192.168.2.3:1000 mac-ip 52dc.cafd.0500 fe80::50dc:caff:fefd:500 192.168.2.3 - 100 0 i * >Ec RD: 192.168.2.1:1000 mac-ip aac1.ab0d.85f0 192.168.2.1 - 100 0 i * ec RD: 192.168.2.1:1000 mac-ip aac1.ab0d.85f0 192.168.2.1 - 100 0 i * >Ec RD: 192.168.2.1:1000 mac-ip aac1.ab0d.85f0 fe80::a8c1:abff:fe0d:85f0 192.168.2.1 - 100 0 i * ec RD: 192.168.2.1:1000 mac-ip aac1.ab0d.85f0 fe80::a8c1:abff:fe0d:85f0 192.168.2.1 - 100 0 i * >Ec RD: 192.168.2.3:1000 mac-ip aac1.abcb.d425 192.168.2.3 - 100 0 i * ec RD: 192.168.2.3:1000 mac-ip aac1.abcb.d425 192.168.2.3 - 100 0 i * >Ec RD: 192.168.2.3:1000 mac-ip aac1.abcb.d425 fe80::a8c1:abff:fecb:d425 192.168.2.3 - 100 0 i * ec RD: 192.168.2.3:1000 mac-ip aac1.abcb.d425 fe80::a8c1:abff:fecb:d425 192.168.2.3 - 100 0 i * >Ec RD: 192.168.2.1:1000 imet 192.168.2.1 192.168.2.1 - 100 0 i * ec RD: 192.168.2.1:1000 imet 192.168.2.1 192.168.2.1 - 100 0 i * >Ec RD: 192.168.2.3:1000 imet 192.168.2.3 192.168.2.3 - 100 0 i * ec RD: 192.168.2.3:1000 imet 192.168.2.3 192.168.2.3 - 100 0 i s1#show bgp evpn vni 101001 BGP routing table information for VRF default Router identifier 192.168.1.1, local AS number 65500 Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP c - Contributing to ECMP, % - Pending best path selection Origin codes: i - IGP, e - EGP, ? - incomplete AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop Network Next Hop Metric LocPref Weight Path * >Ec RD: 192.168.2.2:1001 mac-ip 52dc.cafd.0400 fe80::50dc:caff:fefd:400 192.168.2.2 - 100 0 i * ec RD: 192.168.2.2:1001 mac-ip 52dc.cafd.0400 fe80::50dc:caff:fefd:400 192.168.2.2 - 100 0 i * >Ec RD: 192.168.2.3:1001 mac-ip 52dc.cafd.0501 fe80::50dc:caff:fefd:501 192.168.2.3 - 100 0 i * ec RD: 192.168.2.3:1001 mac-ip 52dc.cafd.0501 fe80::50dc:caff:fefd:501 192.168.2.3 - 100 0 i * >Ec RD: 192.168.2.3:1001 mac-ip aac1.ab60.b145 192.168.2.3 - 100 0 i * ec RD: 192.168.2.3:1001 mac-ip aac1.ab60.b145 192.168.2.3 - 100 0 i * >Ec RD: 192.168.2.3:1001 mac-ip aac1.ab60.b145 fe80::a8c1:abff:fe60:b145 192.168.2.3 - 100 0 i * ec RD: 192.168.2.3:1001 mac-ip aac1.ab60.b145 fe80::a8c1:abff:fe60:b145 192.168.2.3 - 100 0 i * >Ec RD: 192.168.2.2:1001 mac-ip aac1.aba5.c348 192.168.2.2 - 100 0 i * ec RD: 192.168.2.2:1001 mac-ip aac1.aba5.c348 192.168.2.2 - 100 0 i * >Ec RD: 192.168.2.2:1001 mac-ip aac1.aba5.c348 fe80::a8c1:abff:fea5:c348 192.168.2.2 - 100 0 i * ec RD: 192.168.2.2:1001 mac-ip aac1.aba5.c348 fe80::a8c1:abff:fea5:c348 192.168.2.2 - 100 0 i * >Ec RD: 192.168.2.2:1001 imet 192.168.2.2 192.168.2.2 - 100 0 i * ec RD: 192.168.2.2:1001 imet 192.168.2.2 192.168.2.2 - 100 0 i * >Ec RD: 192.168.2.3:1001 imet 192.168.2.3 192.168.2.3 - 100 0 i * ec RD: 192.168.2.3:1001 imet 192.168.2.3 192.168.2.3 - 100 0 i ```
As we can see, both link-local addresses and vlan-if interfaces — which are bound inside FRR — are being propagated. Below is an excerpt from ip a on leaf-3. ``` 3: vlan1000: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 52:dc:ca:fd:05:00 brd ff:ff:ff:ff:ff:ff inet6 fe80::50dc:caff:fefd:500/64 scope link valid_lft forever preferred_lft forever 4: vlan1001: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 52:dc:ca:fd:05:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::50dc:caff:fefd:501/64 scope link valid_lft forever preferred_lft forever ``` And here’s the EVPN route output from leaf-3:
leaf-3 show evpn ``` l3# show bgp evpn route vni 101000 BGP table version is 1164, local router ID is 192.168.2.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id] EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] Network Next Hop Metric LocPrf Weight Path *>i [2]:[0]:[48]:[52:dc:ca:fd:03:00]:[128]:[fe80::50dc:caff:fefd:300] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *=i [2]:[0]:[48]:[52:dc:ca:fd:03:00]:[128]:[fe80::50dc:caff:fefd:300] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *=i [2]:[0]:[48]:[52:dc:ca:fd:03:00]:[128]:[fe80::50dc:caff:fefd:300] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *=i [2]:[0]:[48]:[52:dc:ca:fd:03:00]:[128]:[fe80::50dc:caff:fefd:300] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *> [2]:[0]:[48]:[52:dc:ca:fd:05:00]:[128]:[fe80::50dc:caff:fefd:500] 192.168.2.3(l3) 32768 i ET:8 RT:65500:1000 *>i [2]:[0]:[48]:[aa:c1:ab:0d:85:f0]:[128]:[fe80::a8c1:abff:fe0d:85f0] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *=i [2]:[0]:[48]:[aa:c1:ab:0d:85:f0]:[128]:[fe80::a8c1:abff:fe0d:85f0] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *=i [2]:[0]:[48]:[aa:c1:ab:0d:85:f0]:[128]:[fe80::a8c1:abff:fe0d:85f0] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *=i [2]:[0]:[48]:[aa:c1:ab:0d:85:f0]:[128]:[fe80::a8c1:abff:fe0d:85f0] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *> [2]:[0]:[48]:[aa:c1:ab:cb:d4:25]:[128]:[fe80::a8c1:abff:fecb:d425] 192.168.2.3(l3) 32768 i ET:8 RT:65500:1000 *>i [3]:[0]:[32]:[192.168.2.1] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *=i [3]:[0]:[32]:[192.168.2.1] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *=i [3]:[0]:[32]:[192.168.2.1] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *=i [3]:[0]:[32]:[192.168.2.1] 192.168.2.1 100 0 i RT:65500:1000 ET:8 *> [3]:[0]:[32]:[192.168.2.3] 192.168.2.3(l3) 32768 i ET:8 RT:65500:1000 Displayed 6 prefixes (15 paths) l3# show bgp evpn route vni 101001 BGP table version is 1170, local router ID is 192.168.2.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id] EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] Network Next Hop Metric LocPrf Weight Path *>i [2]:[0]:[48]:[52:dc:ca:fd:04:00]:[128]:[fe80::50dc:caff:fefd:400] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *=i [2]:[0]:[48]:[52:dc:ca:fd:04:00]:[128]:[fe80::50dc:caff:fefd:400] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *=i [2]:[0]:[48]:[52:dc:ca:fd:04:00]:[128]:[fe80::50dc:caff:fefd:400] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *=i [2]:[0]:[48]:[52:dc:ca:fd:04:00]:[128]:[fe80::50dc:caff:fefd:400] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *> [2]:[0]:[48]:[52:dc:ca:fd:05:01]:[128]:[fe80::50dc:caff:fefd:501] 192.168.2.3(l3) 32768 i ET:8 RT:65500:1001 *> [2]:[0]:[48]:[aa:c1:ab:60:b1:45]:[128]:[fe80::a8c1:abff:fe60:b145] 192.168.2.3(l3) 32768 i ET:8 RT:65500:1001 *>i [2]:[0]:[48]:[aa:c1:ab:a5:c3:48]:[128]:[fe80::a8c1:abff:fea5:c348] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *=i [2]:[0]:[48]:[aa:c1:ab:a5:c3:48]:[128]:[fe80::a8c1:abff:fea5:c348] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *=i [2]:[0]:[48]:[aa:c1:ab:a5:c3:48]:[128]:[fe80::a8c1:abff:fea5:c348] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *=i [2]:[0]:[48]:[aa:c1:ab:a5:c3:48]:[128]:[fe80::a8c1:abff:fea5:c348] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *>i [3]:[0]:[32]:[192.168.2.2] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *=i [3]:[0]:[32]:[192.168.2.2] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *=i [3]:[0]:[32]:[192.168.2.2] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *=i [3]:[0]:[32]:[192.168.2.2] 192.168.2.2 100 0 i RT:65500:1001 ET:8 *> [3]:[0]:[32]:[192.168.2.3] 192.168.2.3(l3) 32768 i ET:8 RT:65500:1001 Displayed 6 prefixes (15 paths) ```
If you take a look in Wireshark, you can observe Type 2 route exchanges happening on the leaf node. ![bgp-update](https://content.gitbook.com/content/t770ZYQYIfz1HzwklrwS/blobs/TyrXQ7k3iLkx8939jdDx/bgp-update.png) One of the most surprising discoveries was that Type 2 EVPN routes also carry IPv6 link-local addresses. ![bgp-updateipv6](https://content.gitbook.com/content/t770ZYQYIfz1HzwklrwS/blobs/ELoWw18WeikCK7Ljm0EQ/bgp-updateipv6.png) It’s easy to retrieve config files using: `netlab collect` Device configuration files: [Spine-1](https://github.com/aeangel/otus-DC-net/blob/main/lab05/s1.cfg) [Spine-2](https://github.com/aeangel/otus-DC-net/blob/main/lab05/s2.cfg) [Leaf-1 ](https://github.com/aeangel/otus-DC-net/blob/main/lab05/l1.cfg)[Leaf-2](https://github.com/aeangel/otus-DC-net/blob/main/lab05/l2.cfg) [Leaf-3](https://github.com/aeangel/otus-DC-net/blob/main/lab05/l3.cfg)