CN115604056A - Efficient storage implementation of downstream VXLAN identifiers - Google Patents

Abstract

The present disclosure relates to efficient storage implementation of downstream VXLAN identifiers. A network device for use as a local VXLAN tunnel endpoint (VTEP) includes a communication interface, a first processor, and a packet processor. The communication interface communicates between the local VTEP and the remote VTEP, and each VTEP has a corresponding VXLAN identifier (VNI). The first processor imports a downstream-VNI (D-VNI) for forwarding packets from the local VTEP to the remote VTEP, creates a unique egress routing interface (RIF) that can be A RIF is associated with one or more routing entries in the local VTEP. The Packet Processor receives a packet destined for the remote VTEP, looks up the packet in the routing entry in the local VTEP to retrieve the unique egress RIF, converts the unique egress RIF into an imported D‑VNI, encapsulates the packet with the imported D‑VNI, And forward the encapsulated packet according to the unique egress RIF.

Description

Efficient storage implementation of downstream VXLAN identifiers

technical field

Embodiments described herein relate generally to data communications, and more particularly to methods and systems for efficient storage implementation of downstream VXLAN identifiers (D-VNI).

Background technique

Virtual Extensible LAN (VXLAN) is a network virtualization technology suitable for large-scale deployments such as cloud computing and data centers. VXLAN uses an encapsulation technology similar to VLAN. For example, VXLAN is described in Request for Comments (RFC) 7348 .

Ethernet Virtual Private Network (EVPN) is the control plane of VXLAN, allowing the construction and deployment of large-scale VXLAN-based networks. For example, EVPN is specified in RFC 8365.

VRF is a technique in which multiple independent forwarding tables are located in the same network device (such as a router or switch). The forwarding table in each VRF instance is used to specify the next hop for each data packet, as well as a set of rules and routing protocols that control how packets are forwarded. Since VRF routing instances are independent, the same or overlapping IP addresses can be used in different instances without conflicting with each other, and network paths can be segmented without the need for multiple routers. Additionally, since traffic is automatically segregated, VRF also increases network security and can reduce the need for encryption and authentication.

Contents of the invention

Embodiments described herein provide a network device for use as a local virtual extensible local area network (VXLAN) tunnel endpoint (VTEP), the network device including a communication interface, a first processor and a packet processor. The communication interface communicates between a local virtual routing and forwarding domain (VRF) and remote VRFs, each of which has a unique VXLAN identifier (VNI). The first processor runs a control program that creates a local VRF instance for the local VRF configured in the local VTEP, importing a downstream-VNI (D-VNI) for forwarding packets from the local VRF into the remote VTEP instead of the local The remote VRF configured in the VTEP, creates a unique egress routing interface (RIF) that can be converted to the imported D-VNI, and associates the unique egress RIF with one or more routing entries in the local VRF instance. A packet processor receives a packet destined for a remote VRF, looks up the packet in one or more routing entries in the local VRF instance to retrieve a unique egress RIF, converts the unique egress RIF to an imported D-VNI, and uses the imported The D-VNI encapsulates the packet and forwards the encapsulated packet according to the unique egress RIF.

In some embodiments, the control program in the local VTEP exports the local VNI of the local VRF to the remote VTEP for use by the remote VTEP in forwarding packets from the remote VRF to the local VRF. The control program further creates a second egress RIF for the local VNI and associates the second egress RIF with one or more second routing entries in the local VRF instance. The packet processor receives a second packet destined for the local VRF from the remote VRF through the communication interface, the second packet is encapsulated by the remote VTEP with the exported local VNI, and the second packet is decapsulated, and one or more of the local VRF instances Look up the decapsulated packet in a second routing entry to retrieve the second egress RIF, and forward the second packet according to the second egress RIF. In other embodiments, the local VTEP and the remote VTEP are included in an Ethernet Virtual Private Network (EVPN), where packets communicated between different VRFs are encapsulated based on VXLAN encapsulation. In other embodiments, the control program imports the D-VNI using an instance of Border Gateway Protocol (BGP) associated with the local VRF.

In one embodiment, the control program associates a unique egress RIF with multiple routing entries belonging to multiple VRF instances respectively created for multiple local VRFs provided in the local VTEP. In another embodiment, the control program configures one or more routing entries in the forwarding rules in the access control list (ACL), and the packet processor finds the packet by matching it with one of the forwarding rules in the ACL . In yet another embodiment, each of the local VTEP and the remote VTEP includes a leaf network device or a serving network device in the communication network, each of the leaf network devices is assigned one or more local VRFs, and the serving network Each of the devices is assigned one or more remote VRFs different from the local VRF.

In some embodiments, a serving host (serving host) is coupled to a given serving network device configured with a corresponding shared service VRF, and the serving host sends messages to one or more served hosts (served hosts) in the local VRF through a communication network. Provide services. In other embodiments, a communication network having a hub-and-spoke topology, wherein one or more hub network devices are configured with a hub VRF that supports routing between served hosts belonging to different VRFs in the local VRF. In other embodiments, the communication network supports the Equal Cost Multi-Path (ECMP) routing protocol, and the packet processor encapsulates packets forwarded to multiple remote VTEPs using different ECMP paths with different corresponding D-VNIs.

In one embodiment, the packet processor receives packets from a host or network element in a first VRF, or receives a packet from a third VRF. In another embodiment, the control program imports the D-VNI from a remote VTEP, either by receiving the D-VNI in one or more commands sent manually by the user, or automatically by running a script containing one or more commands Import D-VNI correctly.

According to embodiments described herein, there is also provided a method for data communication comprising, in a network device serving as a local virtual extensible local area network (VXLAN) tunnel endpoint (VTEP), in a local virtual routing and forwarding domain (VRF ) and remote VRFs, each of the local VRFs and each of the remote VRFs has a unique VXLAN identifier (VNI). The local VRF instance is created by the local VRF control program configured in the local VTEP. Import a downstream-VNI (D-VNI) for forwarding packets from the local VRF to the remote VTEP instead of the remote VRF configured in the local VTEP. A unique egress routing interface (RIF) convertible to the imported D-VNI is created and associated with one or more routing entries in the local VRF instance. Packets destined for remote VRFs are received by the packet processor of the local VTEP. The packet is looked up in one or more routing entries in the local VRF instance to retrieve a unique egress RIF. Convert the only egress RIF to an imported D-VNI and use the imported D-VNI to encapsulate the grouping. The encapsulated packets are forwarded according to the unique egress RIF.

According to embodiments described herein, there is additionally provided a network device for use as a local virtual extensible local area network (VXLAN) tunnel endpoint (VTEP), the network device comprising a communication interface, a first processor and a packet processor. The communication interface communicates with one or more remote VTEPs, the local VTEP and the one or more remote VTEPs are assigned corresponding VXLAN identifiers (VNIs). a first processor running a control program that imports a downstream-VNI (D-VNI) for use in forwarding packets from the local VTEP to the remote VTEP, creating a unique egress routing interface convertible to the imported D-VNI (RIF), and associate a unique egress RIF with one or more routing entries in the local VTEP. A packet processor receives a packet destined for a remote VTEP, looks up the packet in one or more routing entries in the local VTEP to retrieve a unique egress RIF, converts the unique egress RIF to an imported D-VNI, and uses the imported The D-VNI encapsulates the packet and forwards the encapsulated packet according to the unique egress RIF.

In some embodiments, the control program exports the local VNI of the local VTEP to the remote VTEP for use by the remote VTEP in forwarding packets from the remote VTEP to the local VTEP. The control program further creates a second egress RIF for the local VNI and associates the second egress RIF with one or more second routing entries in the local VTEP. The packet processor receives a second packet destined for the local VTEP from the remote VTEP through the communication interface, the second packet is encapsulated by the remote VTEP with the derived local VNI, the second packet is decapsulated, and the one or more second routing entries The decapsulated packet is looked up in to retrieve the second egress RIF, and the second packet is forwarded according to the second egress RIF. In other embodiments, the local VTEP and the one or more remote VTEPs belong to different respective sites in the multi-site topology. In yet other embodiments, the local VTEP acts as a border gateway (BGW) VTEP and one or more remote VTEPs act as leaf VTEPs coupled to the host, the BGWVTEP and the host are assigned a common virtual routing and forwarding domain (VRF) .

In one embodiment, the local VTEP and the remote VTEP are assigned different corresponding VNIs. In another embodiment, the network device is included in a communication network comprising a plurality of interconnected network devices, and the network device acts as a leaf VTEP or a BGW VTEP in the communication network.

According to the embodiments described herein, there is also provided a method for data communication, comprising: communicating with one or more remote VTEPs in a network device serving as a local Virtual Extensible Local Area Network (VXLAN) tunnel endpoint (VTEP) To communicate, the local VTEP and one or more remote VTEPs are assigned corresponding VXLAN identifiers (VNIs). A downstream-VNI (D-VNI) is imported by a control program running on the local VTEP for forwarding packets from the local VTEP to the remote VTEP. A unique egress routing interface (RIF) convertible to the imported D-VNI is created and associated with one or more routing entries in the local VTEP. Packets destined for the remote VTEP are received by the packet processor of the local VTEP. The packet is looked up in one or more routing entries in the local VTEP to retrieve a unique egress RIF. Convert the only egress RIF to an imported D-VNI and use the imported D-VNI to encapsulate the grouping. The encapsulated packets are forwarded according to the unique egress RIF.

According to embodiments described herein, there is also provided a method for communication between virtual routing and forwarding domains (VRFs), the method comprising: a local VRF configured in a local VXLAN tunnel endpoint (VTEP) and a remote VTEP But not between remote VRFs configured in the local VTEP. The local VTEP imports the downstream VXLAN identifier (D-VNI) associated with the remote VRF for forwarding packets from the local VRF to the remote VRF and creates a unique egress routing interface (RIF ). When a packet destined for a remote VRF is received by the local VTEP, the unique egress RIF retrieved based on the packet is converted to an imported D-VNI, and the packet is encapsulated with the imported D-VNI. The encapsulated packets are forwarded according to the unique egress RIF.

According to embodiments described herein, there is also provided a method for communicating between sites of different routing domains, the method comprising: communicating between a local VXLAN tunnel endpoint (VTEP) and a remote VTEP belonging to a different corresponding routing domain communicate between. Import a downstream VNI (D-VNI) from the local VTEP to forward packets from the local VTEP to the remote VTEP and create a unique egress routing interface (RIF) that can be converted to the imported D-VNI. When the local VTEP receives a packet destined for the remote VTEP, the unique egress RIF retrieved based on the packet is converted to an imported D-VNI, and the packet is encapsulated with the imported D-VNI. The encapsulated packets are forwarded according to the unique egress RIF.

Description of drawings

For a more complete understanding of these and other embodiments, the embodiments are described in detail below along with the accompanying drawings, in which:

FIG. 1 is a block diagram schematically illustrating a computer system for providing sharing services according to an embodiment described herein;

Figure 2 is a block diagram schematically illustrating a network device serving as a virtual tunnel endpoint (VTEP) according to embodiments described herein;

3A and 3B are diagrams schematically illustrating VTEP processing and forwarding applied to non-encapsulated and encapsulated packets, according to embodiments described herein;

Figure 4 is a flowchart schematically illustrating a method for configuring a VTEP to communicate with a remote VTEP, according to embodiments described herein;

5 is a block diagram schematically illustrating a computer system with a hub-and-spoke topology, according to embodiments described herein; and

Figure 6 is a diagram schematically illustrating a multi-site computer system, according to embodiments described herein.

detailed description

overview

Embodiments described herein provide improved methods and systems for virtual extensible local area network (VXLAN) tunnels with encapsulation of downstream VXLAN identifiers (D-VNIs) across different routing domains.

Various communication networks are divided into routing domains, which are usually isolated from each other, eg for security reasons. For isolated routing domains, traffic is allowed to flow within each routing domain, but not between different routing domains. For example, a routing domain might be associated with a site or a virtual routing and forwarding domain (VRF) in a multi-site computer system.

A network device that supports VXLAN is called a virtual tunnel endpoint (VTEP). VTEP encapsulates VXLAN traffic and decapsulates the traffic as it leaves the VXLAN tunnel.

In VXLAN, each VXLAN tunnel is typically assigned a unique Open Systems Interconnection (OSI) Layer 3 (L3) VXLAN Identifier (VNI). In the following description, the term "L3VNI" is also simply referred to as "VNI" for the sake of brevity. VNIs can be allocated in a communication network in various ways. For example, in a multi-VRF configuration, different VRFs are typically assigned different corresponding VNIs, and in a multi-site configuration, network devices belonging to a common site may be assigned the same or different VNIs. Different sites usually belong to different administrative domains.

In some applications, for example, a communication network needs to support communication between different routing domains associated with various sites or VRFs. For example, inter-domain communication can be achieved by importing and exporting certain VNIs between different routing domains. A VNI imported from another routing domain for establishing a VXLAN tunnel is called a "downstream-VNI" (D-VNI).

In some embodiments, packet forwarding in a network device is based on pre-ordered routing entries, where each routing entry is associated with a corresponding egress router interface (RIF). In principle, routing entries related to inter-domain VXLAN tunnels can store explicit D-VNI information for imported D-VNIs. However, this approach is usually cost-prohibitive or even infeasible, since storing explicit D-VNI information on a large number of routing entries may consume a large amount of storage space. For example, assuming each routing entry has 10 bytes of D-VNI information, the total storage space for more than 10,000 routing entries is 100KB. For example, another requirement in hardware implementation is that hardware is needed to support storing explicit D-VNI information in routing entries.

In some embodiments, an efficient solution for supporting VXLAN encapsulation with D-VNI is provided. In an efficient scenario, a unique egress RIF is created for the corresponding imported D-VNI and associated with the relevant routing entry.

Consider an embodiment of a network device acting as a local virtual extensible local area network (VXLAN) tunnel endpoint (VTEP), for example, in a multi-site computer system. The network device includes a communication interface, a first processor and a packet processor. The communication interface communicates with one or more remote VTEPs, where the local VTEP and the one or more remote VTEPs are assigned respective VXLAN identifiers (VNIs). The first processor runs a control program that imports (for example, from a remote VTEP or from a user) a downstream-VNI (D-VNI) for forwarding packets from the local VTEP to the remote VTEP, creating D-VNI's unique egress routing interface (RIF), and associate the unique egress RIF with one or more routing entries in the local VTEP. A packet processor receives a packet destined for a remote VTEP, looks up the packet in one or more routing entries in the local VTEP to retrieve a unique egress RIF, converts the unique egress RIF to an imported D-VNI, and uses the imported D-VNI - The VNI encapsulates the packet and forwards the encapsulated packet according to the unique egress RIF.

