Route Reflection bug (possibly?)

[michaelterrero]

using the c7200-adventerprisek9-mz.152-4.S6 on my lab it was noted, using "debug ip bgp vpnv4 unicast updates" and packet captures that the route reflector reflects back the routes from "client A" back to "client A". This occurs when the BGP session is established under the new rtfilter unicast address-family (AFI/SAFI 1/132).

has anyone seen this? possibly bug? is there something that I misconfigured to make the RR ignore the rules of route reflection lol

 I  currently have a TAC case open with cisco.

attached is a packet capture were you can see

items # 11 and 12

RR = 1.1.1.1

Client = 2.2.2.2

# 11 update from client (2.2.2.2) to RR (1.1.1.1) the update messages with all the prefixes announced sourcing from the client

# 12 an update message is sent from RR to client its own prefixes. (the other 3 prefixes are from client B (3.3.3.3))

attached is also the output from the a updates debug

[Vasilii Mikhailovskii]

Hello.

What is your MP-BGP configuration? do you test it on real hardware or in GNS?

Could you please share your ticket number?

[Vasilii Mikhailovskii]

Hello.

I found the configuration you were using to observe the behaviour. And I would say, that it's the same with and without rtfilter capability.

In your topology RR (1.1.1.1) has 2 clients - 2.2.2.2 and 3.3.3.3

The RR is using a single vpnv4 update group to send updates to the clients - check command "sh bgp vpnv4 uni all update-group" - to optimize update processing. As a result it sends update into update-group -> means to 2.2.2.2 as well; but it's not an issue, as 2.2.2.2 has capability to drop the update.

The workaround (for your lab) - force 3.3.3.3 to join another update-group with command

address-family vpnv4 uni
 nei 3.3.3.3 advertisement-interval 1

(reset the peer and check if 3.3.3.3 has been put into different update group than 2.2.2.2 - then test your updates).

PS: The only case when this could be an issue - if you use as-override for multiple clients (and they are grouped into single update-group).