MPLS Day 2

Workbook One Observation and Analyses.

• OSPF Sham-links
• When OSPF is propagated via MP-BGP over MPLS core, the prefixes received from the other end are interpreted as EITHER LSA Type-3 or Type-5 or INTER-AREA routes.
• Causes problems when a backdoor, BACKUP link is used between the CE routers, independently, outside the MPLS domain.
• If the backup link is in the SAME area as the CE routers, it will be an INTRA-AREA route.
• This means, because of OSPF's design, it WILL ALWAYS be PREFERRED to the INTER-AREA routes learnt over the MPLS cloud.
• Issue can ONLY be resolved by configuring MPLS core to be in the SAME area as the CE routers.
• Solution is to use a SHAM-LINK.
• Special tunnel similar to a virtual link connecting TWO PE routers, configured in the SAME area as CEs.
• Link is used to ESTABLISH an ACTUAL adjacency BETWEEN PEs and exchange LSAs.
• Once these LSAs are loaded into the OSPF database, the SHAM-LINK is used for INTRA-AREA path computation.
• HOWEVER, when the routes are being installed in the VRF, the FORWARDING information is based on looking up MP-BGP learned routes' EXACT prefix match.
• Corresponding VPN and Transport labels are then used for ACTUAL packet forwarding over MPLS cloud.
• REMEMBER – INFORMATION LEARNED ACROSS SHAM-LINK IS USED ONLY FOR SPF CALCUATIONS AND BEST-PATH SELECTION.
• ACTUAL FORWARDING IS BEING DONE BASED ON INFO LEARNT OVER MPLS VIA MP-BGP.
• Sham-links are sourced off actual interfaces configured in respective VRFs. Loopbacks are MOST commonly used.
• IPs for these endpoinds should be advertised by some means OTHER THAN OSPF.
• area # sham-link cost (cost)
• SHAM-LINK ENDPOINTS SHOULD NOT BE ADVERTISED IN OSPF.
• IN ADDITION, THEY HAVE TO BE FULLY MASKED – /32.

—————————————————————————————————————————————————

• PE-CE Routing with EIGRP
• MP-BGP stores EIGRP information in special extended communities with are preserved over MPLS core.
• Original metric values
• Route-type
• Source AS
• Remote router-id
• Metric is not carried simply in MED as there exists a remote possibility that the two sites DO NOT agree on K-values.
• Any routes with AS different than LOCAL AS are considered EX/external routes.
• Another special attribute is the “cost attribute”
• Main idea is to CHANGE BGP bestpath selection.
• Problem is SAME path may enter PE BGP table in TWO ways -
• via Redistribution – Learnt from CE
• via BGP update – Learnt from REMOTE PE
• Per BGP path selection, locally redistributed routes have a weight of 32768 – PREEMPTS bestpath selection is IOS and ALWAYS wins.
• THUS, there lies the potential that BGP will ALWAYS use the locally redistributed route, even though the METRIC of the path learnt across MP-BGP is better.
• To resolve this issue, EIGRP prefixes redistributed into MP-BGP have teh COST ATTRIBUTE set to the composite metric.
• BGP process HONORS the cost attribute value BEFORE ANY OTHER bestpath selection option IF cost indeed is present in a prefix.
• Prefix with LOWEST cost immediately wins the bestpath selection AND WILL BE redistributed INTO the local EIGRP prcess.
• Process is AUTOMATIC.
• This is NOT a potential problem is OSPF as prefixes learnt via MP-BGP are treated as INTER-AREA and ALWAYS less preferred when compared to same prefixes learnt via CE.
• When configuring EIGRP for MPLS, same process is SHARED amongst MULTIPLE VRFs.
• An address-family MUST be configured per VRF.
• For every address-family, an AS number MUST BE CONFIGURED –autonomous-system
• ABOVE STEP IS MANDATORY to enable EIGRP for that VRF.

—————————————————————————————————————————————————

• EIGRP Site-of-Origin
• Multi-homed scenarios where BGP and EIGRP perform MUTUAL redistribution at PE routers, there is potential for TRANSIENT routing loops.
• When a prefix is WIDRAWN in MP-BGP at ONE PE router AND IS NOT TIMELY propagated to EIGRP, then EIGRP gets a chance to feed the INVALID ROUTE into MP-BGP at a DIFFERENT PE router.
• Core of this problem is the mutual redistribution that allows information from BGP at ONE site to RE-ENTER BGP at another site.
• This can usually be solved by tagging.
• IOS implements a special feature called SoO that uses an extended community appended to BGP AND EIGRP routing updates. (TLV structure of EIGRP makes this easy to implement).
• Feature is configured at INTERFACE level
• ip vrf sitemap
• set extcommunity soo ASN:NN
• All BGP prefixes redistributed into EIGRP and sent OVER the interface will have this community appended BUT ONLY IF THE COMMUNITY IS NOT ALREADY PRESENT.
• If the update is to be sent ALREADY has the SAME SoO, it is discarded as being redistributed back to the same site.
• NEXT, the feature applies the SAME SoO to all EIGRP routes received on this interface and REDISTRIBUTED INTO BGP.
• Two COMMON ways to apply
• SoO is applied on PE interfaces facing CE ONLY.
• Every PE use SAME value
• Prevents PEs from learning MP-BGP originated routes from CE.
• SIDE-EFFECT – MPLS core CANNOT be used as a “backup” path BETWEEN segments of MULTI-HOMED sites.
• Because MP-BGP updates for in-site EIGRP prefixes carry the SAME SoO applied to PE-CE interfaces and CANNOT be redistributed back to the site.
• DIFFERENT values of SoO are used at EACH PE-CE interface.
• To prevent PE to PE feedback, additional SoO interface is configured on the BACKUP interface between CE-CE.

—————————————————————————————————————————————————

• PE-CE Routing with BGP
• Simple configuration with eBGP peering between the PE-CE.
• Common problem that arises is that MULTIPLE sites for the same organization MAY use the SAME AS number for BGP.
• Due to eBGP loop prevention, this FILTERS prefixes learnt from one site from entering the other side with SAME AS.
• TWO solutions :

1. allowas- in option inbound at CE for the PE peer.
2. as-override option on PE routers for CE peering sessions.

• Compares remote-as number with AS# stored AT THE END OF AS_PATH.
• If a MATCH, the AS_PATH AS# is REPLACED with LOCAL-AS #
• POSITIVE SIDE-EFFECT – Length of AS_PATH REMAINS SAME.

____________________________________________________________________________________________

• BGP SoO Attribute
• as-override may result in LOOPS for multi-homed sites with BACKUP links.
• To prevent loops, BGP implements SoO
• Value configured PER-NEIGHBOR peering session
• TWO methods
• neighbor soo
• Available in 12.4(11) T and above
• set extcommunity soo in a route-map AND APPLYING IT INBOUND
• WILL NOT WORK ON OUTBOUND MAPS
• Works similarly to EIGRP SoO
• If an incoming/outgoing update has SoO MATCHING locally configured one, UPDATE IS DROPPED.
• ELSE, update is TAGGED with LOCAL SoO.
• To use MPLS as BACKUP
• Use different SoO at PEs
• Apply SoO at CEs over the BACKDOOR.