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