Ospf

OSPF can be the routing protocol on the PE-CE link. To propagate the customer routes from PE to PE, OSPF is redistributed into iBGP and vice versa on the PE routers. The down side of this is that all OSPF routes become external routes on the remote PE when the routes are redistributed back into OSPF. The result of this would be that all OSPF routes that transverse the MPLS VPN backbone would be less preferable than the routes that did not transverse the backbone but were sent via an intersite link (backdoor link) from one OSPF site to another.

To prevent all redistributed routes from becoming OSPF external prefixes, internal OSPF routes are advertised as summary routes (link-state advertisement [LSA] type 3)—which are interarea routes—on the PE when they are redistributed from BGP back to OSPF. This is not the normal behavior, because the PE routers redistribute BGP routes into OSPF and are autonomous system boundary routers (ASBR) that should advertise the routes as external OSPF routes (LSA type 5). In effect, it is as if the PE routers are area border routers (ABR) that advertise summary routes into another area. However, all OSPF internal routes (intra-area and interarea routes) become interarea (LSA type 3) routes after BGP propagates them, even if the area numbers match on different PE routers. Figure 7-19 shows the propagation of OSPF internal routes across the MPLS VPN backbone.

Figure 7-19 Internal OSPF Routes Across MPLS VPN Backbone

MPLS VPN Super Backbone

VPNv4 Route

VPN Red

Network X LSA Type 1, 2 or 3

Area 0

Area 0

VPN Red

Network X LSA Type 3

Area 0

Area 4

VPN Red

Network X LSA Type 3

Area 0

The normal OSPF route preference dictates that intra-area routes are more preferred than interarea OSPF routes. Because all internal OSPF routes become interarea routes at the remote sites, intra-area routes might still cause a problem becoming interarea routes when a backdoor link exists between sites. The intra-area routes remain intra-area routes across the backdoor link but become interarea routes across the MPLS VPN backbone. Therefore, the intra-area routes that are advertised across the backdoor link are always preferred. To avoid this, you must configure a special link, called a sham link, between the PE routers. Read the section "Sham Link" later in this chapter to learn more.

The PE routers have OSPF areas connected to them. These areas can be the backbone area 0 or any other area. The MPLS VPN backbone can be considered an added hierarchy that is higher than the OSPF backbone area: the MPLS VPN super backbone. Figure 7-20 shows this concept.

Figure 7-20 Possible OSPF MPLS VPN Scenarios

Figure 7-20 Possible OSPF MPLS VPN Scenarios

OSPF VRF Configuration

To run OSPF for a VRF, you configure the OSPF process command with the VRF keyword. The syntax is router ospf process-id vrf vrf-name. Note that RIPv2 and EIGRP have only one routing process with an address family per VRF configured. OSPF has one separate OSPF process per VRF.

Example 7-25 shows the basic OSPF VRF configuration. Obviously, the OSPF VRF process needs to be redistributed into BGP and vice versa. You can configure all the regular OSPF commands for the OSPF VRF process. Make sure you have the subnets keyword on the redistribute bgp command under the router ospf process. Otherwise, only classful routes are redistributed. When you are redistributing OSPF into BGP, make sure to configure the appropriate match parameters on the redistribute command so that you can redistribute the proper OSPF type of routes.

Example 7-25 Basic OSPF VRF Configuration ip vrf cust-one rd 1:1

route-target export 1:1 route-target import 1:1

interface Loopback1 ip vrf forwarding cust-one ip address 10.99.1.1 255.255.255.255

router ospf 42 vrf cust-one router-id 10.99.1.1 log-adjacency-changes redistribute bgp 1 metric 10 subnets network 10.10.2.0 0.0.0.255 area 0

router bgp 1

bgp log-neighbor-changes neighbor 10.200.254.5 remote-as 1

neighbor 10.200.254.5 update-source Loopback0

address-family vpnv4

neighbor 10.200.254.5 activate neighbor 10.200.254.5 send-community extended exit-address-family

address-family ipv4 vrf cust-one redistribute connected redistribute ospf 42 vrf cust-one metric 10 match internal external 1 external 2 exit-address-family

Example 7-26 shows the OSPF VRF process 42 running on the PE router.

Example 7-26 Show IP OSPF Command london#show ip ospf 42

Routing Process "ospf 42" with ID 10.99.1.1

Domain ID type 0x0005, value 0.0.0.42 Supports only single TOS(TOS0) routes Supports opaque LSA Supports Link-local Signaling (LLS) Supports area transit capability Connected to MPLS VPN Superbackbone, VRF cust-one It is an area border and autonomous system boundary router Redistributing External Routes from, bgp 1 with metric mapped to 10, includes subnets in redistribution

Number of areas in this router is 1. 1 normal 0 stub 0 nssa Number of areas transit capable is 0 External flood list length 0 Area BACKBONE(0)

Number of interfaces in this area is 2

Area has no authentication

SPF algorithm last executed 00:04:35.120 ago

SPF algorithm executed 25 times

Area ranges are

Number of LSA 17. Checksum Sum 0x0E27D6

Number of opaque link LSA 0. Checksum Sum 0x000000

Number of DCbitless LSA 0

Number of indication LSA 0

Number of DoNotAge LSA 13

Flood list length 0

OSPF Metric Propagation

When you redistribute both internal and external OSPF routes from OSPF into MP-BGP on the PE router, the PE router uses the OSPF metric to set the BGP MED. The MED is often referred to as the external metric of a BGP route. It is part of the BGP best path selection process. BGP can use it to select the best path when two or more BGP speakers advertise the same route in BGP. The MED is shown as "metric" in the BGP table in Cisco IOS. Look at Example 7-27, where the prefixes 1:1:10.10.100.1/32 and 1:1:10.200.200.1/32 are advertised with a MED (external metric) of 10. When the PE redistributes the route back from BGP into OSPF, the PE uses the MED to set the OSPF metric of the OSPF internal or external route. When you use the default-metric metric-value command or metric option on the redistribute command, it overrides this behavior because it directly sets the metric to the configured value.

BGP Extended Communities for OSPF

To carry the characteristics of the OSPF routes across the MPLS VPN backbone, several additional BGP extended communities were defined. The OSPF characteristics that are transported with MP-BGP include the following:

■ Metric type 1 or 2 for OSPF external routes

The OSPF-specific BGP extended communities allow the OSPF route to be completely reconstructed at the remote PE router. The route type lets the remote PE router figure out what kind of route to advertise in OSPF. If the route type is 1, 2, or 3 (corresponding to LSA types 1, 2, or 3), the remote PE router advertises an interarea summary route (LSA type 3) into the OSPF area.

The domain ID indicates to the remote PE whether an external OSPF route is to be advertised. If the domain ID (by default set equal to the OSPF router process ID) of the route received by a PE router does not match the OSPF process ID of the particular VRF, the route is advertised as an OSPF external route (LSA type 5) type 2 to provide support for networks that are redistributing IP routes between different OSPF processes. If the domain ID does match the OSPF process ID, the route is advertised as an internal route. You can change the domain ID on the PE router with the command domain-id ospf domain ID.

A route type of 5 indicates that the vpnv4 route that is received is an OSPF external route. As such, the PE floods a type 5 LSA into the OSPF site; by default, the metric type is type 2. The metric that is used for the type 5 LSA is the MED from the BGP vpnv4 route if one is present. If none is present, the default OSPF metric is used.

Example 7-27 shows the BGP extended communities for OSPF. Prefix 10.10.100.1/32 is an OSPF internal route, and prefix 10.200.200.1/32 is an OSPF external route.

Example 7-27 BGP Extended Communities for OSPF

sydney#show ip bgp vpnv4 rd 1:1 10.10.100.1

