VXLAN Questions

[carl_townshend]

Hi All

I am working on a vxlan lab in cml and have it up and running between 2 8000v switches using IOS-XE.

I have some questions.

1.I want to create multiple vlans for my vxlan config, is the below the way to do it? and is the below where you map the vlan to vni?

l2vpn evpn instance 101 vlan-based
encapsulation vxlan

!

l2vpn evpn instance 102 vlan-based
encapsulation vxlan

!

vlan configuration 101
member evpn-instance 101 vni 10101
vlan dot1q tag native

!

vlan configuration 102
member evpn-instance 102 vni 10102
vlan dot1q tag native

!

interface nve1
no ip address
source-interface Loopback1
host-reachability protocol bgp
member vni 10101-10102 mcast-group 225.0.0.101

2.Can you use the same multicast group for the VNI's? or should you have a group per VNI? if you can do multiple, what is the recommended number per multicast group?

3.Does it actually create tunnels? or does it simply just send individual packets with an outer header, so no tunnel per se?

4.I have 2 switches with vxlan running between them, I want to put anycast gateway on each of them, how does it work, if a host on leaf 1 arps for its gateway, would leaf 1 respond to this arp? and is it clever enough not to send this arp over the overlay to the other leaf? I believe bgp sends this as an extended community value to the other leaf and it installs a route pointing locally, is this correct?

[Flavio Miranda]

@carl_townshend 

1.I want to create multiple vlans for my vxlan config, is the below the way to do it?

This is the basic config but if  you aim to work with Multicast, you need one step more.

Device(config-evpn)# replication-type static

and is the below where you map the vlan to vni?

Yes, with the command below:

member evpn-instance 101 vni 10101

2.Can you use the same multicast group for the VNI's? or should you have a group per VNI? 

Yes. But...

"mapping multiple VXLAN segments to a single multicast group can help conserve multicast control plane resources on the core devices and achieve the desired VXLAN scalability. However, this mapping comes at the cost of suboptimal multicast forwarding. Packets forwarded to the multicast group for one tenant are now sent to the VTEPs of other tenants that are sharing the same multicast group. This causes inefficient utilization of multicast data plane resources. Therefore, this solution is a trade-off between control plane scalability and data plane efficiency. "

if you can do multiple, what is the recommended number per multicast group?

I dont believe there will be a number but we know IANA has reversed the range "224.0.0.0 through 239.255.255.255" for multicast and this can be the limitation.

3.Does it actually create tunnels? or does it simply just send individual packets with an outer header, so no tunnel per se?

Yes, it does and the concept of outer header is the same as tunnel.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-1/configuration_guide/vxlan/b_171_bgp_evpn_vxlan_9500_cg/configuring_evpn_vxlan_layer_2_overlay_network.html

4.I have 2 switches with vxlan running between them, I want to put anycast gateway on each of them, how does it work, if a host on leaf 1 arps for its gateway, would leaf 1 respond to this arp? and is it clever enough not to send this arp over the overlay to the other leaf?

I believe this is the whole idea of fabric. I recommend the following video as he explained better then I would.

https://www.youtube.com/watch?v=4MpfWgMzMRI

[M02@rt37]

Hello @carl_townshend 

1. Mapping VLAN to VNI

Yes, your configuration is mostly correct. 

l2vpn evpn instance 101 vlan-based
encapsulation vxlan

-- This command creates an EVPN instance for a VLAN and encapsulates it over VXLAN.

vlan configuration 101
member evpn-instance 101 vni 10101

-- This command ties VLAN 10* to EVPN instance 10*, and maps VNI 10101 to that VLAN. This is the way to map your VLANs to VNIs.

interface nve1
no ip address
source-interface Loopback1
host-reachability protocol bgp
member vni 10101-10102 mcast-group 225.0.0.101

-- This binds your VNIs (10101 and 10102) to the multicast group (225.0.0.101). The multicast group is used for BUM (Broadcast, Unknown Unicast, Multicast) traffic forwarding within VXLAN.

2. Using the Same Multicast Group for Multiple VNIs

