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

eBGP Peer returning UPDATE message back upstream?

LanDownUnda
Spotlight
Spotlight

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?

*** Rate All Helpful Responses ***
1 Accepted Solution

Accepted Solutions

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

 

View solution in original post

4 Replies 4

Jon Marshall
Hall of Fame
Hall of Fame

 

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

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?

*** Rate All Helpful Responses ***

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

 

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

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco