Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Optional Configurations: DHCP Relay and Multicast

 

Use these examples to configure optional DHCP relay and multicast forwarding on your collapsed spine data center architecture.

Configure DHCP Relay (Optional)

Requirements

Overview

Use this section to configure the spine switches to relay the DHCP requests to the DHCP server. Enable DHCP relay in a routing instance with the forward-only option. The forward-only option ensures that DHCP packets are forwarded on the switch but that no DHCP server client bindings are created.

Topology

The DHCP server can be located anywhere in the data center or in a different data center. In this case, the DHCP server is connected to one of the ToR switches in DC1 and the IP address of the DHCP server is 192.168.201.10. The DHCP relay topology is shown in Figure 1.

Figure 1: DHCP Relay Topology
DHCP Relay Topology

Configuration

Configure Spine 1

Step-by-Step Procedure

  1. Configure the DHCP relay on the first routing instance.
  2. Configure the DHCP relay on the second routing instance.
  3. Verify the DHCP relay on Spine 1.
    user@spine1> show dhcp relay statistics routing-instance JNPR_1_VRF

Configure Spine 2

Step-by-Step Procedure

  1. Configure the DHCP relay on the first routing instance.
  2. Configure the DHCP relay on the second routing instance.
  3. Verify the DHCP relay on Spine 2.
    user@spine2> show dhcp relay statistics routing-instance JNPR_1_VRF

Configure Multicast for Intra-VNI Traffic (Optional)

Requirements

Overview

Use this section to configure your collapsed spine architecture to allow intra-VNI multicast traffic. The multicast source and receivers are part of the same VLAN.

Note

The collapsed spine architecture with QFX5120 spine switches does not support inter-VNI multicast traffic.

Topology

This section includes the configuration for two multicast groups. The first is multicast group 224.0.0.66. As shown in Figure 2, the multicast source is Endpoint 62. The multicast receiver, Endpoint 61, is connected to ToR 2. Both the source and receiver are in the same VLAN, so traffic between them is intra-VNI multicast traffic.

Figure 2: Multicast Group 224.0.0.66 Topology

Configuration

Configure Devices

Step-by-Step Procedure

  1. Enable IGMP snooping for all VLANs on both spine switches.
  2. Configure the ToR switches with IGMP snooping for all VLANs.

Verification for Multicast Group 224.0.0.66

Step-by-Step Procedure

  1. Verify IGMP snooping membership on ToR 2.
    user@tor2> show igmp snooping membership
  2. Verify IGMP snooping membership on Spine 1.
    user@spine1> show igmp snooping evpn membership detail
  3. Verify IGMP snooping membership on Spine 2.
    user@spine2> show igmp snooping evpn membership detail
  4. Verify the designated forwarder on Spine 1. The output shows that Spine 1 is the designated forwarder for all Ethernet segments.
    user@spine1> show evpn instance designated-forwarder
  5. Verify the multicast traffic flow on Spine 1.

    Based on LAG hashing, ToR 1 sends the multicast traffic to Spine 1. The traffic reaches Spine 1 on the AE1 interface. Spine 1 forwards this traffic through AE2 based on IGMP group membership.

    user@spine1> monitor interface traffic detail
  6. Verify the multicast traffic flow on Spine 2.

    Based on LAG hashing, ToR 1 does not send the multicast traffic to Spine 2. Spine 2 receives this traffic from Spine 1 through the overlay, but it drops this traffic and does not forward it to AE2.

    user@spine2> monitor interface traffic detail

Verification for Multicast Group 224.0.0.65

The configuration above also applies to multicast group 224.0.0.65. As shown in Figure 3, Endpoint 62 is still the source and Endpoint 61 is still the receiver for this multicast traffic.

Figure 3: Multicast Group 224.0.0.65 Topology

Step-by-Step Procedure

  1. Verify the designated forwarder on Spine 1. The output shows that Spine 1 is still the designated forwarder for all the Ethernet segments.
    user@spine1> show evpn instance designated-forwarder
  2. Verify the multicast traffic flow on Spine 1.

    Based on LAG hashing, ToR 1 does not send the multicast traffic to Spine 1, so there is no incoming traffic for this multicast group on Spine 1. Spine 1 receives the multicast stream from Spine 2 through the overlay. Spine 1 drops the traffic and does not forward it to AE2 because Spine 1 and Spine 2 are part of the same Ethernet segments for AE1 and AE2.

    user@spine1> monitor interface traffic detail
  3. Verify the multicast traffic flow on Spine 2.

    Based on LAG hashing, ToR 1 sends the multicast traffic to Spine 2. Spine 2 is not the designated forwarder for the Ethernet segments, but Spine 2 still forwards this traffic to receivers on AE2 based on the local bias rules for multicast forwarding. See Overview of Selective Multicast Forwarding for more information about the EVPN multicast forwarding rules.

    user@spine2> monitor interface traffic detail

    You have successfully configured multicast traffic forwarding on your network.