VXLAN Flood and Learn with Multicast

I ran into this kind of error:

VTEP2#show ip mroute 239.1.1.1
Group 239.1.1.1 not found

VTEP2#show ver
Cisco IOS XE Software, Version 16.03.03

Hello Dan

This error is not due to an unsupported feature, but probably due to a misconfiguration. The command is used to show the multicast routing table, and the groups that are registered within it. From the moment that you are getting a result where the specific group is not found, this indicates that it has not been configured initially. I suggest you issue the following command to see all the multicast routes in the device:

show ip mroute

If there are none, then you should go back and check your multicast configuration based on the lesson.

I hope this has been helpful!

Laz

Hi
Thanks for this great post.

According to above trace, host1 alreasy knows MAC of host2 before VTEP MAC learning . Is it possible ?
Initially, host1 does not know host2 MAC. It sends ARP multicast. After host2 reply, both host1 and vtep learn host2 MAC at the same time. Could you please explain ?

Cloud topology is spine-leaf.
Without vxlan, spine forwards layer3 packet, leaf forwards layer2(vlan) frame. With vxlan, both spine and leaf forward layer3 packet(multicast, unicast). True or false ?

Thanks
Michael

Hello Michael

Remember that the hosts between them believe they are on the same subnet, connected to the same switch. Because they’ve already communicated with each other, they already know each other’s MAC addresses, through ARP packets that have already been exchanged. In the lesson, Rene cleared the bridge domain MAC table which resides on the VTEP devices. This has no effect on the ARP tables of the hosts.

So in the above Wireshark capture, you can see that for the “inside” or encapsulated ETHERNET and IP headers, all is normal. For the outside ETHERNET and IP headers, the first ICMP packet is multicast, the return ICMP packet is unicast, and the second ICMP packet is also unicast.

The answer here is “it depends”. This is because a spine and leaf architecture can function at L2 or L3. You can indeed configure such an architecture without VXLAN such that the spine does forward layer 3, and leaves are at Layer 2, but you are not restricted to such a configuration.

With VXLAN, the idea is that the overlay network can indeed be L2 at both spine and leaf, while the underlay network can be L3 at both spine and leaf, so really there is no restriction.

Are you speaking about a particular case of configuration? If so, please clarify so that we can answer more accurately.

I hope this has been helpful!

Laz

Hi Laz/Rene

  1. Could you plz solve this for me?
    If I change the topology to this, do we need to change the config at all?
    I need to extend the vlan 1010 from the right switch to the left switch…

and what about trunks, VXLAN ports(service instance) doesn’t support trunks? so that we can tag the traffic from downstream on any VLAN and send it over the vxlan tunnel to another destination? in other word can Gi2 be a trunk port that goes to a switch?

Hello Aaron

Yes that is correct. If you replace H1 and H2 with two switches, as you have done in your diagram, then those switches will simply need to be configured with access ports on VLAN 1010. No change in the config of VTEP1 and VTEP2 is necessary. From the moment the encapsulation untagged command is used on Gi2 of both VTEP1 and VTEP2, these ports can connect to hosts or to access ports of switches.

Yes, it is possible to make Gi2 on the VTEP devices function as a trunk. This is achieved using the encapsulation dot1q command in which you specify the VLAN(s) that will be tagged. For example:

encapsulation dot1q vlan 5-10,12

The above command specifies that VLANs 5, 6, 7, 8, 9, 10, and 12 are allowed on this port. Any switch connected to such a port should be configured as a trunk port with the same allowed VLANs. This is similar in concept to the router on a stick configuration.

I hope this has been helpful!

Laz

How vxlan achieves 16 million when we have 1:1 mapping with vni to vlan ?
I have succeeded in mapping VLANs to vnis,
but I would like to know how can I use different vnis on access ports.

VxLAN_Bridge

vlan 1000
vn-segment 5000
int e1/6
switchport access vlan 1000

Hello YongHun

Take a look at this post which should answer your question:

I hope this has been helpful!

Laz

1 Like

Hi, Rene, Laz, and Everyone

I have a question.
Part “Unknown Unicast Traffic”, ping to H2(192.168.12.102) form H1,
so I see Wireshark packet capture, the first ICMP request is not flooding.
Why? Missconfiguration?

H1#ping 192.168.12.102 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 192.168.12.102, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 3/3/3 ms
H1#

Hello Yoichi

