In this part we are going to look at the L2VNI setup of the topology. This is basically the VLAN setup of the topology where we can define the vlans in use.
Lets remind ourselves of the topology:
The L2VNI setup is isolated to the leaves as the spines are not involved and are not specifically configured with the underlying VNI setup.
L2VNI Configuration
In our topology, we have servers in vlan 10. By the end of this part, the servers will be able to communicate at layer 2 despite being separated by layer 3 boundaries.
The L2VNI configuration is nice and simple and means it can be replicated for as many layer 2 domain as your needs require.
Lets look at vlan 10 first:
vlan 10
vn-segment 100010
interface nve1
member vni 100010
suppress-arp
mcast-group 224.1.1.192
evpn
vni 100010 l2
rd auto
route-target import auto
route-target export autoThe configuration above creates the vlan and assigns the vn-segment ID for the vlan, this should match across the topology for this vlan. Next, we add the vni into the nve interface and add the command to suppress arp, this is a very useful command which allows the leaves to cache mac addresses of nodes attached to prevent excessive ARP messages being sent across the fabric.
The last part of the configuration adds the vni to the evpn control plane so it can be pushed into the MP-BGP topology.
As you can tell, the configuration is very simple to add new L2VNIs.
Verification
Let move the server vPC interfaces onto the correct vlan:
interface port-channel2
switchport access vlan 10We should in theory now have layer 2 communication between the servers, lets test that fact between server-1-vl10 and server-2-vl10:
Success! we have layer 2 connectivity. Lets do a few commands to confirm whats happening.
We can check the arp cache on the local vPC leaves to show the flood and learn technique in action:
LEAF-1(config)# show ip arp suppression-cache vlan 10
Flags: + - Adjacencies synced via CFSoE
L - Local Adjacency
R - Remote Adjacency
L2 - Learnt over L2 interface
PS - Added via L2RIB, Peer Sync
RO - Dervied from L2RIB Peer Sync Entry
Ip Address Age Mac Address Vlan Physical-ifindex Flags Remote Vtep Addrs
10.1.1.1 00:00:16 c29b.c4cc.04ef 10 port-channel2 L2
10.1.1.2 00:00:17 4e29.205e.baf4 10 (null) R 10.0.1.102 LEAF-2(config)# show ip arp suppression-cache vlan 10
Flags: + - Adjacencies synced via CFSoE
L - Local Adjacency
R - Remote Adjacency
L2 - Learnt over L2 interface
PS - Added via L2RIB, Peer Sync
RO - Dervied from L2RIB Peer Sync Entry
Ip Address Age Mac Address Vlan Physical-ifindex Flags Remote Vtep Addrs
10.1.1.1 00:00:19 c29b.c4cc.04ef 10 port-channel2 L2
10.1.1.2 00:00:20 4e29.205e.baf4 10 (null) R 10.0.1.102 We can see from LEAF-1 we have 10.1.1.1 (server-1-vl10) learnt locally and then 10.1.1.2 (server-2-vl10) learnt remotely from the remote vtep of 10.0.1.102 which is important as thats the secondary IP address we configured that is common between both vPC members, meaning this entry isn't tied to a single VTEP, but both of them.
We can also check the BGP l2vpn evpn table for the address 10.1.1.2 on LEAF-1:
LEAF-1# show bgp l2vpn evpn 10.1.1.2
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.0.0.3:32777 (L2VNI 100010)
BGP routing table entry for [2]:[0]:[0]:[48]:[4e29.205e.baf4]:[32]:[10.1.1.2]/248, version 333
Paths: (2 available, best #2)
Flags: (0x000212) (high32 00000000) on xmit-list, is in l2rib/evpn, is not in HW
Path type: internal, path is valid, not best reason: Router Id, no labeled nexthop
Imported from 10.0.0.6:32777:[2]:[0]:[0]:[48]:[4e29.205e.baf4]:[32]:[10.1.1.2]/248
AS-Path: NONE, path sourced internal to AS
10.0.1.102 (metric 81) from 10.0.0.1 (10.0.0.1)
Origin IGP, MED not set, localpref 100, weight 0
Received label 100010
Extcommunity: RT:64500:100010 SOO:10.0.1.102:0 ENCAP:8
Originator: 10.0.0.6 Cluster list: 10.0.0.1
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop, in rib
Imported from 10.0.0.5:32777:[2]:[0]:[0]:[48]:[4e29.205e.baf4]:[32]:[10.1.1.2]/248
AS-Path: NONE, path sourced internal to AS
10.0.1.102 (metric 81) from 10.0.0.1 (10.0.0.1)
Origin IGP, MED not set, localpref 100, weight 0
Received label 100010
Extcommunity: RT:64500:100010 SOO:10.0.1.102:0 ENCAP:8
Originator: 10.0.0.5 Cluster list: 10.0.0.1
Path-id 1 not advertised to any peer
Route Distinguisher: 10.0.0.5:32777
BGP routing table entry for [2]:[0]:[0]:[48]:[4e29.205e.baf4]:[32]:[10.1.1.2]/248, version 328
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.0.1.102 (metric 81) from 10.0.0.2 (10.0.0.2)
Origin IGP, MED not set, localpref 100, weight 0
Received label 100010
Extcommunity: RT:64500:100010 SOO:10.0.1.102:0 ENCAP:8
Originator: 10.0.0.5 Cluster list: 10.0.0.2
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop
Imported to 1 destination(s)
Imported paths list: L2-100010
AS-Path: NONE, path sourced internal to AS
10.0.1.102 (metric 81) from 10.0.0.1 (10.0.0.1)
Origin IGP, MED not set, localpref 100, weight 0
Received label 100010
Extcommunity: RT:64500:100010 SOO:10.0.1.102:0 ENCAP:8
Originator: 10.0.0.5 Cluster list: 10.0.0.1
Path-id 1 not advertised to any peer
Route Distinguisher: 10.0.0.6:32777
BGP routing table entry for [2]:[0]:[0]:[48]:[4e29.205e.baf4]:[32]:[10.1.1.2]/248, version 332
Paths: (2 available, best #1)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop
Imported to 1 destination(s)
Imported paths list: L2-100010
AS-Path: NONE, path sourced internal to AS
10.0.1.102 (metric 81) from 10.0.0.1 (10.0.0.1)
Origin IGP, MED not set, localpref 100, weight 0
Received label 100010
Extcommunity: RT:64500:100010 SOO:10.0.1.102:0 ENCAP:8
Originator: 10.0.0.6 Cluster list: 10.0.0.1
Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.0.1.102 (metric 81) from 10.0.0.2 (10.0.0.2)
Origin IGP, MED not set, localpref 100, weight 0
Received label 100010
Extcommunity: RT:64500:100010 SOO:10.0.1.102:0 ENCAP:8
Originator: 10.0.0.6 Cluster list: 10.0.0.2
Path-id 1 not advertised to any peerNow, thats a lot of output. But, lets break it down. We can see the top route is attached to the RD 10.0.0.3:32777. We can see that it was imported from the RD 10.0.0.6:32777 which is leaf-4 and another from 10.0.0.5:32777 which is leaf-3, these are where the remote endpoint are connected. The next hop on all of the routes is 10.0.1.102 which shows the advertise-pip BGP command is working.
We also see a SOO (Site of Origin) on these routes. This is a loop prevention method used to stop a vPC switch learning routes from its peer.
We can also see the MAC address and IP address of server-2 in the entry to confirm its the correct mapping.
On the RDs 10.0.0.5:32777 and 10.0.0.6:32777 we can see that these routes have been imported into the L2VNI L2-100010, as these are the routes that have actually come from the remote leaves, 10.0.0.3:32777 is essentially an import of these routes into its own routing table.
Note - The mac addresses are learnt as normal so a host has to communicate on the network for the leaf to grab its MAC address and advertise it. This is the role of arp suppression in flood and learn.
In the next part we will look at setting up anycast gateways for the L2VNIs so we can start the process of getting the hosts of their layer 2 network.
0 Comments