Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

EBGP

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...

4 ACCEPTED SOLUTIONS

Accepted Solutions
Cisco Employee

EBGP

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

Cisco Employee

EBGP

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

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Cisco Employee

Re: EBGP

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

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Cisco Employee

Re: EBGP

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

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
15 REPLIES
Cisco Employee

EBGP

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

New Member

EBGP

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?

Cisco Employee

EBGP

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

Cisco Employee

EBGP

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

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
New Member

EBGP

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"

Cisco Employee

Re: EBGP

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

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
New Member

EBGP

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

Cisco Employee

EBGP

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

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
New Member

EBGP

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?

Cisco Employee

Re: EBGP

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

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
New Member

EBGP

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

New Member

EBGP

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

Cisco Employee

EBGP

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

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Cisco Employee

EBGP

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

Cisco Employee

EBGP

Hi Peter,

The behavior would not be seen with a dynamic update group with ibgp neighbors, unless of course the router in question is configured as a RR, in which case you would see an update received from one RRC being reflected to all dynamic upgrade group members including the originating RRC. The RRC would then see its originator id and drop the update.

Regards

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
315
Views
5
Helpful
15
Replies