07-18-2008 05:14 AM - edited 03-06-2019 12:17 AM
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
Solved! Go to Solution.
07-21-2008 04:17 AM
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
07-21-2008 04:28 AM
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
07-21-2008 05:34 AM
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
07-21-2008 08:15 AM
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
07-21-2008 08:59 AM
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
07-22-2008 04:44 AM
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
07-22-2008 04:58 AM
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
07-22-2008 07:44 AM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: