BGP Update-Group

[Mahesh Gohil]

Hi experts,

Problem: Customer is sending some routes and PE is advertising same routes back to same CE.

Details:

> customer is having two links terming on same PE.

> both links are part of same vrf.

When we investigate we have seen  that both peer are part of same bgp update-group index (30) (because both peer is having identical config)

     ---------------------

PE                      CE

     ---------------------

#sh ip bgp vpnv4 vrf xxx update-group (IP's, AS changed)
BGP version 4 update-group 30, external, Address Family: VPNv4 Unicast
  BGP Update version : 211994649/0, messages 0
  Overrides the neighbor AS 65000 with my AS before sending updates
  Update messages formatted 1234, replicated 1812
  Number of NLRIs in the update sent: max 86, min 0
  Minimum time between advertisement runs is 0 seconds
  Has 2 members (* indicates the members currently being sent updates):
   10.10.10.1 10.10.10.5

Resolution: We have changed one line of config for one peer and now they are part of different update-group..issue resolved (now

both peer is not having identical config)

#sh ip bgp vpnv4 vrf xxx update-group

BGP version 4 update-group 30, external, Address Family: VPNv4 Unicast

  BGP Update version : 210974385/0, messages 0

  Overrides the neighbor AS 65000 with my AS before sending updates

  Update messages formatted 2417, replicated 1753

  Number of NLRIs in the update sent: max 86, min 0

  Minimum time between advertisement runs is 0 seconds

  Has 1 member (* indicates the members currently being sent updates):

   10.10.10.1

BGP version 4 update-group 169, external, Address Family: VPNv4 Unicast

  BGP Update version : 210974385/0, messages 0

  Overrides the neighbor AS 65000 with my AS before sending updates

  Outgoing update prefix filter list is rs-vpnprotect-in

  Update messages formatted 10, replicated 0

  Number of NLRIs in the update sent: max 86, min 2

  Minimum time between advertisement runs is 0 seconds

  Has 1 member (* indicates the members currently being sent updates):

   10.10.10.5

Query:

>Is this behavior ok..i mean bgp advertising prefix to peer from where it has learned. bgp ovverriding split-horizon rule.

> Is there any work around apart from what i have implemented

Hoping for detailed answer

Regards

Mahesh

[milan.kulik]

Hi Mahesh,

1) there is nothing like split-horizon in BGP, see https://supportforums.cisco.com/message/3227309#3227309 (I think you were participating in that thread?)

2) It would be nice to see the prefix details on both CE and PE before and after you implemented your config change.

IMHO, Cisco IOS has some checks which prevents sending prefixes back to the originating AS/router (as would be refused anyway) but those checks are

a) extending the BGP RFCs,

b) not published,

c) failing under some conditions (AS override might be the case)

BR,

Milan

[Mahesh Gohil]

Hello Milan,

Thanks for the reply,

I really feel uncomfortable when I see router advertising back to the one from where it is learned. I do not see any logic behind it.

Even if i implement as-override I do dot see this behavior. Before writing this I have verified no. of customers with different

config.

I know rfc doesn't talk about this split-horizon but this kind of behavior is like inviting loops

Even with RR structure which takes care of not advt. back to the router from where it is learned. I did not understand

two lines

a) extending the BGP RFCs,

b) not published

Can you eleborate more on this

REgards

Mahesh

[milan.kulik]

Hi Mahesh,

what I was trying to say was:

I believe it would be 100% OK if a router implementing  BGP just based on RFCs would advertise ALL BGP prefixes  to all his eBGP neighbors.

(And I remember 3 years ago I met a CE router with a very old IOS which was sending many prefixes back to the PE router it was receiving from.)

It would create no loops as the eBGP neighbors would see their AS numbers in the prefix AS-PATH and would ignore the looping prefixes.

IMHO, newer IOSes are having some simple checking not to advertise prefixes which would be rejected anyway. I.e., they might have a rule "don't send a prefix to a neighbor if the AS-PATH is starting with the neighbor's AS number" implemented.

Or something similar.

This is what I call "extending RFCs" - an implementation which does not break the RFC but includes some logic not described in the RFC.

But no such feature was described in any available Cisco materials - that's what I call "not published".

And still the loop detection is the receiving router responsibility!

And last but not least:

IMHO, the update group implementation might be breaking such a checking with a goal to consume less router memory - having one extra update group consumes some amount of memory.

I see in my network some prefixes being advertised back to the neighbor they were received from.

I'm not able to say why just those prefixes. I can see they are being advertised to an update group composed by two routers.

It would be interesting to split each of them to a separate  update group - probably my router would stop advertising the prefixes back.

But I can't play so much with my productive network.

I'll try to make some test in my lab "when I have so free time".

BR,

Milan

[Mahesh Gohil]

Hello Milan,

Thanks for the detailed explanation.

I have tried few test in lab without update-group but no luck. I have implemented as-override at one end and

that router do not care for advt. back to the originator (atleast debug message didn't shown any message that

it is advt. back)

as you said this behavior with old ios only and new ios may have extra check not to advt. back.

I think this is the behavior only with update-group << you already said..i am just echoing

Please let me know once you perform some tests

Regards

mahesh