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.

[paul driver]

Hello

not so sure I understand this- you are saying that you receive an external prefix and then your ce rtr  re-advertises it?

[madrileño18]

If that is. The CE receives it through eBGp and re-announces it to the Pe, which is the same team that has been announced to CE. The CE receives the prefix 1.1.1.1 by eBGP from the PE and returns it to the PE exactly as it has received it.

Sorry but it's difficult for me to explain it in English.

[madrileño18]

But it happens in some teams and others not even with the same model, the same version of equipment and with a similar configuration.
Is there a case in which a team can send to its peer by EBGP the same prefixes that the peer has sent?

[xAdventix]

Can you send us the configuration, this may be easier to understand. 

[madrileño18]

I can not send the configuration but nothing special is a session bgp with another AS and with route maps that filter in the neighbor that in the CE because the PE is from the provider.
But without seeing the configuration, is there any reason why a peer re-announces the prefixes that the neighbor announces to the same neighbor that sent them? In other words, the PE sends 10 prefixes to the CE and the CE sends them back to the PE with the same prefixes plus the ones that the CE originates.

[Richard Burts]

The behavior you describe of receiving a routing update via EBGP and advertising those received prefixes back to the originator of the advertisement is quite unusual. It suggests that something is hiding or is changing the AS of the advertising router. Without seeing the BGP configuration it is difficult to know what might be doing that. Is it possible to post output of show ip bgp identifying that prefixes involved?

HTH

Rick

[madrileño18]

Does not matter that I change the real ip addresses? When I debug ip bg update in those who have the behavior that I describe, I get this message, which does not appear in those with normal behavior.

* Jan 8 12: 04: 03.456: BGP (0): 172.16.1.1 NEXT_HOP is on same subnet as the bgp peer and set to 172.16.1.1 for net 192.168.240.0/20, flags 200, sb: 512E1000, mask: FFFFFE00

[Richard Burts]

You ask if it matters if you have changed the real ip addresses. I have experienced examples where clumsy efforts to change the addresses have made it much more difficult to understand the problem. I do understand the need to protect your network and that disguising the address may be needed. So I suggest some approaches to changing addresses in posting your problem:

- prominently proclaim that addresses have been changed and that addresses in the post are not really the correct addresses.

- keep it in the same class of address (class A changes to some other class A, class B to class B, class C to class C).

- if the address is a public IP change it to some other public IP. If the address is a private address - then why change it at all.

The message that you have included is quite interesting.

NEXT_HOP is on same subnet as the bgp peer

What can you tell us about the topology of this network, and especially what can you tell us about 172.16.1.1 ? 

HTH

Rick

[madrileño18]

The ip 172.16.1.1 is the PE, the topology is typical of an MPLS-VPN network the CEs are connected to the PE directly through a metropolitan ethernet network and both the CE and the PE are in the same vlan and the same subnet .

The outputof  show ip bgp is 

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

The neighborhood with the Pe has configured allowas-in that may be the problem.

The ip 172.16.1.1 originally is a public ip

The address 192.168.240.0/20 that is the LAN that has not changed

[madrileño18]

To compare with one that works well I put another capture. The difference I see is that the connection to the PE is with a private ip.

sh ip bgp 192.168.240.0
BGP routing table entry for 192.168.240.0/20, version 4665
Paths: (2 available, best #2, table default)
Advertised to update-groups:
2
Refresh Epoch 1
1 1
10.120.1.2 from 10.120.1.2 (10.120.1.2)
Origin incomplete, metric 200, localpref 200, valid, external
Extended Community: SoO:65200:5240938 RT:1:110800
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
1 1
10.120.1.1 from 10.120.1.1 (10.120.1.1)
Origin incomplete, metric 100, localpref 200, valid, external, best
Extended Community: SoO:65200:5240938 RT:1:110800
rx pathid: 0, tx pathid: 0x0

[madrileño18]

This is another capture of one of the computers in which it does not work.

This line is a capture of the prefix that is announced from the CE
  Network Next Hop Metric LocPrf Weight Path
  *> 192.168.240.0 172.16.1.1 100 200 0 1 i

This is a capture of the predicted as I receive it
sh ip bgp 192.168.2404.0
BGP routing table entry for 192.168.240.0/20, version 5340
Paths: (2 available, best # 2, table default)
   Advertised to update-groups:
      two
   Refresh Epoch 1
   one
     172.16.1.2 from 172.16.1.2 (172.16.1.2)
       Origin IGP, metric 200, localpref 200, valid, external
       Extended Community: RT: 1: 1000
       rx pathid: 0, tx pathid: 0
   Refresh Epoch 1
   one
     172.16.1.1 from 172.16.1. (172.16.1.)
       Origin IGP, metric 100, localpref 200, valid, external, best
       Extended Community: RT: 1: 1000
       rx pathid: 0, tx pathid: 0x0

[Richard Burts]

So you are receiving the same prefix advertised by 2 EBGP peers and sending an advertisement of that prefix back. Are you sending the advertisement to both peers or to just one peer? And if to just one peer then is it being sent to 172.16.1.2?

HTH

Rick

[madrileño18]

The prefixes are received and sent in the two peers.
The CEs are in the same subnet as the PEs. Although they have not created the peer group, they still receive and send the prefixes in the two peers with ip 172.16.1.1 the main PE and 172.16.1.2 the backup PE