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.

MPLS Day 1

Workbook One Observation and Analyses.

• VRF Lite
  • VRFs create MULTIPLE, VIRTUAL, ISOLATED networks.
    • Each technically has its OWN RIB and FIB.
  • Router interface CAN be assigned to a VRF.
    • ip vrf forwarding
    • Command erases ALL existent IP ADDRESSES from the interface.
    • This is done to avoid potential address duplication in NEW RIB/FIB.
    • After the completion of config, ALL packets received on this interface are ROUTED and FORWARDED using the ASSOCIATED RIB/FIB and NOT the global routing table.
    • Concept is similar to how VLAN trunking works in L-2.
    • Like trunks, VRFs can be extended across MULTIPLE devices.
      • MUST BE DONE MANUALLY.
      • VRFS STILL REMAIN LOCAL SPECIFIC.
  • VRFs can be extended beyond a single router by PROPERLY MAPPING VRFs to links connecting the routers.
    • Results in “parallel” VPNs being run across devices.
    • THIS RESULTS IN THE TERM “VRF LITE”.
    • Simplest, if tedious, way of creating NON-OVERLAPPING VPNs in a network.
    • POOR SCALABILITY.
    • May need a DEDICATED inter-router link for EVERY VPN.
      • Sub-interfaces can be used effectively.
  • BY DEFAULT, ALL interfaces are assigned to a VRF named global.
    • Simply the global routing table.
    • show ip route.
  • To create a new VRF :-
    • ip vrf
    • rd X:Y
  • A route-distinguisher is a special 64-bit prefix PREPENDED to EVERY route in a given VRF.
    • Done for the purpose of distinguishing the prefixes inside the router and AVOIDING collisions if two VRFs contain the same prefix.
    • Common format is ASN:NN
      • ASN is AS number.
      • NN is VRF number inside the router or more globally, the VPN number WITHIN the AS.
  • Possible to associate static routes or dynamic routing protocol process with VRFs.
    • ip route vrf (NAME) (IP) (MASK)[interface] [next-hop]
    • If NEXT-HOP only, then NEXT-HOP has to be a IP address RESOLVABLE through VRF.
    • If INTERFACE is specified, it can belong to ANY VRF.
      • With multi-access interfaces, a next-hop associated with the interface HAS to be specified.
      • This is because IOS will install a CEF entry in SOURCE VRF using information provided and NOT RESOLVE THE NEXT-HOP RECURSIVELY.

__________________________________________

