BGP Next-Hop-Self

I have seen lot of guys which say that next-hop-self feature in BGP is used for the E-BGP peering. But with the given case study all of you come to know that It is very practical in I-BGP session in SP domain usually when the customers use static routes.

This case study is divided into two parts:-
a)IP-VPN
b)MPLS-VPN
IP-VPN
In SP cloud, 4*7200 routers are configured as per the diagram. Every router is having IPV4 peering with RR router. OSPF is using for IGP.CE – PE is configured with static routing. All wan links are /30 and loopback addresses are /32.

RR Config is given below:-

I know you will be amazed to see the new config in the BGP. But don’t afraid let’s understand that. The BGP templates introduced in Cisco IOS releases 12.3T, 12.4, 12.2S and 12.2SBC allow you to group session-specific and routing-policy-specific BGP settings into templates with a hierarchical inheritance structure. The peer-session templates define all session-specific parameters (for example, update-source, ebgp-multihop, password, remote-as or local-as), while the peer-policy templates define parameters that influence routing policies, route filters, community propagation and generation of BGP updates The peer-session template is applied to the global neighbor definition. The peer-policy template needs to be applied to a neighbor for each address family in which the neighbor is activated.

Requirement:- CE1 is having one loopback address i.e 10.1.1.1/32 and it is directly attached with the PE1. CE has a default route towards PE1 and CE1 wants that its another location which is CE2 should able to access its loopback. In SP cloud we added a static route of 10.1.1.1/32 towards CE1. But for reachabilty thi default route should be advertised in the SP IGP cloud, but the worse effect of doing this is in the increase of E2 route. So this is not a scalable solution of doing this. Another solution is that this route can be advertised in the BGP and with the help of RR, it will be advertised in the whole cloud. It means no more E2 routes and this solution is scalable one. So we opt the latter solution and advertise the client static route in the BGP.

After this the route should be advertised to RR. You can see with the help of given command.

Now lets come to the RR and check the update.

Hey, Its getting the update of 10.1.1.1/32 as next hop 172.168.2.2. Now the next step is that this route should be advertised to the other client’s also.

In the highlighted line it i showing that the route i not advertised to any peer. Next to this line its is showing that the route i being recived by RR-Client i.e 10.10.10.1 with next hop 172.168.2.2 (inaccessible). What does this inaccessible means, it means the next hop which is 172.168.2.2 is not in the routing table. So from here you got the clue and now check the routing table of RR.

So from the routing table, it is cleared that the next hop is not reachable thats why RR is not advertising this route to its others peer. This problem can be traced on the first level also, see the figure 4 which cleary states that the route in the BGP table is not the best thats why it is not marked with the > sign. So you can check the other peers BGP table also.

Lets analyse the problem carefully. Why the next hop is not present in the routing table. Usually we never advertise the PE-CE links in SP IGP routing table. I know now will be thinking of that why not advertise this PE-CE link in the OSPF or redistributed connected in the OSPF. Yes, you can do this but it will impose another E2 routes and any time when customer link will down your PF will be calculated. Thats why it is not a scalable solution to advertise in the SP IGP. Another question comes in the mind advertise PE-CE directly connected link in the BGP. It really looks sound. Lets try and see the results.

Output of RR after advertising PE-CE wan link in BGP

Output of PE2 after advertising PE-CE wan link in BGP

Output of P after advertising PE-CE wan link in BGP

From the above outputs it is cleared that now the route is in the all SP routers. Lets check from the customer end.
SHIVLU-CE2#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 604/708/868 ms
SHIVLU-CE2#
Hurra, Its working fine. Now you are thinking that this is the first-rate solution, But actually the main disadvantage of the soulution is that for every customer we will be getting one extra route i.e wan route which i consuming your router’s memory and ofcourse processes also. From the above outputs we can conclude that the clients route can reachable if I reach to that PE router and from that PE router we are having static route for that client. Lets think is it possible for all clients. It means if my PE will advertise all the static routes of clients with its loopback address then all the clients would be reachable. For this we can use the next-hop-self in the BGP peering with RR.

Now lets analyse the other routers output.
RR Output

PE2 Output

E2 Output
SHIVLU-CE2#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 560/1018/1292 ms
SHIVLU-CE2#
MPLS-VPN
I am not going to explain the case of MPLS-VPN. The Only difference is that instead of IPV4 peering, will be having VPN-V4 peering and clients will be part of VRF.

People who read this post also read :