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 :-
- 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)
- 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.
- POINT OF INSERTION (POI) : PRE-BESTPATH permits COMPARISON BEFORE any other route attribute INCLUDING AD.
- COST COMMUNITY ID : 128 for EIGRP internal routes, 129 for EIGRP extrenal routes. LOWER PREFERRED.
- 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.
