Routing

Hi all.

When I read the document and found that has new behavios about accept-remote-nexthop 

feature on JUNOS 13.3

"For Junos OS Release 13.3 and laterst releases, specify that a multihop EBGP peer accepts a remote next hop with which it does not share a common subnet. This allows working around current resolver limitations to realize multipath forwarding in recursive next-hop resolution scenarios."

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/accept-remote-nexthop-edit-protocols-bgp.html

But I am not understand clearly, I tested on lab with old version(9.3 etc) and saw that multihop

EBGP peer always accepts a remote next hop .

So anyone can help me which exactly is change on 13.3 ?

Many thanks

I will try to explain for you, however can you explain what are you trying to acheive with the lab you have set up? BGP can be very simple to deploy, but it can become very complex. The configurations we make are done because we are trying to achieve an objective and not just include all possible configration options available. In order to understand the concept of  accept-remote-nexthop, you must first understand all of these concepts:

I am not assuming anything, do you understand all of these concepts and the effects on bgp when configured?

bgp default load balancing behavior

1- BGP path selection process

2- Multihop

3- Multipath

Then we get to:

 accept-remote-nexthop

"....I tested on lab with old version(9.3 etc) and saw that multihop EBGP peer always accepts a remote next hop ..." Can you share your your config and the results because "The default behavior is for any next-hop address received from a single-hop EBGP peer that is not recognized as sharing a common subnet to be discarded."

prior to Junos ver 9, this statement was not availanble (I never worked with Junos OS 9; just what the docs say)

This article summs it up nicely. If this does it great, if not we can proceed.

http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/bgp-accept-remote-nexthop.html

""For Junos OS Release 13.3 and latest releases, specify that a multihop EBGP peer accepts a remote next hop with which it does not share a common subnet. This allows working around current resolver limitations to realize multipath forwarding in recursive next-hop resolution scenarios.""

>This is just someone additional explanation (probably adding to the confusion) as the behaviour in the configurations of ver 9.3 and ver13.3 have not changed as far as I can see.

Hi lyndidon

I attached my topology and the result test. 

Attachment(s)

accept-next-hop-multihop.zip   156 KB 1 version

So my concerns are still valid. If you understand the effects of the configurations, exactly what are you trying to accomplish with the configurations you have made? For example accepting a route from the EBGP peer 99, (agg_route) and setting the nexthop to the remote address and then advertise it back in your export policy to your eBGP peer 99. So lets start with the basics; review the path selection process first, concentrating from step 9 downwards.
http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/general/routing-ptotocols-address-representation.html
Remember the path selection process; only one of the next-hops will be made available to the routing process if the same route with equal cost paths in received from different peers in the same AS. When you configure multipath on session on the router, the selection algorithm ignores both the router ID and the peer ID selection criteria as is now able to accept and make both next-hops available to routing process as valid next-hops. Without multipath, only a single next-hop would be selected as valid.

Multipath is used when you want to enable load balancing to peers in different AS or the same AS if one or more of the destinations have next-hops that are not of the same subnet or going to multiple peers in the same AS. We are talking about eBGP peers.
This example and diagram best explains it well:
http://www.juniper.net/techpubs/en_US/junos11.4/topics/topic-map/bgp-multipath.html

http://www.juniper.net/techpubs/en_US/junos13.2/topics/topic-map/bgp-multipath.html


R1=========R-ID-2=============>15.15.6.6/24
R1=========R-ID-3=============>15.15.6.6/24

Normal selection for example will only have single active path with the single next-hop going to the router with the lowerID, R-ID-2 for the network 15.15.6.6/24. If both routers had routier ID R-ID-2, then lower peer-IP address would selected. No load-balancing could be done. With multipath configured, even though a signle path is active to the network 15.15.6.6/24, both next-hops to R-ID-2 and  R-ID-3 will be valid and available for load-balancing.
Fig. 22
R1=========R-ID-2=============>15.15.6.6/24
R1=========R-ID-3=============>15.15.6.6/24
R1=========R-ID-7-in AS 22=============>=R-ID-18>15.15.6.6/24
R1=========R-ID-8-in AS 22================R-ID-16>15.15.6.6/24

