Hi Giuseppe,

I agree with you this is an interesting setup. The BGP neighbor addresses/update-sources required for a session to work properly should normally be known by some means other than the specific BGP session itself. I think for this setup to work properly, the subnets that are not directly connected and are used in the BGP configuration should probably be provided at each side using specific static routes. I think the current configuration kind of overcomes this by using a default route on the first router.

Kind Regards,

Maria

Hi Maria,

I agree.

See the neighbor ebgp-multihop command reference at http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp3.html#wp1013715

saying:

" To prevent the creation of loops through oscillating routes, the multihop will not be established if the only route to the multihop peer is the default route (0.0.0.0). "

Which is this case, I'm afraid.

BR,

Milan

Hello Milan,

if we look at the log provided by original poster we see that the BGP session is established.

The only prefix advertised is first accepted and installed * >

At a later time some BGP consistency check is performed and the BGP route is considered not valid.

net 20.20.20.20/32 via 20.20.20.20  implies a recursion.

As I noted in my first post one reason of this issue is the eBGP session is used to advertise the BGP endpoint itself.

I agree that the second part of the issue is the absence of a specific route to reach the BGP endpoint on R0.

This causes the failure of  the consistency check the BGP route can be accepted if the BGP next-hop is reachable, but that BGP next-hop best route is the BGP route itself.

From a lab point of view this setup is interesting, actually the fact that the BGP session is established is a somewhat unexpected result.

The session is established but the single prefix advertised is first accepted and then refused.

Hope to help

Giuseppe

Hi all,

When I first saw the original post I was puzzled about how the BGP session had been established. Obviously for the route to be entering the BGP table, the session must have been up and the author didn't mention any type of flapping of the session. I personally wouldn't like the use of a default for the purpose of session establishement from a best practice perspective anyway (if a second such session is needed for some reason how would it be done? and what if default has to change at some point?).

Giuseppe, I do not see a problem with advertising over a BGP session the same network that is used for the session itself. If a /30 connected is used between two eBGP peers, the eBGP peer that is assigning the /30 from one of its blocks will typically advertise the entire block that includes that subnet over the BGP session (the Connected route will be used for the session establishment and next-hop validation, while other destinations will be reachable using the BGP route), so what is the problem with advertising a longer prefix from a functionality perspective (other than whether it makes sense or not)? Do you think this is an issue that has to do primarily with the advertisement of the specific network over BGP ? You mean the issue won't appear with any other route advertised over such a session?

As I see it, the primary issue is the lack of a specific route for the peer address before session establishment, and the rest seem to me like consequences of this. I cannot find any official explanation for all this behavior, but I am guessing the following is happening:

1. The BGP session is established kind of loosely using the default like any TCP session would. According to the documentation posted by Milan there should be a problem with session establishment, but it is not clear to me what this means. Would the side with multihop configured not actively initiate the session, but would passively accept a session actively tried from the other side? Anyway, maybe this is just a bug or a consequence of the asymmetric nature of this setup.

2. When BGP tries to validate the next-hop of the route it has in the table, it cannot use the route itself as noted by Giuseppe and cannot use the default either (according to Zinin, all recursive route lookups are performed in classful mode, otherwise presence of a default would lead to resolvability of any intermediate address of any path). Still wondering why the route makes it as a valid path into the BGP table at some point however. Maybe the route shouldn't be making it into the BGP table as a valid path ever or it makes it temporarily and validation occurs somewhat asynchronously later. If this route oscillates, I guess the same will happen with any other route that has the same BGP next-hop because a stabler specific (say static) route for the next-hop doesn't exist (can anyone check this?)

Kind Regards,
Maria

Hi Maria,

I rememeber a year ago I had a similar problem in my lab.

The only difference was there were eBGP multihops configured on both sides.

And the behaviour was similar:

The BGP session was up, but ALL the prefixes were flapping periodically.

And everything was fixed by adding static host routes for loopbacks used as BGP update sources.

So IMHO,

added to R0 configuration would fix the problem here.

ad 2.) According to the config provided, isn't it possible the 20.20.20.20/32 prefix is the only one sent by the 20.20.20.20  neighbor?

I.e., the problem would be the same with other prefixes, if they were advertised?

BTW, could you provide some more details for "according to Zinin, all recursive route lookups are performed in classful mode"?

BR,

Milan

Hi Milan,

Sorry for the late response, but I am having some serious and unexpected issues going on and this question needed some thinking I must admit I still haven't managed to complete. The basic question I am trying to find an answer to is whether the default can validate the BGP next-hop. At a first glance it seems to me that it can't, but so would I think about the BGP session establishment, and there it is up ignoring my opinion. I guess reality sometimes disagrees with me and I have to live with that!

------------------------------------------------------------------------------------------------------------------------------------

