Troubleshooting BGP Neighbor Adjacency

Hi Andrew,

Many thanks for the response!

I’ll have to re-read the notes on the lesson again to better understand your response. Bit murky still. Not to worry, this is on me to figure out first.

Rgds,

Shannon

@Ajay

There are quite some different things you can do to increase the BGP convergence time. Is there anything in particular you want to know or just a general overview?

Rene

@Shannon thanks for reporting the typo, it has been fixed.

Hi Rene,

Noted with thanks!

Rgds,

Shannon

Hi Rene,

I need general overview of increasing the BGP convergence time.

Regards,
Ajay

Hello Ajay!

At the moment we don’t have a section covering BGP convergence timers and tuning, but INE has a great blog post about it that you can find here:

http://blog.ine.com/2010/11/22/understanding-bgp-convergence/

I hope this is helpful!

Laz

Hello Rene,

Could you please tell me why a router cannot have two BGP autonomous systems configured ?

Thanks,
Harsha.

Hello Harsha

By design, BGP is made so that each router belongs to a single AS. But this doesn’t limit its functionality. You can still peer with routers from multiple AS as well as to routers in the same AS. There is however a way to allow a router to appear to neighbors to be a member of a second AS using what is called the Local-AS feature. This is usually done for migrations when moving from one ISP to another, or from one MPLS provider to another, and is usually provided as a temporary solution during the migration process.

BGP is designed to function with only a single AS assigned to each router.

I hope this has been helpful!

Laz

Hello Laz,

           Thank you so much for the reply. I appreciate the help. 

Thanks,
Harsha.

1 Like

whenever the neighbor in active state , that means open message is synchronizing between both R1 & R2 routers.
so in that circumstances R1 & R2 both should ping each other but the telnet will not works , that means the L2 & L3 is working fine but issue with L4 i e. issue with TCP port 179

whenever the neighbor in idle state , that means there is surely an L2 or L3 issue.

so my question is that , in what circumstances BGP neighborship will stuck in connect state.

Although we do not generally seeing that problem i.e. neighborship stuck in connect state.

Thanks in advance…

Hi Laz ,

Thanks for your great post , could you please share the link / blog for Local-AS feature , how it works.
Also please check my following comments & help to share your acknowledgement / feedback.
whenever the neighbor in active state , that means open message is synchronizing between both R1 & R2 routers.
so in that circumstances R1 & R2 both should ping each other but the telnet will not works , that means the L2 & L3 is working fine but issue with L4 i e. issue with TCP port 179

whenever the neighbor in idle state , that means there is surely an L2 or L3 issue.

so my question is that , in what circumstances BGP neighborship will stuck in connect state.

Although we do not generally seeing that problem i.e. neighborship stuck in connect state.

Hello Tanmoy

The Active state can be reached via two situations. The first is when a BGP peering goes from Connect to Active. This will take place if the Connect three-way handshake fails. The other case is going from OpenSent to Active. This will take place again, if the TCP session fails. So theoretically, yes, two routers in Active state will be able to ping each other, but are in a situation where they have not yet successfully completed the TCP three way handshake.

If two routers are configured correctly to be BGP peers, and they remain in the idle state, then yes, it is most likely an L2 or L3 problem. However, it could also be a misconfiguration on one of the routers such as an incorrect neighbor IP address.

Like you said, we don’t generally see a “stuck in connected” state. This is clearly described in the BGP Neighbor Adjacency States lesson:

Connect: BGP is waiting for the TCP three-way handshake to complete. When it is successful, it will continue to the OpenSent state. In case it fails, we continue to the Active state. If the ConnectRetry timer expires then we will remain in this state. The ConnectRetry timer will be reset and BGP will try a new TCP three-way handshake. If anything else happens (for example resetting BGP) then we move back to the Idle state.

I hope this has been helpful! Stay healthy and safe!

Laz

Hello Tanmoy

The Local-AS feature is further described in this Cisco Documentation:

I hope this has been helpful! Stay safe and healthy!

Laz

Hi Laz ,

Awesome
Thank you very much

1 Like

I am confused on the multi-hop section. Why do we need to change the multi hop to “ebgp-multihop 2” if it’s a direct connection? Does the local int fas 0/0 on the router count as a hop?
ex. lo0 > int fas 0/0 > int fas 0/0 (remote router)

Hello Juan

Take a look at this post:


I hope this has been helpful!

Laz

Hello, I have a question: how often does it happen in a real BGP router that static routes are entered there? Furthermore: how often does it happen in a real BGP router that the loopback addresses or loopback networks between two routers are made known there?

Thanks in advance.

1 Like

Hello Roberto

BGP routers that are installed in a production network will often have static routes. It all depends upon the needs of a particular implementation. You will find that BGP routers on the edge of an enterprise network may need such configurations in order to function correctly, so it is not unusual to see.

Also, loopbacks are used very often for BGP routers in order to ensure that a BGP peering is not lost due to a downed interface. Loopbacks will remain up even if you have an interface that goes down, and this can maintain peerings in such an event. In order for this to function, you need to advertise the loopback interfaces so that routing can be established between them, which is a prerequisite for BGP peering.

You can find out more about this in the following lesson. The lesson may be about eBGP multihop, but it fully describes the requirements of loopbacks:

I hope this has been helpful!

Laz

you need to change the following at the very end to say “iBGP” instead of EBGP as you have taught us that EBGP has one hop dependency by default so you have typo there.

Problem solved! The only difference with EBGP is that we don’t have to change the TTL with the ebgp-multihop command.

Hello Brian

The example in section 4 of the lesson dealt with changing the source of the iBGP peering. In the example in section 2, he deals with a similar situation but with eBGP peering

What Rene is saying with his final statement there is that in the case of iBGP, you don’t need to change the TTL with the ebgp-multihop command as you do with the eBGP case.

Maybe the wording is not quite clear. Maybe a better wording would be:

Problem solved! The only difference here is that for iBGP peerings, we don’t need to change the TTL, whereas for eBGP we must use the ebgp-multihop command.

Does that make sense? I’ll let Rene know to clarify the wording.

I hope this has been helpful!

Laz