In some embodiments, the control program exports the local VNI of the local VTEP to the remote VTEP for use by the remote VTEP in forwarding packets from the remote VTEP to the local VTEP, creates an egress RIF for the local VNI, and links the egress RIF to the One or more second routing entries in the local VTEP are associated. In response to receiving a second packet from the remote VTEP via the communication interface, encapsulated by the remote VTEP with the derived local VNI and destined for the local VTEP, the packet processor decapsulates the second packet, looks in the one or more second routing entries The decapsulated packet is retrieved to retrieve a second egress RIF, and the second packet is forwarded according to the second egress RIF.

In some embodiments, the local VTEP and the one or more remote VTEPs belong to different respective sites in a multi-site topology, eg, a multi-site data center. In some embodiments, a local VTEP acts as a border gateway (BGW) VTEP, while one or more remote VTEPs act as leaf VTEPs coupled to the host, where the BGW VTEP and the host are assigned a common VRF.

In the disclosed technology, a low-storage solution of using D-VNI to support VXLAN tunnel is provided. For this, a unique RIF will be created for the corresponding imported D-VNI and associated with the relevant routing entry. Each of the unique egress RIFs may be associated with multiple routing entries, but is typically only stored once in a network device, regardless of the number of VRFs configured in that network device. Since the number of imported D-VNIs is usually relatively small, the only export RIF consumes very little storage space.

The low memory scheme of the present disclosure can be used in various applications including, but not limited to, multi-VRF communication systems providing shared services, multi-VRF communication systems with hub-and-spoke topologies, and multi-site communication systems.

instructions

FIG. 1 is a block diagram schematically illustrating a computer system 20 for providing sharing services according to an embodiment described herein.

Computer system 20 includes service hosts 24A and 24B that provide services to hosts 28A, 28B, and 28C over communication network 30 . Communications network 30 may include, for example, Ethernet.

Service hosts 24A and 24B belong to routing domains specified by Domain Name System (DNS) VRF and Storage VRF, which are assigned corresponding VNI values 20001 and 20002. Hosts 28A, 28B, and 28C belong to different routing domains specified by respective VRFs denoted pink, blue, and purple, which are assigned respective VNI values 10001, 10002, and 10003.

In this example, each of hosts 28A, 28B, and 28C receives DNS service from DNS host 24A, denoted DN1 and DN2, and storage service from storage host 24B, denoted ST1 and ST2. In other embodiments, other types of services and/or other numbers of service types may also be used.

The communication network 30 includes a plurality of interconnected network devices such as leaf switches 34 denoted L11...L32, spine switches 36 denoted S1 and S2, and serving leaf switches 38 denoted SL1 and SL2. For brevity, service leaf switches 34 are also referred to herein as "service switches."

In the following description, a leaf switch includes a switch that is directly or indirectly coupled to one or more hosts. Hosts may include, for example, physical servers and/or virtual machines or servers in a virtualized data center environment.

Leaf switch 34 is coupled to hosts 28A, 28B, and 28C on one side and to spine switch 36 on the other side. For example, leaf switch L11 is coupled to host 28A denoted H11 and H12 in the pink VRF, and host 28B denoted H13 and H14 in the blue VRF. Service switches SL1 and SL2 are coupled to DNS hosts DN1 and DN2 and storage hosts ST1 and ST2 on one side and to spine switch 36 on the other side.

In computer system 20, leaf, spine and service switches are assigned respective Autonomous System Numbers (ASNs). Specifically, leaf switches L11...L32 are assigned ASNs 65001...65006, spine switches S1 and S2 are assigned ASNs 65100 and 65101, respectively, and service switches SL1 and SL2 are assigned ASNs 65201 and 65202, respectively. For example, ASNs can be used to specify routing targets (RTs), as described below.

In some embodiments, communication network 30 includes an Ethernet Virtual Private Network (EVPN), where at least some of the network devices function as VXLAN virtual tunnel endpoints (VTEPs). In the description that follows, the terms "network device", "switch", "router", "gateway" and "VTEP" are used interchangeably.

In some embodiments, a network device acting as a VTEP typically creates VRF instances for each VRF provisioned in that VTEP. In this example, each of the leaf VTEPs L11...L32 is configured with two of the pink, blue, and purple VRFs, depending on the VRFs of the hosts coupled to the leaf switches. Similarly, in this example, each of service VTEPS SL1 and SL2 creates a corresponding VRF instance for its configured VRFs (eg, DNS and storage VRFs).

In some embodiments, the communication network 30 is required to support VXLAN tunneling between different VRFs provided in different VTEPs. To this end, the VTEP can establish an inter-VRF VXLAN tunnel by exchanging VNIs associated with different VRFs.

In the service-to-host direction, each of the service VTEPs SL1 and SL2 imports from each leaf-VTEP the D-VNI of each VRF configured in the leaf-VTEP. The serving VTEP then encapsulates packets destined for the given VRF in the leaf-VTEP using the D-VNI imported from the given VRF's leaf-VTEP. In the host-to-service direction, each leaf VTEP in L11...L32 imports the D-VNI from each service VTEP SL1 and SL2. In this example, the leaf VTEP imports two D-VNIs corresponding to DNS and storage VRFs from the service VTEP. The leaf VTEP then encapsulates packets destined for the given VRF in the serving VTEP using the D-VNI imported from the serving VTEP for the given VRF.

As mentioned above, a VRF configured in a VTEP has a corresponding forwarding table that includes routing entries. Each routing entry is associated with (eg points to) a corresponding egress RIF, which is used by the VTEP for packet forwarding. In some embodiments, the VTEP creates a unique egress RIF for each imported D-VNI and associates the unique egress RIF with the relevant routing entry in the VRF configured in the VTEP.

In some embodiments, the communication network 30 supports communication between different VRFs in different leaf VTEPs using VXLAN encapsulation with D-VNI. For example, L11 can import a D-VNI associated with a purple VRF for its pink VRF from L21, L22, L31 and/or L32. L11 creates a unique RIF for the imported D-VNI and associates this unique egress RIF with the route entry sent to the purple VRF via one of the L21...L32 in the local pink VRF instance. L11 then uses the imported D-VNI to encapsulate the packets that H11 sends to H22, eg via L11, S1 and L22.

In some embodiments, a control program in a network device imports and exports routes using route targets (RTs). RT is a structure used in the BGP protocol to specify and control the direction and content of route import/export. In some embodiments, the RT is used to control the import and export of routes/VNIs between VTEPs.

In some embodiments, a VRF instance in a VTEP includes an import RT list and an export RT list. The RTs in the export list are appended to every route that a VTEP advertises to other VTEPs. When a remote VTEP receives an advertised route with an attached RT, the remote VTEP compares the RT to the import list defined in its corresponding VRF instance. If any of the attached RTs match the VRF instance's import list, the remote VTEP will import the advertised routes into that VRF instance. When all RTs attached to an advertised route do not match the VRF instance's import list, the remote VTEP ignores importing the advertised route into that VRF instance.

In some embodiments, accessing shared services in computer system 20 using a VXLAN tunnel with D-VNI involves the following stages:

• Each of the leaf VTEPs L11...L32 imports RTs to each of its configured VRFs (eg, in pink, blue and purple VRFs), where serving VTEPs SL1 and SL2 export routes corresponding to their shared serving VRFs. For example, if the service VTEP exports an auto-derived RT, the leaf VTEP imports RT *:20001 and *:20002. The wildcard "*" in these RTs indicates the Autonomous System Number (ASN) 65201 and 65202 assigned to SL1 and SL2 respectively. Alternatively, an RT can be specified using an explicit ASN instead of wildcard notation.

• Each of SL1 and SL2 imports the RTs announced by the leaf VTEPs for the pink, blue and purple VRFs for its configured VRFs (DNS and Storage VRFs). In this example, SL1 and SL2 each import RT *:10001, *:10002, and *:10003. Alternatively, explicit ASNs of leaf VTEPs can be used in RT instead of wildcard notation.

