Solved: Re: BGP Advertisement Question

lamav · ‎03-13-2009

I have a question regarding BGP advertisements.

I have an iBGP peer whose parameters are the following:

router bgp 65000

no synchronization

bgp log-neighbor-changes

network 0.0.0.0

timers bgp 15 45

neighbor AS65000 peer-group

neighbor AS65000 remote-as 65000

neighbor AS65000 password 7 02000B490F0408310C

neighbor AS65000 update-source Loopback0

neighbor AS65000 next-hop-self

neighbor AS65000 route-map Ford-Internal-Routes-Only out

neighbor AS65000 maximum-prefix 50000 80

neighbor 19.213.1.130 peer-group AS65000

According to this config, the next-hop that should be advertised by this router to iBGP peer 19.213.1.130 is itself.

But thats not the case. This router is acting in the classic BGP fashion, where it learns of a prefix through eBGP and passes the prefix on to its iBGP neighbor with the originating router as the next-hop.

ecc#sh ip bgp nei 19.213.1.130 advertised-routes

BGP table version is 34095654, local router ID is 19.213.1.2

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

S Stale

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

Network Next Hop Metric LocPrf Weight Path

*> 0.0.0.0 19.213.2.106 0 32768 i

*> 4.37.104.132/32 19.213.2.18 20 0 65300 ?

*> 8.17.200.208/28 19.213.2.18 20 0 65300 ?

ecc#sh ip bgp 4.37.104.132

BGP routing table entry for 4.37.104.132/32, version 30991629

Paths: (3 available, best #2, table Default-IP-Routing-Table)

Advertised to update-groups:

2 3 4 5

65300

19.213.2.26 from 19.213.2.26 (19.211.4.2)

Origin incomplete, metric 20, localpref 100, valid, external

65300

19.213.2.18 from 19.213.2.18 (19.211.4.1)

Origin incomplete, metric 20, localpref 100, valid, external, best

65300

19.213.1.1 (metric 130816) from 19.213.1.1 (19.213.1.1)

Origin incomplete, metric 20, localpref 100, valid, internal

ecc#

ecc#sh ip ro 4.37.104.132

Routing entry for 4.37.104.132/32

Known via "bgp 65000", distance 20, metric 20

Tag 65300, type external

Last update from 19.213.2.18 1w5d ago

Routing Descriptor Blocks:

* 19.213.2.18, from 19.213.2.18, 1w5d ago

Route metric is 20, traffic share count is 1

AS Hops 1

Route tag 65300

ecc#

So, notice that ECC learned of this 4.x.x.x prefix from an eBGP neighbor with a next-hop of 19.213.2.18, and it is that next-hop that it passes on to its iBGP neighbor 19.213.1.130.

Why?

What am I missing -- besides a brain?

Victor

Edison Ortiz · ‎03-13-2009

Victor,

You won't be able to see the attribute modified on the source router. The attribute is modified as it leaves the router. To verify your suspicion, I recommend checking the receiving router.

Same logic applies when setting an as path-prepend. You don't see the as-path added on the advertised routes, right?

HTH,

__

Edison

View solution in original post

Edison Ortiz · ‎03-13-2009

Victor,

You won't be able to see the attribute modified on the source router. The attribute is modified as it leaves the router. To verify your suspicion, I recommend checking the receiving router.

Same logic applies when setting an as path-prepend. You don't see the as-path added on the advertised routes, right?

HTH,

__

Edison

lamav · ‎03-13-2009

Gotcha!

Thanks, buddy. Youre right.

I would have thought that way if there were an outbound policy attached to the neighbor statement, such as a route map, prefix list, etc. I didnt think that next-hop self would also behave that way.

Thanks again