VXLAN Part V: Flood and Learn

In this chapter, I am going to show how the VXLAN Flood & Learn mac learning process works. I am going to ping from Host-1 to Host-2 and then walk through the Flood and Learn process starting from ARP request. I am using the same Lab that was used in VXLAN Part-IV. Configurations can be found from the VXLAN Part-1 and Part IV.

Figure 1: VXLAN Flood & Learn topology

VXLAN Part IV: The Underlay Network – Multidestination Traffic: PIM BiDir

My Last post, VXLAN Part III, introduces VXLAN Fabric L2VNI service with Anycast-RP PIM (RFC4610 and RFC 7761). In this chapter, I will show how the PIM BiDir (RFC5015) with Phantom-RP can be used for the same purpose. I will use configurations, show commands and Wireshark captures to explain the theory part.

Figure 1: Example VIRL topology

VXLAN Part III: The Underlay Network – Multidestination Traffic: Anycast-RP with PIM

The role of the Underlay Network, related to BUM traffic in the VXLAN fabric, is to transport ARP, ND, DHCP and other Layer 2 BUM (Broadcast, Unknown Unicast, and Multicast) traffic between the hosts connected to different VTEPs. For the Layer 3 Multicast traffic between hosts, there should be an overlay Multicast routing design. This chapter shows how an Anycast-RP with PIM can be used in a VXLAN fabric. In figure 1, we can see our example topology used in this chapter. There are two Spine switches, which shares the same Anycast-RP IP address and belongs to the same “Anycast-RP set” group (Loopback 238). In addition to that, there is an another loopback interface, which must be unique in each Spine (Loopback 511 and 512). These addresses are used as an Anycast-RP group member Id. Both addresses, shared and unique, needs to be reachable for all switches. Complete configuration can be found from the Appendix 1 at the end of the document.

Note! I am using Cisco VIRL with nxos.7.0.3.I7.1

Figure 1: Example topology with Anycast-RP - IP addresses.

VXLAN Part II. The Underlay network – Unicast Routing

Introduction

VXLAN is MAC-over-IP / UDP tunneling mechanism that allows the Layer2 segments to be stretched over the Layer3 network (Underlay/Transport). In this chapter, I will show one possible design of the Underlay network. I will also show basic configurations and monitor commands. At the end of this article, you can find a mindmap for memory builder.

Our example network consists of four Cisco Nexus 9000 switches. The edge switches Leaf-101 and Leaf-102 works as a VTEP (VXLAN Tunnel Endpoint) devices. VTEPs are responsible for encapsulation of Ethernet frames received from directly connected hosts with VXLAN header as well as removing VXLAN header from the packet received from another VTEP switch. Spine-11 and Spine-12 are the core switches. These switches are not aware of hosts/VMs behind the VTEP Leaf switches, Spine switches only route packet between VTEP switches.

Figure-1: Example topology

VXLAN Part I. Why do we need VXLAN?

Introduction

This section examines the challenges that virtualization of servers causes for Datacenter networks with traditional three-layer architecture and how VXLAN can respond to these challenges. At the end of this article, you can find a mindmap for memory builder.

Challenges for existing Datacenter networks

Figure 1-1 shows a hypothetical 3-tier Cloud Service Provider DC network consisting of the following components.

• Access layer (L2): Twenty of the 48-port switches. Access - Distribution links 2 x 10Gbps MEC (Multichassis EtherChannel).
• Distribution layer (L2 / L3): Two distribution switches, which together form a virtualized switch. The default gateway for server segments is in distribution switches. Distribution - Core Links are L3.
• Core Layer (L3): Two Core switches

Figure 1-1: The hypothetical Cloud SP Datacenter network.

Rapid per VLAN Spanning Tree protocol (Rapid PVST+): Synchronization

Introduction

This article describes the Rapid per VLAN Spanning Tree Protocol (Rapid PVST +) synchronization process based on Proposal / Agreement messages. The purpose of the synchronization is to form a new loop-free layer 2 topology as a response to changes in stable STP domains. The synchronization process is started by a switch that loses its connection to a current STP root switch and it does not have an STP Alternate port.

The article also describes the topology change process that occurs when the STP non-Edge port status changes from Discarding/Learning state to Forwarding state.

The idea for writing this article started when I studied the new Cisco VXLAN-based Campus Fabric model and I wanted to compare its complexity with the complexity of the traditional Campus network.

Figure 1-1: Spanning Tree topology

Border Gateway Protocol – Finite State Machine (BGP-FSM)

Introduction

The BGP-FSM model presents different states during BGP neighbor negotiation: Idle, Connect, Active, OpenSent, OpenConfirm and Established. It also describes the events that launch changes from one state to another. This article is based on Based on RFC 4271 – A Border Gateway Protocol 4 (BGP-4).

There are 28 events, which are grouped into four categories.

• Administrative Events: Events that either start or stop the process.
• Timer Events: Expiration of HoldTimer, KeepaliveTimer or ConnectRetryTimer trigger this event.
• TCP connection based events: These events describe the different state of the TCP three-way handshake.
• BGP message based events: Receiving or sending BGP messages: OPEN, KEEPALIVE, UPDATE and NOTIFICATION launch this event.

A Complete list can be found in Appendix A.

Figure 1-1 shows the map of different states and related event numbers. Timers and counters are excluded from both the text part and picture to keep things as clear as possible.

Figure 1-1: Overview of BGP-FSM.