Quick Routing Question

[lamav]

Morning, folks:

If I redistribute a static route into a dynamic routing protocol, that static route will lose its AD and take on the AD of the dynamc routing protocol. Correct?

Example:

I have 2 separate edge routers (A and B) that connect to the same router (C) on the back end of it. I want to make router A the primary route to network 10.0.0.0 and router B the alternate route.

If I create a static route (ip route 10.0.0.0 255.0.0.0 192.168.1.1) on both those routers and redistribute into, say, eigrp, giving the static route on router B an AD of, say, 200, is meaningless. Correct?

I say this because each static route will be converted to an external eigrp route and take on an AD of 170. So, C will receive 2 comparable, equal-cost routes with the same AD and place both of them in its routing table. Correct?

So, if I want to make router B the alternate route, I must manipulate the seed metrics on routers A and B so that router C can receive both eigrp routes and use the metrics as the decision maker as to which route will be placed in C's routing table -- you know, the usual way it's done.

Correct?

If all this is correct, I am wondering why I see static routes being redistributed into BGP on 2 separate edge routers (at a client site) -- but one with an AD higher than the other. No BGP attributes are being manipulated at the redistribution point with, say, a route map. So, whats the point? A goof-up?

Any input?

Thanks

VL

[Richard Burts · Accepted solution]

Victor

It does appear that the more specific 172.27.88.64/27 is not advertised because of advertising the summary. In general my experience has been like yours and configuration of a summary does not necessarily suppress advertisement of the more specific routes. Without more information from the switch I am not sure that I can explain it well. Perhaps it is enough to say that the more specific is not advertised because of the summary - or perhaps you may want to post the switch config so we can dig into it more deeply.

HTH

Rick

[lamav]

Thanks, Rick, for that sanity check.

Yes, let me see if I get a chance to sanitize the config and post it.

For now, I do think we have hit the nail on the head.

Thanks

VL

[lamav]

Rick, I think I spoke too soon. Sorry. I think I have pinned down the characteristics of this "problem". Its not really a problem. This is a production env. Everything works. Just want to understand it.

Anyway, here are the pertinent configs.

Take note that Switch A advertises to Switch B and Switch B accepts that advert, but does not advertise to any peers, EXCEPT if it originated the route.

So, if Switch B has a static route that is redistributed into BGP, it WILL advertise to peers. If, however, it receives an advert from Switch A (its eBGP peer), it will NOT advertise to any peers.

SWITCH B

Switch B>sh start | be router bgp

router bgp 64726

no synchronization

bgp router-id 10.182.80.21

bgp log-neighbor-changes

redistribute static route-map VENDOR.SERVICES.NETS

neighbor BGP.STANDARD.CONFIG peer-group

neighbor BGP.STANDARD.CONFIG timers 1 3

neighbor BGP.STANDARD.CONFIG remove-private-as

neighbor BGP.STANDARD.CONFIG soft-reconfiguration inbound

neighbor BGP.STANDARD.CONFIG prefix-list DMZ.SUMMARY.NETS out

(ESM NEIGHBOR - To SWITCH A)

neighbor 10.182.80.3 remote-as 64716

neighbor 10.182.80.3 description eBGP <--> To Switch A

neighbor 10.182.80.3 ebgp-multihop 5

neighbor 10.182.80.3 update-source Loopback1

neighbor 10.182.80.3 timers 1 3

neighbor 10.182.80.3 soft-reconfiguration inbound

(ALLOWS ADVERTSIEMENTS IN FOR CERTAIN DEFINED BLOCKS)

neighbor 10.182.80.3 route-map ALLOWED.FROM.ESM in

(DEFINES BLOCKS WHOSE ADVERTISEMENTS SHOULD BE PREPENDED)

neighbor 10.182.80.3 route-map PREPEND-AS out

(TYPICAL NEIGHBOR ON THIS ROUTER)

neighbor 192.168.85.102 remote-as 64743

neighbor 192.168.85.102 peer-group BGP.STANDARD.CONFIG

neighbor 192.168.85.102 description OSC Router#2

neighbor 192.168.85.102 password dfglshgf

neighbor 192.168.85.102 prefix-list OSC.NETS in

ip prefix-list DMZ.SUMMARY.NETS seq 5 permit 10.0.0.0/8

ip prefix-list DMZ.SUMMARY.NETS seq 10 permit 170.186.0.0/16

ip prefix-list DMZ.SUMMARY.NETS seq 15 permit 172.19.0.0/16

ip prefix-list DMZ.SUMMARY.NETS seq 20 permit 172.22.0.0/17

ip prefix-list DMZ.SUMMARY.NETS seq 25 permit 172.27.0.0/17

ip prefix-list OSC.NETS seq 10 permit 172.27.85.96/27

(ROUTE ORIGINATED BY SWITCH B)

Switch B>sh ip bgp 172.27.84.64

