Quick Routing Question

Answered Question
Jul 18th, 2008

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

I have this problem too.
0 votes
Correct Answer by Richard Burts about 8 years 4 months ago

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

Correct Answer by Richard Burts about 8 years 4 months ago

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

Correct Answer by sundar.palaniappan about 8 years 4 months ago

Ok. Let's say Router A advertises the route to C and C advertises it to B. B has two options - External EIGRP (from C) or floating static route (distance of 200) - it would choose EIGRP (distance of 170) over the static route because of the lower admin distance. Hence, all trafffic would flow through A.

If A becomes unreachable then B would start using the static route and advertise the same to C and it would become the alternate route for C till A becomes reachable again.

Your goal of trying to do primary and backup route would work in this situation excepting that C wouldn't have both routes in the routing table at any given time when B's static route is configured with a higher admin distance. If you want C learn both routes and choose one over the other or load balance the traffic then configure the static route of both A and B with the same distance or default (1).

Hope I understood your requirement correctly. If there's any part that I misunderstood please let me know what that is.

HTH

Sundar

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (6 ratings)
Loading.
sundar.palaniappan Fri, 07/18/2008 - 05:46

" 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?"

This would not be correct if all 3 routers are in the same EIGRP AS. If they are in the same AS then B would prefer the redistributed route from C as the admin distance of that route would be 170 on B (external EIGRP) and the static route on B would function as a backup route only.

Can you clarify that part?

lamav Fri, 07/18/2008 - 06:13

Sundar:

I think there is a bit of confusion about who is doing the redistributing.

A and B are the edge routers and they are redistributing a static route into eigrp. Router C sits behind them and has a 100Mbps connection to each of them.

All same eigrp AS.

Thanks

Correct Answer
sundar.palaniappan Fri, 07/18/2008 - 06:23

Ok. Let's say Router A advertises the route to C and C advertises it to B. B has two options - External EIGRP (from C) or floating static route (distance of 200) - it would choose EIGRP (distance of 170) over the static route because of the lower admin distance. Hence, all trafffic would flow through A.

If A becomes unreachable then B would start using the static route and advertise the same to C and it would become the alternate route for C till A becomes reachable again.

Your goal of trying to do primary and backup route would work in this situation excepting that C wouldn't have both routes in the routing table at any given time when B's static route is configured with a higher admin distance. If you want C learn both routes and choose one over the other or load balance the traffic then configure the static route of both A and B with the same distance or default (1).

Hope I understood your requirement correctly. If there's any part that I misunderstood please let me know what that is.

HTH

Sundar

Richard Burts Fri, 07/18/2008 - 06:52

Victor

I believe that there were 2 parts to your question. Sundar has given a very good explanation in answering the first part which deals with redistribution into EIGRP (and clarifies that a floating static on B would be effective - as long as its distance was greater than 170). The second part of the question was about some client site that is redistributing into BGP. I am not clear whether that is the same kind of issue as what Sundar discusses or whether it is different. If it is different could you give us a bit more detail about that client site issue?

HTH

Rick

lamav Fri, 07/18/2008 - 07:10

Hey, Rick. How goes it, buddy?

Yes, you are very detail oriented and I love it. Sundar set my head straight with part 1. Please feel free to read my response to him.

And as far as part 2 (BGP), I am right now going over it in my head to see if it is indeed the same type of scenario or something different. If different, I will give more details so we can knock out that piece.

Fair enough?

Victor

lamav Fri, 07/18/2008 - 07:08

Sundar:

Yes, I see now where I missed something. I forgot that C will advertise to B. And when that happens, B will not place the floating static route (AD 200) in its routing table at all because it will select C's route as the best one (AD 170). Therefore, it will never advertise the floating static to C in the first place.

MOREOVER, when A does fail, that floating static on router B will come into play, of course, and the alternate path will be set up through B.

Did I get that right?

So, then, there is indeed a good reason to configure a static and floating static on the 2 edge routers and then redistribute both of them to create primary/alternate routes.

Having forgotten that C will advertise to B, thereby forcing B to abandon its floating static and consequently NOT advertising it to C, I kept thinking C will receive both routes as external eigrp of 170 and begin load sharing.

So, the piece I missed was C advertising to B...

If I seem repitious it is because I am making sense out of it in my head as I translate my thoughts to my fingers. :-) I'm really not as insane as my words make me out to be. LOL

Let me know if I got it now, please.

Thanks

VL

sundar.palaniappan Fri, 07/18/2008 - 07:20

Victor,

Your understanding is right on the money as Rick already stated. You know repetition isn't always bad as I've been there. lol

BTW, thanks for those high scoring of our posts ;-)

HTH

Sundar

lamav Fri, 07/18/2008 - 07:35

My pleasure, Sundar. Thank you for your time and expertise.

Victor

lamav Sun, 07/20/2008 - 08:15

Hi, Rick:

OK, I finally had a chance to take a closer lok at that redistribution scenario into BGP and I see why in that case the engineer configured floating statics.

I don't want to waste your time because I figured that out already, but I do have another thing that I bet you can help me with.

I have an L3 switch running BGP in its own AS and its eBGP peering with another L3 switch in its own AS, of course.

We can call these L3 switches A and B.

B accepts BGP prefix advertisements from A but will "not advertise to any peers."

Usually I think that there is a community attribute being manipulated (no-advertise tage, for axample) which is causing the route not to be advertised. But I dont see one configured.

I know that posting the configs for both switches may be necessary, but off the top off your head, what would cause a route to not be advertised, besides a community list or other filter list to block it?

Heres the entry below from the BGP table of B.

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)

10.182.80.3 from 10.182.80.3 (10.182.80.3)

Origin incomplete, localpref 100, valid, external

ve01>

Thanks

Victor

Richard Burts Sun, 07/20/2008 - 17:49

Victor

I am glad that you figure out the BGP redistribution and floating static question (as I assumed that you would).

As to your other issue, in my experience probably the most frequent cause of "not advertised to any peer" is related to the message about Paths: (1 available, no best path) and is caused when the advertised next hop address is not reachable from the router. So I would look on B and see if 10.182.80.3 is reachable or not.

HTH

Rick

lamav Sun, 07/20/2008 - 18:02

Hi, Rick:

To answer your question, switch A is the BGP neighbor (10.182.80.3) that advertised the subnet to switch B.

Switch A(10.182.80.3) <-----eBGP Peers-----> Switch B (10.182.80.21)

I know you dont have the benefit of viewing the configs or being able to execute commands, so I will have to take the time to sanitize tne configs aand post them.

Meanwhile, I will also investigate further. I bet there is something obvious Im missing.

let me know if any other thoughts pop up in your head.

Thanks

Victor

lamav Mon, 07/21/2008 - 04:06

Good morning, Rick

I think I may have figured it out.

I think the specific prefix is "not advertised to peers" because the router is advertising an aggregate address that encompasses the subnet in question.

Check it out:

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)

10.182.80.3 from 10.182.80.3 (10.182.80.3)

Origin incomplete, localpref 100, valid, external

ve01>

ve01>

ve01>sh ip bgp nei 192.168.85.42 advertised-routes | in 172.27

*> 172.27.0.0/17 10.182.80.3 0 0 64716 i

ve01>

Take note, the 192 address is just a peer of this router that I chose at random.

I am trying to find documentation that supports this suspicion. I can say, though, that I always thought that BGP will not suppress the subnets of an aggregate route unless you specifically tell it to by using the "summary-only" keyword.

Any thoughts?

Thank you, sir.

VL

Correct Answer
Richard Burts Mon, 07/21/2008 - 04:17

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 Mon, 07/21/2008 - 04:28

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 Mon, 07/21/2008 - 05:34

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 Mon, 07/21/2008 - 08:15

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 Mon, 07/21/2008 - 08:59

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

Correct Answer
Richard Burts Tue, 07/22/2008 - 04:44

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 Tue, 07/22/2008 - 04:58

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 Tue, 07/22/2008 - 07:44

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

Actions

This Discussion