MPLS LDP
LDP works similar to distance-vector protocols; it broadcasts all local prefixes with their respective labels. As soon as a local router learns the labels used by its neighbors for the same prefixes, it will program the LFIB with respective label values: incoming label (which has been locally generated) replaced with an outgoing label (used by the neighbor routers).
To enable MPLS switching on an interface and start LDP on the same interface, you must enter the interface-level command mpls ip . If you have too many interfaces to enable MPLS on, you may use MPLS LDP auto configuration, which is available when you run OSPF as your IGP protocol. Under the OSPF process, enter the command mpls ldp autoconfig. mpls ldp neighbor <IP> password <password>
By default, LDP will generate and advertise labels for every prefix found in the local routing table. Use mpls ldp advertise-labels for 10 command.
MP-BGP VPNv4
By default, when you create a new BGP neighbor using the command neighbor <IP> remote-as <NR> , the default IPv4 unicast address-family is activated for this neighbor. If for some reason you don’t want this behavior and only need the VPNv4 prefixes to be sent, you may disable the default behavior via the command no bgp default ipv4-unicast.
The VPN label is generated by the BGP process on the advertising router and directly corresponds to the local VRF route. The /32 restriction is needed to guarantee that the transport LSP terminates on the particular PE router, and not some shared network segment Check the MPLS labels (VPN labels) assigned to the VPN prefixes at the PE routers. There are two labels in the stack; one is the VPN label and the other is the transport label. You may find the VPN label in the BGP table, and the transport label can be found by looking up the VPNv4 BGP next-hop in the MPLS forwarding table.
MP-BGP Prefix Filtering
The special export route-map associated with the VRF could match the prefixes based on the prefix-lists, access-lists, or extendedcommunities. All routes not permitted in an export route-map are not exported into the BGP process. The export route-map may also be used to set the extendedcommunity attribute selectively, using the command set extcommunity rt.
PE-CE Routing with RIP
When you need to redistribute the MP-BGP routes into RIP, use the command redistribute bgp <N> metric [X|transparent] under the respective address family. Here, N is the BGP process number (AS#) and X is the metric assigned to the RIP routes. If you are using the keyword transparent , the RIP metrics will be recovered from the BGP MED attribute, which in turn is copied from RIP metrics learned at the remote site. This allows for transparent preservation of RIPv2 metric values across the VPN and better path selection in case of backdoor links.
PE-CE Routing with OSPF
All OSPF routes redistributed into MP-BGP are treated pretty much like Type 3 summary LSAs, because they enter the super-backbone from other areas. When
injected into BGP, OSPF prefixes have two extended-community attributes attached to them. One of the attributes is known as domain-id, which is equal to the OSPF
process numbers on the local router OR explicitly configured using the command domain-id under the OSPF process. The purpose of this attribute is to identify
OSPF processes belonging to different VPNs. It is assumed that you configured all OSPF processes within the same VPN using the same domain-id (such as the same
process number). If for some reason you exchange routes between two different VPNs using different domain-ids, the OSPF process will interpret all such prefixes
as if they are Type-5 External LSAs, effectively external routes. The other extended community attribute is known as the OSPF route-type, which
has three significant fields: source area, route-type, and option. They are usually depicted as triple X:Y:Z. Here, Y=2 for intra-area learned prefix, Y=3 for inter-area routes, Y=5 for external prefixes.
Notice that all routes redistributed from BGP into OSPF appear like inter-area routes even if they belong to the same area number at different sites. This effect occurs because the LSAs cross the super-backbone and essentially are inter-area routes. The last BGP attribute used to carry OSPF information is MED or metric, which copies the original route’s metric from the routing table. The route-type attribute is needed to allow for proper OSPF best-path calculation when routes are inserted into the OSPF database based on redistribution from BGP. Notice that the routes traveling the MP-BGP cloud do not increment their metric unless you manually change the MED attribute for incoming BGP prefixes.
OSPF implements some basic loop prevention rules. First, all summary LSAs generated from the routes redistributed from BGP have a special “Down” bit set in the LSA headers. If a router receives a summary-LSA with the down bit set on an interface that belongs to a VRF, it simply drops this LSA. This is to prevent the case of routing loops for multi-homed sites, when a summary LSA is flooded across the CE site and delivered back to another PE. However, this feature may have an undesirable effect when you have a CE router configured with multiple VRFs. In this case, you may want to enter the OSPF process command capability vrf-lite on the CE router. This will disable the default loop-prevention capability. Be advised that some IOS versions do not support this feature (such as older IOSs or some Catalyst IOS revisions). If you have such a router configured for multi-VRF and experience route black holing, configure the PE routers with different
domain-IDs; this will force all redistributed routes to become external and bypass the down-bit check. Note that in newer IOS versions, such as the one used in this example, the down bit is also included in Type-5 LSAs. capability vrf-lite would be needed.
The other feature is based on the route tagging. All routes redistributed via a particular PE will carry the OSPF route tag with the BGP AS number encoded
inside. The receiving router that has VRFs enabled will compare the AS number in the tag with the local BGP AS number. If they match, this could mean the LSA has
looped back to another PE connecting the same site to the MPLS backbone. If for some reason you encounter this issue and need to get rid of it, simply apply a
proper tag to the redistributed routes.
OSPF Sham-Link
If the link is in the same area as the PE/CE routers, the PE routers will prefer the path across the back-door link, because OSPF treats all paths across it
as intra-area, and the prefixes received via MP-BGP are interpreted as inter-area.
OSPF sham-link is a special tunnel similar to a virtual-link connecting two PE routers and configured in the same area as the PE routers. When the routes are being installed in the respective VRF RIB, the forwarding information is based on looking up the MP-BGP learned routes based on exact prefix-match. The corresponding VPN and transport labels are then used for actual packet forwarding across the MPLS core. Therefore, the information loaded across the sham-link is used only for SPF calculations and best-path selection; the actual forwarding is being done based on the information learned via MP-BGP.
Sham-links are sourced off actual interfaces configured in the respective VRF. Commonly, these are Loopback interfaces used as endpoints for the shamlink
tunnel. Notice that the IP addresses for these interfaces should be advertised into the VRF routing table by means other than OSPF, most commonly via BGP.
The sham-link’s endpoints should not be advertised into OSPF.
PE-CE Routing with EIGRP
One issue with transporting EIGRP routes over MP-BGP is preserving the original metric values, the route type, the source AS#, and the remote Router ID. These all are encoded using special BGP extended-community attributes that allow the remote site to properly decode the incoming routing update information.
Of course, the local EIGRP process will treat all prefixes originated in different remote AS# as external, per the normal EIGRP rules. Therefore, the AS# and the Router-ID information could be crucial to resolve potential routing loops in scenarios with backdoor links between the VPN sites. Another special attribute used with EIGRP prefixes redistributed into MP-BGP is known as the “cost attribute.” Although this attribute was designed to have pretty wide use, the main idea is to change the BGP best-path selection process. The problem with MPLS VPN route redistribution is that the same route may enter the PE’s BGP table using redistribution (learned from a CE router) and via a BGP update (learned from a remote site). Per the BGP best-path selection process, locally redistributed prefixes have a BGP weight of 32768, which make them always win the best-path selection process. Therefore, BGP will always choose the locally received update even if the remote site has better a EIGRP metric to reach the destination.
To resolve this issue, EIGRP prefixes redistributed into MP-BGP will have the Cost attribute value set to their composite metric. The BGP process will honor the Cost attribute value before ANY other best-path selection option if the attribute is present. The prefix with the lowest cost will immediately win the best-path selection and will be redistributed into the local EIGRP process. This process happens automatically and does not require any additional configuration. Notice that the Cost attribute is NOT needed with OSPF because the prefixes received via MP-BGP are treated as inter-area and are always less preferred compared to the same prefixes learned as intra-area from a CE device. When RIP is used for PE-CE routing, Cisco IOS does not implement the Cost attribute at all, so the locally redistributed prefixes will always get preferred over MP-BGP learned prefixes, preventing effective RIP deployment in scenarios with backdoor links.
When configuring EIGRP for MPLS VPNs, the same process is shared among multiple VRFs. An address family must be configured per VRF under the routing
process, and for every address-family you must configure an AS number using the command autonomous-system N . This command is mandatory to enable EIGRP for
that particular VRF.
EIGRP Site-of-Origin
With multi-homed scenarios similar to the ones we are using, BGP and EIGRP perform mutual redistribution at PE routers. This may potentially result in transient
routing loops, when a prefix is withdrawn in MP-BGP at one PE router and it is not timely propagated into EIGRP. EIGRP could then feed the invalid information back to BGP at another PE router, keeping the false information circulating between the PE routers until it’s eliminated by counting to infinity. The core of this problem is the mutual redistribution that allows the information learned from BGP at one site to reenter BGP at another site.
Cisco IOS implements a special feature known as EIGRP Site-of-Origin (SoO), which uses an extended community appended to BGP and EIGRP routing updates. All BGP prefixes redistributed into EIGRP and sent over the interface with the SoO set will have this extended community appended, but only if the community is not already present. If the update to be sent already has the same extended community value set, it is discarded as being redistributed back to the same site. The next thing that this feature does is apply the same extended community to all EIGRP routes received on the interface and redistributed into BGP. All these actions are performed by IOS automatically; you need only apply the route-map to the relevant interfaces.
-If you need to preserve the path across the MPLS core network, you should use different SoO values at every PE router of a multi-homed site. However, this means that the MP-BGP information injected into EIGRP at one PE router will reach the other PEs without being blocked. To prevent this effect, an additional SoO interface should be configured on the CE routers with the backdoor link.