In the 2.3 Unknown Unicast Traffic section of the lesson, the first thing that Rene does is clear the bridge domain MAC table in both VTEP devices. This ensures that there are no MAC addresses present in the MAC address table, which will result in a multicast communication for the first echo request.

Also, you must make sure that the packet capture is being taken at the right place. If the packet capture is taking place at H1, then you will see a unicast communication, because the destination IP is known to H1. However, when this reaches VTEP1 and is sent on into the VXLAN fabric, it becomes a multicast communication. The proper location to take the packet capture is on the egress of Gi3 on VTEP1 or even at one of the interfaces on the CORE.

I hope this has been helpful!

Laz

1 Like

Hello Laz,

Thank you for your reply.
Oh, I was making a mistake! As you say, I wasn’t doing packet captures in the right place. After setting it to the Gi3 exit of VTEP1, it was the result I expected! Thank you so much!

Yoichi

1 Like

I have everything working in gns3.
All the ospf, pings, multicast and vxlan verification commands show the expected output.
However i cannot ping between hosts.
VTEP1#show bridge-domain 1 - this only shows the mac address of host 1 - same on VTEP2 - only shows host2 mac address.
VTEP1#show nve interface nve1 detail - should show out / in packets - mine only shows outs. Same on vtep2.

I’m not great on multicasting - but as i’ve said all the verification commands do return the expected output.
Looks like the vtep is not forwarding on the traffic - evening though the underlay is working correctly. Anything else i should check ??? Or any type of logging i can turn on ?

Edit : I have no nve peers - the output is empty from # show nve peers

Edit 2 : I found the solution.

I resolved the above issue - in a roundabout way - when really it would have been easier to check my running config - my bad !!!
It turned out i did not have on the vtep nodes the loopback interface command :
# ip pim sparse-mode

I worked thru the Cisco troubleshooting document -https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/16450-mcastguide0.html
and finally ran the command -
#show ip pim interface

That showed pim sparse-mode NOT configured on loopback interfaces.

2 Likes

Hello Charles

Thanks for sharing your solution with us, it’s always helpful for others on the forum as well. Much appreciated!

Laz

Hello Rene,
Could pls make video for MPBGP EVPAN, it’s really helpful in my upcoming project.

Hello Harsh

If you have a suggestion for a lesson or for content on the site, feel free to use the Member Ideas page below. You may find that others have suggested similar topics to what you’re looking for, and you can add your voice to theirs.

I hope this has been helpful!

Laz


Hello Rene, please help me with this topo. How can I configure VTEPs to PCs in VLAN10 communicate together and the same with PCs in VLAN20
Thank you!

Hello Quyen

In the example in the lesson, when configuring the host-facing interfaces, the following configuration is applied:

VTEP1(config)#interface GigabitEthernet 2
VTEP1(config-if)#service instance 1 ethernet
VTEP1(config-if-srv)#encapsulation untagged
VTEP1(config-if-srv)#exit
VTEP1(config-if)#exit

Notice the command encapsulation untagged. In the lesson, the interface accepted untagged frames. In your case, you want e0/1 of each VTEP to accept tagged frames, so you would have to configure dot1q encapsulation. Take a look at this context-sensitive help with the available options:

R1(config)#interface gigabitethernet 0/1
R1(config-if)#service instance 1 ethernet 
R1(config-if-srv)#encapsulation ?
  default          catch-all unconfigured encapsulation
  dot1ad           802.1ad - Provider Bridges
  dot1q            IEEE 802.1Q Virtual LAN or S-VLAN
  priority-tagged  Priority tagged EFP
  untagged         Untagged encapsulation

R1(config-if-srv)#encapsulation

Using dot1q encapsulation will allow the VTEP to receive and tunnel the VLAN tags so that you can achieve communication between VLANs 10 and 20.

I hope this has been helpful!

Laz

Thanks man, I made the same mistake.

Hi Rene,
Could you share the link with VXLAN with MP-BGP EVPN example here?

Hello Azat

Creating such a topology of a VXLAN network with MP-BGP EVPN would be an interesting lesson to examine. I suggest you go to the following Member Ideas page of NetworkLessons and make your suggestion there as to a new lesson topic. You may find that others have suggested something similar, and you can add your voice to theirs.

In the meantime, here is some Cisco documentation that may be useful for you concerning VXLAN and MP-BGP EVPN:

I hope this has been helpful!

Laz