BGP advertising learned from provider - back to the provider itself

[rahul nair]

Hi guys,

I have come across a peculiar scenario in which my Campus Edge router is learning routes from my MPLS provider through an eBGP neighbourship. 

Most of these routes can only be learnt through the provider router and no where else. 

The funny thing is i can see my router advertising the same prefix ( which is being learnt from the MPLS neighbor) back to the same neighbor. Is that normal ? 

For instance this network is from the " show ip bgp " command output. 

*> 1.6.36.32/32   152.181.87.9   0    65000 64802 64820 ?

Now if we look at the "show ip bgp neighbor 152.181.87.9  advertised-routes" output - i can still find the same prefix being advertised. 

*> 1.6.36.32/32   152.181.87.9  0   65000 64802 64820 ?

Am i missing something here ? I am sure that the MPLS provider would be rejecting these routes because of the presence of their AS path ( 65000) - but still is it normal for BGP to do this ?

[balaji.bandi]

we need information to understand your BGP Arrangement with Provider

show us some more configuration and IP information.

1.6.36.32/32  <<-- what is this IP ? you after 

[rahul nair]

Hi Thanks for the reply.

1.6.36.32/32 is a network advertised from our US office. ( It is just an example in this case - there are more than 6000 routes with the same behaviour)

The bgp configuration is as follows.

router bgp 65210
bgp router-id 10.237.255.240
bgp log-neighbor-changes
network 10.237.255.240 mask 255.255.255.255
timers bgp 10 30
neighbor 10.237.255.17 remote-as 65209
neighbor 10.237.255.17 description INTNE-S-RT100
neighbor 10.237.255.18 remote-as 65209
neighbor 10.237.255.18 description INTNE-S-RT101
neighbor 10.237.255.18 ebgp-multihop 2
neighbor 152.181.87.9 remote-as 65000

!

[Martin L]

Yes, you will see those same routes being send back under some circumstance.
BGP loop prevention mechanism are AS path and sort of "split-horizon" for iBGP. Your eBGP neighbor should not reject that route based on AS number.
I think u have iBGP peers, so route is coming back. anytime u have dual eBGPs or internal iBGPs, u may have duplicate routes in bgp table ( twice amount of routes).

In case of MPLS setup, you will ended up with 2x amount of routes if u have import both or import x and export x,  meaning u do importing and exporting RTs - even if u have different or same RDs.

Regards, ML
**Please Rate All Helpful Responses **

[Giuseppe Larosa]

Hello Rahul,

can you post also

show ip bgp 1.6.36.32

so that we can see if your router is learning other BGP advertisements for the same prefix.

Hope to help

Giuseppe

[rahul nair]

Hi All,

Thanks for your replies.

Posting the output for show ip bgp 1.6.36.32 below.

INTNE-S-RT10#show ip bgp 1.6.36.32
BGP routing table entry for 1.6.36.32/32, version 56303
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
65000 64802 64820
152.181.87.9 from 152.181.87.9 (152.164.136.9)
Origin incomplete, localpref 100, valid, external, best
Extended Community: RT:65000:4728
rx pathid: 0, tx pathid: 0x0

Anything abnormal in this @Giuseppe Larosa ?

[Giuseppe Larosa]

Hello Rahul,

there is only one path to this destination and it is an eBGP advertisement via 152.181.87.9.

However, I have two notes for you:

if this is a conventional eBGP session in address-family ipv4 unicast you should not receive the extended community from the peer as this is to be sent on AF VPNv4 inside the provider network.

>> Extended Community: RT:65000:4728

You should not receive this unless the peer has configured send-community both on  session to your router.

b) the router declares to advertise the prefix to update-group 2

>> Advertised to update-groups:
2

Can you post

show ip bgp update-group 2

to see if ISP eBGP next-hop is listed in this group or only iBGP peers are listed.

Hope to help

Giuseppe

[rahul nair]

Hi,

Thanks a lot @Giuseppe Larosa .

I did not understand your first point well . ( my knowledge base in MPLS/service-provider stuff is limited ).

But you are right in pointing out that the prefix is being learnt "only from one source" - and it also being advertised to that source ! Doesn't eBGP's split horizon work like the other routing protocols ? Or am i right in understanding that, the only criteria which matters in eBGP is the "best path" and my router will advertise the best patch back to source - and it is responsibility of the receiver to drop it  ?!

BTW , please find the output below. 

INTNE-S-RT10#show ip bgp update-group 2
BGP version 4 update-group 2, external, Address Family: IPv4 Unicast
BGP Update version : 60684/0, messages 0
Topology: global, highest version: 60684, tail marker: 60684
Format state: Current working (OK, last minimum advertisement interval)
Refresh blocked (not in list, last not in list)
Update messages formatted 3066, replicated 9116, current 0, refresh 0, limit 2000
Number of NLRIs in the update sent: max 941, min 0
Minimum time between advertisement runs is 30 seconds
Has 3 members:
10.237.255.17 10.237.255.18 152.181.87.9

[Giuseppe Larosa]

Hello Rahul,

your device should not send back the BGP prefix to the eBGP neighbor that is currently the best path.

But it is doing it as it is listed in BGP update-group 2.

>> I did not understand your first point well . ( my knowledge base in MPLS/service-provider stuff is limited ).

A BGP extcommunity of type RT = route-target provides a "color" to the route and it is used within an MPLS service provider to decide if a VPNv4 prefix should be imported in a local VRF or not.

The ISP should not send this attribute to you, because your router doesn't need it. It is useful only within their internal network.

However, the presence of the RT attribute is the only strange thing about the received prefix.

I am not able to say that is the root cause for the strange behaviour of your router, but I don't see any other misleading info in the received BGP advertisement.

Hope to help

Giuseppe