Router operating methods and apparatus using virtual VPN instances for hosts of remote extranet VPNs

In one illustrative example, a router may be configured to provide a plurality of virtual private network (VPN) instances for a plurality of VPNs associated with a plurality of IDs. Each VPN instance may comprise a forwarding table instance for storing a plurality of host-to-router mappings for the VPN. The router may be further configured to provide a virtual VPN instance for a virtual VPN associated with an ID of a remote extranet VPN. The virtual VPN instance may comprise a map-cache for storing a host-to-router mapping for the remote extranet VPN. The virtual VPN instance has no corresponding forwarding table instance for user plane traffic associated with the remote extranet VPN, but rather serves as part of a control plane interface for control signaling associated with the remote extranet VPN. Accordingly, the router may provide multiple updates to host-to-router mappings in forwarding table instances of the VPNs in accordance with a change in the host-to-router mapping in the virtual VPN instance.

TECHNICAL FIELD

The present disclosure relates generally to methods and apparatus for use in providing virtual private networks (VPNs) for hosts in communication networks, and more particularly to router operating methods and apparatus for providing VPNs with use of “virtual VPN instances” for hosts of remote extranet VPNs.

BACKGROUND

A network overlay may employ software virtualization to create an additional layer of network abstraction on top of a physical network. Such a network overlay may be used to provide virtual private networking (VPN) for hosts in the network.

Specifically, network routers may be configured to operate using a network overlay protocol to facilitate VPN networking. The protocol may be, for example, Locator ID/Separation Protocol (LISP); however, other suitable alternatives may be utilized, such as Virtual Extensible LAN (VXLAN), Enhanced VLAN (EVLAN), or Identifier Locator Addressing (ILA). Here, the routers create and maintain multiple VPN instances comprising forwarding tables for the routing of user plane traffic associated with different VPNs.

Current implementations of these routers involve remote extranet VPNs to be instantiated locally, so that control plane messages received in the context of these VPNs may be processed. However, when routers support one-to-many extranet VPN deployments, the amount of control plane signaling associated with the extranet VPNs grows in proportion to the number of extranets. At scale, the amount of such control plane signaling may become very large or even prohibitive.

DESCRIPTION OF EXAMPLE EMBODIMENTS

OVERVIEW

In one illustrative example, a router may be configured to provide a plurality of virtual private network (VPN) instances for a plurality of VPNs associated with a plurality of IDs. Each VPN instance may comprise a forwarding table instance for storing a plurality of host-to-router mappings for the VPN. The router may be further configured to provide a virtual VPN instance for a virtual VPN associated with an ID of a remote extranet VPN. The virtual VPN instance may comprise a cache or map-cache for storing a host-to-router mapping for the remote extranet VPN. The virtual VPN instance may have no corresponding forwarding table instance in the router, but simply serve as part of a control plane interface for control signaling associated with the remote extranet VPN (e.g. no user plane traffic associated with the remote extranet VPN is or need be facilitated by the router). Accordingly, the router may provide multiple updates to host-to-router mappings in forwarding table instances of the VPNs in response to a change in the host-to-router mapping of the virtual VPN instance. Such a virtual VPN instance may be provided in association with each one of a plurality of different remote extranet VPNs.

More detailed and alternative techniques and implementations are provided as described further below.

EXAMPLE EMBODIMENTS

As described in the background, a network overlay may employ software virtualization to create an additional layer of network abstraction on top of a physical network. Such a network overlay may be used to provide virtual private networking (VPN) for hosts in a network. Specifically, routers in the network may be configured to operate using a network overlay protocol to facilitate VPN networking. The protocol may be, for example, Locator ID/Separation Protocol (LISP); however, other suitable alternatives may be utilized, such as Virtual Extensible LAN (VXLAN), Enhanced VLAN (EVLAN), or Identifier Locator Addressing (ILA). Here, the routers create and maintain multiple VPN instances comprising forwarding tables for the routing of user plane traffic associated with different VPNs.

The technology utilized may be based on or referred to as virtual routing and forwarding (VRF) technology. Such network virtualization creates multiple, logically-separated topologies across one common physical infrastructure. Network reachability within a VPN is typically restricted to the addresses of the end-points that are members of the VPN. Such a level of segmentation is useful in providing fault isolation, enforcing access-control restrictions, enabling the use of a single network by multiple tenants, and scoping network policy per VPN.

Again, a protocol referred to as LISP may be to used create and maintain VPNs. LISP provides two namespaces: an End-point Identifier (EID) namespace and a Routing Locator (RLOC) namespace. A host (e.g. a computer or a server) may be associated with an EID (e.g. an IP address), whereas a router may be associated with an RLOC (e.g. an IP address). A router may be an ingress tunnel router (ITR), an egress tunnel router (ETR), or a combination thereof (ITR+ETR=XTR).