You can use the same multicast group for multiple VNIs. However, it's generally recommended to use separate multicast groups for scalability and traffic segregation, especially in larger environments.

If multiple VNIs share the same multicast group, the multicast traffic may be unnecessarily replicated to devices that don't need it, causing overhead. The number of VNIs per multicast group will depend on the network size and hardware capabilities, but a typical recommendation is to limit multicast groups to fewer VNIs (e.g., 2-10 VNIs per group) to avoid excessive multicast traffic.

3. Tunnels in VXLAN

VXLAN doesn't technically create static "tunnels" like GRE or IPsec. Instead, it encapsulates Layer 2 frames into VXLAN headers, which are then sent as individual packets over the Layer 3 network with an outer IP header. So, you can think of VXLAN as packet encapsulation, rather than persistent tunnel formation.

Each packet has an outer UDP header and a VXLAN header, containing the VNI to identify the virtual network, but no "tunnel" is kept up at all times.

4. Anycast Gateway in VXLAN

For an anycast gateway to function properly in a VXLAN environment, both leaf switches (8000v in your case) would share the same IP address and MAC address for the gateway. When a host on Leaf 1 ARPs for its gateway, Leaf 1 will respond with the shared anycast MAC addres, and Leaf 1 will forward traffic locally.

VXLAN with EVPN ensures that the ARP request doesn't travel across the overlay to the other leaf because each leaf has a local route pointing to the same gateway IP/MAC address. When the host ARPs, it gets a reply from its local leaf, and there’s no need to forward that ARP to the remote leaf. The EVPN control plane via BGP ensures that the distributed anycast gateway is synchronized across the leaves, and each leaf knows to handle ARP requests locally.

You're correct that BGP EVPN propagates this information (using extended communities), ensuring that the anycast gateway is locally installed on each leaf for traffic originating from hosts connected to that leaf.

[carl_townshend]

Hi, thanks for the response.

Regarding the anycast gateway, in my lab, I have a host connected to leaf 1 and leaf 2, when I look at the arp for its default gateway, I see a different mac address, I see the mac address of the vlan interface locally and they are not the same, is this correct?

Also, I read something on IRB, at the moment I can ping the host on the same vlan on the other end of the tunnel as well as route, is this not IRB ? 

Looking at the config guide from Cisco, there were lots of extra steps to enable IRB it seemed, if that's the case, what exactly is IRB giving you?, the extra config was on here

BGP EVPN VXLAN Configuration Guide, Cisco IOS XE 17.14.x (Catalyst 9500 Switches) - Configuring EVPN VXLAN Integrated Routing and Bridging [Support] - Cisco

[M02@rt37]

@carl_townshend 

Using the command fabric forwarding anycast-gateway-mac <MAC> on all relevant leaf switches helps establish a consistent Anycast Gateway MAC address across your network fabric. This configuration ensures that hosts connected to different leaf switches will see the same gateway MAC address, streamlining network operations and reducing potential issues related to ARP and routing. Just ensure that this command is compatible with your environment and applied correctly on all switches involved.

Regarding IRB, it's a feature that allows you to combine Layer 2 and Layer 3 operations within the same interface or VLAN. This means that you can have routing and bridging functionalities on the same interface, which can simplify the network architecture and configuration. In a traditional setup without IRB, you would typically need separate interfaces for routing (L3) and bridging (L2), which can complicate the network design.

When you mention being able to ping hosts on the same VLAN over the tunnel, that indicates L2 connectivity is working correctly. However, for IRB functionality, you typically need additional configurations, such as creating a bridge domain and linking it to a routing instance. IRB allows for a seamless interaction between routed and bridged traffic, which can be beneficial in scenarios like virtualized environments where both types of traffic need to coexist.

The extra steps you found in the configuration guide for enabling IRB are likely related to setting up bridge domains, configuring VLANs, and establishing routing instances that IRB requires... The main benefit of IRB is the enhanced flexibility and ease of configuration when managing networks that require both L2 and L3 functionalities, especially in complex topologies such as data centers.

[carl_townshend]