• MPLS LDP
  • Technique that overcomes the scalability issue of VRF-Lite.
  • MPLS ”tunnels” are known as LSP (LABEL SWITCHED PATH).
    • Very similar to FR PVC but more automated.
  • MPLS employs a principle that insers a “stack” of lables BETWEEN L-2 and L-3. Almost a L-2.5 technology.
  • Every MPLS label starts with a 20-bit value.
  • Actual tag is 32-bits after the addition of special and reserved fields.
  • Acts as a “shim-layer” introducing an extra set of virtual paths deployed OVER the L-2 technology employed in the network.
  • Every router performs switching based on the topmost label in the stack.
    • Done using LFIB which maps incoming labels to outgoing labels.
  • MPLS-labeled packets are SWITCHED based on label-lookup/switch in LFIB INSTEAD of a lookup in the RIB for a destination prefix.
  • First router on the edge of MPLS cloud is called a LER (LABEL EDGE ROUTER).
    • PE (PROVIDER EDGE) is another popular name.
    • Responsible for PUSHING/LABEL IMPOSITION of initial label on the packet.
    • Responsible for POPPING/LABEL DISPOSITION and switching the packet traditionally if the router is last LER in LSP.
  • Router inside the cloud are called LSR (LABEL SWITCH ROUTER).
    • P (Provider) or CORE routers.
    • Responsible for SWAPPING labels based on pure LFIB lookup.
  • FUNDAMENTAL core of MPLS centers around HOW the labels are assigned.
  • Tunnel path is established for EVERY IGP prefix found in the network.
    • This allows for replacement of routing based on DESTINATION IP LOOKUP by switching based on LABEL SWAPPING.
  • Dynamic technology that uses a special protocol LDP (LABEL DISTRIBUTION PROTOCOL) to exchange label values.
  • BY DEFAULT, every router will generate a label called LOCAL LABEL for every prefix in the RIB and advertise it via LDP to neighbors.
  • This label, called OUTGOING LABEL on adjacent routers will be used by them when switching for this prefix, VIA the LOCAL router.
  • LDP works similarly to Distance-Vector protocols.
    • In that is BROADCASTS ALL local prefixes with respective labels.
  • AS SOON AS LOCAL ROUTER LEARNS LABELS USED BY ITS NEIGHBORS FOR SAME PREFIXES, IT PROGRAMS LFIB WITH RESPECTIVE LABEL VALUES.
    • LOCAL LABEL – AKA Incoming label
    • OUTGOING LABEL – Used by neighbor routers for LFIB lookups.
  • LDP works as follows -
    • MPLS and LDP are activated on an interface
      • mpls ip
      • For many interfaces that need configuration, MPLS auto-configuration can be used.
      • Available when OSPF IS USED as IGP
      • mpls ldp autoconfig UNDER the OSPF process.
      • After its enabling, LDP attempts to discover neighbor routers on the interface by initially sending UDP packets to 224.0.0.2 ALL ROUTER MC address on port 646.
    • Upon hearing from other LDP routers, LDP learns their LDP router-ID, BY DEFAULT THE HIGHEST LOOPBACK.
      • This is address used BY DEFAULT for LDP peering.
      • The router-id can be changed by mpls ldp router-id [force].
      • If router-ID IP is UNREACHABLE, a TCP connection WILL NOT be established.
      • If LDP needs to be peered on physical interface address :-
        • mpls ldp discovery transport-address interface
        • Command CHANGES the address SENT in LDP HELLOS.
    • Using router-ID IP address as SOURCES, two routers that heard from each other establish a TCP connection to the ADVERTISED address using the DESTINATION port of 646.
      • Connection can be authenticated using an MD5 option.
      • Define PER-NEIGHBOR
        • mpls ldp neighbor (IP)password (PW)
        • IP is router-ID
      • Define on an ACL with key-chain
        • mpls ldp password option
      • To make use of passwords MANDATORY locally
        • mpls ldp password required
        • If a password is NOT configured for a neighbor, the session WILL NOT be established.
    • After TCP has been established, routers exchange prefix and label bindings.
  • After the population of LFIB, label switching may occur.
  • Important for ALL routers in MPLS domain to have SAME prefixes in RIBs.
    • OTHERWISE, bindings WILL NOT match AND label switched packets will be dropped.
    • THIS RESULTS IN INABILITY TO USE SUMMARIZATION WITH MPLS AND IGPS.

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

• MPLS Label Filtering
  • BY DEFAULT, LDP generates AND advertises labels for EVERY prefix in RIB.
  • To change this behavior and GENERATE (NOT JUST ADVERTISE) labels ONLY for specific prefixes, use :-
    • no mpls ldp advertise-lablels
    • mpls ldp advertise-lables for (ACL) to (ACL)
  • This command has an additive nature as multiple ACLs can be used in MULTIPLE statements.
  • The statements are read in the order they were input AND as soon as a match for prefix is found in the list, the rest is not read.
  • As the command is enabled by default to label the ENTIRE RIB, the default MUST FIRST BE DISABLED with a NO keyword before further configuration.

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