A LISP Mapping System (e.g. including a mapping server and/or database) maps EIDs to RLOCs. Either the EID space, the RLOC space, or both, may be segmented. The LISP Mapping System can be used to map a segmented EID address space to the RLOC space. When the EID namespace is segmented, a LISP Instance-ID (IID) is encoded in both the data plane and the control plane to provide segmentation as well as to disambiguate overlapping EID Prefixes. This allows multiple VRFs to share a common routing locator network while maintaining EID prefix segmentation.

In a LISP VPN, XTRs that are members of the VPN should be configured with a forwarding context (e.g. a VRF) and the associated IID for the VPN. Based on this configuration, the ETRs must register the EIDs within the forwarding context as Extended EIDs (IID+EID). The LISP mapping system consolidates the registrations from all the ETRs in the VPN and builds a mapping database for the VPN. ITRs that are members of the VPN will do forwarding lookups in the forwarding context where traffic was received. Upon a cache miss within the forwarding context, the ITR will issue a Map-Request for the destination EID and include the VPN's IID. This information will be encoded as an Extended EID (IID+EID) in the Map-Request issued. The IID to associate with the EID in this Map-request is derived from the configuration of the VPN's forwarding context (in which the traffic was received). The Mapping System should reply to the Map Request with a Mapping for the Extended EID (IID+EID), the IID of the Extended EID should be used to identify the forwarding context in which the Mapping received should be cached.

Once a mapping has been cached in the VPN's forwarding context, the ITR will encapsulate the traffic towards the RLOC in the mapping. The IID corresponding to the VPN's forwarding context must be included in the IID field of the data plane header. When the encapsulated traffic is received at the ETR, the encapsulation header is removed and the IID received in the header is used to identify the forwarding context to use to do a forwarding lookup for the decapsulated traffic.

Additional details regarding LISP VPN networking may be found in, for example, a document titled “LISP Virtual Private Networks (VPNs),” draft-moreno-lisp-vpn-00, an Internet-Draft from the Network Working Group.

Distributed extranet VPN support may also be provided with LISP. As the extranets are not centralized but rather distributed to ITRs, there is no centralized point of failure. For LISP extranet routes, an ITR may operate to encapsulate user plane traffic associated with the IID corresponding to the VPN connected to the ETR. Extranet routes may be installed at the ITR with the IID corresponding to the destination VPN.

Such routers as described need to replicate control signaling for each and every VPN to which a route is leaked. When a host of a remote extranet VPN moves from one router to another router, for example, each and every VPN instance in the router may need to have the same extranet route updated separately and individually. At scale, when the number of VPNs grows, the amount of control signaling may become very large or even prohibitive.

The forwarding tables in the routers are comprised of costly, high-speed memory, such as ternary content-addressable memory (TCAM). Conservation of such costly memory space is desirable. Extranets may be built on the observation that, when deploying network overlays, not all routers need to instantiate all VPNs with their associated routes in the forwarding tables. Extranet “hard state” in the forwarding tables may be programmed on a need-to-know basis.

Accordingly, what is proposed is the creation and maintenance of “virtual VPNs instances” (or “virtual soft states”) to facilitate “virtual VPNs” for remote extranet VPNs. Virtual VPNs may be fully functional from a control signaling perspective, but do not lead to the generation of “hard states” in the router. Thus, the advantages associated with a distributed hard state for extranets may be maintained without “paying the price” of an increased control signaling load.

A “virtual VPN instance” in the router may be used to exchange control plane signaling associated with a remote extranet VPN. Advantageously, the router need not replicate control signaling to each and every VPN to which an extranet route is leaked. When a host of a remote extranet VPN moves from one router to another, for example, a single exchange of control signaling may trigger an update to each and every affected VPN instance in the router. Refresh signaling may be performed only once, and this may correctly refresh the hard state on each and every VPN that has learned the extranet route. No control signaling across VPN boundaries in the router is necessary. Further, memory space in costly, high-speed memory of router forwarding tables may be conserved.

FIG. 1Ais an illustrative representation of a network infrastructure arrangement100for use in describing general VPN techniques. Although LISP is used in the examples, any suitable network overlay protocol for VPN networking may be utilized (e.g. VXLAN, EVLAN, or ILA).

Network infrastructure arrangement100includes a plurality of routers106(e.g. a router102indicated as “XTR1,” and a router104indicated as “XTR2”) and a plurality of hosts108(e.g. hosts122,124, and126). InFIG. 1A, host122(e.g. a computer or other computing device) may be identified with an End-point Identifier (EID) (e.g. an IP address) of 10.1.1.1; host124(e.g. a computer or other computing device) may be identified with an EID of 10.2.2.2; and host126(e.g. a server) may be identified with an EID of 10.3.3.3. Router102(“XTR1”) may be identified with a Routing Locator (RLOC) (e.g. an IP address), generally indicated as “XTR1,” and router104(“XTR2”) may be associated with an RLOC, generally indicated as “XTR2.”

Routers106may be configured to provide VPNs for the plurality of hosts108with use of VRF technology. In the example ofFIG. 1A, host122may be associated with a VPN110(“VPN1”), host124may be associated with a VPN112(“VPN2”), and host126may be associated with a VPN114(“VPN3”).

To provide VPNs in the network infrastructure arrangement100, a router may be generally configured to create and maintain a plurality of VPN instances. Each VPN and/or VPN instance may be associated and/or identified with a unique ID, which may be an Instance-ID (IID). In general, a VPN instance comprises a forwarding table (or forwarding table instance) which includes a plurality of host-to-router mappings of the VPN. The host-to-router mappings in the forwarding table instance of the VPN are used for routing user data traffic between hosts of the VPN. Typically, a forwarding table is or includes a relatively costly, high-speed memory, such as TCAM. Each host-to-router mapping may be, for example, between an EID (e.g. an IP address) of a host and an RLOC (e.g. an IP address) of a router (e.g. an EID-to-RLOC mapping). Note that a VPN instance or forwarding table instance may refer or be referred to as a VRF, VRF instance, a forwarding context, or the like.

More specifically inFIG. 1A, router102(“XTR1”) may be configured to create and maintain VPN instance160and VPN instance162to provide VPN110(“VPN1”) and VPN112(“VPN2”), respectively. VPN instance160for VPN110(“VPN1”) associated with IID1 may include a forwarding table instance130and an associated map-cache132, and VPN instance162for VPN112(“VPN2”) associated with IID2 may include a forwarding table instance140and an associated map-cache142. On the other hand, router104(“XTR2”) may be configured to create and provide a VPN instance164for VPN114(“VPN3”) associated with IID3, which includes a forwarding table instance150and an associated map-cache152. From the perspective of router102(“XTR1”), VPN114is a remote extranet VPN having no local member hosts/endpoints.

In general, a forwarding table instance of a VPN corresponds to storage of a “hard state” and its associated map-cache corresponds to storage of a “soft state.” In router102, a host-to-router mapping in VPN instance160for host126(e.g. 10.3.3.3 @XTR2 in the IID3 context) is stored in map-cache132as the “soft state,” and this mapping may be (subsequently) stored in forwarding table instance130as the “hard state.” Also in router102, the same host-to-router mapping in VPN instance162for host126(e.g. 10.3.3.3@XTR2 in the IID3 context) is stored for VPN112in map-cache142as the “soft state,” and this mapping may be (subsequently) stored in forwarding table instance140as the “hard state.” In router104, a host-to-router mapping in VPN instance164for host122(e.g. 10.1.1.1 @XTR1 in the IID1 context) is stored in map-cache152as the “soft state,” and this mapping may be (subsequently) stored in forwarding table instance150as the “hard state.” Also in router104, a host-to-router mapping in VPN instance164for host124(e.g. 10.2.2.2@XTR1 in the IID2 context) is stored in map-cache152as the “soft state,” and this mapping may be (subsequently) stored in forwarding table instance150as the “hard state.”

Sometime during network usage, host126may be moved to a different location and/or become connected to a different router. In response, the host-to-router mapping for host126will change. That is, the router and/or RLOC in the host-to-router mapping will change. As a result, host-to-router mappings in other routers/VPNs (e.g. in router102) may need to be updated.

Thus, as indicated inFIG. 1B, an exchange of control plane signaling150between routers may need to take place to update the host-to-router mapping for host126in VPN instance160for VPN110(“VPN1”). Further as indicated inFIG. 1B, an additional (duplicate) exchange of control plane signaling152between routers may need to take place to update the host-to-router mapping for host126in VPN instance162for VPN112(“VPN2”).

As is apparent, replicated control information is exchanged between routers when an update to a host-to-router mapping is needed. When the number of remote extranet VPNs becomes large, the number of exchanges of control plane signaling may become very large or even prohibitive.

FIG. 2Ais an illustrative representation of a network infrastructure arrangement200for use in describing virtual private networking techniques according to some implementations of the present disclosure. Network infrastructure arrangement200includes the same or similar network elements and functionality as described above in relation toFIGS. 1A-1B, except that router102(now a “router202” inFIGS. 2A-2B) is configured to employ VPN instances as well as “virtual VPN instances” for “virtual VPNs” according to some implementations of the present disclosure. To simplify the description and for comparative purposes, router104is configured to operate in the same or similar manner as that described in relation toFIGS. 1A-1B. Although LISP is used in the example implementations described herein, any suitable network overlay protocol may be utilized (e.g. VXLAN, EVLAN, or ILA).