Hi, I think the command you posted is for NX-OS not IOS-XE, I already have the command "default-gateway advertise" under the l2vpn evpn config.

I can ping the host on the other end of the tunnel in the same vlan, I can also ping the local vlan interface and route to other vlans, so surely in my setup its doing IRB? I havent added any bridge domains etc.

The config for one of my leafs is below

! Last configuration change at 15:19:00 UTC Wed Oct 2 2024
!
version 17.10
service timestamps debug datetime msec
service timestamps log datetime msec
service call-home
platform punt-keepalive disable-kernel-core
!
hostname Leaf-01
!
!
vrf definition Mgmt-vrf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
no logging console
no aaa new-model
switch 1 provision c9kv-q200-8p
!
!
!
!
ip routing
!
ip multicast-routing
!
!
!
login on-success log
!
!
!
!
!
!
!
l2vpn evpn
replication-type static
router-id Loopback1
default-gateway advertise
!
l2vpn evpn instance 101 vlan-based
encapsulation vxlan
!
l2vpn evpn instance 102 vlan-based
encapsulation vxlan
!
!
!
crypto pki trustpoint SLA-TrustPoint
enrollment pkcs12
revocation-check crl
!
crypto pki trustpoint TP-self-signed-2874884994
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-2874884994
revocation-check none
rsakeypair TP-self-signed-2874884994
!
!
crypto pki certificate chain SLA-TrustPoint
certificate ca 01
30820321 30820209 A0030201 02020101 300D0609 2A864886 F70D0101 0B050030
32310E30 0C060355 040A1305 43697363 6F312030 1E060355 04031317 43697363
6F204C69 63656E73 696E6720 526F6F74 20434130 1E170D31 33303533 30313934
3834375A 170D3338 30353330 31393438 34375A30 32310E30 0C060355 040A1305
43697363 6F312030 1E060355 04031317 43697363 6F204C69 63656E73 696E6720
526F6F74 20434130 82012230 0D06092A 864886F7 0D010101 05000382 010F0030
82010A02 82010100 A6BCBD96 131E05F7 145EA72C 2CD686E6 17222EA1 F1EFF64D
CBB4C798 212AA147 C655D8D7 9471380D 8711441E 1AAF071A 9CAE6388 8A38E520
1C394D78 462EF239 C659F715 B98C0A59 5BBB5CBD 0CFEBEA3 700A8BF7 D8F256EE
4AA4E80D DB6FD1C9 60B1FD18 FFC69C96 6FA68957 A2617DE7 104FDC5F EA2956AC
7390A3EB 2B5436AD C847A2C5 DAB553EB 69A9A535 58E9F3E3 C0BD23CF 58BD7188
68E69491 20F320E7 948E71D7 AE3BCC84 F10684C7 4BC8E00F 539BA42B 42C68BB7
C7479096 B4CB2D62 EA2F505D C7B062A4 6811D95B E8250FC4 5D5D5FB8 8F27D191
C55F0D76 61F9A4CD 3D992327 A8BB03BD 4E6D7069 7CBADF8B DF5F4368 95135E44
DFC7C6CF 04DD7FD1 02030100 01A34230 40300E06 03551D0F 0101FF04 04030201
06300F06 03551D13 0101FF04 05300301 01FF301D 0603551D 0E041604 1449DC85
4B3D31E5 1B3E6A17 606AF333 3D3B4C73 E8300D06 092A8648 86F70D01 010B0500
03820101 00507F24 D3932A66 86025D9F E838AE5C 6D4DF6B0 49631C78 240DA905
604EDCDE FF4FED2B 77FC460E CD636FDB DD44681E 3A5673AB 9093D3B1 6C9E3D8B
D98987BF E40CBD9E 1AECA0C2 2189BB5C 8FA85686 CD98B646 5575B146 8DFC66A8
467A3DF4 4D565700 6ADF0F0D CF835015 3C04FF7C 21E878AC 11BA9CD2 55A9232C
7CA7B7E6 C1AF74F6 152E99B7 B1FCF9BB E973DE7F 5BDDEB86 C71E3B49 1765308B
5FB0DA06 B92AFE7F 494E8A9E 07B85737 F3A58BE1 1A48A229 C37C1E69 39F08678
80DDCD16 D6BACECA EEBC7CF9 8428787B 35202CDC 60E4616A B623CDBD 230E3AFB
418616A9 4093E049 4D10AB75 27E86F73 932E35B5 8862FDAE 0275156F 719BB2F0
D697DF7F 28
quit
crypto pki certificate chain TP-self-signed-2874884994
certificate self-signed 01
30820330 30820218 A0030201 02020101 300D0609 2A864886 F70D0101 05050030
31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 32383734 38383439 3934301E 170D3234 31303031 31333033
30395A17 0D333431 30303131 33303330 395A3031 312F302D 06035504 03132649
4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D32 38373438
38343939 34308201 22300D06 092A8648 86F70D01 01010500 0382010F 00308201
0A028201 0100AE97 80A01C7F 60C4EC1E 88E90238 3FEF386F E59B5A4A FD60671A
78423365 766E78BF C6B6E76B 5F0E0546 78B8AD0D 2238DB9C B0DE309A 5F9D97ED
E076EB29 96E5A5AD 216A6E30 F7ED973A 077BE33B 380030EE 1DB31283 D23282D1
3B14212A BB2A4E17 51AC2B4A 96C986A3 B3C12477 867C5E80 A75688A0 F1D39464
FBEA5564 D05A1FBA D191ADC0 55D36286 21E1FAC1 A564A6B4 EAEBC203 05217B7E
E33BF0C1 94DB05A8 774659B1 8BB066DE 69039422 E6B157DA F83C1838 25352DEF
B8330A4F 421C249C 24A3CEA5 3FEB99C9 71D840F9 D41D01EA C34B969D 7929BF6B
83E5FB5B 6978670E 157AE585 7806625C 4A3721C6 B49C051C D77693D7 3392853F
43264628 47B30203 010001A3 53305130 0F060355 1D130101 FF040530 030101FF
301F0603 551D2304 18301680 1441C518 8F571EC4 0EB7C915 572C9CC8 4BE2CDFF
33301D06 03551D0E 04160414 41C5188F 571EC40E B7C91557 2C9CC84B E2CDFF33
300D0609 2A864886 F70D0101 05050003 82010100 0890634E 6C267A03 8A5032B6
5D61B2CC 67FB3078 20745D13 EBA83F31 9AF2ECAC 606CF68E 28A45C00 A4B58DBF
557D5E76 8D51E670 D2BBAA61 2FFFAEFF E94ADDB6 88CA6E2D A61D3D5C 7532980E
F8B59C1D 3B198E70 98D0CCC5 6C29C9FB 076E2EAA F88C8B49 250AC463 7B593DC3
CB29C99F 220B3CDE 8381D53C EBEF7891 AAFAB79C 4C06E39E 13765C2D C64E0A42
83DBD9CB DBF57F63 3B31C833 7D4B34E7 5D0DF1A3 48E39A09 1DF0DD71 08436667
B6E00CA5 0075A2F9 C337266E 2158CDCB 558EE50F 791B0153 90E07D3D 87E6FA46
C5DD8561 ACC5AB1E 5485EFFE F405030B 9924D750 472F8954 C8CEDBFA 5F46A800
749C5159 9E62337A F36E6E0F FA597839 19F0517D
quit
!
!
license boot level network-advantage
memory free low-watermark processor 180784
!
system mtu 8978
diagnostic bootup level minimal
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
!
enable secret 9 $9$9JbstN1LYlbO0U$g.ASkx6QECTmolMdief65DhzA5zZF6ubUey9GrMQOCs
!
!
redundancy
mode sso
crypto engine compliance shield disable
!
!
!
!
!
vlan configuration 101
member evpn-instance 101 vni 10101
vlan configuration 102
member evpn-instance 102 vni 10102
vlan dot1q tag native
!
!
class-map match-any system-cpp-police-mac-learning
description MAC Learning
class-map match-any system-cpp-police-mcast-data
description MCAST Data traffic
class-map match-any system-cpp-police-topology-control
description Topology control - STP
class-map match-any system-cpp-police-unknown-uc
description Unknown UC Packets
class-map match-any system-cpp-police-sw-forward
description Software forwarding
class-map match-any system-cpp-police-proto-snoop-v6
description Protocol snooping v6
class-map match-any system-cpp-default
description Inter FED Traffic
class-map match-any system-cpp-police-proto-snoop-v4
description Protocol snooping v4
class-map match-any system-cpp-police-rip-bc
description RIP Broadcast
class-map match-any system-cpp-police-svl-ctrl
description NGSVL IPC Traffic
class-map match-any system-cpp-police-mpls-oam
description MPLS OAM (traceroute, ping etc)
class-map match-any system-cpp-police-dhcp-v6
description DHCP V6
class-map match-any system-cpp-police-dhcp-v4
description DHCP V4
class-map match-any system-cpp-police-forus
description Forus Address resolution and Forus traffic
class-map match-any system-cpp-police-icmp-v6
description ICMP redirect, ICMP_GEN over IPv6
class-map match-any system-cpp-police-icmp-v4
description ICMP redirect, ICMP_GEN over IPv4
class-map match-any system-cpp-police-ospf-v6
description OSPF over IPv6
class-map match-any system-cpp-police-ospf-v4
description OSPF over IPv4
class-map match-any system-cpp-police-arp
description Address Resolution Protocol
class-map match-any system-cpp-police-igrp-v4
description IGRP and EIGRP over IPv4
class-map match-any system-cpp-police-fhrp-v4
description VRRP, HSRP, GLBP over IPv4
class-map match-any system-cpp-police-igrp-v6
description IGRP and EIGRP over IPv6
class-map match-any system-cpp-police-fhrp-v6
description VRRP, HSRP, GLBP over IPv6
class-map match-any system-cpp-police-fragment-v4
description IPv4 Fragmented Packets
class-map match-any system-cpp-police-fragment-v6
description IPv6 Fragmented Packets
class-map match-any system-cpp-police-ldp-v4
description LDP (MPLS) over IPv4
class-map match-any system-cpp-police-ldp-v6
description LDP (MPLS) over IPv6
class-map match-any system-cpp-police-l2-control
description L2 control
class-map match-any system-cpp-police-lacp
description LACP control traffic for ether channel
class-map match-any system-cpp-police-bgp-v4
description BGP sessions over IPv4
class-map match-any system-cpp-police-bgp-v6
description BGP sessions over IPv6
class-map match-any system-cpp-police-rip-v6
description RIP over IPv6
class-map match-any system-cpp-police-alt-sw-forward
description Alternate Software forwarding
class-map match-any system-cpp-police-rip-v4
description RIP over IPv4
class-map match-any system-cpp-police-mtu-ttl-fail
description MTU/TTL 0/TTL 1 failures
class-map match-any system-cpp-police-isis
description IS-IS protocol
class-map match-any system-cpp-police-bfd-v4
description BFD and BFD Echo over IPv4
class-map match-any system-cpp-police-udp-v4
description UDP V4
class-map match-any system-cpp-police-mcast-rpf-fail
description MCAST Data RPF fail
class-map match-any system-cpp-police-bfd-v6
description BFD and BFD Echo over IPv6
class-map match-any system-cpp-police-udp-v6
description UDP V6
class-map match-any non-client-nrt-class
class-map match-any system-cpp-police-tcp-v6
description TCP V6
class-map match-any system-cpp-police-tcp-v4
description TCP V4
class-map match-any system-cpp-default-v6
description Inter FED Traffic
class-map match-any system-cpp-default-v4
description Inter FED Traffic
class-map match-any system-cpp-police-dhcp-snooping
description DHCP snooping
class-map match-any system-cpp-police-svl-ipc
description NGSVL IPC Traffic
class-map match-any system-cpp-police-mcast-ctrl-v4
description MCAST control packets over IPv4
class-map match-any system-cpp-police-system-critical
description System Critical and Gold Pkt
class-map match-any system-cpp-police-mcast-register-v4
description MCAST v4 Register traffic
class-map match-any system-cpp-police-lisp-ctrl
description LISP Control Packets
class-map match-any system-cpp-police-mcast-ctrl-v6
description MCAST control packets over IPv6
class-map match-any system-cpp-police-mcast-register-v6
description MCAST v6 Register traffic
!
policy-map system-cpp-policy
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 172.16.255.1 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!
interface Loopback1
ip address 172.16.254.1 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!
interface GigabitEthernet0/0
vrf forwarding Mgmt-vrf
ip address dhcp
negotiation auto
!
interface GigabitEthernet1/0/1
switchport access vlan 101
switchport mode access
spanning-tree portfast
!
interface GigabitEthernet1/0/2
!
interface GigabitEthernet1/0/3
no switchport
ip address 172.16.12.1 255.255.255.0
ip pim sparse-mode
ip ospf network point-to-point
ip ospf 1 area 0
!
interface GigabitEthernet1/0/4
!
interface GigabitEthernet1/0/5
!
interface GigabitEthernet1/0/6
!
interface GigabitEthernet1/0/7
!
interface GigabitEthernet1/0/8
!
interface Vlan1
no ip address
!
interface Vlan101
ip address 10.1.101.254 255.255.255.0
no autostate
!
interface Vlan102
ip address 10.1.102.254 255.255.255.0
no autostate
!
interface nve1
no ip address
source-interface Loopback1
host-reachability protocol bgp
member vni 10101 mcast-group 225.0.0.101
member vni 10102 mcast-group 225.0.0.101
!
router ospf 1
router-id 172.16.255.1
!
router bgp 65001
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 172.16.255.2 remote-as 65001
neighbor 172.16.255.2 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family l2vpn evpn
neighbor 172.16.255.2 activate
neighbor 172.16.255.2 send-community both
exit-address-family
!
ip forward-protocol nd
ip tcp mss 1280
ip tcp window-size 212000
ip http server
ip http authentication local
ip http secure-server
ip pim rp-address 172.16.255.1
ip ssh bulk-mode 131072
!
!
!
!
!
!
control-plane
service-policy input system-cpp-policy
!
!
line con 0
exec-timeout 0 0
stopbits 1
line vty 0 4
exec-timeout 0 0
login
transport input ssh
line vty 5 15
login
transport input ssh
!
call-home
! If contact email address in call-home is configured as sch-smart-licensing@cisco.com
! the email address configured in Cisco Smart License Portal will be used as contact email address to send SCH notifications.
contact-email-addr sch-smart-licensing@cisco.com
profile "CiscoTAC-1"
active
destination transport-method http
!
!
!
!
!
end

