Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

why the bgp route is jitter???

Hello,dear all.

I have encountered a strange problem in my lab,it will describe bellow:

Top:

R0(.1)--------------1.1.1.X/24---------------(.2)R1(loopback 0:20.20.20.20/32)

Configuration:

R0's:

router bgp 100

no synchronization

bgp router-id 1.1.1.1

bgp log-neighbor-changes

neighbor 20.20.20.20 remote-as 200

neighbor 20.20.20.20 ebgp-multihop 255

no auto-summary

!

ip classless

ip route 0.0.0.0 0.0.0.0 1.1.1.2

R1's:

router bgp 200

no synchronization

bgp router-id 2.2.2.2

bgp log-neighbor-changes

network 20.20.20.20 mask 255.255.255.255

neighbor 1.1.1.1 remote-as 100

neighbor 1.1.1.1 update-source Loopback0

no auto-summary

Then when i use "debug ip bgp update"command on R0,it displayed some information periodic bellow:

R0(config)#do debug ip bgp up

*Feb 13 00:45:03.159: BGP(0): Revise route installing 1 of 1 routes for 20.20.20.20/32 -> 20.20.20.20(main) to main IP table

When the above msg appeared,i use "show ip bgp"command:

R0(config)#do sh ip bgp

BGP table version is 16, local router ID is 1.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

When the above msg appeared,i use "show ip bgp"command:

   Network          Next Hop            Metric LocPrf Weight Path

*> 20.20.20.20/32   20.20.20.20              0             0 200 i

*Feb 13 00:45:29.167: BGP(0): no valid path for 20.20.20.20/32

*Feb 13 00:45:29.779: BGP(0): nettable_walker 20.20.20.20/32 no best path

When the above msg appeared,i use "show ip bgp"command:

R0(config)#do sh ip bgp

BGP table version is 15, local router ID is 1.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*  20.20.20.20/32   20.20.20.20              0             0 200 i

Can anyone tell me why,Tks!!!

1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Super Silver

Re: why the bgp route is jitter???

Hello Huang,

from the point of view of router R0 you are advertising net 20.20.20.20/32 with a BGP next-hop of 20.20.20.20

That is you are trying to advertise over an eBGP session the eBGP session R1's endpoint!

This simply does not make sense.

Try to advertise another subnet may be creating a new loop interface like

int loop 7

ip address 70.70.21.1 255.255.255.0

add on R1

router bgp 200

network 70.70.21.0 mask 255.255.255.0

this time net 70.70.21.0/24 with BGP next-hop 20.20.20.20 should be accepted and stable on R0.

interesting in your setup the use of ebgp multihop on only one side the one using its connected interface as local source for the eBGP session.

Hope to help

Giuseppe

13 REPLIES
Hall of Fame Super Silver

Re: why the bgp route is jitter???

Hello Huang,

from the point of view of router R0 you are advertising net 20.20.20.20/32 with a BGP next-hop of 20.20.20.20

That is you are trying to advertise over an eBGP session the eBGP session R1's endpoint!

This simply does not make sense.

Try to advertise another subnet may be creating a new loop interface like

int loop 7

ip address 70.70.21.1 255.255.255.0

add on R1

router bgp 200

network 70.70.21.0 mask 255.255.255.0

this time net 70.70.21.0/24 with BGP next-hop 20.20.20.20 should be accepted and stable on R0.

interesting in your setup the use of ebgp multihop on only one side the one using its connected interface as local source for the eBGP session.

Hope to help

Giuseppe

Re: why the bgp route is jitter???

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

Re: why the bgp route is jitter???

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

Hall of Fame Super Silver

Re: why the bgp route is jitter???

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

Re: why the bgp route is jitter???

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

Re: why the bgp route is jitter???

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,

ip route 20.20.20.20  255.255.255.255 1.1.1.2

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

Re: why the bgp route is jitter???

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

Community Member

Re: why the bgp route is jitter???

Tks 2 all of u!You are all expert and very warmhearted!

I'm a Chinese and I've had my Spring-Festival holidays several days ago.So long time i haven't confirm yours post,sorry very much!

Best regards!

sky.h

 

Re: why the bgp route is jitter???

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

Community Member

Re: why the bgp route is jitter???

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!

Re: why the bgp route is jitter???

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.

Community Member

Re: why the bgp route is jitter???

Hi,Maria.

I am so sorry, i haven't resolved this problem so far!Bcz i think it's seldom encounter in the real life.

I respect that you love cisco technique so depth!!!

sky.h

Best regards!

Re: why the bgp route is jitter???

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.

1080
Views
9
Helpful
13
Replies
CreatePlease to create content