In the example ofFIG. 2A, router202(“XTR1”) may be configured to create and maintain VPN instances210and220to provide VPNs110and112, respectively. VPN instance210for VPN110(“VPN1”) associated with IID1 comprises a forwarding table instance212, and VPN instance220for VPN112(“VPN2”) associated with IID2 comprises a forwarding table instance222. The host-to-router mapping in VPN instance210of VPN110for host126(e.g. 10.3.3.3@XTR2 in the IID3 context) is stored in forwarding table instance212as the “hard state.” The same host-to-router mapping in VPN instance220of VPN112for host126(e.g. 10.3.3.3 @XTR2 in the IID3 context) is stored in forwarding table instance222as the “hard state.”

Router202may be further configured to create and maintain a virtual VPN instance230for a virtual VPN for host126of VPN114(“VPN3”), which is a remote extranet VPN. Virtual VPN instance230may comprise a cache or map-cache232for storing a host-to-router mapping of the remote extranet VPN114(“VPN3”). Virtual VPN instance230for the virtual VPN is without a (uniquely) corresponding forwarding table instance in router202. Thus, virtual VPN instance230does not require the use of the relatively costly, high-speed memory in router230. As is apparent, a VPN instance for VPN114is not instantiated in router202, but rather virtual VPN instance230for a virtual VPN″ associated with VPN114is created and maintained. Note that, with use of a virtual VPN instance, a specific map-cache or soft state need not be used or maintained in relation to either one of VPN instances210and220.

Virtual VPN instance230of the virtual VPN may serve as part of a control plane interface for control signaling associated with the remote extranet VPN (i.e. VPN114or “VPN3”). For example, virtual VPN instance230may be used in an exchange of control signaling/information for an update to the host-to-router mapping of host126of the remote extranet VPN. For providing such an update(s), one or more pointers or links may be provided in association with the host-to-router mapping in map-cache232of virtual VPN instance230.

For example, a first pointer or link may be provided for pointing or linking to forwarding table instance212of VPN instance210, and a second pointer or link may be provided for pointing or linking to forwarding table instance222of VPN instance220. In response to an update to the host-to-router mapping in map-cache232of virtual VPN instance230, the first pointer or link may be used to identify and update the host-to-router mapping in forwarding table instance212of VPN instance210, and the second pointer or link may be used to identify and update the host-to-router mapping in forwarding table instance222of VPN instance220.

To more fully illustrate such an update, host126of the remote extranet VPN (“VPN3”) may be moved to a different location and/or become connected to a different router. In response, the host-to-router mapping for host126will change. That is, the router and/or RLOC in the host-to-router mapping will change. As a result, host-to-router mappings in other routers/VPNs (e.g. in router202) may need to be updated. As described previously, virtual VPN instance230of the virtual VPN may serve as part of a control plane interface for control signaling associated with the remote extranet VPN. Thus, according to some implementations of the present disclosure, as indicated inFIG. 2B, an exchange (e.g. a single exchange) of control plane signaling250may take place between routers to update the host-to-router mapping for host126in map-cache232of the virtual VPN instance230of router202. This (e.g. single) notification or update to the host-to-router mapping in map-cache232of the virtual VPN instance230may be used to update both (or all) of the affected host-to-router mappings in forwarding table instances212and222of the VPN instances210and220, respectively. Here, the first pointer or link associated with virtual VPN instance230may be used to identify and update the host-to-router mapping in forwarding table instance212of VPN instance210(“VPN1”), and the second pointer or link associated with virtual VPN instance230may be used to identify and update the host-to-router mapping in forwarding table instance222of VPN instance220(“VPN2”).

Note that, although a single virtual VPN instance of a single virtual VPN is shown and described in relation toFIGS. 2A-2B, a plurality of virtual VPN instances for a plurality of virtual VPNs associated with a plurality of remote extranet VPNs may be provided and used in the same or similar manner.

FIG. 3is a flowchart300for describing a router operating method for use in providing VPNs in communication networks according to some implementations of the present disclosure. The router operating method may involve the use of one or more virtual VPN instances in the router or routing device. The router may include one or more processors and one or more memory devices coupled to the one or more processors. The method may be embodied as a computer program product including a non-transitory computer readable medium and instructions stored in the computer readable medium where the instructions are executable on one or more processors of the router or routing device for performing the steps of the method.