[Giuseppe Larosa]

Hello @carl_townshend ,

the anycast gateway feature to work requires that each leaf is configured with the same  fabric anycast gatewway MAC address.

This is used also on Cisco SD access that actually use IS-IS in the underlay , VXLAN encapsulation.

To be noted the VXLAN tunnels are stateless based on UDP there is no need to setup a TCP session or to use any form of keepalive.

The UDP destination port is well known the UDP source port is calculated based on the inner packet so it changes for each flow between two leaf or VTEPs

in this way a load balancing algorythm based on L4 ports in addtion to source IP / destination IP is able to use ECMP paths between two leaf nodes.

each path goes via a different Spine node.

leafs connect only to spines . Spines are not connected between them.

No user service ports are on Spines.

All user ports connect to leafs including SDN controllers and external switches or routers.

MP BGP can be used on top of the overlay to build a VRF lite over VXLAN.

on IOS XE you can use the

mac command under each each user facing SVI (assuming the access uses a VLAN ID).

you need to manually configure the same MAC address under each interface VLAN based SVI and the same IP address.

in this way you build an anycast gateway.

Please note that some services like DHCP servers must be outside of the fabric in order to be able to use DHCP relay with anycast gateway. The border leaf node takes note of what specific leaf node has sent to him the DHCP offer so it able to send  back the DHCP reply to the correct leaf.

Hope to help

Giuseppe

[carl_townshend]

Hi Giuseppe,

It appears the manual way of configuring the mac addresses on the L3 svi's has been replaced with mac aliasing, see the below extract from the Cisco guide

MAC Aliasing

MAC aliasing removes the need to explicitly configure the same MAC address on the VLAN interfaces of every leaf switch. MAC aliasing allows the leaf switches in a VXLAN network to advertise the MAC addresses of their VLAN interface as the gateway MAC addresses to all the other leaf switches in the network. The MAC address that is being advertised will be stored on each leaf switch as a gateway MAC address, provided that the gateway IP address matches with the VLAN IP address.

In Figure 1, when MAC aliasing is enabled in subnet 1, leaf switch 1 and leaf switch 2 advertise their MAC addresses to each other as gateway MAC addresses. As leaf switch 2 now recognizes the MAC address in the ARP entry of host device 1 as a gateway MAC address, it sends the traffic from host device 1 outside of subnet 1, even though its MAC address does not match with the ARP entry on host device 1.

MAC aliasing in a VXLAN network is configured by enabling the default gateway advertisement on all leaf switches.

[carl_townshend]

Also, I have another question around L3 VNIs, I have seen things about IRB and having to create VRFs and a so called transit VNI to route to other vxlan segments.

