Route announcements by BGP

[madrileño18]

I have seen BGP behavior that I do not understand. The CE receives a prefix of the neighbor eBGP (a PE) and re-announces the same prefixes, exactly the same, with the same attributes. In other words, a neighbor eBGP announces a route and it returns it to announce without modifying anything to the same neighbor that has published it, without going through more intermediate equipment or anything, directly. It can be said that the CE is reflecting the routes but to the PE again, I had never seen it before and I do not know the reason why this can happen.

[Sergey Lisitsin]

I think this behaviour might relate to the concept of update groups in BGP. All members of an update group receive exactly the same update. You can check that by looking at a specific prefix that your CE router sends back to PE. I bet your CE have got more than one eBGP peer. In that case, all eBGP peers will be grouped into a single update group and all prefixes are sent to all peers in that group. To check that, what you can do is:

1. see if the prefix you receive from PE is being advertised to an update group - show ip bgp x.x.x.x

2. see what peers are included into the update group - show ip bgp update-group N where N is the number of update-group found in step 1.

This is standard default behaviour of BGP on Cisco routers from some version (don't know which) and shouldn't be worrying, as it doesn't make much harm.

[madrileño18]

But it can not be that a group of pairs "reflects" towards the group of companions the routes that receive the same. Neither can it be for the IOS version or router because in some passes and in others it does not. The truth is not very well the reason why it happens.

[Richard Burts]

Here is a link to a discussion that suggests that update group may be involved. Is it possible to test this by (temporarily) removing the update group from the config?

https://learningnetwork.cisco.com/thread/126096

I continue to wonder about the log message that makes a point that both peers are in the same subnet. Can you answer my question about whether you send advertisement to both peers or to just one? And if to just one is it always to 172.16.1.2?

HTH

Rick

[Richard Burts]

Could you post the output of the commands 

show ip bgp neighbor advertised-routes

show ip bgp neighbor received-routes

for both of the ebgp neighbors? Perhaps we might see something helpful in the output.

HTH

Rick

[madrileño18]

sh ip bgp neighbors 172.16.1.1 routes

Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 172.16.1.1 100 0 1 1 i
*> 1.1.1.1/32 172.16.1.1 100 0 1 1 ?
*> 1.1.1.2/32 172.16.1.1 100 0 1 1 ?
*> 10.2.0.0/25 172.16.1.1 100 0 1 i
*> 192.168.240.0/20 172.16.1.1 100 0 1 i
*> 172.40.10.0/25 172.16.1.6 100 0 1 1 i

Total number of prefixes 14


sh ip bgp neighbors 172.16.1.1 advertised-routes

Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 172.16.1.1 100 0 1 1 i
*> 1.1.1.1/32 172.16.1.1 100 0 1 1 ?
*> 1.1.1.2/32 172.16.1.1 100 0 1 1 ?
*> 10.2.0.0/25 172.16.1.1 100 0 1 i
*> 192.168.240.0/20 172.16.1.1 100 0 1 i
*> 172.40.10.0/25 172.16.1.6 100 0 1 1 i

Total number of prefixes 16


sh ip bgp neighbors 172.16.1.2 advertised-routes
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 172.16.1.1 100 0 1 1 i
*> 1.1.1.1/32 172.16.1.1 100 0 1 1 ?
*> 1.1.1.2/32 172.16.1.1 100 0 1 1 ?
*> 10.2.0.0/25 172.16.1.1 100 0 1 i
*> 192.168.240.0/20 172.16.1.1 100 0 1 i
*> 172.40.10.0/25 172.16.1.6 100 0 1 1 i

Total number of prefixes 16


sh ip bgp neighbors 172.16.1.2 routes

Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 172.16.1.2 200 0 1 1 i
*> 1.1.1.254/32 172.16.1.2 200 0 1 1 ?
*> 1.1.1.255/32 172.16.1.2 200 0 1 1 ?
*> 10.2.0.0/25 172.16.1.2 200 0 1 i
*> 192.168.240.0/20 172.16.1.2 200 0 1 i
*> 172.40.10.0/25 172.16.1.2 200 0 1 1 i

Total number of prefixes 14

sh ip bgp 172.40.10.0
BGP routing table entry for 172.40.10.0/25, version 27550
Paths: (2 available, best #2, table default)
Advertised to update-groups:
1
Refresh Epoch 1
1 1
172.16.1.2 from 172.16.1.2 (172.16.1.2)
Origin IGP, metric 200, localpref 100, valid, external
Extended Community: SoO:65200:6147299 RT:1:110800
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
1 1
172.16.1.6 from 172.16.1.1 (172.16.1.1)
Origin IGP, metric 100, localpref 100, valid, external, best
Extended Community: SoO:65200:6147299
rx pathid: 0, tx pathid: 0x0


*Jan 18 13:25:33.107: BGP(0): (base) 172.16.1.1 send UPDATE (format) 0.0.0.0/0, next 172.16.1.1, metric 100, path 1 1, extended community SoO:65200:6570988 RT:1:110800

*Jan 21 13:45:33.107: BGP(0): 172.16.1.1 NEXT_HOP is on same subnet as the bgp peer and set to 172.16.1.6 for net 10.1.0.0/26 flags 200, sb: 512E1000, mask: FFFFFE00



*Jan 18 15:34:51.896: BGP(0): 172.16.1.1 NEXT_HOP is on same subnet as the bgp peer and set to 172.16.1.6 for net 10.1.0.0/26, flags 200, sb: 512E1000, mask: FFFFFE00
*Jan 18 15:34:51.896: BGP(0): (base) 172.16.1.1 send UPDATE (format) 10.1.0.0/26, next 172.16.1.6, metric 100, path 1 1, extended community SoO:65200:6150833

The difference is that from the backup PE all routes are received with next-hop backup PE but this is normal. This team does not have the Peer-group configured but the same problem occurs in teams that have peer-group as those that do not

[Richard Burts]

Thank you for posting the output of the commands that I requested. They are helpful. In the original post you tell us that 

The CE receives a prefix of the neighbor eBGP (a PE) and re-announces the same prefixes, exactly the same, with the same attributes

But that is not really the case. Look closely at the output from peer 172.16.1.2. It is advertising prefixes with next hop of 172.16.1.2 but you are advertising prefixes to that peer with next hop of 172.16.1.1. So the attributes are not the same. This makes me wonder if it is indeed related to update groups. Is it possible, as a test, to remove the update groups and see if the behavior changes?

HTH

Rick

[madrileño18]

In the case of the prefixes that I exchange with the main PE, I do announce them to the PE with the same attributes as those I receive in the case of the PE that backs the announcements. In the case of backup PE, this is not the case, I advertise to PE with the attributes of the main PE. But regardless of that. The question is: because an ad that I receive from an eBGP neighbor, I announce it to the neighbor in the same way? As I understand it, BGP should not be like that.

[Richard Burts]

Can you do a test and remove the update group and see if the behavior changes?

HTH

Rick

[madrileño18]

Remove the update group and continue with the neighbor of the two PE or remove configuring the neighbor configuration with a PE?

[Richard Burts]

My suggestion is to keep both PE neighbors and simply remove the update group. Then see if the update behavior changes (which I am guessing will).

HTH

Rick

[madrileño18]

The output of the commands that I have shown you is a CE without update-group configured. The output of the commands that I have shown you is of a CE without update-group configured. The behavior does not change with update-group or without update group

[Richard Burts]

After removing the update group did you reset both of the neighbors?

HTH

Rick

[madrileño18]

I did not have to delete the update group because it was not created but I did soft in and soft out

[Richard Burts]

Thank you for the clarification. Could you post the output of show ip bgp neighbor from your router.

HTH

Rick

[pheras2004@yahoo.es]

You need all the information that shows the output of the command or only a part. Because it shows a lot of information about