BGP Behaviour

[ccnak1ing]

This is more of a cosmetic issue than an actual fault

I have 3 devices A, B & C.
A & B are ebgp neighbors, C & B are also ebgp nei
A sends 3 prefixes to B while C sends 1620 to B
B sends all 1620 + 3 routes to both neighbors A & C

I know BGP will forward learnt prefixes to peers and if peers see their AS number in the AS path they ignore the prefix.

My question: is there any way to stop B from sending back to A & C the prefixes it has already learnt from them? this will make troubleshooting much easier I guess.

[Jon Marshall]

Are A & C in the same AS ?

Jon

[ccnak1ing]

No, A is a WAN distribution device while B is my edge device peering with C which is my ISP edge device.

[Jon Marshall]

Then why should B advertise A's routes back to A ? and the same question for C ?

Jon

[ccnak1ing]

That's my question and how to stop this from happening as i only want to see in B's advertise routes to C routes learnt from A and vice versa

[Jon Marshall]

Sorry, i shoud have been more specific. An EBGP peer does not advertise the networks it learns from one peer back to that same peer.

So if A advertises routes to B then B doesn't advertise them back to A unless you have somehow setup a redistribution loop somewhere.

B should advertise A's routes to C and C's routes to A but not A+C's routes to A & C.

How have you got this configured.

Jon

[milan.kulik]

Hi Jon,

ad "An EBGP peer does not advertise the networks it learns from one peer back to that same peer."

I know BGP works this way.