My question is why do we need this, could this not just be done by traditional routing, i.e the local vxlan anycast gateway IP, if the route was on the local router surely this would just be handled by normal routing? why would we need to tunnel the routed traffic ?

[Giuseppe Larosa]

Hello @carl_townshend ,

>> I have another question around L3 VNIs, I have seen things about IRB and having to create VRFs and a so called transit VNI to route to other vxlan segments

>> My question is why do we need this, could this not just be done by traditional routing, i.e the local vxlan anycast gateway IP, if the route was on the local router surely this would just be handled by normal routing? why would we need to tunnel the routed traffic ?

For example to support hosts mobility without the need for them to get a new IP address or even to be aware of the move.

The proposed services use IRB , L3 VPNI and VRFs between segments for some reasons.

the use of VXLANs for providing L2 services is the first step.

The old but still current segmentation approach in campus networks is VRF lite.

VRF lite maps to VLANs to reach the next-hop in the L3 VPN topology.

The VLAN is 802.1Q link local identifier between two subinferfaces in two directly connected device,

Now think of using a VXLAN encapsulation with UDP external header  instead  an 802.1Q tag.

The use of UDP/IP encapsulation allows to make the inner packets to travel to any device that is in  the routing domain of the so called underlay.

Each  leaf acts as the anycast gateway in multiple user facing VLANs.