Beginning at a start block302ofFIG. 3, a router may provide a plurality of VPN instances (e.g. VRFs) for a plurality of VPNs associated with a plurality of IDs (step304ofFIG. 3). Each VPN instance may comprise a forwarding table instance which stores a plurality of host-to-router mappings of the VPN. The router may further provide a virtual VPN instance for a virtual VPN associated with an ID of a remote extranet VPN (step306ofFIG. 3). The virtual VPN instance may comprise a cache or a map-cache for storing a host-to-router mapping associated with the remote extranet VPN. The virtual VPN instance may have no (uniquely) corresponding forwarding table instance in the router, but serve as part of a control plane interface for control signaling associated with the remote extranet VPN. With use of the virtual VPN instance, the router may provide updates to host-to-router mappings in forwarding table instances of the VPNs in accordance with an update to the host-to-router mapping in the virtual VPN instance for the remote extranet host (step308ofFIG. 3). For updates, one or more pointers or links may be provided in association with the host-to-router mapping in the map-cache of the virtual VPN instance. Note that step306ofFIG. 3(as well as its associated step308) may be performed (e.g. repeated) for and in association with each one a plurality of additional remote extranet VPNs.

In some implementations, the technique ofFIG. 3may be implemented using LISP, where each host-to-router mapping may be between an End-point Identifier (EID) of a host and a Routing Locator (RLOC) of a router (e.g. with use of LISP), and the IDs used may be Instance-IDs (“IIDs”).

FIG. 4is a flowchart400for describing a router operator method for use in providing VPNs in communication networks according to some implementations of the present disclosure. The router operating method may be executed in a router or routing device. The router operating method may involve the use of one or more virtual VPN instances in the router or routing device. The router may include one or more processors and one or more memory devices coupled to the one or more processors. The method may be embodied as a computer program product including a non-transitory computer readable medium and instructions stored in the computer readable medium where the instructions are executable on one or more processors of the router or routing device for performing the steps of the method.

Beginning at a start block402ofFIG. 4, the router may create and provide a plurality of VPN instances for a plurality of VPNs associated with a plurality of IDs (step404ofFIG. 4). Each VPN instance may comprise a forwarding table instance for storing a plurality of host-to-router mappings of the VPN. The router may receive a host-to-router mapping associated with an ID of a remote extranet VPN (step406ofFIG. 4). The ID may correspond to a VPN which is not instantiated in the router, and/or has no local member host/endpoints. In response, the router may create a virtual VPN instance for a virtual VPN associated with the ID of the remote extranet VPN (step408ofFIG. 4). The virtual VPN instance for the virtual VPN may comprise a cache or a map-cache for storing the host-to-router mapping associated with the ID of the remote extranet VPN. The virtual VPN instance may have no (uniquely) corresponding forwarding table instance in the router, but may serve as part of a control plane interface for control signaling associated with the remote extranet VPN. With use of the virtual VPN instance, the router may update one or more of the host-to-router mappings in one or more of the forwarding table instances in accordance with the host-to-router mapping of the virtual VPN instance (step410ofFIG. 4). For the updates, one or more pointers or links may be provided in association with the host-to-router mapping in the map-cache of the virtual VPN instance. Note that step410ofFIG. 4may be repeated for one or more updates to the host-to-router mapping associated with the remote extranet VPN. Note also that steps406,408, and410ofFIG. 4may be repeated for one or more additional host-to-router mappings associated with one or more additional remote extranet VPNs.

In some implementations, the technique ofFIG. 4may be implemented using LISP, where each host-to-router mapping may be between an End-point Identifier (EID) of a host and a Routing Locator (RLOC) of a router (e.g. with use of LISP), and the IDs used may be Instance-IDs (“IIDs”).

FIG. 5Ais an illustrative representation of a network infrastructure arrangement500for further general VPN techniques, without use of virtual VPN instances of the present disclosure. Although LISP technology is used in the example, any suitable network overlay protocol configured to provide VPN networking may be utilized.

Network infrastructure arrangement500includes a plurality of routers504(e.g. routers510,512, and514) and a plurality of hosts506(e.g. hosts530,532, and534) in one or more communication networks502. InFIG. 5A, router510may be associated with an RLOC of 172.16.1.1; router512may be associated with an RLOC of 172.18.1.1; and router514may be associated with an RLOC of 172.17.1.1. In addition, host530(e.g. a computer or other computing device) may be associated with an EID of 10.1.1.1; host532(e.g. a server) may be associated with an EID of 192.168.1.1; and host534(e.g. a server) may be associated with an EID of 192.168.2.2.

The plurality of routers504may be configured to provide VPNs for the plurality of hosts506with use of VRF technology. In the example ofFIG. 5A, host530may be associated with a VPN520(“VPN1”), host532may be associated with a VPN524(“VPN2”), and host534may be associated with VPN526(“VPN3”).

To provide VPNs in the network infrastructure arrangement500, a router may be generally configured to create and maintain a plurality of VPN instances. Each VPN instance and/or VPN may be associated and/or identified with a unique ID, which may be an IID. A VPN instance comprises a forwarding table (or forwarding table instance) which includes a plurality of host-to-router mappings of the VPN. The host-to-router mappings in the forwarding table instance of the VPN are used for routing user data traffic between hosts of the VPN. Again, a forwarding table is or includes a relatively costly, high-speed memory, such as a TCAM. Each host-to-router mapping may be, for example, between an EID (e.g. an IP address) of a host and a RLOC (e.g. an IP address) of a router (e.g. an EID-to-RLOC mapping), in accordance with LISP.

More specifically inFIG. 5A, router514may be configured to create and maintain VPN instance554and VPN instance564to provide VPN524(“VPN2”) and VPN526(“VPN3”), respectively. VPN instance554for VPN524(“VPN2”) associated with IID2 may include a forwarding table instance550and an associated map-cache552, and VPN instance564for VPN526(“VPN3”) associated with IID3 may include a forwarding table instance560and an associated map-cache562. From the perspective of router514, VPN520(“VPN1”) is a remote extranet VPN having no local member hosts/endpoints.

Again, a forwarding table instance of a VPN corresponds to storage of a “hard state” and its associated map-cache corresponds to storage of a “soft state.” In router514, a host-to-router mapping in VPN instance554for host530(e.g. 10.1.1.1 via 172.16.1.1 in the IID1 context) is stored in map-cache552as the “soft state,” and this mapping be (subsequently) stored in forwarding table instance550as the “hard state.” Also in router514, the same host-to-router mapping in VPN instance564for host530(e.g. 10.1.1.1 via 172.16.1.1 in the IID1 context) is stored in map-cache562as the “soft state,” and this mapping may be (subsequently) stored in forwarding table instance560as the “hard state.”

When VPN524(“VPN2”) needs to resolve the route or mapping associated with host530, it may send to a mapping database540a map request580which includes the EID of host530(i.e. 10.1.1.1) in the context of IID2. In response, VPN524may receive from mapping database540a map reply582which includes the host-to-router mapping associated with host530(i.e. 10.1.1.1 via 172.16.1.1) and its associated IID (i.e. IID1). Map-cache552of VPN instance554of VPN524is updated with the received host-to-router mapping, and this map-cache552is used to update the host-to-router mapping in the forwarding table instance550of VPN instance554of VPN524. Similarly, when VPN526(“VPN3”) needs to resolve the route or mapping associated with host530, it may send to mapping database540a map request580which includes the EID of host530(i.e. 10.1.1.1) in the context of IID3. In response, VPN526may receive from mapping database540a map reply582which includes the host-to-router mapping associated with host530(i.e. 10.1.1.1 via 172.16.1.1) and its associated IID (i.e. IID1). Map-cache562of VPN instance564of VPN526is updated with the received host-to-router mapping, and this map-cache562is used to update the host-to-router mapping in the forwarding table instance560of VPN instance564of VPN526.

To more fully illustrate such an update with reference toFIG. 5B, sometime during network usage, host530may be moved to a different location and/or become connected to a different router (step1ofFIG. 5B). For example, host530may be moved from router510to router512of a network522. Accordingly, the host-to-router mapping for host530will change. In this example, the RLOC in the host-to-router mapping for host530will change from 172.16.1.1 of router510to 172.18.1.1 of router512.

Subsequently, in response to detecting host530, a message such as a solicit map request (SMR) may be generated for and received at VPN524(“VPN2”) (step2ofFIG. 5B). In response to receiving the SMR, VPN524may resolve the route, for example, by sending to mapping database540a map request and receiving a map reply in response (step3ofFIG. 5B). The map reply includes the updated host-to-router mapping associated with host530(i.e. 10.1.1.1 via 172.18.1.1). Map-cache552of VPN instance554of VPN524is updated with the received host-to-router mapping, and this map-cache552is used to update the host-to-router mapping in the forwarding table instance550of VPN instance554of VPN524(step4ofFIG. 5B).

Subsequently, an SMR may also be generated for and received at VPN526(“VPN3”) (step5ofFIG. 5B). In response to receiving the SMR, VPN526may resolve the route, for example, by sending to the mapping database540a map request and receiving a map reply in response (step6ofFIG. 5B). The map reply includes the same updated host-to-router mapping associated with host530(i.e. 10.1.1.1 via 172.18.1.1). Map-cache562of VPN instance564of VPN526is updated with the received host-to-router mapping, and this map-cache562is used to update the host-to-router mapping in the forwarding table instance560of VPN instance564of VPN526(step7ofFIG. 5B).

As is apparent, replicated control information is undesirably exchanged between routers when an update to a host-to-router mapping associated with a remote extranet VPN occurs (e.g. when a host moves to a new location). Again, when the number of remote extranet VPNs becomes large, the number of exchanges of control plane signaling may become undesirably large or even prohibitive.

FIG. 6Ais an illustrative representation of a network infrastructure arrangement600for use in describing virtual private networking techniques according to some implementations of the present disclosure. Network infrastructure arrangement600includes the same or similar network elements and functionality as described above in relation toFIGS. 5A-5B, except that router514(now a “router614” ofFIGS. 6A-6B) is configured to employ VPN instances as well as “virtual VPN instances” for “virtual VPNs” according to some implementations of the present disclosure. Again, although LISP technology is used in the example implementations described herein, any suitable network overlay protocol configured to provide VPN networking may be utilized.

Notably, router614may be configured to create and maintain a “virtual VPN instance”640for a virtual VPN610for host530of VPN520(“VPN1”) which is a remote extranet VPN. Virtual map instance640may comprise a cache or map-cache642for storing a host-to-router mapping associated with the remote extranet VPN. Virtual VPN instance640for the virtual VPN610is without a (uniquely) corresponding forwarding table instance in router614. Virtual VPN instance640does not require the use of the relatively costly, high-speed memory in router614. As is apparent, a VPN instance is not instantiated in router614for the remote extranet VPN, but rather virtual VPN instance640for virtual VPN610is created and maintained. Relatedly, note that, with use of virtual VPN instance640, a specific corresponding map-cache or soft state need not be used or maintained in relation to either one of VPN instances654and664as shown (e.g. compare withFIGS. 5A-5B).

Router614may create virtual VPN instance640in response to receiving a message, such as message which includes a host-to-router mapping for a host of a remote extranet VPN. More specifically, virtual VPN instance640may be created when the received host-to-router mapping is associated with an IID of a remote extranet VPN which is not instantiated in router614and/or has no local member host/endpoints.

To illustrate such creation, VPN524(“VPN2”) may send to mapping database540a map request680associated with host530identified by 10.1.1.1 and, in response, receive from mapping database540a map reply682which includes the host-to-router mapping for host530(i.e. 10.1.1.1 via 172.16.1.1) and its associated IID (i.e. IID1). IID1 corresponds to a remote extranet VPN; a VPN for IID1 is not instantiated in router614, and no local member host/endpoints for IID1 exist. In response, VPN524may create virtual VPN instance640for the remote extranet VPN. Alternatively, and similarly, VPN526(“VPN3”) may send to mapping database540a map request680associated with host530identified by 10.1.1.1, and receive in response a map reply682which includes the host-to-router mapping for host530(i.e. 10.1.1.1 via 172.16.1.1) and its associated IID (i.e. IID1). IID1 corresponds to a remote extranet VPN; a VPN for IID1 is not instantiated in router614, and no local member host/endpoints for IID1 exist. In response, VPN526may create virtual VPN instance640for the remote extranet VPN.

Again, virtual VPN instance640of the virtual VPN may serve as part of a control plane interface for control signaling associated with the remote extranet VPN. For example, virtual VPN instance640may be used in an exchange of control signaling/information for an update to the host-to-router mapping of host530of the remote extranet VPN (i.e. VPN520or “VPN1”). For providing such an update(s), one or more pointers or links may be provided in association with the host-to-router mapping in map-cache642of virtual VPN instance640. For example, a first pointer or link may be provided for pointing or linking to forwarding table instance650of VPN instance654, and a second pointer or link may be provided for pointing or linking to forwarding table instance660of VPN instance664. In response to an update to the host-to-router mapping in map-cache642of virtual VPN instance640, the first pointer or link may be used to identify and update the host-to-router mapping in forwarding table instance650of VPN instance654, and the second pointer or link may be used to identify and update the host-to-router mapping in forwarding table instance660of VPN instance664.

To more fully illustrate such an update with reference toFIG. 6B, sometime during network usage, host530may be moved to a different location and/or become connected to a different router (step1ofFIG. 6B). For example, host530may be moved from router510to router512of network522. Accordingly, the host-to-router mapping for host530will change. In this example, the RLOC in the host-to-router mapping for host530will change from 172.16.1.1 of router510to 172.18.1.1 of router512. In response to detecting the new host530, a message such as an SMR may be generated for and received at the virtual VPN610(“virtual VPN1”) (step2ofFIG. 6B). In response to receiving the SMR, the virtual VPN610may resolve the route, for example, by sending to the mapping database540a map request and receiving a map reply in response (step3ofFIG. 6B). The map reply may include the updated host-to-router mapping associated with host530(i.e. 10.1.1.1 via 172.18.1.1). Map-cache642of VPN instance640of virtual VPN610may then be updated according to the received host-to-router mapping (step4ofFIG. 6B). The updated host-to-router mapping in the map-cache642of VPN instance640may then be used to update the host-to-router mapping in forwarding table instance650of VPN instance654for VPN524(“VPN2”), as well as to update the host-to-router mapping in forwarding table instance660of VPN instance664for VPN526(“VPN3”) (step5ofFIG. 6B).

