Wierd eBGP advertisements

[john.dean]

I have a router ( in one AS) that is advertising the routes that it learned from a peer (in another AS) back to that same peer. ( it should only be advertising 11 prefixes that originate within

If you look at the output below, the next hop that is being advertised to the peer is the peer's own IP address!!!

I am uncertain as to why this would ever happen. It seems totally illogical to me. I have tried resetting the peer and clearing bgp/route/igp tables but it just does not go away.

Any ideas?

sample output (edited)

<paste>

#sh ip bgp summ

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

68.137.230.101 4 65000 135841 138948 46252 0 0 1w0d 1050

#sh ip bgp nei 68.137.230.101 advertised-routes

BGP table version is 46252, local router ID is 10.48.0.9

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

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

Originating default network 0.0.0.0

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/13 68.137.230.101 0 65000 65180 i

*> 10.0.0.0/9 0.0.0.0 0 32768 i

*> 10.8.0.0/16 68.137.230.101 0 65000 65180 i

*> 10.16.0.0/16 68.137.230.101 0 65000 65030 i

*> 10.16.0.0/15 68.137.230.101 0 65000 65030 i

*> 10.17.0.0/16 68.137.230.101 0 65000 65030 i

*> 10.28.16.0/20 68.137.230.101 0 65000 65180 i

*> 10.28.252.3/32 68.137.230.101 0 65000 64924 i

*> 10.30.4.0/23 68.137.230.101 0 65000 65222 i

[etc...]

</paste>

[Giuseppe Larosa]

Hello John,

what is the output of

sh ip bgp n 68.137.230.101 received-routes

I hope it can be an error in CLI providing the output of one command for another.

May you check on the other router if actually receives these advertisements ?

Hope to help

Giuseppe

[Richard Burts]

I think it might also be helpful if John would post the BGP portions of the configuration of his router.

HTH

Rick

[john.dean]

yes - i am receiving all those routes from the peer

i do not have access to the peer - it is a provider router

router bgp 65010

no synchronization

bgp log-neighbor-changes

network 10.0.0.0 mask 255.128.0.0

network 10.48.0.0 mask 255.252.0.0

network 10.128.0.0 mask 255.128.0.0

network 10.224.0.0 mask 255.248.0.0

network 144.15.0.0 mask 255.255.128.0

network 144.15.68.29 mask 255.255.255.255

network 144.15.128.0 mask 255.255.128.0

network 172.16.0.0 mask 255.248.0.0

network 172.24.0.0 mask 255.248.0.0

network 172.25.74.0 mask 255.255.255.0

network 172.25.75.0 mask 255.255.255.0

network 192.168.0.0 mask 255.255.128.0

network 192.168.128.0 mask 255.255.128.0

neighbor 68.137.230.101 remote-as 65000

neighbor 68.137.230.101 description Verizon-MPLS-BGP_Peer

neighbor 68.137.230.101 password

neighbor 68.137.230.101 version 4

neighbor 68.137.230.101 send-community

neighbor 68.137.230.101 default-originate

no auto-summary

[Giuseppe Larosa]

Hello John,

you cannot access the peer so you cannot be sure that these prefixes are actually advertised back to it.

The impact of this should be limited because the peer should drop these routes.

You say the peer is a provider router, Verizon I see in the description, but AS 65000 is a private-as.

My guess is that your peer is using a feature called local-as: it is pretending to you over the EBGP session to be part of private AS 65000 but if it is a real MPLS PE node it should be member of one ASes of Verizon.

In order to be sure that you don't send back these prefixes you can implement an output filter using a prefix-list:

you need to allow

the default route you are sending out and the prefixes that are configured in the network commands

ip prefix-list To_Verizon seq 5 permit 0.0.0.0/0

ip prefix-list To_Verizon seq 10 permit 10.0.0.0/9

ip prefix-list To_Verizon seq 20 permit 10.128.0.0/9

ip prefix-list To_Verizon seq 20 permit 10.48.0.0/14

and so on

then

router bgp 65000

neighbor 68.137.230.101 prefix-list To_Verizon out

!

clear ip bgp 68.137.230.101

then issue again the

sh ip bgp n 68.137.230.101 advertised-routes

and see what declares

with this experiment you can understand if the show output is meaningful or not.

Hope to help

Giuseppe

[john.dean]

Since this is not a transit AS there is a simpler solution. Filter any route that does not originate in the local AS.

ip as-path access-list 99 permit ^$

ip as-path access-list 99 deny .*

router bgp 65010

neighbor 68.137.230.101 filter-list 99 out

After applying this filter, the advertised routes output looks correct - so i do not think this is a CLI output issue as you suggest.

HOWEVER, the intent of the post was to understand WHY this strange advertisement is happening, not simply to stop it.

If you look back at the original post there is nothing to explain the observed behavior.

In effect the conversation is....

"Hello Giuseppe, this is John. I have a bunch of routes for you to learn and the next hop for all of them is YOU, Giuseppe. "

I don't believe these routes are being learned form any other source than the eBGP peer in question, otherwise the next hop would be different.

So if anyone has any more ideas on what might be happening, I am listening.

[CriscoSystems]

Does your local router also have these routes from other sources, like a backup ISP?

'Cause I mean if it's advertising routes it learned from 68.137.230.101 right back to it, how come there are additional AS'es in the paths it's advertising?

[EDIT: Wait wait, duh; those are the AS paths in the routes that 68.137.230.101 was advertising in the first place... DER. (I wish this board would let us delete our own posts instead of just edit them.)]

[csco10716389]

You need to analyse the topology if posible please share,Origin is somewhere again connected to the other AS from where has is again getting the routes.