NMC VOD Series - Lesson MPLS

Part 1 : BASIC CONFIGURATION

• MPLS Layer 3 VPN BASICS
• On Provider Edge router, each VPN (CUSTOMER) has its OWN Virtual Routing and Forwarding table (VRF).
• Each VRF has TWO associated values it, Route Distinguisher and Route Target.
• To setup a VRF :-
• ip vrf
• rd AA:NN
• route-target import AA:NN
• route-target export AA:NN
• To assign an interface to a VRF :-
• ip vrf forwarding
• Routes redistributed INTO MP-BGP from the VRF are marked with EXPORT RT (BGP extended community)
• On the receiving router, routes are IMPORTED into a VRF using the IMPORT RT.
• Routes are TRANSPORTED across the MPLS core between PE routers using MP-BGP updates.
• A 64-bit RD is COMBINED with IPv4 prefixes to create a GLOBALLY UNIQUE VPNv4 route.
• Depending on the protocol being redistributed in MP-BGP, BGP extended communities are utilized to REPORT route attibutes such as :-
• Route source
• Route type
• Route metric
• UNICAST traffic between CUSTOMER sites, ACROSS the core between PEs uses MPLS.
• TWO LABELS are used (STACKED)
• TOP (TRANSPORT) label is SWAPPED/CHANGED HOP-TO-HOP towards the FAR side PE.
• INNER (VPN) label remains UNCHANGED.
• This is the label used by DESTINATION PE to determine the VPN/VRF the packet belongs to.
• MP-BGP is used as the CONTROL protocol to exchange the VPN labels between PE routers.

_______________________________________________________________________________

• BASIC LAYER-3 VPN CONFIGURATION
• ENABLE MPLS IN THE CORE
• Advertise CORE links via an IGP.
• ENABLE LDP on core links.
• ENABLE MP-BGP session between PE routers.
• Peer the PEs in global BGP.
• In the VPNv4 address-family, ACTIVATE the PE neighbors.
• Configure them, in the VPNv4 address-family to exchange BGP extended communities.
• Create the respective VRFs on PE routers.
• DEFINE :-
• VRFs
• RDs
• IMPORT/EXPORT RTs.
• Associate interfaces with VRFs.
• Usually the value of RT and RD is left the SAME for SANITY's sake but it is the RT value that is used to CONTROL the content of VRF table.
• On receiving router, a route's RD is NATURALIZED to match the DESTINATION VRF's RD.
• show ip vrf is used to VERIFY the VRFs.
• ENABLE routing for PE-CE.
• Can be ANY IGP with each having its own demands.
• MANUALLY redistribute IGP into MP-BGP on the PE routers.
• Also redistribute, inside proper VRF, BGP into IGP.
• Redistribution is done under address-family vrf (name) ipv4 in MP-BGP.

_______________________________________________________________________________ PART 2 : TESTING AND VERIFICATION

• Test reachability WITHIN each VPN via PING, TRACEROUTE etc.
• no mpls ip propagate-ttl makes the P core TRANSPARENT by NOT copying the TTL value of the IP packet header to MPLS header.
• THIS VALUE IS COPIED BY DEFAULT.
• Test and verify ALL VRFs on PE routers.
• Use PING, TRACEROUTE and TELENT PER VRF on the PEs.
• Use show ip bgp vpnv4 all
• Shows a SEPERATE BGP table for each RD/VPN/VRF.
• Prefixes are sorted into the CORRECT VPN table by thier RD values.
• show ip bgp vpnv4 (IP)
• Shows individual prefix's information.
• IP next-hop
• Prefix metric
• RT
• RD/VPN label

________________________________________________________________________________

• VPN AND LDP LABEL DISTRIBUTION
• PEs assign VPN labels to PREFIXES to identify LOCAL VPNs.
• Advertised via MP-BGP to FAR-SIDE PE for it to use as INNER LABEL when sending back a packet.
• LDP is used to advertise the TRANSPORT label HOP-by-HOP for PE-P-PE.
• TIP :- TAG/LABEL ADVERTISED BY ONE PE ROUTER IS USED BY ITS NEIGHBOR TO SEND DATA BACK TO ADVERTISING ROUTER.
• TRUE FOR CONNECTED NEIGHBORS IN LDP AS WELL.
• Switching of packets INSIDE the core takes place SOLELY on the base of LABEL imposed on the packet.
• NO IP LOOKUP TAKES PLACE.

