Broadcast, Unknown Unicast, and Multicast Packet Path

The following procedure steps through debugging the packet path for broadcast, unknown unicast, and multicast (BUM) traffic in Contrail Networking. In this example, the virtual machines (VMs) listed are in the same subnet 70.70.70.0/24.

The ToR Service Node (TSN) actively holds the contrail-tor-agent and is responsible for:

1. Acting as a receiver of all BUM traffic coming from the ToR switch.

2. Acting as DNS/DHCP responder for the BMS connected to the ToR switch.

Contrail Networking releases earlier than 5.x, used an Open vSwitch Database (OVSDB)-managed VXLAN environment.

Topology example for an OVSDB-managed VXLAN:

• Top-of-Rack Switch 1 (ToR SW1) - 10.204.74.229 (lo0.0 = 1.1.1.229)

• Top-of-Rack Switch 2 (ToR SW2) - 10.204.74.230 (lo0.0 = 1.1.1.230)

• ToR Services Node 1 (TSN1) = 10.219.94.7

• ToR Services Node 2 (TSN2) = 10.219.94.8

• Controller1 = 10.219.94.4

• Controller2 = 10.219.94.5

• Controller3 = 10.219.94.6

• Compute1 = 10.219.94.9

• Compute2 = 19.219.94.18

• Virtual Network (VN) = 70.70.70.0/24

• Virtual Machine 1 (VM1) = 70.70.70.3 residing on Compute2

• Virtual Machine 2 (VM2) = 70.70.70.5 residing on Compute1

• Bare Metal Server 1 (BMS1) = 70.70.70.100

• Bare Metal Server 2 (BMS2) = 70.70.70.101

1. Run the set protocols ovsdb interfaces <interface> command to configure the physical interfaces that you want the OVSDB protocol to manage.

   Example:

   The ToR interfaces from which the BMS hangs are marked as ovsdb interfaces.

2. View packets coming into these interfaces by displaying the ovsdb mac table for the ToR switch.

   Example:

   The entry marked in red (ff:ff:ff:ff:ff:ff:ff - broadcast route) indicates the next hop for a BUM packet coming into the ToR SW’s ovsdb interface. In this case, VTEP address 10.219.94.7 is the next hop, which is TSN1. This changes based on which TSN has the active contrail-tor-agent for the ToR switch in question. With this, the BUM packet is forwarded to the TSN node in a VXLAN tunnel (local VTEP source interface is 1.1.1.229 and RVTEP source interface is 10.219.94.7).

   The VXLAN encapsulated packet is sent with a VXLAN Network Identifier (VNI) that is predetermined by Contrail Networking when logical interfaces are created. For example, when ge-0/0/46 was configured as a logical port in Contrail Networking, the following configuration was committed on the ToR.

   Example:

   As the VXLAN encapsulated packet arrives on the TSN node, let’s examine how the vRouter handles this packet.

3. Run vxlan --dump to dump the VXLAN table. The VXLAN table maps a network ID to a next hop.

   Example:

   In the example, next hop 13 is programmed for VNI 4.

4. Run nh --get <nh id> to display the next-hop details and determine the virtual routing and forwarding (VRF) associated.

   Example:

5. Run the following command to display all of the entries from the bridge table:

   Example:

   In the example bridge table, since we are tracing the BUM packet path, we need to examine the ff:ff:ff:ff:ff:ff:ff route by selecting the next hop programmed. In the example, it is 24. Note that a series of composite next hops are programmed.

6. Run nh --get <nh id> to display the next-hop details.

   Example:

   The multicast tree in the example shows that there are two Dynamic IPs (DIP)s. The DIP where the packet came from is ignored. Therefore, packet gets forwarded to DIP 10.219.94.18 only.

7. Run vxlan --get <vnid> to examine what DIP 10.219.94.18 does with the incoming VXLAN encapsulated packet.

   Example:

8. Run nh --get <nh id> to display the next-hop details.

   Example:

9. Run the following command to display all of the entries from the bridge table:

   Example:

   In the example bridge table, since we are tracing the BUM packet path, we need to examine the ff:ff:ff:ff:ff:ff:ff route by selecting the next hop programmed. In the example, it is 50.

10. Run nh --get <nh id> to display the next-hop details.

    Example:

    In the example, you only have to inspect DIP 10.219.94.9. The remaining endpoints are either local or the source where the BUM traffic came from. Now, let us examine, what DIP 10.219.94.9 does with the incoming VXLAN encapsulated packet.

11. Run vxlan --get <vnid> to examine what DIP 10.219.94.9 does with the incoming VXLAN encapsulated packet.

    Example:

12. Run nh --get <nh id> to display the next-hop details.

    Example:

13. Display the bridge table for the VRF by using the following command:

    Example:

14. Run nh --get <nh id> to display the next-hop details.

    Example:

    From the above output, the only DIP that you have to further examine is 10.219.94.8. The remaining DIPs are either local or the source where the BUM traffic came from. Now, let’s examine what DIP 10.219.94.8 does with the incoming VXLAN encapsulated packet.

15. Run vxlan --get <vnid> to examine what DIP 10.219.94.9 does with the incoming VXLAN encapsulated packet.

    Example:

16. Run nh --get <nh id> to display the next-hop details.

    Example:

17. Display the bridge table for the VRF by using the following command:

    Example:

18. Run nh --get <nh id> to display the next-hop details.

    Example:

    Now, you just have one DIP 1.1.1.230 which is the ToR SW2 in the topology. This should also be present in the multicast tree as this ToR SW also has an end-point (which is BMS2) in the same VN (VNI=4) as the one we are tracing.

This completes all levels of forwarding and tracing the BUM packet from one ToR switch and is replicated to other intended receivers in the topology.

These multicast trees are programmed by the controllers that the TSN is connected to. If you want to inspect the controller’s memory and what eventually gets programmed on all TSN computes, enter the following introspect URL using your controller IP address: