cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
3172
Views
4
Helpful
15
Replies

BGP Loop Prevention Mechanism Visibility....

TangoAlfa
Level 1
Level 1

Hi All,

Referring to my attached diagram. To check how BGP loop avoidance mechanism work and where its shows basically, What I did, I have  advertise one network 10.10.30.0/24 on the router R-2. And Based on eBGP loop prevention the router R-3 should not received the route via router R-1 because  the AS path is same and its works also. Even I can See (visible) the same in R-3 after enable the debugging (debug ip bgp update) the output is below.

"

*May 17 05:04:14.939: BGP(0): 192.168.2.1 rcv UPDATE w/ attr: nexthop 192.168.2.1, origin i, originator 0.0.0.0, merged path 100 200, AS_PATH , community , extended community , SSA attribute*May 17 05:04:14.947: BGPSSA ssacount is 0

*May 17 05:04:14.947: BGP(0): 192.168.2.1 rcv UPDATE about 10.10.30.0/24 -- DENIED due to: AS-PATH contains our own AS;

"

Now My question is that referring to the diagram again router R-3 also should not received the same network (10.10.30.0/24) via router R-4 because iBGP don't advertise learned route to other iBGP peer and that is also work. 

But I can't see anywhere like I seen in case of eBGP after enabling the debugging. Can any one tell me how to check it could be by debugging like eBGP case or with Wireshark any one. Please help me that how can I see.(I want visibility).

tannetpro_0-1684315144840.png

 

1 Accepted Solution

Accepted Solutions

Hi @TangoAlfa ,

> My concern over here is that visibility for iBGP loop avoidance mechanism

You can also use bgp debug commands to see loop avoidance mechanism in action for iBGP as well, but to see the debug messages you would need to create a loop condition first. Here are some messages I captured in my virtual lab.

*May 18 06:18:19.113: BGP(0): 192.168.100.3 rcv UPDATE about 192.168.1.0/24 -- DENIED due to: NEXTHOP is our own address; ORIGINATOR is us;

*May 18 06:25:49.483: BGP(0): 192.168.100.2 rcv UPDATE about 192.168.1.0/24 -- DENIED due to: NEXTHOP is our own address; ORIGINATOR is us; reflected from the same cluster;

*May 18 06:30:30.547: BGP(0): 192.168.100.2 rcv UPDATE about 192.168.1.0/24 -- DENIED due to: reflected from the same cluster;

Regards,

View solution in original post

15 Replies 15

M02@rt37
VIP
VIP

Hello @TangoAlfa,

You can enable BGP debugging on router R-3 to monitor the BGP updates and route advertisements. Use the command "debug ip bgp update" on router R-3. This will display the BGP updates received and any denied routes. If the route from R-4 is being denied due to the AS-PATH containing your own AS, it should be visible in the debug output.

Another method to verify the BGP route advertisements is by capturing the BGP packets using Wireshark. You can connect Wireshark to a port on router R-3 and capture the BGP traffic. Look for BGP update messages and check if the route from R-4 is being advertised. If it is not present in the BGP update messages received by R-3, it indicates that the iBGP loop prevention mechanism is working as expected.

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

Thanks for your reply.

1. 1st Option I did by debug its not work(no visibility) for iBGP.

2. 2nd Option also tried with Wireshark, yes where its not showing any update coming from R4 to R3 but how do I understand its because of iBGP split horizon I am not receiving.?

Ok @TangoAlfa,

By using a combination of these methods, you can gain visibility into the BGP routing updates and confirm whether the iBGP loop avoidance mechanisms are preventing the network 10.10.30.0/24 from being received by router R-3 via router R-4.

-- BGP Database: Check the BGP database on router R-3 using the command "show ip bgp". Look for the network 10.10.30.0/24 in the BGP table. If the loop avoidance mechanisms are functioning properly, this network should not be present in the BGP table of router R-3.

--BGP Neighbor Information: Verify the BGP neighborship between router R-3 and R-4 using the command "show ip bgp summary". Ensure that the neighborship is established and the BGP session is in the "Established" state. This confirms that router R-3 is receiving BGP updates from router R-4.

--BGP Update Messages: If you have access to Wireshark or a network analyzer, you can capture BGP update messages exchanged between routers R-3 and R-4. Analyze the captured packets to see if there are any BGP update messages advertising the network 10.10.30.0/24 from R-4 to R-3. If the loop avoidance mechanisms are functioning correctly, you should not see such updates.

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

Hi M02@rt37 M02

in terms of iBGP debug I am getting one common output during capture. that is below

*May 17 11:12:40.379: BGP_Router: unhandled major event code 128, minor 0

but you answer yourself, eBGP advertise the prefix to neighbor and you use debug and see that the router see prefix and drop it.
in iBGP split horizon the iBGP never re-advertise the prefix learn via iBGP to other iBGP peers. 

try using RR and make RR readvertise the same prefix for direct connect iBGP.

Hi @MHM Cisco World ,

Thanks a lot for both of your response.

My concern is, all loop avoidance mechanism is working properly but only in case of iBGP Split Horizon I am not get any visibility like what I am getting in the  eBGP loop avoidance scenario through debug(output mention earlier). 

