OSPF VPN Extension

 I. OSPF multi-instance on PE


OSPF is a prevalent IGP protocol. In many cases, VPN clients are connected through BGP peers, and the clients often run OSPF. Running OSPF between PEs and CEs can simplify the configuration and management of the CEs, because the CEs only need to support OSPF. In addition, if the customers require MPLS L3VPN services through conventional OSPF backbone, using OSPF between PEs and CEs can simplify the transition.

For OSPF to run between CEs and PEs, the PEs must support multiple OSPF instances. Each OSPF instance must correspond to a VPN instance and have its own interface and routing table.

The following describes details of OSPF configuration between PEs and CEs.

1) Configuration of OSPF areas between PEs and CEs

The OSPF area between a PE and a CE can be either a non-backbone area or a backbone area.

In the OSPF VPN extension application, the MPLS VPN backbone is considered the backbone area (area 0). Since OSPF requires that the backbone area must be contiguous, the area 0 of each VPN site must be connected with the MPLS VPN backbone.

That is, if a VPN site contains an OSPF area 0, the PE connected with the CE must be connected with the area 0 in this VPN site through an area 0 (the virtual link can be used for logical connection).

2) BGP/OSPF interaction

With OSPF running between PEs and CEs, PEs advertise VPN routes to each other through BGP and to CEs through OSPF.

With conventional OSPF, two sites are considered to be in different ASs even if they belong to the same VPN. Therefore, the routes that one site learns are advertised to the other as external routes. This results in higher OSPF traffic and network management problems that should have been avoided otherwise.

Currently, OSPF supports multiple instances and therefore can address the above problems. Properly configured, OSPF sites are considered directly connected, and PEs can exchange OSPF routing information as they are using dedicated lines. This improves the network management and makes OSPF applications more effective.

PE 1 and PE 2 are connected through the MPLS backbone, while CE 11, CE 21, and CE 22 belong to VPN 1. Assumes that all the routers in the figure belong to the same AS, that is, CE 11, CE 21, and CE 22 belong to the same OSPF domain. The advertisement procedure of VPN 1 routes is as follows:
  •  At first, PE 1 redistributes OSPF routes from CE 11 into BGP.
  • Then, PE 1 advertises the VPN routes to PE 2 through BGP.
  • Finally, PE 2 redistributes the BGP VPN routes into OSPF and advertises them to CE 21 and CE 22.
 Application of OSPF in VPN


With the standard BGP/OSPF interaction, PE 2 advertises the BGP VPN routes to CE 21 and CE 22 through Type 5 LSAs (ASE LSAs). However, CE 11, CE 21, and CE 22 belong to the same OSPF domain, and the route advertisement between them should use Type 3 LSAs (inter-provider routes).

To solve the above problems, PE uses an extended BGP/OSPF interaction process called BGP/OSPF interoperability to advertise routes from one site to another,differentiating the routes from real AS-External routes. The process requires that extended BGP community attributes carry the information for identifying the OSPF attributes.

It is required that each OSPF domain has a configurable domain ID. It is recommended to configure for all OSPF instances in the network related to each VPN instance the same domain ID, or adopt the default ID. Thus, the system can know that all VPN routes with the same domain ID are from the same VPN instance.

3) Routing loop detection

If OSPF runs between CEs and PEs and a VPN site is connected to multiple PEs, when a PE advertises the BGP VPN routes learnt from MPLS/BGP to the VPN site through LSAs, the LSAs may be received by another PE, resulting in a routing loop.

To avoid routing loops, when creating Type 3 LSAs, the PE always sets the flag bit DN for BGP VPN routes learnt from MPLS/BGP, regardless of whether the PE and the CEs are connected through the OSPF backbone. When performing route calculation, the OSPF process of the PE ignores the Type 3 LSAs whose DN bit is set.

If the PE needs to advertise to a CE the routes from other OSPF domains, it must indicate that it is the ASBR, and advertise the routes using Type 5 LSAs.

II. Sham link

Generally, BGP peers carry routing information on the MPLS VPN backbone through the BGP extended community attributes. The OSPF that runs on the remote PE can use the information to create Type 3 summary LSAs to be transmitted to the CEs. As shown in Figure 1-17, both site 1 and site 2 belong to VPN 1 and OSPF area1. They are connected to different PEs, PE 1 and PE 2. There is an intra-area OSPF link called backdoor link between them. In this case, the route connecting the two sites through PEs is an inter-area route. It is not preferred by OSPF because its preference is lower than that of the intra-area route across the backdoor link.

Network diagram for sham link


To solve the problem, you can establish a sham link between the two PEs so that the routes between them over the MPLS VPN backbone become an intra-area route.

The sham link acts as an intra-area point-to-point link and is advertised through the Type 1 LSA. You can select a route between the sham link and backdoor link by adjusting the metric.

The sham link is considered the link between the two VPN instances with one endpoint address in each VPN instance. The endpoint address is a loopback interface address with a 32-bit mask in the VPN address space on the PE. Different sham links of the same OSPF process can share an endpoint address, but that of different OSPF processes cannot.

BGP advertises the endpoint addresses of sham links as VPN-IPv4 addresses. A route across the sham link cannot be redistributed into BGP as a VPN-IPv4 route.

A sham link can be configured in any area. You need to configure it manually. In addition, the local VPN instance must have a route to the destination of the sham link.

III. Multi-VPN-Instance CE


Multiple OSPF instances usually run on PEs. A router on a LAN that runs multiple OSPF instances is called a multi-VPN-instance CE. Compared with the OSPF multi-instance on PEs, a multi-VPN-instance CE does not need to support the BGP/OSPF interoperability.

Multi-VPN-instance CEs are used to solve the security problem of LANs at a lower cost.

It is hard to implement the complete separation of services on LANs with traditional routers. Currently, a router supports multiple OSPF processes, which can belong to the public network or a VPN instance. Therefore, you can run multiple OSPF processes on a router and bind them to different VPN instances.

In practice, you can create OSPF instances for different services to separate services and ensure their security.

No comments:

Post a Comment