I set up a lab (topology only) based on this GNS3 lab.
I’m not using that workbook; I built it on my own.
I’m using OSPF for the IGP.
Key Points:
BGP Confederation: The network is divided into multiple sub-ASes, each consisting of a PE, RR, Core Router, and Edge PE. This helps manage the network more efficiently.
MPLS: Required for label switching within the intra-subAS network, enabling efficient data forwarding. It must be enabled on both PEs and Core Routers within each subAS. For Edge PE to Edge PE, I believe MPLS is required as well, but further confirmation is needed.
BGP-LU: Necessary for label switching between sub-ASes, managing both IPv4 routes for remote PE loopbacks and the corresponding labels.
RR: Functions as a route reflector for both VPNv4 and BGP-LU routes, ensuring route propagation across the network. MPLS is not required, and all PEs are connected to it.
Core Routers: Operate solely with IGP and MPLS, without running BGP.
VPNv4#
Used to exchange VRF routes between PE routers.
mpls ip bgp forwarding is automatically configured on interfaces that establish the VPNv4 connection, allowing labeled packets to be forwarded between PEs
VPNv4 routes are installed only if the corresponding VRF exists on the router, except for RRs, which do not require VRFs for every route they reflect.
In the topology, the edge PE connects to two sub-ASes, advertises routes to the RR, which then propagates them to other PEs, ultimately reaching the CE.
However, since the edge PE does not have a defined VRF, the VPNv4 routes will not be installed or propagated further.
no bgp default route-target filter is required to bypass this limitation on the edge PE.
BGP-LU#
It enables label distribution across AS boundaries without relying on LDP. We will use it to advertise PE loopback along with labels to the remote Sub-AS.
The next-hop for the advertised routes and labels is the IP of the remote edge PE.
Thus, the reachability to the remote edge PE is crucial. I redistributed the connected subnets of the edge PE into OSPF.
The label switching forwarding terminates at the remote edge PE. Therefore, MPLS must be enabled on the link between the edge PEs. (I need to double check this)
To enable BGP-LU
router bgp YYYY
address-family ipv4
neighbor x.x.x.x send-label
This must be used throughout the chain: PE → Edge PEs → RR → PE.
Label Switching#
MPLS Label:
- Used to forward packets within an intra-AS.
- The next hop is directly connected.
PE12#sh mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
18 Pop Label 9.9.9.9/32 0 Gi0/0 10.9.12.9
19 Pop Label 10.9.11.0/24 0 Gi0/0 10.9.12.9
20 Pop Label 10.8.9.0/24 0 Gi0/0 10.9.12.9
21 Pop Label 10.9.13.0/24 0 Gi0/0 10.9.12.9
22 21 13.13.13.13/32 0 Gi0/0 10.9.12.9
23 23 11.11.11.11/32 0 Gi0/0 10.9.12.9
24 24 10.10.10.10/32 0 Gi0/0 10.9.12.9
25 25 8.8.8.8/32 0 Gi0/0 10.9.12.9
26 26 7.7.7.7/32 0 Gi0/0 10.9.12.9
28 28 10.8.10.0/24 0 Gi0/0 10.9.12.9
29 29 10.7.8.0/24 0 Gi0/0 10.9.12.9
30 No Label 172.30.22.0/24[V] \
5744 Gi1/0 10.12.22.22
31 30 10.6.7.6/32 0 Gi0/0 10.9.12.9
33 18 10.6.7.0/24 0 Gi0/0 10.9.12.9
BGP-LU Label:
- Used to forward packets across inter-AS boundaries.
- The next hop of the prefixes in remote AS is not directly connected. (eg: 4.4.4.4/32)
PE12#sh bgp label
Network Next Hop In label/Out label
4.4.4.4/32 10.6.7.6 nolabel/21
5.5.5.5/32 10.6.7.6 nolabel/20
12.12.12.12/32 0.0.0.0 imp-null/nolabel
13.13.13.13/32 13.13.13.13 nolabel/imp-null
In Label:
- The router checks this label in its LFIB to determine how to forward the packet. (lookup the table)
Out Label:
- The label that replaces the incoming label on a packet before forwarding it to the next hop (label swapping).
Next Hop:
- The next destination for the packet.
MPLS Table:
- The MPLS label table is based on the IP routing table.
- Labels are assigned to routes and exchanged with MPLS peers using protocols like LDP or RSVP-TE.
- If the route is not present in the routing table, no label will be assigned, and the entry will not be added to the table.
Next Hop Reachability:
- Similar to BGP, MPLS requires the next hop to be reachable for label switching to function correctly.
- If the next hop is unreachable, the MPLS path will not be established.
Example: Sending a packet to 4.4.4.4/32
BGP-LU:
- Prefix: 4.4.4.4/32
- Out label: 21
- Next-hop: 10.6.7.6
MPLS:
- Prefix: 10.6.7.0/24
- Out label: 30
- Next-hop: 10.9.12.9
Packet forwarding process:
- Push label 21 (inner label) onto the packet.
- Push label 30 (outer label) onto the packet.
- Forward the packet to 10.9.12.9.
- The outer label (30) is swapped as the packet moves through the MPLS network until it reaches 10.6.7.6.
- Once at 10.6.7.6, the inner label (21) is processed.
Next Hop#
- eBGP: Sets the next-hop to itself when advertising routes to external peers.
- eBGP in BGP Confederation: Does not change the next-hop for inter-SubAS connections. This is why VPNv4 routes advertised across SubAS still retain the PE IP as the next-hop.
- BGP-LU Routes: Sets the next-hop to itself when advertising routes. (even in BGP Confederation)
Option ABC#
There are a few options for multi-AS MPLS.
End-to-End BGP-LU is Option B
Option A - VRF-to-VRF: Set up VRF on the Edge PE so that VPNv4 routes are installed in the BGP IPv4 VRF route table. These routes are then advertised to the RR and distributed to other PEs. However, managing a separate VRF for each customer on the Edge PE can be resource-intensive.
Option C uses next-hop-self on Edge PEs and between Edge PEs and the RR. This approach eliminates BGP-LU and the need to enable and MPLS on the link between the Edge PEs.
BGP Notes#
(For my old 7200 router)
- BGP routes are installed and advertised only when the next hop is reachable.
- If the next hop is unreachable, the route will not propagate to the peer.
neighbor PEER-GROUP activatedoesn’t work, I need to activate each peer individually.- For VPNv4, peers must be explicitly activated, while for IPv4 this is not required.
next-hop-selfdoesn’t work globally; it needs to be explicitly set under the address family config.
Troubleshooting#
If BGP routes are not propagating or being installed in the route table, check the following:
- Ensure the next hop is reachable.
- (I mean the propagation) Verify if the route is a route reflector client (iBGP).
sh bgp x.x.x.x provides more details on why a BGP route is not installed
If the BGP connection is not established:
- Check reachability of the peer, as incorrect IGP configuration or misconfigured interfaces (e.g., wrong IP) are common issues.
- For eBGP using loopbacks, remember it requires more than one hop, so
ebgp-multihopis necessary.
Sometimes the global configuration doesn’t apply to the address family configuration. For example, the connection might start in IPv4 but not in VPNv4.
Always verify IGP, BGP, and MPLS membership using these commands:
sh bgp summary
sh bgp vpnv4 unicast all summary
sh ip ospf neighbor
sh mpls interface
For BGP-LU, use sh bgp vpnv4 unicast all neighbor x.x.x.x to check the capability for IPv4 labeling.
For MPLS:
- Check the forwarding table and trace the label switching as explained in previous sections.
- If the target prefix is not in the table, it’s likely due to the prefix not being in the IP routing table or the next hop being unreachable.
For VPNv4, if the route isn’t installed or propagated:
- Ensure the VRF exists
- the VRF filter is disabled. (in Edge PE)
When performing ping tests:
- Always ensure you are testing under the correct VRF and using the correct source.