• Based on the imported routes, the leaf VTEP creates unique egress RIFs for the corresponding D-VNIs 20001 and 20002. In the routing table of the VRF provided in the leaf VTEP, the leaf VTEP further associates these unique egress RIFs with routing entries destined for DNS and storage hosts.

• Each of SL1 and SL2 creates a unique egress RIF for the corresponding D-VNI 10001 , 10002 and 10003 based on the routes imported from the leaf VTEP. The serving VTEP further associates these unique egress RIFs with routing entries destined for hosts H11...H34 in DNS and in the corresponding routing tables of the storage VRF.

• Consider a packet sent from a source host (eg H11 (IP 192.168.51.11)) to a DNS host (eg DN1 (IP 200.11.3.1)). The leaf VTEP (L11 or L12) receives the packet from H11, encapsulates the packet with D-VNI 20001, and tunnels the encapsulated packet to SL1 (IP 10.150.3.1) or SL2 (IP 10.150.3.2). SL1 or SL2 decapsulates the packet and routes the decapsulated packet to DN1 in the target DNS VRF based on the D-VNI (20001) in the received packet. SL1 or SL2 performs last-pass routing by selecting the routing table of the DNS VRF based on the D-VNI in the received packet. Instead, SL1 or SL2 receives a packet from host DN1 and encapsulates the packet with D-VNI 10001 of the pink VRF to which H11 belongs. SL1 or SL2 tunnels the encapsulated packet to L11 or L12, and L11 or L12 uses the routing table of the pink VRF to decapsulate the packet and route the decapsulated packet.

In some embodiments, leaf VTEP 34 or service VTEP 38 connects to the local host using a multi-chassis link aggregation (MLAG) configuration. In such an embodiment, the peer VTEP appears to the host binding as a single logical network device. For example, leaf VTEPs L11 and L12 may be configured as MLAG peers for each of hosts H11, H12, H13, and H14. Similarly, serving VTEPS SL1 and SL2 may be configured as MLAG peers for each of serving hosts DN1, DN2, ST1 and ST2.

In some embodiments, communication network 30 supports the Equal Cost Multi-Path (ECMP) routing protocol. Typically, ECMP can be used for fast failover recovery. For example, ECMP is suitable for EVPN multi-home (MH) configurations, such as data centers with CLOS network topologies. In ECMP, a source VTEP forwards packets to multiple destination VTEPs over multiple corresponding ECMP paths, where the source VTEP encapsulates the packets forwarded over different ECMP paths using different corresponding D-VNIs.

Network device used as VTEP

Fig. 2 is a block diagram schematically illustrating a network device 50 serving as a virtual tunnel endpoint (VTEP) according to embodiments described herein. For example, the network device 50 can be used to implement the leaf VTEP L11...L32 and the service VTEP SL1 and SL2 in the computer system 20 of FIG. .

Network device 50 includes a packet processor 54 coupled to a network interface 56 that is connected to a communication network (e.g., communication network 30 of FIG. 1) using port 58. Each port 58 can be used as an input port for incoming packets, an output port for outgoing packets, or a combined port for incoming and outgoing packets. Packet processor 54 typically handles real-time packet processing and forwarding.

Cumulus Linux NOS。为简洁起见，控制平面程序64在本文中也简称为“控制程序”。Network device 50 also includes a general-purpose processor 60 , such as a central processing unit (CPU), and memory 62 accessible by CPU 60 and packet processor 54 . CPU 60 runs control plane programs 64, which handle off-line control and provisioning tasks of network devices. In some embodiments, the control plane program 64 (or a portion thereof) includes a network operating system (NOS) 65, such as

Cumulus Linux NOS. For the sake of brevity, the control plane program 64 is also simply referred to as "control program" herein.

In some embodiments, control program 64 creates one or more VRF instances 66 in memory 62 , each VRF instance corresponding to a VRF provided in network device 50 . In one embodiment, a VRF instance stores various types of information, such as: its own VNI 70 assigned to a network device, one or more imported D-VNIs 72, and one or more local VNIs 74 (network device export). In the inter-domain VXLAN tunnel, VTEP 50 uses the D-VNI imported from the remote VTEP to encapsulate packets destined for the remote VTEP. The remote VTEP encapsulates packets destined for the VTEP 50 using the derived local VNI 74 received from the VTEP 50 as a D-VNI. The derived local VNI 74 may include, for example, the same values as the own VNI 70 .

VRF instance 66 also includes a forwarding information base (FIB) 76 that includes a number of routing entries 78 . In some embodiments, the FIB is implemented in hardware, but controlled by the control plane program 64 . In some embodiments, packet processor 54 looks up the packet in the routing entries of the FIB to find a routing entry that specifies how the packet should be forwarded. In one embodiment, packet lookups in FIB 76 are generally based on information in packet headers, such as IP addresses and prefixes.

In this example, the routing entry includes at least the egress routing interface (RIF) and next hop information. Route entries can also store vendor-specific information. An egress RIF includes a logical interface representing a routable interface, which may include a physical port, sub-interface, switch virtual interface (SVI), L3VNI, or any other suitable type of interface. In some embodiments, a VNI or D-VNI may be derived from the egress RIF and used for VXLAN encapsulation.

In one embodiment, VTEP 50 stores egress RIFs in RIF table 80 in memory 62. In this embodiment, routing entries 78 in FIB 76 point to individual egress RIFs in the RIF table, where multiple different routing entries may point to a common egress RIF.

In some embodiments, VTEP 50 creates a unique egress RIF for each imported D-VNI and stores the unique egress RIF in RIF table 80 . In some embodiments, VTEP 50 also creates a unique egress RIF for each local VNI 74 and stores the unique egress RIF in RIF table 80. An exported local VNI is associated with the same egress RIF created for the local VNI.

The next hop information in routing entry 78 typically specifies the IP address of the next network device to be traversed along the path to the destination.

In some embodiments, control program 64 creates a unique forwarding identifier (FID) for each imported D-VNI and each native VNI (except for the unique egress RIF), where the FID maps to the unique egress RIF's Imported D-VNI. In these embodiments, FIB 76 provides a routing entry pointing to an egress RIF, which in turn points to the FID of the importing D-VNI mapped to the egress RIF. In one embodiment, the packet processor exports the imported D-VNI for the packet using a chain of operations: FIB lookup -> egress RIF -> FID -> imported D-VNI. Since each imported D-VNI is assigned only one FID, the storage area occupied by the FID is very small.

In some embodiments, VTEP 50 includes one or more instances of gateway protocol 84, such as Border Gateway Protocol (BGP). For example, VTEP 50 may allocate a dedicated BGP instance for each VRF configured in the VTEP. In some embodiments, VTEP 50 uses BGP 84 to exchange routing information such as VNIs and RTs with other VTEPs.

In some embodiments, control program 64 specifies one or more routing entries in forwarding rules in an access control list (ACL). In these embodiments, packet processor 54 looks up the packet by matching the packet to one of the forwarding rules in the ACL.

Packet processing in a network device used as a VTEP

3A and 3B are diagrams schematically illustrating VTEP processing and forwarding applied to non-encapsulated and encapsulated packets, according to embodiments described herein.

FIG. 3A depicts processing in packet processor 100 . For example, the same or similar processing may be performed by packet processor 54 of VTEP 50 .

