
245
A source IP address (local VTEP) must be specified for configured VXLAN. The valid source IP interface is
either a loopback interface or a routing interface (port-based or VLAN-based) on the router. It is
recommended that a loopback interface be dedicated for VXLAN gateway purposes and configured with
the intended source IP configuration before associating it with VXLAN. If the configured source IP interface
is down or has no IP address, all remote VTEPs in the VPN are considered unreachable. No traffic flows to
the remote VTEPs.
Note that the configured source IP address must correspond to an IP address configured on each remote
VTEP. Otherwise, the remote VTEPs will discard the gateway's packets.
9.6.2.2.
Configuration of Remote VTEPs
Each gateway VTEP must know the set of VTEPs other than itself in VXLAN. This knowledge is necessary
because tenant systems can send broadcast and multicast Ethernet frames. For example, ARP requests are
generally broadcast. Also, a VTEP may receive a packet for a destination MAC address it has not learned yet.
Such a packet is called an unknown frame. The VTEP must send the packet to all other remote VTEPs
configured in VXLAN, since the destination may be accessed through any one of them.
VXLAN handle broadcast, multicast, and unknown frames by encapsulating the packet in an IP packet
whose destination IP address is an IP multicast group configured for the VN. Each VTEP sends Join messages
to join the VN's multicast group. There can be difficulties in using IP multicast to deliver broadcast and
unknown frames, the main difficulty being that the data center networks that would be used as underlays
often do not enable IP multicast because it does not scale to the size of large public cloud networks.
Because of this limitation, VXLAN implementation requires user configuration of the remote VTEPs
associated with a particular VPN.
Dynamic VTEP learning through IP multicast is not currently supported.
When a gateway receives a broadcast, multicast, or unknown packet on an access port, it makes a copy of
each packet for each of the other VTEP's in the VN, setting the outer IP address to the unicast IP address of
the remote VTEP, and setting the outer MAC address to the unicast MAC address of the next hop to the VTEP.
The hardware does this packet replication. In this mode, the gateway can still learn L2 entries from packets
it decapsulates and, thus, is able to unicast to a single VTEP most of the time.
For each remote VTEP, the operator must specify the following parameters:
The associated virtual network (specified by VNID).
The VTEP's IP address. This address is an IP address in the underlay.
The source IP address is inherited from the VXLAN configuration. The system creates overlay tunnels to all
configured remote VTEPs in hardware as they become reachable. The system removes the tunnel
configuration from hardware when the VTEPs are not reachable.
VXLAN with matching tunnel configuration (i.e., a pair of VTEPs {source or gateway IP address, remote VTEP
IP address}) share the same hardware tunnel. Each hardware tunnel has unicast packet and unicast byte
counters in either direction (Tx/Rx). When the tunnel is removed from hardware, counters are reset to 0.
If the gateway receives a packet for an unknown VNID or for a known VNID from a VTEP IP address that has
not been configured, the gateway drops the packet.
Summary of Contents for QuantaMesh QNOS5
Page 1: ...QuantaMesh Ethernet Switch Configuration Guide QNOS5 NOS Platform ...
Page 209: ...209 Table 7 8 IPv6 Neighbor Discovery Settings ...
Page 226: ...226 Table 8 2 L3 Multicast Defaults ...
Page 254: ...254 Appendix A Term and Acronyms Table 9 5 Terms and Acronyms ...