• MP-BGP VPNv4
  • Idea is to establish a FULL-MESH of dynamic MPLS LSRs between the PE routers AND using these for TUNNELING VPN packets ACROSS NETWORK CORE.
  • In order to select PROPER VRF instance on the PE router, an ADDITIONAL label is needed.
  • Thus, TWO LABELS are required in the packet MPLS stack
    • Topmost label is TRANSPORT label.
      • Swapped along the entire path between PEs.
    • Innermost label is the VPN label.
      • Used to select the PROPER outgoing VRF CEF entry.
  • BGP has been chosen as a UNIVERSAL prefix redistribution protocol.
  • To support the new features, BGP functionality has been enhance to handle VRF specific routes.
  • New, special MP-BGP address-family named VPNv4 has been added to BGP along with a NEW NLRI format.
    • Every VPNv4 prefix has RD associated with it and the corresponding MPLS label, in ADDITION to BGP attributes.
  • By default, when a new BGP neighbor is created, the DEFAULT IPv4 unicast address-family is ACTIVATED for that neighbor.
    • no bgp default ipv4 unicast disables this default behavior.
  • Special limitations exist for iBGP peering sessions that need to be enabled for VPNv4 prefix exchange.
    • THEY MUST BE SOURCED FROM LOOPBACK 0 (?) interface
    • The interface MUST HAVE A /32 interface
      • The /32 restriction is needed to GUARANTEE that TRANSPORT LSP TERMINATES on a PARTICULAR router, NOT a SHARED segment.
      • This is handled automatically by LDP for IPs used for LDP router-ids.
    • This IP address is used as the NEXT-HOP for ALL prefixes advertised FROM that router to another.
    • When the remote BGP router receives those prefixes, it performs a recursive routing lookup for the NEXT-HOP and finds a LABEL in the LFIB.
    • THIS LABEL IS USED AS THE TRANSPORT LABEL BY THE RECEIVING ROUTER.
    • EFFECTIVELY, NEXT-HOP IS USED TO BUILD A “TUNNEL” OR TRANSPORT LSP BETWEEN PEERS OVER THE CORE.
  • VPN label is generated by the BGP process on the ADVERTISING router and DIRECTLY CORRESPONDS to a LOCAL VRF route.
  • To inject a particular VRFs routers into BGP, the respective VRF's IPv4 UNICAST address-family needs to be activated in the BGP process.
  • Also, under the appropriate IPv4 UNICAST address-family VRF, route redistribution/advertisement has to be enabled.
  • All respective routes belonging to that VRF will be injected into BGP WITH their RDs and VPN labels generated by MPBGP.
  • IMPORT process is more complicated.
    • Based on Route-Targets as opposed to RDs
  • RT is a BGP extended community value.
    • 64-bit, optional transitive.
  • Need arises from the fact that JUST RDs are insufficient for prefix importing/exporting.
    • Routes with SAME RD may eventually belong to MULTIPLE VRFs when the routes are shared.
  • HOW RT BASED IMPORT WORKS -
    • By default, ALL prefixes redistributed from a VRF into BGP are TAGGED with RT X:Y specified UNDER THE VRF CONFIGURATION.
      • route-target export X:Y
    • Multiple export commands can be used to tag prefixes with MULTIPLE RTs.
    • ON RECEIVING SIDE, VRF will import the BGP VPNv4 prefixes with RTs that MATCH -
      • route-target import X:Y
    • THE IMPORT PROCESS IS BASED ENTIRELY ON RTs NOT RDs.
    • IF IMPORTED ROUTES HAVE DIFFERENT RDs FROM ONE USED ON LOCAL VRF, THEY ARE “NATURALIZED” BY HAVING THEIR RD CHANGED TO LOCAL VALUE.
    • Theoratically, an RT can be assigned to EVERY VPN site and fine-tuned import policies be specified to accept remote site routes locally.
    • route-target both X:Y simply means BOTH export AND import statements AT THE SAME TIME.

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

• MP-BGP Prefix Filtering
  • IOS provides a way to have GRANULAR control over tag assigning.
  • Configured under the VRF context.
    • {import|export} map
  • Export-map feature can match prefixes based on prefix-list, access-list or extended communities.
  • ALL ROUTES NOT PERMITTED IN MAP ARE NOT EXPORTED TO BGP PROCESS.
  • Can also be used to set the extended-community attribute selectively.
    • set extcommunity rt X:Y
  • IMPORT map is used sparingly.
  • Controls all routes imported into VRF from BGP.
  • BY DEFAULT, all prefixes NOT permitted by import map are IMPLICITLY denied and NOT imported into VRF.

————————————————————————————————————————————————–