_________________________________________________________________________________ PART 3 - PE-CE ROUTER RELATIONSHIP

• Using OSPF for PE-CE protocol.
• On PE, configure ONE GLOBAL process and ONE process for EACH VPN.
• Each OSPF PROCESS-ID must be DIFFERENT.
• Each OSPF process on the PE router MUST HAVE A DIFFERENT ROUTER-ID
• If there is an AREA 0 in the customer site, it MUST connect to the PE router.
• VRF aware OSPF :-
• router ospf (PID) vrf (NAME)

_________________________________________________________________________

• OSPF-BGP INTERACTION
• Manually redistribute between OSPF and BGP at the PE routers.
• NORMALLY, NO ADJACENCY IS FORMED ACROSS THE CORE
• BGP reports the ORIGINAL OSPF metric in MED attribute.
• ORIGINAL AREA and ROUTE-TYPE are reported as an EXTENDED COMMUNITY VALUE.
• A new value called DOMAIN-ID is reported and compared.
• EQUAL to PROCESS-ID by default.
• Can be changed in the OSPF process - domain-id #
• ALL routes are redistributed as LSA-5 (external) if their DOMAIN-ID differs from the local one.
• If SAME, routes are redistributed as LSA-3 (InterArea)
• Core is called the SUPER BACKBONE and ADD another layer of hierarchy.
• Extended community OSPF RT = X:Y:Z reports :
• X = Original AREA
• Y = Original LSA #
• Z = 1 or 2 if LSA # is 5 or 7.
• Reports metric type 1 or 2 for external LSA 5 or 7.

____________________________________________________________________________

• OSPF LOOP AVOIDANCE AND SHAM-LINKS
• Connecting customer sites to MULTIPLE PE routers can result in ROUTING LOOPS.
• OSPF uses the concept of DOWN BIT in its redistributed LSA's and SHAM-LINKS to overcome these problems.
• HOW THE DOWN-BIT AND ROUTE TAG STOP LOOPS
• The DOWN-BIT keeps LSA-3/IA routes from REMOTE sites from being redistributed BACK into MP-BGP.
• The PE router that receives the OSPF LSA-3 in MP-BGP updates sets the DOWNWARD bit on the LSA.
• If another PE router receives this LSA from a VRF ENABLED INTERFACE, it will CLEAR the ROUTING-BIT on the LSA, THEREBY STOPPING THE LSA FROM BEING REDISTRIBUTED BACK INTO MP-BGP.
• Similarly, a ROUTE-TAG keeps LSA-5/EX routes from being redistributed BACK INTO MP-BGP.
• LSA-5 DO NOT support the concept of DOWNWARD-BIT.
• Instead, a route-tag defined by RFC 1403 is used.
• LAST 16 bits of the TAG define the BGP-AS the LSA was learnt from.
• PE routers will IGNORE the LSA if the LOCAL AS matches ROUTE-TAG AS.
• Downward-bit can cause an unnecessary problem if the CE router is using VRFs on its PE-CE interface.
• Namely, the LSA with the down bit will have its routing bit cleared and will not be used to install routes into the routing table.
• To overcome this issue, the special OSPF command capability vrf-lite is used.
• This makes the CE router IGNORE the down bit and install the LSA into the RIB.
• Using DIFFERENT DOMAIN-IDs to produce LSA-5 at the REMOTE END of MPLS core is the alternative and especially useful on catalyst switches that DO NOT support the above command.
• The LSA-5, as noted above, do not have the concept of the downward bit and hence will be installed as normal.

__________________________________________________________________