In figure 22, even with multipath configured, I cannot accept or use the router in AS 22, so now I have to configure multihop. But multihop is configured, it breaks multipath and even thow I can peer with both AS, I still cannot loadbalance to both AS. So we need a hybrid solution.

Multihop allows you to form an eBGP peering relation with a neighbor (or loopback address) that is not directly connected. The default ttl for bgp packet is 1 so multihop changes it to 64 so the packet can go further. "When you configure a multihop session in this situation, all next-hop routes learned through this EBGP peer are labeled indirect even when they do share a common subnet. This situation breaks multipath functionality for routes that are recursively resolved over routes that include these next-hop addresses... so you still form the "remote eBGP peer, but lose the load balancing benefits of multipath."
This example and diagram best explains it well:
http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/bgp-multihop-understanding.html
R1<=========R-ID-3=============R-ID-4=============>R-ID-5
So you want to eBGP peer with R-ID-5. It cannot work by default. BGP ttl is 1. R-ID-5 is 3 hops away. Configure multihop ttl 4, then you can peer with R-ID-5.

In order to accept the remote next-hop and restore the multipath functionality that was broken by multihop, you would configure accept-remote-nexthop. So accept-remote-nexthop essentially does the same thing that multihop does but also multpiath. Think of as a hybrid of multipath and multihop fused together.
This example and diagram best explains it well:
https://www.juniper.net/techpubs/en_US/junos13.2/topics/example/bgp-accept-remote-nexthop.html
R1<=========>R-ID-3=============R-ID-4=============>R-ID-5=15.15.6.6/24

R-ID-3 has a policy that accepts 15.15.6.6/24 and advertise to R1 with the next-hop of course pointing to the peer-IP of R-ID-5. R1 says, no way, I cannot accept that next-hop, because it must point to R-ID-3, so it is unusable, we do not share a comment subnetwork.
So, we remove the multihop config (cannot be done with accept-remote-nexthop at teh same time) with accept-remote-nexthop configured for Fig 22, we get all the benefits, we can now load balance.
As you saw from your results the route was hidden from the routing table from being used, with the explanation "next-hop unusable" when you show route hidden detail. It was discarded as far as the routing process is concerned. "show route 1.1.10.10" was blank. Now your setup was incomplete because you only had a single peer in the eBGP session.

If you still ahve questions, please let us know exactly what you are expecting from the lab and what exactly you do not understand.

maybe I too am confused and would welcome the explanation.

Hi Lyndidon

Very apperciate your help. I understand about the concepts of multihop, multipath, bgp selection ..

and did training on lab.

>As you saw from your results the route was hidden from the routing table from being used, with the explanation

>"next-hop unusable" when you show route hidden detail. It was discarded as far as the routing process is concerned.

>"show route >1.1.10.10" was blank. 

=>

yes, it was hidden because it was indirect route, but you can saw on the next-slide, it was accepted when I configured

accept-remote-nexthop or multihop only. 

-> "The default behavior is for any next-hop address received from a single-hop EBGP peer that is not recognized as sharing a common subnet to be discarded."

>If you still ahve questions, please let us know exactly what you are expecting from the lab and what exactly you do not

>understand. maybe I too am confused and would welcome the explanation.

=>

I`m do not understand clearly about new behavior of multihop and accept-remote-nexthop command on JUNOS

13.3 and before (9.3, 11.4 etc... ). 

For example, on the Fig.22

R1=========R-ID-2=============>15.15.6.6/24
R1=========R-ID-3=============>15.15.6.6/24
R1=========R-ID-7-in AS 22=============>=R-ID-18>15.15.6.6/24
R1=========R-ID-8-in AS 22================R-ID-16>15.15.6.6/24

If we configure multihop , it breaks multipath , right ?

So on Junos 13.3, it doesn`t ?

