07-11-2021 04:59 AM
Recently I've come across a strange scenario whereby my downstream router that I'm peering with using eBGP is returning UPDATE messages back whenever I originate an UPDATE message myself.
Topology:
R1 - 172.16.1.1
R2 - 172.16.1.2
When I enable debugs on R1 and advise a new prefix I see this debug log:
BGP(0): 172.16.1.2 rcv UPDATE about 1.1.1.1/32 -- DENIED due to :AS PATH contains our own AS; NEXTHOP is our own address;
Can anybody explain why I would be seeing R2 return the Update message back to the originator?
Solved! Go to Solution.
07-11-2021 07:43 AM - edited 07-11-2021 07:46 AM
Hello @LanDownUnda and @Jon Marshall ,
in Cisco BGP the concept of update-groups has been introduced as a way to optimize the preparation of routes to be sent to multiple neighbors.
This feature should be automatically active ( no need to activate this) in short all eBGP neighbors sharing the same outbound routing policy are placed in the same update-group.
If you do not use a per neighbor route filter in the form of a route-map , a prefix-list a path-list in the out direction, then all neighbors are in the same update group.
The existence of the update-groups can be see with
show ip bgp <prefix>
going at the line advertised to update-groups a single number or a list of numbers separated by a "," comma appears.
You can also use
show ip bgp update-groups
To see what update-groups exist in your router.
This explains your lab tests R2 when it has multiple eBGP neighbors that are placed in the same update-gtoup prepares the set of prefixes to be sent to all neighbors without looking at the fact that a specific prefix was learned via R1
Hope to help
Giuseppe
07-11-2021 06:04 AM
Is R2 peering with other neighbors ?
If so then it seems this is expected behaviour and I have verified it in a lab but not sure why it does this -
http://lxllx.blogspot.com/2010/05/ebgp-split-horizon.html
Jon
07-11-2021 06:09 AM
Yes R2 is peering with other devices.
It seems to only happen when there is 2 or more adjacencies. If I have only a single one then I no longer see the behaviour.
That article is good but doesn't explain why though?
07-11-2021 07:43 AM - edited 07-11-2021 07:46 AM
Hello @LanDownUnda and @Jon Marshall ,
in Cisco BGP the concept of update-groups has been introduced as a way to optimize the preparation of routes to be sent to multiple neighbors.
This feature should be automatically active ( no need to activate this) in short all eBGP neighbors sharing the same outbound routing policy are placed in the same update-group.
If you do not use a per neighbor route filter in the form of a route-map , a prefix-list a path-list in the out direction, then all neighbors are in the same update group.
The existence of the update-groups can be see with
show ip bgp <prefix>
going at the line advertised to update-groups a single number or a list of numbers separated by a "," comma appears.
You can also use
show ip bgp update-groups
To see what update-groups exist in your router.
This explains your lab tests R2 when it has multiple eBGP neighbors that are placed in the same update-gtoup prepares the set of prefixes to be sent to all neighbors without looking at the fact that a specific prefix was learned via R1
Hope to help
Giuseppe
07-11-2021 09:01 AM - edited 07-11-2021 09:45 AM
Can you share the topology ?
if two Router advertise the same prefix then the upstream router will be as transit AS.
https://networklessons.com/bgp/bgp-prevent-transit-as
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide