It has been long time since the last part of this interesting – my own opinion– series, so before diving through today’s task I recommend everyone to check our LAB Topology & Tasks thus everyone should have known what we are doing here and our strategy to accomplish the mentioned tasks.

In the previous tasks we already implemented IS-IS to be the used IGP and then configured MPLS LDP as the labeling protocol, this LDP is used to assign label IGP prefixes.

Note: In some vendor implementations like Juniper’s LDP only assigns labels for IGP /32 prefixes.

So now we need another mechanism or a protocol to assign labels for the customer/vpn routes. Sure the engineering community gave a try to the routing protocols like IS-IS/OSPF to take this responsibility but the problem is they have to do extensions to all routing protocols or force ISPs to use just one which didn’t make sense at all, so as usual they came with the magic solution of extending the BGP to carry customers routes and assign labels to the routes and that does make sense because BGP is already used in ISPs and much flexible to be extended using AFI/SAFI concept.

The new extension was named MP-BGP which is clearly for MultiProtocol-Border Gateway Protocol, this protocol is mainly works between all PEs which requires a full mesh of iBGP sessions, or between a BGP Route Reflector and all PEs which requires only one iBGP session for each, this one is so recommended and I have never seen an ISP does full mesh of iBGP sessions, if you know some ISP do that please call 911 🙂

MP-BGP is responsible to carry customers routes from a PE and offer them to all other PEs if interested*, so now let’s see how to accomplish this easy task using Cisco routers of 7200VXR series which obviously run the traditional Cisco IOS.

*Interested: Once a customer is attached to a certain PE, this PE will import his related routes/prefixes from other PEs using BGP extended communities “will be discussed later”

In our topology we have three PE routers “PE01, PE02 & PE03” as we mentioned we can do full mesh of MP-BGP sessions which is not recommended so we picked up P1 to be the Route Reflector collecting all the VPNv4 prefixes and redistribute them again to all clients “PEs”.

Note: In real operational network you could pick up a PE to play the Route Reflector role or you could have a separate router to play this role, it has no standard.

First of all we will configure P1 to be ready for his new role, by mentioning his clients under the BGP process.

router bgp 123  no synchronization  bgp log-neighbor-changes  neighbor 1.1.1.1 remote-as 123  neighbor 1.1.1.1 update-source Loopback0  neighbor 2.2.2.2 remote-as 123  neighbor 2.2.2.2 update-source Loopback0  neighbor 3.3.3.3 remote-as 123  neighbor 3.3.3.3 update-source Loopback0  no auto-summary  !  address-family vpnv4   neighbor 1.1.1.1 activate   neighbor 1.1.1.1 send-community extended   neighbor 1.1.1.1 route-reflector-client   neighbor 2.2.2.2 activate   neighbor 2.2.2.2 send-community extended   neighbor 2.2.2.2 route-reflector-client   neighbor 3.3.3.3 activate   neighbor 3.3.3.3 send-community extended   neighbor 3.3.3.3 route-reflector-client  exit-address-family

Lets clarify what we’ve done in this configuration exactly. Firstly we defined the iBGP peers “PEs” and then activated all these peers under the VPNv4 address-family which means that we extended our BGP process to be MP-BGP and can exchange VPNv4 prefixes normally, then we defined these peers to be clients and that obviously means that P1 now became officially a Route Reflector.

There is a small part we didn’t mention which is “send-community extended”, this is enabled by default when activating a neighbor within the VPN address-family which means that we can exchange extended communities like “Route-Targets” with that peer and we will discuss this in details later.

Now we have just one thing to do, is to do the same configuration “excluding client part” on the PE routers.

router bgp 123  no synchronization  bgp log-neighbor-changes  neighbor 10.10.10.10 remote-as 123  no auto-summary  !  address-family vpnv4   neighbor 10.10.10.10 activate   neighbor 10.10.10.10 send-community extended  exit-address-family

This part does not need any clarification I assume, and once this configuration was done, a notification msg of a BGP peering 10.10.10.10 became up, and after checking we found that an undesirable ipv4 BGP session became up and that because BGP expects an IPv4 BGP peer by default.

*Sep 20 00:26:21.803: %BGP-5-ADJCHANGE: neighbor 10.10.10.10 Up

To solve this issue we only need to tell the routers “Never expect an IPv4 BGP session unless mentioned” by doing the following command on all PE routers and the Route Reflector under the BGP process, please read BGP default IPv4-unicast:

Router(config-router)#no bgp default ipv4-unicast

Now lets verify what we’ve done already:

P1#show bgp suP1#show bgp vpnv4 unicast all summary BGP router identifier 10.10.10.10, local AS number 123 BGP table version is 1, main routing table version 1Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd 1.1.1.1         4          123       5       5        1    0    0 00:01:21        0 2.2.2.2         4          123       2       2        1    0    0 00:00:22        0 3.3.3.3         4          123       2       2        1    0    0 00:00:31        0

Now we are done, be ready for the most interesting part, VRFs & PE-CE routing…