I`d prefer if you could explain or help me how to check the difference between 13.3 before and later

 with simple topology.

Many thanks

I`m do not understand clearly about new behavior of multihop and accept-remote-nexthop command on JUNOS 13.3 and before (9.3, 11.4 etc... ).

I fouund these explanations so I am not able to simplify any different, so I will default to allow someone else to give it  ago. I know that Juniper can be difficult to understand and if one cannot find the correct words to use, then it can be hard to understand.

Overview

In some situations, it is necessary to configure a single-hop EBGP peer to accept a remote next hop with which it does not share a common subnet. The default behavior is for any next-hop address received from a single-hop EBGP peer that is not recognized as sharing a common subnet to be discarded. The ability to have a single-hop EBGP peer accept a remote next hop to which it is not directly connected also prevents you from having to configure the single-hop EBGP neighbor as a multihop session. When you configure a multihop session in this situation, all next-hop routes learned through this EBGP peer are labeled indirect even when they do share a common subnet. This situation breaks multipath functionality for routes that are recursively resolved over routes that include these next-hop addresses. Configuring the accept-remote-nexthop statement allows a single-hop EBGP peer to accept a remote next hop, which restores multipath functionality for routes that are resolved over these next-hop addresses.

"

Release Information

Statement introduced in Junos OS Release 8.5.

Statement introduced in Junos OS Release 9.0 for EX Series switches.

Statement introduced in Junos OS Release 11.3 for the QFX Series.

Description

Specify that a single-hop EBGP peer accepts a remote next hop with which it does not share a common subnet. Configure a separate import policy on the EBGP peer to specify the remote next hop. You cannot configure multihop and accept-remote-nexthop statements for the same EBGP peer.

For Junos OS Release 13.3 and later releases, specify that a multihop EBGP peer accepts a remote next hop with which it does not share a common subnet. This allows working around current resolver limitations to realize multipath forwarding in recursive next-hop resolution scenarios."

================================================================================

yes, it was hidden because it was indirect route, but you can saw on the next-slide, it was accepted when I configured

accept-remote-nexthop or multihop only. 

It was hidden because  "The default behavior is for any next-hop address received from a single-hop EBGP peer that is not recognized as sharing a common subnet to be discarded." Not becuase it was Indirect.

+++++===========================================================

If we configure multihop , it breaks multipath , right ? Yes

So on Junos 13.3, it doesn`t ? Yes, it still does break multipath.

The ability to have a single-hop EBGP peer accept a remote next hop to which it is not directly connected also prevents you from having to configure the single-hop EBGP neighbor as a multihop session. When you configure a multihop session in this situation, all next-hop routes learned through this EBGP peer are labeled indirect even when they do share a common subnet. This situation breaks multipath functionality for routes that are recursively resolved over routes that include these next-hop addresses.

BGP uses different tables to resolve protocol next-hop for different applications. In a normal BGP application like IPv4, the prefix is learned in the default table inet.0.  BGP will try to resolve its protocol next-hop in the table inet.3 first;  if fails, it will resolve in the table inet.0.

Understanding Indirect Next Hops

Junos OS supports the concept of an indirect next hop for all routing protocols that support indirectly connected next hops, also known as third-party next hops.

Because routing protocols such as internal BGP (IBGP) can send routing information about indirectly connected routes, Junos OS relies on routes from intra-AS routing protocols (OSPF, IS-IS, RIP, and static) to resolve the best directly connected next hop. The Routing Engine performs route resolution to determine the best directly connected next hop and installs the route to the Packet Forwarding Engine. By default, Junos OS does not maintain the route for indirect next hop to forwarding next-hop binding on the Packet Forwarding Engine forwarding table....so that is why special configuration is needed to accept those indirect nexthops.

I definitly follow this for a clear explanations from one of the experts maybe one who has service provider experience and training. I do not have it.

Very thanks for your explaination.

I will try to check again on lab later.