My concern over here is that visibility for iBGP loop avoidance mechanism

M02@rt37  has guided me that only we have to use wireshark to showcase that router R-4 not advertise any update to router R-3. So apart from this is there any other way out to get visibility. Or if anyone having Lab to test the same? 

Hi @TangoAlfa ,

> My concern over here is that visibility for iBGP loop avoidance mechanism

You can also use bgp debug commands to see loop avoidance mechanism in action for iBGP as well, but to see the debug messages you would need to create a loop condition first. Here are some messages I captured in my virtual lab.

*May 18 06:18:19.113: BGP(0): 192.168.100.3 rcv UPDATE about 192.168.1.0/24 -- DENIED due to: NEXTHOP is our own address; ORIGINATOR is us;

*May 18 06:25:49.483: BGP(0): 192.168.100.2 rcv UPDATE about 192.168.1.0/24 -- DENIED due to: NEXTHOP is our own address; ORIGINATOR is us; reflected from the same cluster;

*May 18 06:30:30.547: BGP(0): 192.168.100.2 rcv UPDATE about 192.168.1.0/24 -- DENIED due to: reflected from the same cluster;

Regards,

Hi @Harold Ritter Thanks for your response and test in your virtual lab.

This is what I am Looking for.. But I am bit confuse why in my router such notification is not showing even though I have enable the debug.

1. Can you please help me by letting me know that exact which debug command you have used?

2. Can you please have a look at my diagram and let me know is it right diagram where I tried to create iBGP loop?

Hi @TangoAlfa ,

which debug command you have used?

Probably the same you did.

deb bgp ipv4 uni updates

is it right diagram where I tried to create iBGP loop?

Bear in mind that for iBGP loop is not possible by default, as all iBGP peers need to be fully meshed and will not readvertised iBGP received updates. 

Route reflection introduce a potential for loop though. This is why RFC4456 introduced 2 new attributes to avoid loops (originator id and cluster list). 

To create a loop condition, you could have a RR client connected to 2 route reflectors. The route reflectors should be connected between themselves.

The first route reflector inserts the originator id and its cluster is in the cluster list and send the message to the second RR. If they have the same cluster id, the update is denied with a debug message similar to the following on the receiving route reflector:

*May 18 06:30:30.547: BGP(0): 192.168.100.2 rcv UPDATE about 192.168.1.0/24 -- DENIED due to: reflected from the same cluster;

If the cluster ids are different, the second route reflector propagates the update to the client and the client denies the update with a debug message similar to the following on the route reflector client:

*May 18 06:18:19.113: BGP(0): 192.168.100.3 rcv UPDATE about 192.168.1.0/24 -- DENIED due to: NEXTHOP is our own address; ORIGINATOR is us;

Regards,

Hi
In my topology I made R-4 route reflector (neighbor 192.168.4.3 route-reflector-client) and then R-3 is receiving the route which is advertising by R-2. after enable the debug still I am unable to see any output. It could be my iOS issue.
R-4#

router bgp 200
bgp log-neighbor-changes
neighbor 192.168.3.2 remote-as 200
neighbor 192.168.4.3 remote-as 200
neighbor 192.168.4.3 route-reflector-client
neighbor 192.168.4.3 next-hop-self all
R-4#



 

=======Route add and remove=========================

R-2(config-router)#network 10.10.30.0 mask 255.255.255.0
R-2(config-router)#no network 10.10.30.0 mask 255.255.255.0
R-2(config-router)#network 10.10.30.0 mask 255.255.255.0

 

============R-4=============

R-4#debug ip bgp updates in
BGP updates debugging is on (inbound) for address family: IPv4 Unicast
R-4#debug ip bgp updates out
BGP updates debugging is on (outbound) for address family: IPv4 Unicast
R-4#
*May 18 16:26:26.563: BGP(0): Revise route installing 1 of 1 routes for 10.10.30.0/24 -> 192.168.3.2(global) to main IP table
*May 18 16:26:26.575: BGP(0): 192.168.4.3 NEXT_HOP is set to self for net 10.10.30.0/24,
*May 18 16:26:26.579: BGP(0): (base) 192.168.4.3 send UPDATE (format) 10.10.30.0/24, next 192.168.4.4, metric 0, path Local

===========After removing the RR in R4 and add again network in R-3 output below=====

R-4#
R-4#
*May 18 16:38:18.911: %SYS-5-CONFIG_I: Configured from console by console
*May 18 16:38:27.479: BGP(0): Revise route installing 1 of 1 routes for 10.10.30.0/24 -> 192.168.3.2(global) to main IP table

 

It could be my iOS issue

still not success 
you need to config ibgp between R2 and R3. 

ibgp have Loop prevention 
1- split horizon 
2- originator 

I already mention how you can use iBGP originator to detect loop prevent 
but I think you dont get my idea 
the RR will re-advertise the prefix 
between R2 and R1 there is iBGP 

do this lab and debug bgp you will Easly see loop prevention 

Screenshot (692).png

Hi @MHM Cisco World 
I am really sorry for that. Definitely I will try this topology..

Thanks a Lot

you are so welcome
MHM