Packet processor 100 receives input packets 104 without encapsulation. In computing system 20, incoming packet 104 may be from, for example, host 28A, 28B, or 28C, a service host such as DNS host 24A (DN1 or DN2) or storage host 24B (ST1 or ST2). In this example, the incoming packet 104 is destined for a VRF that is not configured in the VETP of the packet processor 100 and therefore needs to be encapsulated with a suitable imported D-VNI.

At lookup stage 106, packet processor 100 identifies the VRF from which the incoming packet came, and looks up the incoming packet in the FIB (76) of the identified VRF. For example, assuming that the incoming packet originates from the host H11 of the pink VEF, the packet processor 100 looks for the incoming packet in the FIB of the pink VRF to which the host H11 belongs. A successful lookup operation results in a routing entry 78 specifying the egress RIF. In this example, the egress RIF includes the only egress RIF assigned to the imported D-VNI.

In the adjacency stage 110, the packet processor 100 generates next hop information from the route ingress or egress RIF of the stage 106. In the mapping stage 112, the packet processor 100 derives the imported D-VNI associated with the egress RIF of the stage 106, and in the rewriting stage 114, generates from the input packet 104 the VXLAN output packet 120 . Packet processor 100 forwards outgoing packets according to the egress RIF of stage 106 .

FIG. 3B depicts processing in packet processor 150 . For example, the same or similar processing may be performed by packet processor 54 of VTEP 50 .

The packet processor 150 receives an input packet 154 encapsulated with a VNI previously exported to the remote VTEP. The derived VNI is used by the remote VTEP as a D-VNI for encapsulating packets destined for the VTEP comprising packet processor 150 .

Packet processor 150 decapsulates incoming packet 154 (stage 156), selects a target VRF based on the VNI with which the incoming packet was encapsulated, and looks for the decapsulated packet in FIB 76 of the selected VRF (stage 158).

In some embodiments, packet processor 150 terminates the VXLAN tunnel through which incoming packet 154 arrived. In this case, the lookup operation of stage 158 results in a normal egress RIF that is not related to D-VNI. In the adjacency stage 160, the packet processor generates next hop information. In rewrite stage 162, packet processor 154 generates unencapsulated output packet 164A and routes the output packet according to the egress RIF of stage 158.

In some embodiments, a VTEP including packet processor 154 acts as a mediator VTEP that mediates communications between different routing domains. A hub-and-spoke topology including a moderator VTEP will be described below with reference to FIG. 5 .

When operating as a mediator VTEP, packet processor 154 exports a local VNI (74) to a source VTEP and imports a D-VNI (72) from a destination VTEP. Packet processor 154 receives an input packet 154 from a source VTEP and processes the packet in stages 156 and 158, resulting in an egress RIF as described above.

In Fig. 3B, the processing related to the moderator VTEP is depicted in dotted lines. In response to identifying that the egress RIF is uniquely associated with the D-VNI (the D-VNI imported from the destination VTEP), packet processor 154 maps the unique egress RIF to the imported D-VNI (stage 170). In rewrite stage 162, packet processor 154 re-encapsulates the packet using the D-VNI imported from the destination VTEP, producing output packet 164B. Packet processor 154 then routes output packet 164B according to the egress RIF of stage 158.

Note that although FIGS. 3A and 3B depict different packet processing flows, in one embodiment, a VTEP (eg, VTEP 50 ) generally implements both packet processing flows of packet processors 100 and 150 .

Control Plane Processing

Figure 4 is a flowchart schematically illustrating a method for configuring a VTEP for communication with a remote VTEP, according to embodiments described herein.

The method of FIG. 4 will be described as being performed by a control program 64 running on a CPU 60 of a VTEP 50, here indicated as a local VTEP.

The method begins with a VRF instance creation step 200 where the control program 64 creates one or more VRF instances for corresponding one or more local VRFs configured in the local VTEP.

In import step 204, the control program imports one or more D-VNIs from the remote VTEP (72). In this example, each of the imported D-VNIs is associated with a corresponding remote VRF configured in the remote VTEP instead of the local VTEP.

In the export step 208, the control program exports to the remote VTEP one or more local VNIs (74), which are respectively associated with the local VRFs configured in the local VTEP, and will be used by the remote VTEP as D-VNIs for encapsulation sent to Grouping of local VTEPs.

In the outbound RIF creation step 212, the control program creates corresponding unique outbound RIFs for the imported D-VNIs, so that each D-VNI can be deduced from its unique outbound RIF. In the inbound RIF creation step 214, the control program creates corresponding unique inbound egress RIFs for the local VNIs (these outbound RIFs are also used for the corresponding exported local VNIs in the inbound direction), so that each exported local VNI can be accessed from Its only inbound and outbound RIF inferred.

In a RIF association step 216, the control program associates the outbound egress RIF of step 212 and the inbound egress RIF of step 214 with the relevant routing entries in the VRF instance of the corresponding local VRF. In some embodiments, the control program associates a unique egress RIF with multiple routing entries belonging to multiple VRF instances respectively created for multiple local VRFs provided in the local VTEP. After step 216, the local VTEP is ready to handle communications between the local VRF in the local VTEP and the remote VRF in the remote VTEP.

Computer system with hub-and-spoke network topology

FIG. 5 is a block diagram schematically illustrating a computer system 300 with a hub-spoke topology, according to embodiments described herein.

In a hub-and-spoke network topology, a hub routing domain acts as a central point of connection for multiple other routing domains (spokes).

Computer system 300 supports multiple routing domains (VRFs) denoted pink, blue, and HUB01, which are assigned L3VNI values 10001, 10002, and 20001, respectively.

Computer system 300 includes a communication network 302 in which a number of network devices are interconnected, including hub switches (also referred to as hub VTEPs) 304 denoted SL1 and SL2, leaf switches (also referred to as leaf VTEPs) 308 denoted L11...L22 and spine switches 316 denoted S1 and S2. In computer system 300, hub VTEP 304 acts as a mediator VTEP, mediating communications between different VRFs configured in leaf VTEP 308.

In communication network 302, leaf switches L11...L22 are coupled on one side to hosts 312A and 312B and on the other side to spine switches 316 (S1 and S2). Furthermore, each of the spine switches S1 and S2 is coupled to hub switches SL1 and SL2 on one side and leaf switches on the other side.

In this example, the HUB01 VRF is configured in each of the hub VTEPs SL1 and SL2, while the pink and blue VRFs are configured in each of the leaf VTEPs L11...L22. In general, each leaf-VTEP 308 is configured with a VRF that is coupled to the leaf-VTEP's hosts 312A and 312B.

In some embodiments, computer system 300 supports communication between different VRFs using D-VNI technology. To this end, VTEPs configured with different VRFs can establish VXLAN-based communication by exchanging VNIs with each other.

In the example of Figure 5, each of the hub VTEPs SL1 and SL2 imports a D-VNI for the pink VRF, and another D-VNI for the blue VRF, from each of the leaf VTEPs L11...L22. In addition, each of leaf VTEP L11...L22 imports D-VNI from SL1 and SL2 for HUB01VRF.

Consider a source leaf VTEP sending a packet to a target leaf VTEP through a hub VTEP. The source VTEP encapsulates the packet using the D-VNI imported from the hub VTEP and tunnels the encapsulated packet to the hub VTEP. Based on the D-VNI in the received packet, the hub VTEP re-encapsulates the packet using the D-VNI imported by the hub VTEP from the target VTEP.

In some embodiments, computer system 300 supports VXLAN tunneling of D-VNI with a low storage footprint, as described above, eg, with reference to FIG. 1 above. In such an embodiment, the leaf and hub VTEPs in computer system 300 create unique egress RIFs for imported D-VNIs and store the unique egress RIFs only once in the VTEP.