BGP routing table entry for 172.27.84.64/27, version 2967

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

Advertised to update-groups:

5

Local

192.168.84.70 from 0.0.0.0 (10.182.80.21)

Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best

64716 64562 64725, (received-only)

10.182.80.3 from 10.182.80.3 (10.182.80.3)

Origin incomplete, localpref 100, valid, external

Switch B>

Switch B>

(ROUTE LEARNED THROUGH SWITCH A BGP)

Switch B>sh ip bgp 172.27.85.192

BGP routing table entry for 172.27.85.192/27, version 0

Paths: (1 available, no best path)

Not advertised to any peer

64716 64562 64725, (received-only)

10.182.80.3 from 10.182.80.3 (10.182.80.3)

Origin incomplete, localpref 100, valid, external

Switch B>

SWITCH A

Switch A>sh start | be router bgp

router bgp 64716

no synchronization

bgp log-neighbor-changes

aggregate-address 172.27.0.0 255.255.128.0

neighbor BGP.STANDARD.CONFIG peer-group

neighbor BGP.STANDARD.CONFIG ebgp-multihop 5

neighbor BGP.STANDARD.CONFIG update-source Loopback1

neighbor BGP.STANDARD.CONFIG timers 1 3

neighbor BGP.STANDARD.CONFIG soft-reconfiguration inbound

(NEIGHBORSHIP WITH SWITCH B)

neighbor 10.182.80.21 remote-as 64726

neighbor 10.182.80.21 peer-group BGP.STANDARD.CONFIG

neighbor 10.182.80.21 description eBGP <--> To Switch B

Let me know what you think when you get a chance.

Thank you

Victor

[Richard Burts]

Victor

On switch B would you post the route map PREPEND-AS? It is applied outbound to switch A and I would like to verify what it is doing.

HTH

Rick

[lamav]

Sure.

route-map PREPEND-AS permit 10

match ip address prefix-list L6NETS

!

route-map PREPEND-AS permit 15

match ip address prefix-list VENDOR.MGMT.NET

!

route-map PREPEND-AS permit 20

match ip address prefix-list VENDOR.NETS

set as-path prepend 64726 64726 64726

!

route-map PREPEND-AS permit 30

match ip address prefix-list DR.NETS

All it does is match certain network prefixes and then PREPENDS them in the direction of Switch A so that Switch A will NOT use switch B as a next hop.

VL

[Richard Burts · Accepted solution]

Victor

It has taken me a while to sort through this and to realize that I was not on the right path in asking about the route map PREPEND-AS. The question is not really what B advertises to A but is what B advertises to other neighbors.

So I re-evaluated what you have told us about this and see a different issue. I will start my explanation by referring to a comment in one of your posts:

"Take note that Switch A advertises to Switch B and Switch B accepts that advert"

I now believe that this is not really the case. The significant clue is in this output:

ve01>sh ip bgp 172.27.88.64

BGP routing table entry for 172.27.88.64/27, version 0

Paths: (1 available, no best path)

Not advertised to any peer

64716 64562 64725, (received-only)

In particular notice that there is no best path and notice that the prefix is marked as

received-only. I had to do some digging to find that received-only means that the policy has rejected this path. However, the router has stored the paths because you have configured soft-reconfiguration inbound for the neighbor.

So what would cause the policy to reject the path? I believe that the answer is in:

neighbor 10.182.80.3 route-map ALLOWED.FROM.ESM in

So can you post the route map ALLOWED.FROM.ESM

For details of received-only you can use this link:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

HTH

Rick

[lamav]

Rick:

Good catch.

The assumption I made was that the prefix advertisement was being received by the ve01 router when in reality, as you lucidly explained, it was not accepting it. It only placed the prefix in the BGP table because soft reconfiguration is configured and it would be necessary to have that route saved to preclude the need for a totally new exchange of prefix advertisements.

And yes, that route map you mention does indeed reference an as-path access filter that denies any traffic that has passed through AS 64725, which is the AS that originates that route in the first place.

AS 64725 is our primary DC and ve01 sits in our DR site. So, routes originated in primary DC should not be advertised by routers sitting in the DR site and vise versa.

Awesome!

But I'm really stupid because I saw that as-path filter and I even made sense of what it is doing, but I didnt put 2 and 2 together because I had the notion that the router IS accepting all adverts from the ESM router stuck in the back of my mind because it was in the BGP table -- forgetting about the effects of configuring soft reconfig inbound.

So, a big "DUH!" for me and kudos to you, my friend.

Thank you very much.

Victor

[Richard Burts]

Victor

Thank you for the compliment (and for the ratings). It was a very subtle issue and I am glad that I tracked it down. I would not categorize this as a "DUH". One of the things that keeps me active in the forum is the occasional question which challenges me to think hard to be able to find the solution. This was one of those. And those are not "DUH" issues.

HTH

Rick