Before installation of a route in the routing table, the router checks whether the route is resolvable. The resolvability condition is defined as follows:
1. A route Rte1 referencing only the intermediate network address is considered resolvable if the routing table contains at least one resolvable route Rte2 that matches Rte1's intermediate network address and is not recursively resolved directly or indirectly through Rte1. If multiple matching routes are available, the most specific route must be chosen.
2. Routes referencing interfaces with or without intermediate addresses are considered resolvable if the state of the referenced interface is up and IP processing is enabled on this interface.
Sentence 1 is obviously recursive and implies a route via an intermediate address can be resolved over another route of the same type. Sentence 2 defines the condition of the exit from such a recursion.

During routing table lookup router tries to find the route along which a packet must be forwarded and identifies the output interface and address of the next-hop node. Recursive routing lookup is done as follows:
1. Find a route matching the packet's destination address.
2. If route's active path contains a reference to an interface, the algorithm stops.
3. Otherwise, consider the active path's intermediate address as the next-hop address for the next routing table lookup operation, and return to step 1.
IP_CLASSLESS flag is passed to the lookup function only when finding the first matching route. All recursive lookups are done in classful mode; otherwise presence of a default in the routing table would lead to resolvability of any-even an invalid- intermediate address of any path.

The 'ip classless' command enables classless routing table lookup. In classful routing, default routes are used very carefully. Classless routing principles state that default routes must be taken every time a router doesn't know where to route a packet. A router looks through the routing table for a route whose network prefix matches the destination address best, that is, the longest matching route. If no matching route is available, the default route is used. When the 'ip classless' command is inactive in a router-classful routing is in effect-router considers supernets and the default route only if router doesn't know any subnet of the destination major network. [Maria says: as you can see, this leaves room for the next-hop to actually be resolved via the default route in some way, so it was not a good choice for me to use it as a defence for my claim that the default cannot be used for BGP next-hop validation. Next sentence does a somewhat better job, although it refers to static routes. As I see it right now, static routes and BGP routes have a similarity as far as the requirement for the recursive lookup of the intermediate address is concerned.]

If the intermediate address of a new [static] route is resolved via the static default and this default is configured over a next-hop rather an interface, the new [static] route is not installed, because the default ensures routing to a subrange in the same direction anyway. The same [static] is installed if the default is configured over an interface.

------------------------------------------------------------------------------------------------------------------------------------------------

The above is a compilation of various sentences from various chapters from Zinin's Cisco IP routing and I haven't modified them significantly. Note that we are ignoring CEF that resolves recursions more efficiently. I don't think this changes the logic significantly (FIB lookup is classless, but FIB is the end result after routes have been resolved). When all this background theory is applied to the specific case, the practical conclusions as I see it right now are:
1. The BGP route already being announced can be resolved via another static route covering the same prefix (next-hop can be the same as the route itself), but the same BGP route cannot be used to resolve itself.
2. The default configured most possibly cannot be used to resolve the BGP next-hop. It can be used to route packets, but cannot be used to validate the next-hop of other routes and make them look better than they already are. Note that I haven't actually seen this being explicitly stated for the case of BGP or done any weird setups to check it out, but somehow makes sense to me. I might be wrong though.

Kind Regards,
Maria

Hi,

Can you provide some details about what happened in your setup? From the ratings you gave us I kind of infer that other networks didn't exhibit the same issue as the network of the BGP session endpoint, as Giuseppe said from the beginning. Is that correct? Did you at any point use specific static routes instead of a default or did everything work with the default in place as it was in your original setup?

Thanks,

Maria

Maria,So sorry for the late response you!

Because i couldn't wait a long time and then terminated the lab last time,so i think the solution above is correct.But when i saw your response,i tried it again,i found that I was wrong.whether i use static route to instead default route on R0 or add a Loopback interface on R1,the problem is still exist!

sorry……

I have learned more valuable information from all of you,tks very much!And i feel that no big significance to research it's any more!How do you think?

sky.h

Best regards!

Don't worry. I am not interested in who is right or wrong. I am interested in what the correct answer is. Now, it's still not clear to me if you finally resolved the issue and how it was resolved, but since you think we have put enough thought to it and I also happen to be too busy these days, I won't insist much. By the way, your setup was very interesting, so thanks for opening this conversation and for your feedback so far.

I wouldn't try your setup in a production network. That's for sure!   I don't usually get very interested in weird setups such as infinite redistribution circles, etc, but your case brings up the following question I find interesting: can the default be used to validate BGP next-hops? This might be tested in a normal iBGP scenario in which the iBGP peers are generally not directly connected. Unfortunately, I do not have any routers to play with at this point, so can't test it. If you ever get a chance to test this, I would be very much interested in the results.