In computer system 300, hosts 312A and 312B coupled to a common leaf switch but belonging to different VRFs can also communicate using D-VNI via hub switches SL1 and SL2. For example, although H11 of the pink VRF and H13 of the blue VRF are both coupled to leaf switch L11, hosts H11 and H13 communicate with each other via mediators VTEP SL1 and SL2 as described above.

In some embodiments, communication in a hub-and-spoke topology using VXLAN tunnels and D-VNI involves the following phases:

• Each hub VTEP SL1 and SL2 imports pink and blue VRFs from leaf VTEP routes (eg using RT as above). For example, the hub VRF instance of HUB01VRF of SL1 or SL2 imports RT *:10001 and *:10002 from the leaf VTEP. For example, each of SL1 and SL2 imports from L11 and L12 routes including IP addresses of hosts H11...H14, and imports from L21 and L22 routes including IP addresses of H21...H24.

Each of SL1 and SL2 aggregates the imported routes into an aggregated route and initiates an aggregated route with exported RT65201:10002 (or 65202:10002) as a pink VRF route. Similarly, SL1 and SL2 initiate an aggregated route that exports RT65201:10001 (or 65201:10001) as the blue VRF route. In some embodiments, SL1 or SL2 generates aggregated routes by applying a longest prefix match (LPM) method to the imported routes represented by the IP addresses of hosts 312A and 312B. For example, SL1 and SL2 generate an aggregated route 192.168.62.0/24 for the pink VRF in L11, which is used to reach H23 and H24 of the blue VRF via L21 or L22.

· Leaf VTEP L11…L22 uses its auto-exported RT for routing export and import. This means that the leaf VTEP imports aggregated routes from SL1 and SL2 for inter-VRF routing via the hub VTEP, for example routing between H11 (pink VRF) and H24 (blue VRF).

• Consider a host in the pink VRF sending a packet to a host in the blue VRF. For example, H11 (IP 192.168.51.11) sends a packet to H24 (IP 192.168.62.24). The packet is received by L11 or L12, which forwards the packet using the aggregated route 192.168.62.0/24 previously sourced from SL1 and/or SL2. L11 or L22 uses D-VNI 20001 of HUB01VRF to encapsulate the packet, and transmits the encapsulated packet to the hub VTEP SL1 or SL2 through the tunnel. SL1 or SL2 decapsulates the packet in HUB01VRF and routes the decapsulated packet based on the complete host route imported from L21 and/or L22 (eg, 192.168.62.24/32 for host H24). SL1 or SL2 re-encapsulates packets using VNI 10002 (imported from L21 and/or L22) and tunnels the re-encapsulated packets to L21 or L22 via VXLAN. L21 or L22 then routes the packet in the blue VRF (eg, to H24 in this example). A similar forwarding scheme applies to communications between hotspots of different VRFs, where hosts are coupled to a common leaf VTEP (eg, H11 and H13).

multi-site computer system

FIG. 6 is a diagram schematically illustrating a multi-site computer system 400 according to embodiments described herein. For example, the computer system in FIG. 6 can be used to implement a multi-site data center, the sites of which can be deployed in different geographic locations and/or have different management domains.

In this example, computer system 400 includes data center (DC) sites 404, denoted DC-1, DC-2, and DC-3, which may be separately managed by different network managers. In alternative embodiments, a multi-site computer system may include other suitable numbers of sites. In some embodiments, DC sites 404 are associated with different corresponding routing domains.

Each of the DC sites 404 includes a border gateway (BGW) router (also referred to as a BGW VTEP) 412 locally connected to one or more leaf switches (also referred to as leaf VTEPs) 416 of the DC site. The BGW VTEPs in DC sites DC-1, DC-2, and DC-3 are denoted as BGW1, BGW2, and BGW3, respectively. In some embodiments, BGW VTEP 412 acts as a mediator VTEP, mediating communications between DC sites with different routing domains.

In some embodiments, BGW VTEP 412 and leaf VTEP 416 are implemented using VTEP 50 of FIG. 2, and packets are processed as described above for FIGS. 3A and 3B.

Leaf VTEPs 416 in DC sites DC-1, DC-2, and DC-3 are denoted DCL-1, DCL-2, and DCL-3, respectively. For clarity, Figure 6 depicts only one lobe VTEP in each DC locus. Each DC site 404 generally includes hosts 420 accessible via the DC site's leaf VTEPs. In some embodiments, BGW VTEP 412 and host 420 share a common VRF denoted "A".

In this example, BGW1, BGW2, and BGW3 are assigned VNIs 50002, 50003, and 50099, respectively, while leaf VTEPs DCL-1, DCL-2, and DCL-3 are assigned VNIs 50001, 50004, and 50099, respectively. VNI allocation in DC-1 and DC-2 sites is asymmetrical (because BGW VTEPs allocate VNIs different from leaf switches in DC sites), while VNI allocation in DC-3 sites is symmetrical (because BGW VTEPs and Leaf VTEPs in this DC site share a common VNI value of 50099).

In the example of FIG. 6, leaf VTEP DCL-1 in site DC-1 needs to send packets to leaf VTEP DCL-2 in site DC-2. This inter-domain communication can be achieved using VXLAN tunnels with D-VNI.

In one example scenario, a host behind leaf VTEP DCL-1 sends a packet to another host behind leaf VTEP DCL-2. To support this scenario, DCL-1 imports D-VNI 50002 from BGW1, BGW1 imports D-VNI 50003 from BGW2, and BGW2 imports VNI 50004 from DCL-2. Packets sent from DCL-1 to DCL-2 will be encapsulated with D-VNI 50002 and tunneled to BGW1. BGW1 decapsulates the packet, re-encapsulates the packet with D-VNI 50003, and tunnels the packet to BGW2. BGW2 decapsulates the packet, recapsulates it with D-VNI 50004, and tunnels the packet to leaf DCL-2. As the final terminating leaf VTEP, DCL-2 decapsulates the packet and forwards the decapsulated packet to the destination host behind DCL-2.

In another example scenario, a host behind leaf VTEP DCL-1 sends a packet to a host behind leaf VTEP DCL-3. To support this scenario, DCL-1 imports VNI 50002 from BGW1, and BGW1 imports VNI 50099 from BGW3. A packet sent from a host behind DCL-1 to another host behind DCL-3 will be processed according to the scenario before BGW1. In the current scenario, BGW1 re-encapsulates the packet using D-VNI 50099, and tunnels the packet to BGW3. Based on VNI 50099, BGW3 forwards the packet to the target host behind DCL-3 through DCL-3.

As mentioned above, the allocation of VNIs in site DC-3 is symmetric, which means that communication within site DC-3 does not require a D-VNI. However, in order to send packets from site DC-3 to DC-1 or DC-2, BGW3 needs to import D-VNI 50002 from BGW1 or D-VNI 50003 from BGW2 respectively.

In some embodiments, computer system 400 supports VXLAN tunneling of D-VNI with a low storage footprint, as described above, eg, with reference to FIG. 1 . In these embodiments, the VTEP in computer system 400 creates a unique egress RIF for the imported D-VNI and stores the unique egress RIF only once in the VTEP.

The configurations of computer system 20 of FIG. 1, computer system 300 of FIG. 5, and computer system 400 of FIG. 6, and network equipment (VTEP) 50 of FIG. 2 are example configurations chosen purely for conceptual clarity. In alternative embodiments, any other suitable computer system and network equipment configurations may also be used. For clarity, elements not necessary for understanding the principles of the invention, such as various interfaces, addressing circuits, timing and sequencing circuits, and debugging circuits, have been omitted from the figures.