BGP routing table entry for 1:1:10.10.100.1/32, version 2045 Paths: (2 available, best #2, table cust-one) Advertised to update-groups: 1

Local

Example 7-27 BGP Extended Communities for OSPF (Continued)

10.200.254.2 (metric 3) from 10.200.254.2 (10.200.254.2)

Origin incomplete, metric 10, localpref 100, valid, internal Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x0000002A0200

OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.10.2.2:512, mpls labels in/out 18/28

sydney#show ip bgp vpnv4 rd 1:1 10.200.200.1

BGP routing table entry for 1:1:10.200.200.1/32, version 5649

Paths: (1 available, best #1, table cust-one) Not advertised to any peer Local

10.200.254.2 (metric 3) from 10.200.254.2 (10.200.254.2)

Origin incomplete, metric 10, localpref 100, valid, internal, best Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x0000002A0200

OSPF RT:0.0.0.0:5:1 OSPF ROUTER ID:10.99.1.1:1281, mpls labels in/out nolabel/18

You can see that the OSPF route type is encoded as area:route-type:option. The area is encoded in 4 bytes; the route-type and option are 1 byte each. If the route is external, the area is 0.0.0.0. If the least significant bit of the option field is set, it indicates an external metric type 2. If the least significant bit is not set, it indicates an external metric type 1.

OSPF Network Design

OSPF is designed to work with areas. The special area 0 is the backbone area that connects all other areas. MPLS VPN has another "area" between the OSPF sites: the MPLS VPN backbone. This is not an OSPF area, of course, because it runs iBGP. Nevertheless, it acts as an area as the PE routers act as ABRs. Therefore, you can consider the MPLS VPN backbone as the super backbone in the OSPF hierarchy. If multiple sites of one VRF have a PE router with area 0, the backbone area is split into more than one part. Normally, a split backbone area requires a virtual link to interconnect the parts. This is not needed for MPLS VPN, though, because iBGP carries the OSPF routes, OSPF routes are re-created on the PE routers, and the MPLS VPN backbone has no flooding. Refer to the next section for one exception; flooding does occur across the MPLS VPN backbone when a sham link is used.

The PE routers function as ABRs as they advertise type 3 LSAs to the CE routers. The CE routers can be in area 0 or any other area. If, however, a site has more than one area, the PE routers must be in area 0 because they are ABRs. If they are not, a virtual link between the PE router and the nearest ABR in the customer site must bring area 0 up to the PE router. Look again at Figure 7-20 to see the possible scenarios regarding OSPF areas and connections to the MPLS VPN backbone.

Sham Link

If two sites belong to the same area and are interconnected with a backdoor link, they appear as one area to OSPF. Through the backdoor link, all LSAs are flooded unaltered from one site to the other. This means that intra-area routes stay intra-area routes. The intra-area routes (type 1 and 2 LSAs) are flooded across the backdoor link. They are transformed into interarea routes across the MPLS VPN backbone. That means that the preferred path between the two sites is always the backdoor link because OSPF always prefers the intra-area routes over the interarea routes. This reduces the MPLS VPN service to a mere backup solution in case the backdoor link goes down. The concept of sham link was invented to solve this problem. The sham link is not a real link but a fake one between two PE routers. It is an OSPF intra-area link created between the two PE routers so that they can flood this link in the area connected to both the PE routers. The sham link has two endpoints. The sham link endpoint on each PE router is a /32 IPv4 address from the specific VRF. iBGP must advertise this /32 IPv4 address from one PE to the other as a vpnv4 prefix. The sham link is an unnumbered point-to-point intra-area link that is treated as a demand-circuit link. This means that LSAs are flooded across the sham link, but no periodic refresh flooding occurs across the sham link.

The sham link is included in the shortest path first (SPF) computation, just as any link in OSPF. As LSAs are flooded across the sham link, all OSPF route types can be preserved and do not have to be converted into type 3 or 5 LSAs. If the sham link fails, the default mechanism of sending only type 3 and type 5 LSAs into the site occurs. Routing across the MPLS VPN backbone is still possible if the sham link fails, but the backdoor link is the preferred path for intra-area routes because intra-area routes are still learned that way. You configure the sham link by specifying a source IP address in the VRF on the local PE and a destination IP address in the VRF on the remote PE. In addition, you can specify a cost for the sham link to make it more or less preferred than the backdoor link. The syntax of the sham link command is area area-id sham-link source-address destination-address cost number.

Figure 7-21 shows an example of a sham link configured for OSPF process 42 in VRF cust-one. Both sites that are attached to the PE routers are in OSPF area 0 of VRF cust-one. A sham link is configured between the two PE routers with endpoints in the VRF cust-one.

Figure 7-21 Example of a Sham Link

Area 0 Sham-link 10.99.1.1 10.99.1.2.Cost 10

Figure 7-21 Example of a Sham Link

Area 0 Sham-link 10.99.1.1 10.99.1.2.Cost 10

CE-2 OSPF 42

CE-2

CE-2 OSPF 42

Backdoor Link

CE-2

OSPF 42

You can see the configuration for the sham link in Figure 7-21 in Example 7-28. Example 7-28 OSPF Sham Link router ospf 42 vrf cust-one router-id 10.99.1.1 log-adjacency-changes area 0 sham-link 10.99.1.1 10.99.1.2 cost 10 redistribute bgp 1 metric 10 subnets network 10.10.2.0 0.0.0.255 area 0

london#show ip ospf 42 neighbor

Neighbor ID Pri State Dead Time Address Interface

10.200.200.1 1 FULL/DR 00:00:35 10.10.2.1 Ethernet0/1/2

continues

Example 7-28 OSPF Sham Link (Continued)

london#show ip ospf 42 sham-links Sham Link OSPF_SL2 to address 10.99.1.2 is up Area 0 source address 10.99.1.1 Run as demand circuit

DoNotAge LSA allowed. Cost of using 10 State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Hello due in 00:00:03

Adjacency State FULL (Hello suppressed)

Index 2/2, retransmission queue length 0, number of retransmission 1

Last retransmission scan length is 1, maximum is 1

Last retransmission scan time is 0 msec, maximum is 0 msec iBGP, not OSPF, must always advertise the sham link endpoints. Otherwise, the sham link flaps. First, iBGP learns the sham link endpoints, and the sham link is created. When the sham link is created, OSPF advertises the sham link endpoints, if the network command includes them. The distance of OSPF is 110, versus 200 for iBGP routes. Therefore, the sham link endpoint routes are in the routing table as OSPF routes, because the distance for OSPF routes is lower than the distance for iBGP routes. As soon as the endpoints are no longer learned in the routing table via iBGP, the sham link goes down and the process starts over again. The result is a continual flapping of the sham link.

Even if a sham link exists and the OSPF routes are flooded across it, iBGP still needs to advertise the OSPF routes as vpnv4 routes from PE to PE router. The reason for this is that iBGP still needs to carry the MPLS VPN label for each OSPF route so that the packets can be correctly forwarded across the MPLS VPN backbone.

If a prefix is learned across the sham link, and the path via the sham link is selected as the best, the PE router does not generate an MP-BGP update for the prefix. This means that OSPF routes learned across the sham link are not redistributed into BGP. The PE router on the other side of the sham link has already redistributed the OSPF routes into BGP, so it does not need to be done a second time.

Down Bit and Domain Tag

The down bit is a bit that is set in the Options field of an OSPF LSA type 3. It indicates the direction that the route has been advertised. If the OSPF route has been advertised from a PE router into an OSPF area, the down bit is set. Another PE router in the same area does not redistribute this route into iBGP of the MPLS VPN network if this bit is set. The PE router does not even include the route in the SPF computation. As such, you can avoid a possible routing loop if the site is multihomed or if a backdoor link exists between OSPF sites. Figure 7-22 demonstrates that an OSPF route with the down bit set is not readvertised into iBGP.

Figure 7-22 Down Bit

The domain tag (also known as the VPN route tag) serves the same purpose as the down bit, but for OSPF external routes. You can set it manually on the PE routers with the command domaintag tag-value. If you set the domain tag to a particular value on a PE router, the tag value of the external OSPF route is set to that value. If another PE router that is connected to the same site or another site that is connected through a backdoor link receives this route and it matches the configured domain tag, the route is not redistributed into iBGP. By default, the domain tag is set to a value as determined in RFC 1745. This RFC specifies the interaction between OSPF and BGP and determines how the tag should automatically be set. The autonomous system number of BGP is encoded into the tag of the OSPF external routes in the least significant 16 bits. Figure 7-23 shows that an OSPF route is not readvertised into iBGP if the domain tag of the route matches the configured domain tag on the PE router.

Figure 7-23 Domain Tag

Figure 7-23 Domain Tag

OSPF 42

Micro Expression Master

Micro Expression Master

If You Could Read Everyone Life A Book You Can Have Better Career, Great Relationships And Become Successful. This Book Is One Of The Most Valuable Resources In The World When It Comes To Reading the smallest and tiniest body Language and know what people are thinking about.

Get My Free Ebook


Post a comment