• PE-CE Routing with RIPv2
  • MP-BGP is the “carrier” routing protocol for MPLS, a wide variety of PE-CE routing protocols are used.
  • PE-CE run independently at EACH site.
    • Rely on MP-BGP to exchange their routing info.
  • Route exchange is performed via MUTUAL prefix-redistribution between MP-BGP and respective PE-CE protocol.
  • RIPv2 supports VRF aware routing
    • address-family ipv4 vrf
  • To redistribute MP-BGP routes into RIP
    • redistribute bgp (#) metric {x|transparent}
    • Keyword transparent enables the RIP metrics to be RECOVERED from BGP MED attribute.
  • Redistribution of RIP into BGP takes place under the proper address-family/VRF
    • RIP metric into BGP MED COPIED BY DEFAULT.
    • This, in combination with the transparent keyword, allow for preservation of RIP metrics across the VPN and better path selection in case of backdoor links.

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

• PE-CE Routing with OSPF
  • OSPF adjacencies CANNOT be formed in TRADITIONAL way OVER the MPLS with BGP running in the cloud.
  • Because of the distance-vector like nature of updates between areas ACROSS area 0, MPLS cloud can be interpreted as a “SUPER AREA 0″
    • Called the SUPERBACKBONE.
    • It is emulated by passing OSPF VRF information in MP-BGP updates.
    • Also allows for NO use of AREA 0 at all.
    • Super backbone is capable of performing area 0 functions.
    • Even with the existence of area 0 at PE-CE, MAIN DESIGN PRINCIPLE to be followed is that ALL areas are connected to SBB in a STAR-like manner.
  • ALL OSPF routes redistributed into MP-BGP are treated as LSA type 3 when redistributed back into OSPF.
  • With OSPF, special extended communities are used to propagate additional OSPF prefix information.
  • When injected into BGP, OSPF prefixes have TWO extended communities attached to them.
  • FIRST attribute is DOMAIN-ID
    • Equal to OSPF Process ID on local router.
    • CAN be changed with domain-id command under the OSPF process.
    • Purpose is to identify OSPF processes belonging to DIFFERENT VPNs.
    • Assumed that ALL processes WITHIN the SAME VPN are configured with the SAME PID.
    • If routes are exchanged between two different VPNs with DIFFERENT D-ID, OSPF interprets them as TYPE-5 LSAs as opposed to TYPE-3.
  • SECOND attribute is OSPF route-type.
    • 3 significant fields X:Y:Z
      • X = Source Area
      • Y = Route/LSA type
      • Z = Metric type. 1 or 2 for Y = 5/7
  • All routes redistributed from BGP appear as INTER-AREA routes, EVEN if they belonged to SAME area at different sites.
    • Because LSAs traveled across SBB, they are IA
  • BGP MED carries the original route’s metric from RIB.
  • Above mechanisms are configured automatically once redistribution is configured.
  • A SEPARATE OSPF process is configured for EACH VRF.
    • router ospf vrf
  • The presence of additional BB area can introduce the probability of routing loops.
  • OSPF implements some basic LOOP prevention rules -
    • Summary LSAs generated from routes redistributed from BGP have a special “DOWNWARD” bit set in LSA header.
      • If a router receives a summary-LSA with this bit set on an interface in VRF, it drops this LSA.
      • Prevents routing LOOPS in MULTI-HOMED sites.
      • May have an undesirable effect when a CE router is configured with MULTIPLE VRFs.
      • Can be disabled on individual router under OSPF process.
        • capability vrf-lite
        • DISABLES ABOVE MENTIONED LOOP PREVENTION.
      • Some versions of IOS do not have this feature.
      • If a router configured for MULTI-VRF experiences route black-holing, PE routers can be configured with DIFFERENT domain-ids.
        • Forces all redistributed routes to become external/Type-5 LSAs.
        • This bypasses the DOWNWARD-BIT check.
  • All routes redistributed via a particular PE will carry the OSPF route tag with BGP AS encoded inside.
    • Receiving routers with VRFs enabled will compare the AS number in the tag with LOCAL BGP AS.
    • If they match, could mean that LSA has looped back to another PE connecting the same site to SBB.
    • If issue occurs, simply apply a proper tag to redistributed routes.
      • redistribute bgp N subnets tag Y