EBGP

[Heinz Kern]

hello,

does anybody have any advice regarding this problem?

we have an EBGP-Session. under normal circumstances i believe that a route from an ebgp-neighbor is not send out to this neighbor again. but in our scenario this happens:

Router#show ip bgp vpnv4 vrf XXX neighbors 10.3.6.13 routes

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 10.3.120.1/32   10.3.6.13                              0 65110 65342 ?

Router#show ip bgp vpnv4 vrf  XXX neighbors 10.3.6.13 advertised-routes                                                                                    ^

  Network          Next Hop            Metric LocPrf Weight Path

*> 10.3.120.1/32    10.3.6.13                              0 65110 65342 ?

just to clarify: we don´t have a problem yet because i assume that the router on the other side (whcih is not in our responsibility) discards the route. but in any case i believe that this is an error.

we already cleared the neighbor, but the routes still remain...

[Peter Paluch · Accepted solution]

Hi Heinz,

This is puzzling - I've tested this briefly and in my quick setup, eBGP neighbors did not return back the VPNv4 routes they learned from each other.

Do you believe you could run the debug bgp vpnv4 unicast updates and clear the session with 10.3.6.13 once again? Perhaps the debug will give us some clue.

Best regards,

Peter

[Heinz Kern]

hi peter,

thanks for your effort. yes i can do that but i don´t want to do it during working hours. i will do it tomorrow morning or today in the night.

generally it´s really curious because we have a second router acting as backup with almost the same config and we don´t have this behaviour there.

i assume it´s an ebgp-rule that the routes must not be advertised to the same router back. do you know if there is any possibility in Cisco IOS to disable this rule?

[Peter Paluch]

Hi Heinz,

thanks for your effort. yes i can do that but i don´t want to do it  during working hours. i will do it tomorrow morning or today in the  night.

Of course. Thank you!

i assume it´s an ebgp-rule that the routes must not be advertised to the same router back

Strangely enough, the BGP specification in RFC 4271 does not specify any limitations in this matter whatsoever. While it is kind of logical not to advertise a route back where it came from, the BGP specification itself contains no such rule.

do you know if there is any possibility in Cisco IOS to disable this rule?

I do not know of any.

Best regards,

Peter

[Harold Ritter · Accepted solution]

Hi Heinz,

This is normal behavior and indicates that you have other neighbors in the same update-group as the current neighbor, hence the PE sending the update back to the originating CE. As you stated, the update will be denied by the CE when it detects that its own ASN is present in the AS path.

Regards

[Heinz Kern]

hi harold,

sorry but i don´t believe that an EBGP-neighbor advertises a route back to the originating router when this route is the bestpath. moreover there is only this neighbor in the peer-group (and i assume this is the same...)

something interesting i found:

non-working router:

show ip bgp vpnv4 vrf XXX neighbors 10.3.6.13

                                   Outbound    Inbound

  Local Policy Denied Prefixes:    --------    -------

    AS_PATH loop:                       n/a       2616

    Total:                                0       2616

working router:

                                   Outbound    Inbound

  Local Policy Denied Prefixes:    --------    -------

    AS_PATH loop:                       n/a       1600

    Bestpath from this peer:            234        n/a

    Total:                              234       1600

the point "bestpath from this peer is missing" in the section "local policy denied prefixes"

[Harold Ritter · Accepted solution]

Heinz,

The goal of update groups is to process an update once and to send it to all members of the update group (not peer group). So if the peer that send ud the update is a member of the update group, it will receive the update as well.

Could you please post the output for the following command:

"show ip bgp vpnv4 vrf XXX neighbors update-group"

What IOS version are you running on the PE in question?

Regards

[Heinz Kern]

now you have my attention

show ip bgp vpnv4 vrf XXX update-group summary

Summary for Update-group 22, Address Family VPNv4 Unicast

BGP router identifier 10.0.100.255, local AS number 64602

BGP table version is 309258, main routing table version 309258

14499 network entries using 2160351 bytes of memory

31145 path entries using 2117860 bytes of memory

1138/713 BGP path/bestpath attribute entries using 182080 bytes of memory

23 BGP rrinfo entries using 552 bytes of memory

286 BGP AS-PATH entries using 13700 bytes of memory

140 BGP extended community entries using 3424 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 4477967 total bytes of memory

BGP activity 34076/19537 prefixes, 182126/150901 paths, scan interval 15 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.3.6.13       4       65110 1783881 1706692   309258    0    0 3d17h          63

10.3.6.50       4       64604  195953  181174   309258    0    0 17w1d          50

and this is really different from the backup-router  (there i only have one neighbor per update-group -->so i have there  two update-groups with one neighbor per group)

hmm...why do i have two neigbors per update-groups on one side?

version is 12.2(33)SXI6

[Harold Ritter]

Heinz,

Initially in IOS, all peers part of the same VRF were placed in their own update group. CSCef70161 changed that initial behavior to allow multiple peers per update group and therefore more scalability. SXI6 does integrate this bugid, hence you seeing the two peers in the same update group. The fact that you are seeing multiple peers per update group on the other side indicates that you are not running an IOS version integrating CSCef70161.

Regards

[Heinz Kern]

i think there´s another reason for that because i´m running the same version on both sides

the router is acting as a bgp-border router. so there are a lot of bgp neighbors on this router

with "show ip bgp replication" i see all update- groups...the last one has the index "100"....so i think i ran into maximum update-groups....

there are still some old neighbors i don´t need anymore...i can delete them...do you know how often the update-groups are calculated or how i can reinitiate this process?? restart the bgp-process?

[Harold Ritter · Accepted solution]

Heinz,

With SXI6, all peers should share the same update group unless they have different outbound policies (route-map, as-override, filter-list, prefix-list, etc) apply to them. Would that be the case on the other router running SXI6.

Regards

[Heinz Kern]

yep...they have a different inbound policy but the same outbound-policy...

haha....and the backup router has different outbound policies for the two neighbors...

i´m impressed. this explains everything. so it works as designed: the update-group breaks the cisco-ebgp-rule regarding advertising the route back to the originator (which is generally not part of the RFC).

thanks very much

[Heinz Kern]

but nevertheless i beleive that there is as maximum of 100 update groups per address-family. i don´t think in a coincidence

[Harold Ritter]

Heinz,

You are very welcome. As far as the limit of 100 dynamic update groups per vrf, there is no such limit that I know of.

Regards

[Peter Paluch]

Hello Harold,

Thank you for your insightful explanation of what is going on! Dynamic update groups... I would not have thought of that. Thank you! Rated and endorsed as deserved.

One more question, though: would the same "phenomenon" be observable with update groups containing internal neighbors? I assume the iBGP rule of not advertising an iBGP-learned path to another iBGP neighbor will apply despite the dynamic update groups but I wanted to make sure here.

Best regards,

Peter