Some elements of network equipment (VTEP) 50, such as packet processor 54, may be implemented in hardware, such as in one or more application specific integrated circuits (ASICs) or FPGAs. Additionally or alternatively, packet processor 54 may be implemented using software or using a combination of hardware and software elements. Memory 62 may comprise any suitable type of memory using any suitable storage technology, such as random access memory (RAM), dynamic RAM (DRAM), non-volatile memory such as flash memory, or a combination of memory types.

In some embodiments, some of the functions of CPU 60 and/or packet processor 54 may be performed by a general purpose processor programmed in software to perform the functions described herein. The software may be downloaded electronically to the processor, eg, over a network, or may alternatively or additionally be provided and/or stored on a non-transitory tangible medium such as magnetic, optical or electronic memory.

The embodiments described above are given by way of example, and other suitable embodiments may also be used.

In the above embodiments, the route/VNI mainly uses the BGP protocol to import and export. However, in alternative embodiments, the routing/VNI may be configured in the network device by a user of the communication network. In an example embodiment, the network device imports the D-VNI by receiving the D-VNI in one or more commands originating from the user, wherein the user sends one or more commands.

The above embodiments mainly refer to the layers specified in the OSI model. However, this is not mandatory and in alternative embodiments layers according to any other suitable layering model may also be used. It is assumed that this alternative layered model includes a transport layer and an IP layer, similar to the transport and IP layers specified in the OSI model.

Although the embodiments described herein primarily address efficient storage implementations of D-VNI in network devices such as switches and routers, the methods and systems described herein may also be used in other applications, such as D-VNI is implemented using a small memory space in the network adapter.

It should be understood that the embodiments described above are cited as examples and that the following claims are not limited to what has been particularly shown and described above. Rather, the scope includes combinations and sub-combinations of the various features described above, as well as variations and modifications not disclosed in the prior art that would occur to those skilled in the art upon reading the foregoing description. Documents incorporated by reference into this patent application shall be deemed to be an integral part of this application, and unless the definition of any term in such incorporated documents conflicts with an express or implied definition in this specification, only the definition in this specification shall be considered. .

Claims (38)

1. A network device for use as a local virtual extensible local area network, VXLAN, tunnel endpoint, VTEP, the network device comprising:

a communication interface for communicating between local virtual routing and forwarding domains, VRFs, and remote VRFs, wherein each of the local VRFs and each of the remote VRFs has a unique VXLAN identifier, VNI;

a first processor running a control program for:

creating a local VRF instance for a local VRF configured in the local VTEP;

importing a downstream-VNID-VNI for forwarding packets from the local VRF into a remote VTEP instead of a remote VRF configured in the local VTEP;

creating a unique egress routing interface, RIF, that is convertible to the imported D-VNI; and

associating the unique egress RIF with one or more routing entries in the local VRF instance; and

a packet processor to:

receiving a packet destined for the remote VRF;

looking up the packet in the one or more routing entries in the local VRF instance to retrieve the unique egress RIF, convert the unique egress RIF to the imported D-VNI, and encapsulate the packet with the imported D-VNI; and

forwarding the encapsulated packet according to the unique egress RIF.

2. The network device of claim 1, wherein the control program in the local VTEP is to:

exporting, by the remote VTEP, a local VNI of the local VRF to the remote VTEP for forwarding of packets by the remote VTEP from the remote VRF to the local VRF; and

creating a second egress RIF for the local VNI and associating the second egress RIF with one or more second routing entries in the local VRF instance; and

the packet processor is to:

receiving, from the remote VRF via the communication interface, a second packet destined for the local VRF, the second packet encapsulated by the remote VTEP with the derived local VNI;

decapsulating the second packet;

looking up the decapsulated packet in the one or more second routing entries in the local VRF instance to retrieve the second egress RIF; and

forwarding the second packet according to the second egress RIF.

3. The network device of claim 1, wherein the local VTEP and the remote VTEP are included in an Ethernet Virtual Private Network (EVPN), wherein packets communicated between different VRFs are encapsulated based on VXLAN encapsulation.

4. The network device of claim 1, wherein the control program is to import the D-VNI using an instance of Border Gateway Protocol (BGP) associated with the local VRF.

5. The network device of claim 1, wherein the control program is to associate the unique egress RIF with a plurality of routing entries respectively belonging to a plurality of VRF instances respectively created for a plurality of local VRFs configured in the local VTEP.

6. The network device of claim 1, wherein the control program is to configure the one or more routing entries in a forwarding rule in an Access Control List (ACL), and wherein the packet processor is to look up the packet by matching the packet to one of the forwarding rules in the ACL.

7. The network device of claim 1, wherein each of the local VTEP and the remote VTEP comprises a leaf network device or a serving network device in the communication network, and wherein each of the leaf network devices is assigned one or more local VRFs and each of the serving network devices is assigned one or more remote VRFs that are different from the local VRFs.

8. The network device of claim 7, wherein a service host is coupled to a given service network device on which a corresponding shared service VRF is configured, and wherein the service host provides services to one or more served hosts of the local VRFs over the communication network.

9. The network device of claim 7, wherein the communication network has a hub-spoke topology in which one or more hub network devices are configured with hub VRFs that support routing between served hosts belonging to different ones of the local VRFs.

10. The network device of claim 1, wherein the communication network supports an equal-cost multipath ECMP routing protocol, and wherein the packet processor is to forward packets to a plurality of remote VTEPs using different ECMP paths with different respective D-VNI encapsulations.

11. The network device of claim 1, wherein the packet processor is to receive the packet from a host or network element in the first VRF, or from a third VRF.

12. The network device of claim 1, wherein the control program is to import the D-VNI from the remote VTEP, or to receive the D-VNI by receiving the D-VNI in one or more commands sent manually by a user, or automatically by running a script containing the one or more commands.

13. A method for data communication, comprising:

in a network device acting as a local virtual extensible local area network, VXLAN, tunnel endpoint, VTEP, communicating between local virtual routing and forwarding domains, VRFs, and remote VRFs, wherein each of the local VRFs and each of the remote VRFs has a unique VXLAN identifier, VNI;

creating a local VRF instance for a local VRF configured in the local VTEP through a control program;

importing a downstream-VNID-VNI for forwarding packets from the local VRF into a remote VTEP instead of a remote VRF configured in the local VTEP;

creating a unique egress routing interface, RIF, that is convertible to the imported D-VNI;

associating the unique egress RIF with one or more routing entries in the local VRF instance;

receiving, by a packet processor of the local VTEP, packets destined for the remote VRF;

looking up the packet in the one or more routing entries in the local VRF instance to retrieve the unique egress RIF, convert the unique egress RIF to the imported D-VNI, and encapsulate the packet with the imported D-VNI; and

forwarding the encapsulated packet according to the unique egress RIF.

14. The method of claim 13, comprising:

exporting a local VNI of the local VRF to the remote VTEP for forwarding of packets by the remote VTEP from the remote VRF to the local VRF, creating a second egress RIF for the local VNI, and associating the second egress RIF with one or more second routing entries in the local VRF instance;

receiving, from the remote VRF, a second packet destined for the local VRF, the second packet encapsulated by the remote VTEP with the derived local VNI;

decapsulate the second packet and look up the decapsulated packet in the one or more second routing entries in the local VRF instance to retrieve the second egress RIF; and

forwarding the second packet according to the second egress RIF.

15. The method of claim 13, wherein the local VTEP and the remote VTEP are included in an Ethernet Virtual Private Network (EVPN), wherein packets communicated between different VRFs are encapsulated based on VXLAN encapsulation.

16. The method of claim 13, wherein importing the D-VNI comprises importing the D-VNI using an instance of a Border Gateway Protocol (BGP) associated with the local VRF.

17. The method of claim 13, wherein associating the unique egress RIF comprises associating the unique egress RIF with a plurality of routing entries respectively belonging to a plurality of VRF instances respectively created for a plurality of local VRFs configured in the local VTEP.

18. The method of claim 13, comprising configuring the one or more routing entries in a forwarding rule in an Access Control List (ACL), and wherein looking up the packet comprises matching the packet to one of the forwarding rules in the ACL.

19. The method of claim 13, wherein each of the local VTEP and the remote VTEP comprises a leaf network device or a serving network device in the communication network, and wherein each of the leaf network devices is assigned one or more local VRFs and each of the serving network devices is assigned one or more remote VRFs different from the local VRFs.

20. The method of claim 19, wherein a service host is coupled to a given service network device on which a corresponding shared service VRF is configured, and wherein the service host provides services to one or more of the local VRFs over the communication network.

21. The method of claim 19, wherein the communication network has a hub-spoke topology in which one or more hub network devices are configured with hub VRFs that support routing between served hosts belonging to different ones of the local VRFs.

22. The method of claim 13, wherein the communication network supports an equal-cost multi-path ECMP routing protocol, and wherein the method further comprises encapsulating packets forwarded to a plurality of remote VTEPs with different respective D-VNIs using different ECMP paths.

23. The method of claim 13, wherein receiving the packet comprises receiving the packet from a host or network element in the first VRF, or receiving the packet from a third VRF.

24. The method of claim 13, wherein importing the D-VNI comprises importing the D-VNI from the remote VTEP, or receiving the D-VNI by receiving the D-VNI in one or more commands manually sent by a user, or automatically by running a script containing the one or more commands.

25. A network device for use as a local virtual extensible local area network, VXLAN, tunnel endpoint, VTEP, the network device comprising:

a communication interface to communicate with one or more remote VTEPs, wherein the local VTEP and the one or more remote VTEPs are assigned respective VXLAN identifiers VNIs;

a first processor running a control program for:

importing a downstream-VNID-VNI for forwarding packets from the local VTEP to a remote VTEP;

creating a unique egress routing interface, RIF, that is convertible to the imported D-VNI; and

associating the unique egress RIF with one or more routing entries in the local VTEP; and

a packet processor to:

receiving a packet addressed to the remote VTEP;

looking up the packet in the one or more routing entries in the local VTEP to retrieve the unique egress RIF, convert the unique egress RIF to the imported D-VNI, and encapsulate the packet with the imported D-VNI; and

forwarding the encapsulated packet according to the unique egress RIF.

26. The network device of claim 25, wherein the control program is to:

exporting, by the remote VTEP, a local VNI of the local VTEP to the remote VTEP for forwarding of packets from the remote VTEP to the local VTEP; and

creating a second egress RIF for the local VNI and associating the second egress RIF with one or more second routing entries in the local VTEP; and

the packet processor is to:

receiving, from the remote VTEP via the communication interface, a second packet destined for the local VTEP, the second packet encapsulated by the remote VTEP with the derived local VNI;

decapsulating the second packet;

looking up the decapsulated packet in the one or more second routing entries to retrieve the second egress RIF; and

forwarding the second packet according to the second egress RIF.

27. The network device of claim 25, wherein the local VTEP and the one or more remote VTEPs belong to different respective sites in a multi-site topology.

28. The network device of claim 25, wherein the local VTEP serves as a border gateway, BGW VTEP, and the one or more remote VTEPs serve as leaf VTEPs coupled to hosts, and wherein the BGW VTEPs and the hosts are assigned a common virtual routing and forwarding domain, VRF.

29. The network device of claim 25, wherein the local VTEP and the remote VTEP are assigned different respective VNIs.

30. The network device of claim 25, wherein the network device is included in a communication network comprising a plurality of interconnected network devices, and wherein the network device functions as a leaf VTEP or a BGW VTEP in the communication network.

31. A method for data communication, comprising:

in a network device acting as a local virtual extensible local area network, VXLAN, tunnel endpoint, VTEP, communicating with one or more remote VTEPs, wherein the local VTEP and the one or more remote VTEPs are assigned respective VXLAN identifiers, VNIs;

importing, by a control program running on the local VTEP, a downstream VNID-VNI for forwarding packets from the local VTEP to a remote VTEP;

creating a unique egress routing interface, RIF, that is convertible to the imported D-VNI;

associating the unique egress RIF with one or more routing entries in the local VTEP;

receiving, by a packet processor of the local VTEP, packets destined for the remote VTEP;

looking up the packet in the one or more routing entries in the local VTEP to retrieve the unique egress RIF, convert the unique egress RIF to the imported D-VNI, and encapsulate the packet with the imported D-VNI; and

forwarding the encapsulated packet according to the unique egress RIF.

32. The method of claim 31, comprising:

exporting, by the remote VTEP, a local VNI of the local VTEP to the remote VTEP for forwarding of packets from the remote VTEP to the local VTEP, creating a second egress RIF for the local VNI, and associating the second egress RIF with one or more second routing entries in the local VTEP;

receiving, from the remote VTEP, a second packet destined for the local VTEP, the second packet encapsulated by the remote VTEP with the derived local VNI;

decapsulate the second packet and look up the decapsulated packet in the one or more second route entries to retrieve the second egress RIF; and

forwarding the second packet according to the second egress RIF.

33. The method of claim 31, wherein the local VTEP and the one or more remote VTEPs belong to different respective sites in a multi-site topology.

34. The method according to claim 31, wherein the local VTEP serves as a border gateway, BGW VTEP, and the one or more remote VTEPs serve as leaf VTEPs coupled to hosts, and wherein the BGW VTEPs and the hosts are assigned a common virtual routing and forwarding domain, VRF.

35. The method of claim 31, wherein the local VTEP and the remote VTEP are assigned different respective VNIs.

36. The method of claim 31, wherein the network device is included in a communication network comprising a plurality of interconnected network devices, and wherein the network device functions as a leaf VTEP or a BGW VTEP in the communication network.

37. A method for communicating between virtual routing and forwarding domains, VRFs, the method comprising:

communicating between a local VRF configured in a local VXLAN tunnel endpoint VTEP and a remote VRF configured in a remote VTEP but not in the local VTEP;

importing, by the local VTEP, a downstream VXLAN identifier, D-VNI, associated with the remote VRF for forwarding packets from the local VRF to the remote VRF and creating a unique egress routing interface, RIF, that is translatable to the imported D-VNI; and

when a packet destined for the remote VRF is received by the local VTEP, converting the unique egress RIF retrieved based on the packet to the imported D-VNI and encapsulating the packet with the imported D-VNI; and

forwarding the encapsulated packet according to the unique egress RIF.

38. A method for communicating between stations of different routing domains, the method comprising:

communicating between a local VXLAN tunnel endpoint VTEP and a remote VTEP belonging to a different respective routing domain;

importing, by the local VTEP, a downstream-VNID-VNI for forwarding packets from the local VTEP to the remote VTEP, and creating a unique egress routing interface, RIF, that is convertible to the imported D-VNI;

when a packet destined for the remote VTEP is received by the local VTEP, converting the unique egress RIF retrieved based on the packet to the imported D-VNI, and encapsulating the packet with the imported D-VNI; and

forwarding the encapsulated packet according to the unique egress RIF.

Images