When there is the need to route between different L2 VNIs the following happen:

the ingress leaf determines that the packet needs to be routed because the destination MAC in ethernet header is equal to the Router MAC. The routing happens only on the ingress leaf the destination leaf node receives a VXLAN header that allows it to deliver the packet to the final destination.

The opposite happens for packets traveling in the opposite direction between the same two hosts Host1 attached to Leaf1 and Host2 attached to Leaf2 node.

For traffic from host1 to host2 that are in different IP subnets the routing function is performed by Leaf1, for packets originated by hosts2  to host 1they are processed by Leaf2.

Compare this with what happens with a traditonal point to point GRE tunnel.

The GRE is an actual L3 logical interface we route to the GRE tunnel the receiving router removes the GRE header and perfoms a second route lookup.

if destination MAC is not equal to the SVI MAC address the packets will be bridged.

Hope to help

Giuseppe

[MHM Cisco World]

Did you sucess in lab?

If not share last config you run let me check it 

MHM

[carl_townshend]

Hi,

yes the lab is working.

is it ok to map multiple vni’s to the same nve? I assume you only need 1 vtep aka nve interface per leaf ?

cheers

[MHM Cisco World]

is it ok to map multiple vni’s to the same nve? I assume you only need 1 vtep aka nve interface per leaf ? Yes sure only one NVE need in each VTEP 

yes the lab is working.<<- how you check that ?? NVE is UP not meaning the L2 traffic can pass 

MHM

[carl_townshend]

Hi, yes the traffic is passing fine, 

show nve peers is up, I can also ping device on same subnet at the other side