As is apparent, with use of a virtual VPN, a simple exchange (e.g. a single exchange) of control signaling may be used as a trigger to update each and every affected VPN instance in the router. Advantages associated with a distributed hard state for extranets may be maintained without “paying the price” of an increased control signaling load. No control signaling across VPN boundaries in the router is necessary. Further, memory space in the costly, high-speed memory of the router may be conserved.

Thus, router operating methods and apparatus using “virtual VPN instances” for hosts of remote extranet VPNs have been described herein. In one illustrative example, a router may be configured to provide a plurality of VPN instances for a plurality of VPNs associated with a plurality of IDs. Each VPN instance may comprise a forwarding table instance for storing a plurality of host-to-router mappings for the VPN. The router may be further configured to provide a virtual VPN instance for a virtual VPN associated with an ID of a remote extranet VPN. The virtual VPN instance may comprise a cache or map-cache for storing a host-to-router mapping for the remote extranet VPN. The virtual VPN instance in the map-cache may have no corresponding forwarding table instance in the router, but simply serve as part of a control plane interface for control signaling associated with the remote extranet VPN (e.g. no user plane traffic associated with the remote extranet VPN is or need be facilitated by the router). Accordingly, the router may provide multiple updates to host-to-router mappings in forwarding table instances of the VPNs in accordance with a (e.g. single) notification of a change in the host-to-router mapping in the virtual VPN instance. Such a virtual VPN instance comprising a cache or map-cache may be provided in the router for and in association with each one of a plurality of different remote extranet VPNs.

One or more pointers or links may be provided in association with the virtual VPN instance which stores the host-to-router mapping of the remote extranet VPN. A pointer or link may be for pointing to a forwarding table instance of a VPN which stores a host-to-router mapping of the VPN. An update to the forwarding table instance of the VPN may be provided based on the pointer or link.

In another illustrative example, a router may comprise one or more processors and one or more memory devices coupled to the one or more processors. The router may be configured to generate and maintain a plurality of VPN instances for a plurality of VPNs associated with a plurality of IDs, where each VPN instance comprise a forwarding table instance for storing a plurality of host-to-router mappings of the VPN; a virtual VPN instance for a virtual VPN associated with an ID of a remote extranet VPN, where the virtual VPN instance comprises a cache or map-cache for storing a host-to-router mapping of the remote extranet VPN; and one or more pointers or links associated with the virtual VPN instance, for updating one or more host-to-router mappings in one or more of the forwarding tables of the VPN instances. The virtual VPN instance for the virtual VPN may be without a corresponding forwarding table instance in the router, and serve as part of a control plane interface for control signaling associated with the remote extranet VPN.

In yet another illustrative example, a router may be configured to provide a plurality of VPN instances for a plurality of VPNs associated with a plurality of IDs. Each VPN instance may comprise a forwarding table instance for storing a plurality of host-to-router mappings. The router may receive a host-to-router mapping associated with an ID of a remote extranet VPN. In response to receiving the host-to-router mapping, the router may create a virtual VPN instance for a virtual VPN associated with the ID of the remote extranet VPN. The virtual VPN instance may comprise a cache or map-cache for storing the host-to-router mapping associated with the ID of the remote extranet VPN. Then, the router may update one or more of the host-to router mappings in one or more of the forwarding table instances of the VPNs in accordance with the host-to-router mapping in the virtual VPN instance.

Note that the components and techniques shown and described in relation to the separate figures may indeed be provided as separate components and techniques, and alternatively one or more (or all of) the components and techniques shown and described in relation to the separate figures are provided together for operation in a cooperative manner.

It will also be understood that, although the terms “first,” “second,” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used to distinguish one element from another. For example, a first VPN instance could be termed a second VPN instance, and similarly, a second VPN instance could be termed a first VPN instance, without changing the meaning of the description, so long as all occurrences of the “first VPN instance” are renamed consistently and all occurrences of the “second VPN instance” are renamed consistently. The first VPN instance and the second VPN instance are both VPN instances, but they are not the same VPN instance.

Further regarding terminology, note that, as the devices indicated in the “host-to-router” mappings may be any suitable devices, the mapping terminology may be more broadly named and/or interpreted, for example, as “node-to-router” mappings, “node-to-node” mappings, “address-to-address” mappings, “identifier-to-identifier” mappings, etc. Further, in relation to any of the illustrative examples described herein, it may be alternatively stated (e.g. in lieu of use of the “virtual VPN” terminology) that what is provided is a cache or map-cache for storing a host-to-router mapping for a remote extranet VPN. Here, the map-cache may have no (uniquely) corresponding forwarding table instance in the router, but may serve simply as part of a control plane interface for control signaling associated with the remote extranet VPN (e.g. no user plane traffic for hosts of the remote extranet VPN is facilitated by the router).