• OSPF SHAM-LINK
• Sham-link creates a VIRTUAL INTRA-AREA path/link through the MPLS CORE BETWEEN THE PE ROUTERS.
• This is needed to OVERCOME the OSPF preference for INTRA-AREA routes over ANY other routes.
• Useful when the customer sites have a BACKDOOR link configured that is an INTRA-AREA link.
• Once configured, the PEs will form and ADJACENCY across the MPLS core and exchange ROUTER-LSA (1).
• COST of this link can now be manipulated to give the sham-link PREFERENCE over the BACKDOOR.
• area (#) sham-link (local-IP) (remote-IP)
• show ip ospf sham-link
• END POINTS MUST BE CUSTOMER VRF HOST ROUTES.
• Usually REDISTRIBUTED into MP-BGP and NOT advertised in OSPF itself to overcome RECURSIVE routing problems.
• SHAM-LINK WILL BE CONFIGURED UNDER THE CUSTOMER VRF OSPF PROCESS.

_____________________________________________________________________

• SUPPORTING EIGRP AS PE-CE PROTOCOL
• EIGRP uses the concept of address-family just like MP-BGP.
• autonomous-system (#) inside the address-family allots the AS to the VRF EIGRP instance.
• If CE sites used DIFFERENT EIGRP AS numbers, the MP-BGP learnt routes are considered external.
• If SAME AS is used, EIGRP behaves as ONE large AS across MPLS core.
• ONE IMPORTANT DIFFERENCE IS THAT QUERIES ARE NOT SENT ACROSS MPLS CORE.
• BGP transports internal metrics and route attributes using EXTENDED communities.
• 0x8800 : 32768 (INTERNAL), 0 (EXTERNAL)
• 0x8801 : AS# / SCALED DELAY ( DLY x 256/10)
• 0x8802 : RELIABILITY, HOP-COUNT, SCALED BW
• 0x8803 : LOAD, MTU
• 0x8804 : REMOTE AS (0 FOR EXTERNAL) / ORIGINATING R-ID IN HEX
• 0x8805 : REMOTE PROTOCOL, R-ID, METRIC (USED FOR REDISTRIBUTED ROUTES)

_______________________________________________________________________

• BGP COST COMMUNITY
• Allows user to CONTROL the use of BACKDOOR paths.
• Contains THREE FIELDS.
1. POINT OF INSERTION (POI) : PRE-BESTPATH permits COMPARISON BEFORE any other route attribute INCLUDING AD.
2. COST COMMUNITY ID : 128 for EIGRP internal routes, 129 for EIGRP extrenal routes. LOWER PREFERRED.
3. COST : EIGRP composite metric.
• Configuration
• Automatic but ROUTE-MAPS can be used to set values using extcommunity keyword and applied to neighbor statement.
• bgp bestpath cost-community ignore can be use to ignore this process.

________________________________________________________________

• BGP SITE-OF-ORIGIN COMMUNITY
• Prevents routing loops when sites are MULTIHOMED.
• EACH route is tagged with a SITE IDENTIFIER.
• Set INSIDE a SPECIAL ROUTE-MAP.
• set extcommunity soo AA:NN
• Applied to customer VRF via a SITE-MAP.
• ip vrf sitemap
• This makes sure that the router will APPLY a TAG on EACH EIGRP route learnt VIA THIS INTERFACE.
• Conversely, EIGRP will FILTER any updates containing this tag from ENTERING the interface.

________________________________________________________________

• USING BGP AS PE-CE PROTOCOL
• CEs on remote ends can be EITHER in SAME or DIFFERENT ASs.
• CE's form eBGP peerings with PEs.

_____________________________________________________________

• CUSTOMER USING A DIFFERENT BGP AS AT EACH SITE
• On PE routers, the BGP peering is configured under address-family ipv4 vrf () for the respective CEs.
• The CE neighbor is ACTIVATED to enable the exchange of routing information for the VRF.
• The CE routers in the VPN are configured for NORMAL eBGP peering with PE.
• VPNv4 prepends the RD to EACH advertised prefix, IDENTIFYING it with CORRECT VRF on the far side PE.
• The CE routers receive ONLY the updates from their VPN.

_____________________________________________________________

• CUSTOMER USING THE SAME BGP AS AT EACH SITE
• The BGP loop-prevention (AS-PATH) mechanism prevents ONE site from successfully learning prefixes from ANOTHER.
• SOLUTION 1 :- The as-override keyword can be used to MODIFY BGP update procedure.
• EACH leading occurrence of customer AS is replaced by provider's AS.
• USED on PE routers.
• CAN OVERCOME AS-PATH PREPENDING.

• SOLUTION 2 : - The allowas-in can alternatively used on CE routers to ACCEPT routes with OWN AS in AS-PATH.

___________________________________________________

• MULTI-VRF CE (VRF-LITE)
• The VRFs are EXTENDED from PE to CE routers in these types of scenario.
• A TRUNK (using sub-interfaces in separate VRFs) between PE and CE keeps costs down and eases configuration.
• EACH sub-interface is associated with VRF on BOTH sides of the trunk.
• The ROUTED CE interfaces are ALSO configured for the VRFs.
• Since CE routers are VRF-aware, capability vrf-lite will need to be used in OSPF for IGNORING LSA-3 with downward bits.