But I tried to find this statement in several documents and books and failed :-(

Is it specified in some BGP RFC?

Thanks,

Milan

[Jon Marshall · Accepted solution]

milan.kulik wrote:
Hi Jon,
ad "An EBGP peer does not advertise the networks it learns from one peer back to that same peer."
I know BGP works this way.
But I tried to find this statement in several documents and books and failed :-(
Is it specified in some BGP RFC?
Thanks,
Milan

Milan

Good point. I don't know is the short answer, i was just going off practical experience. Would seem a bit stupid if they did keep readvertising each others networks back and forth

Perhaps a lab is called for !

Jon

[Giuseppe Larosa]

Hello Milan,

>> Is it specified in some BGP RFC?

not in a direct way but:

>>

One of the most important path attributes is the AS-PATH. AS
   reachability information traverses the Internet, this information is
   augmented by the list of autonomous systems that have been traversed
   thus far, forming the AS-PATH.  The AS-PATH allows straightforward
   suppression of the looping of routing information. In addition, the
   AS-PATH serves as a powerful and versatile mechanism for policy-based
   routing.

RFC 1774

Hope to help

Giuseppe

[milan.kulik]

Hi Giuseppe,

there was another thread here recently discussing "why does a BGP router send updates containing the neighbors AS within the AS_PATH?".

https://supportforums.cisco.com/message/3042419#3042419

And the conclusion was it's each BGP router responsibility to drop such updates.

I've found in RFC 1771:

"A BGP speaker must never advertise an address of a peer to that peer as a NEXT_HOP, for a route that the speaker is originating. A BGP speaker must never install a route with itself as the next hop."

I'd say that's what a had been asking for, but the "for a route that the speaker is originating" is confusing me again (English is not my native language).

Routes received from the neighbor are not originated by the speaker, so it seems they could be advertised back...:-(

@Jon:

This is something on my "when I have some time" list since the first time I read about the dynamic update-group Cisco feature.

I always thought "If an update group means all the members are receiving identical updates, how does the BGP router filter out the routes received from a particular router not to send them back?"

Is it possible the Output Policy Engine on a Cisco router is making this check - not mentioned explicitely anywhere?

The only document which mentioned this rule I found is the famous "Internet Routing Architectures - 2nd Edition" book.

I found there on page 294:

"Note in Example 11-35 that 192.68.10.0/24 is actually learned via two different paths,

whereas 192.68.11.0/24 is learned via a single path. This might seem misleading, but actually

routing is doing the right thing. In this situation, RTF has decided that the best path to reach

192.68.11.0/24 is via RTA (check RTF's BGP table in

Example 11-34). This is why RTF will

not advertise network 192.68.11.0/24 back to RTA and why RTA will have a single entry for

192.68.11.0/24."

BR,

Milan

[ccnak1ing]

I'm running mpls and have vrfs/vpns config'd on A and B, my ISP manages C. C is in an AS300 that connects all my other sites together so site-to-site comms goes thru C.

A-->B-->C-->D-->E

Config on A (AS100)
===================
router bgp 100
..
..
address-family ipv4 vrf Global_A
redistribute connected
neighbor 200.200.200.2 remote-as 200
neighbor 200.200.200.2 activate
neighbor 200.200.200.2 soft-reconfiguration inbound

Config on B (AS200)
===================
router bgp 200
..
..
address-family ipv4 vrf Global                                          
redistribute connected                                                       
neighbor 100.100.100.1 remote-as 100
neighbor 100.100.100.1 activate                                                
neighbor 100.100.100.1 soft-reconfiguration inbound                            
neighbor 300.300.300.3 remote-as 300                                         
neighbor 300.300.300.3 activate                                               
neighbor 300.300.300.3 soft-reconfiguration inbound      

RTB#sh ip bgp vp vrf Global sum
..
Neighbor        V  AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
100.100.100.1   4 100   115    112        914    0    0   1w0d                      3
300.300.300.3   4 300   103    116        914    0    0   1w4d                     1620 

RTB#sh ip bgp vp vrf Global nei 300.300.300.3 received-routes | i Total            
Total number of prefixes 1620                                                  
RTB#sh ip bgp vp vrf Global nei 300.300.300.3 advertised-routes | i Total          
Total number of prefixes 1623
RTB#sh ip bgp vp vrf Global nei 100.100.100.1 received-routes | i Total            
Total number of prefixes 3                                                  
RTB#sh ip bgp vp vrf Global nei 100.100.100.1 advertised-routes | i Total          
Total number of prefixes 1623

[Giuseppe Larosa · Accepted solution]

Hello CCnak1ing,

Neighbor        V  AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down   State/PfxRcd
100.100.100.1   4 100   115    112        914    0     0   1w0d                      3
300.300.300.3   4 300   103     116        914    0    0   1w4d                     1620

RTB#sh  ip bgp vp vrf Global nei 300.300.300.3 received-routes | i  Total            
Total number of prefixes  1620                                                  
RTB#sh ip bgp  vp vrf Global nei 300.300.300.3 advertised-routes | i Total          
Total  number of prefixes 1623
RTB#sh ip bgp vp vrf Global nei  100.100.100.1 received-routes | i Total            
Total number of  prefixes 3                                                  
RTB#sh  ip bgp vp vrf Global nei 100.100.100.1 advertised-routes | i  Total          
Total number of prefixes 1623

this doesn't mean that the 3 additional prefixes are coming from neighbor 100.100.100.1 you have a redistribute connected in BGP Address family ipv4 vrf Global so I would expect those three routes are connected

address-family ipv4 vrf Global                                           
>>> redistribute  connected                                         

neighbor  100.100.100.1 remote-as 100

post sh ip route vrf Global connected

if you have 3 prefixes you should be fine

Hope to help

Giuseppe

[ccnak1ing]

that's correct for 100.100.100.1 but still doesn't explain why it's readvertising 1623 routes to 300.300.300.3.  I'm looking at implementing the following filter list:

neig 300.300.300.3 filter-list 1 out

ip as-path access-list 1 deny ^3_ 
ip as-path access-list 1 permit ^1_
ip as-path access-list 1 permit ^$

As i'm redistributing connected I don't think I need to advertise the /30 networks

[Giuseppe Larosa]

Hello Ccnak1ing,

clearly 300.300.300.3 is not an IPv4 address but just a placeholder.

>> but still doesn't explain why it's readvertising 1623 routes to  300.300.300.3.

locally generated BGP routes have empty AS path as seen on local node:

>> ip as-path access-list 1 permit ^$

this line allows locally injected routes so you see 1623 routes sent to "300.300.300.3"

the neighbor will see an AS path = ASN of local node

Hope to help

Giuseppe

[ccnak1ing]

Thanks to all who contributed to answering this post, I found all very useful.  I set up a lab scenario for this and got the same result of routes being readvertised to Router B however B dropped these routes as it's as was in the as path.  When I implemented the filter list on A and C only the connected and locally generated routes were sent.