BGP - 3 isps, 1 router doesn't want to play nicely..

Answered Question
Sep 29th, 2003

I have 3 local routers connecting to 3 diff providers. All 3 connected with ibgp just fine, sharing all the routes. Router 1 and 2 also connected to the isp with ebgp and get routes just fine.

Now when Router 3 connects to it's isp, it establishes and gets all the routes from it's ISP, but then the ibgp to that router goes all wierd.. All the ibgp routers send withdrawl updates, and removes all the routes, then resends them all again. Over and over, sends/withdraws.

However the bgp connection never goes down between it and the ibgps, and the connection between Router 3 and the isp peer doesn't go down and the routes stay.

Ideas?

I am using basic config of:

neighbor <ibgprouter> remote-as 1

neighbor <ibgprouter> remote-as 1

neighbor <isprouter> remote-as 2

Please any suggestions?

I have this problem too.
0 votes
Correct Answer by ruwhite about 10 years 6 months ago

Second Question:

Can you point me to a sample config on how to have routes going to a certain AS take the path out a certain router?

--

There aren't any that I know of, or that I could fine by poking around the CCO docs.... What you want to do is to use an as path access-list to match on each provider, and then set the local preference for a match. So, say your two providers are AS65000 and AS65001, and you want to push some of the traffic over to AS65000. You can make it so AS65000 is preferred for 3 hop paths, even if the connection through AS65001 is normally preferred:

ip as-path access-list 100 permit ^[0-9]*$

ip as-path access-list 100 permit ^[0-9]*_[0-9]*$

ip as-path access-list 100 permit ^[0-9]*_[0-9]*_[0-9]*$

!

route-map prefer65000 permit 10

match as-path 100

set local-preference 110

!

router bgp x

neighbor x.x.x.x remote-as 65000

neighbor x.x.x.x route-map prefer65000 in

(from memory, not on a router, so I could have something wrong here)

This should match any routes of three AS hops, and force them to go through AS65000, even if you have a two hop route going through AS65001. You can adjust the outbound traffic by adjusting the number of [0-9]*_'s included in the as path access list--two, and it should prefer any two hop as paths to go through AS65000, three for any three hop paths, etc. So, for instance, if you want to influence more distant networks, where there's less likelihood of suboptimal routing, then add statements with 3 and 4 [0-9]*_'s.

I hope this makes sense....

:-)

Russ.W

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4 (2 ratings)
aretana Mon, 09/29/2003 - 12:31

Turn syncronization off: "no sync" under router bgp.

By default, the BGP process tries to find a matching route in the routing table (from an IGP) to validate the routes...if that doesn't happen then the routes are removed from the table. It is common for an ISP to announce a block that covers the next-hop...this contributes to seeding the behavior you're seeing: the routes get installed (using the BGP route to resolve the next-hop), but then they get withdrawn because the next-hop is no longer rechable (outside BGP), etc...

'no sync' should solve the problem. ;-)

Alvaro.

gskhanna Mon, 09/29/2003 - 12:40

Actually sorry I forgot to put that here.

router bgp 1

neighbor remote-as 1

neighbor remote-as 1

neighbor remote-as 2

no synchronization

bgp log-neighbor-changes

no auto-summary

i have that set allready also.

I do not have the neighbor command with the next-hop-self, But that should not affect this config i'd think.

aretana Mon, 09/29/2003 - 12:51

If 'no sync' is already there (in all routers), then...

Setting the next-hop to self assures that the next-hop is known via the IGP. If the next-hop is not known via the IGP *and* (as I mentioned in my last post) a route from this ISP covers the next-hop, then you can get the bouncing behavior as well.

So...the next step is to either make sure that the next-hop is reachable through the IGP OR use next-hop self.

After this, I'll probably need to take a look at the actual routes...

Alvaro.

ruwhite Mon, 09/29/2003 - 12:53

Hmmm.... It's most likely the same problem, but for a different reason. Is it the iBGP learned routes that are flapping, or the eBGP learned routes? If it's the iBGP learned routes, then somehow you are learning a route to the iBGP peering address that's better than the IGP learned route to the iBGP peering address through iBGP itself. I would check the routing table on the 3rd router for the route to each of the iBGP peers every 60 seconds or so, to see if you see it pointing to an iBGP route intermitently, or where it's pointing when the routes are up.

I'm almost certain it's a recursion problem, in any case, we just have to figure out where the recursion is, and stop it.

Russ.W

gskhanna Mon, 09/29/2003 - 13:10

okay i will try to turn on next-hop-self and see if that fixes it. It is only the ibgp that is affected. so it seems the ebgp might have a better metric then the internal ibgp so that's why it's flapping. I think that next-hop-self will help, as all the routers are connected thru an internal lan.

One question, currently router 1 has a 500mbs link to Yipes, 2nd is 300mbs to cogent, and 3rd is 100mbs to xo. How can i tell it to use more of link 1 vs link2 etc.. Is their an easy way to load share in this environment?

I was told the only way, crudly to do it, is to show certain bigger AS's closer to one router or another to help shape the traffic that way.

Idealy I just don't want one link to be maxed while the other two are idle.

Thanks for your help btw.

-GK

aretana Mon, 09/29/2003 - 13:19

"easy way"...?? No, not currently. The as-path prepend mechanism is pretty much it, but it requires constant tunning as traffic characteristics change.

The "easy way" is called OER. Take a look at the slides in my Networkers' presentation: ftp://ftp-eng.cisco.com/alvaro/4004.pdf

We're currently targetting an official release for sometime next year...

Alvaro.

gskhanna Tue, 09/30/2003 - 03:17

Well, Still no go.

Did notice a few things tho.

First off, I have no sync on both sides, and no autosummary, and barebone confs.

If i set next-hop-self on both sides, and they connect fine as ibgp. But then when i add in the xo (3rd router) ebgp to it's isp, it get's all the routes and for about 1 min all looks good

and then boom. withdraw statements, I was able to capture the debug for it:

*Sep 30 01:17:20: BGP(0): 66.90.64.50 NEXT_HOP part 1 net 193.110.159.0/24, next 66.237.108.29

*Sep 30 01:17:20: BGP(0): 66.90.64.50 send UPDATE (format) 193.110.159.0/24, next 66.237.108.29, metric 3, path 2828 701 702 8513 9154 24770

*Sep 30 01:17:20: BGP(0): 66.90.64.50 NEXT_HOP part 1 net 198.63.206.0/24, next 66.237.108.29

*Sep 30 01:17:20: BGP(0): 66.90.64.50 send UPDATE (prepend, chgflags: 0x208) 198.63.206.0/24, next 66.237.108.29, metric 3, path 2828 2914 27369

*Sep 30 01:17:20: BGP(0): 66.90.64.50 5 updates enqueued (average=66, maximum=69)

*Sep 30 01:17:20: BGP(0): 66.90.64.50 update run completed, afi 0, ran for 0ms, neighbor version 267773, start version 267779, throttled to 267779

*Sep 30 01:17:21: BGP(0): 66.90.64.50 rcv UPDATE about 81.161.240.0/20 -- withdrawn

*Sep 30 01:17:21: BGP(0): 66.90.64.50 rcv UPDATE about 81.161.248.0/21 -- withdrawn

*Sep 30 01:17:21: BGP(0): 66.90.64.50 rcv UPDATE about 82.146.16.0/21 -- withdrawn

*Sep 30 01:17:21: BGP(0): 66.90.64.50 rcv UPDATE about 82.146.24.0/24 -- withdrawn

66.90.64.50 = ibgp peer (2nd router that's working fine :) )

66.237.108.29 = ebgp to xo isp router.

this 3rd router is 66.90.64.51.

I am not sure if u can tell anything by that, but never know..

Also what i noticed was after about 5-10min of this, it seemed to just stop

and was sharing the link load, but the 3rd router was only showing 28K routes from the ibgp, whereas it should of been showing the full routes ~110K like it was with the ebgp isp side.

Also, one odd thing i saw, was that when I did:

XO#sh ip bgp 66.90.64.0

BGP routing table entry for 66.90.64.0/19, version 17797

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

Advertised to non peer-group peers:

66.237.108.29

Local

0.0.0.0 from 0.0.0.0 (66.237.109.41)

Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best

that's from router 3. (the 109.41 is on the lan interface along with 66.90.64.51)

currently I have the bgp off, else it would also show the proper route for the 66.90.64.0/19 thru the ibgp, but it does not show it as best path, nor does it show it with any weight!

66.90.64.0/19 is our block we are advertising everywhere.

My other router #2 (66.90.64.50) the ibgp peer, shows this:

Kingcomp1#sh ip bgp 66.90.64.0

BGP routing table entry for 66.90.64.0/24, version 18069

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

Not advertised to any peer

Local

66.90.64.49 from 66.90.64.49 (209.120.155.14)

Origin IGP, metric 0, localpref 100, valid, internal, best

Now, I know that XO is advertising a 66.90.0.0 /18 thru their router. can that be conflicting and causing this problem? as our block is 66.90.64.0/19 ?

Thanks for all your help in this guys. This is really frustrating and I don't have anyone left to ask help from :(

-GK

ipotts Tue, 09/30/2003 - 23:58

It is possible that what you are seeing is normal BGP behaviour, especially given that it stabilises after about 10 minutes.

Withdraws are very common on IBGP, since you usually compete with the IBGP routes of the other routers. If your advertised IBGP route is inferior to theirs, then you sent an IBGP withdrawal for the route that you sent.

Therefore, before you bring up the 3rd ISP, with all 3 IBGP peers in place, the 3rd router will have a full IBGP table. When the 3rd ISP EBGP peer is added, the third router will now be competing with the other two routers on IBGP. It will win on some IBGP routes usually through AS PATH, and lose on others, thereby ending up with an IBGP routing table that is smaller than its EBGP table.

Regards

Ian

ruwhite Wed, 10/01/2003 - 01:50

After it stablilizes, how many of the XO router's peers are using routes through the XO router, rather than through their eBGP connection? I would guess that you are seeing the normal settling, though its taking longer than I would have expected, and then the other routers are choosing the XO router as their exit point for all but about 28k of their routes, so they stop advertising the full table to the XO router (split horizon).

You could check this by checking some of the routes for which the XO router has eBGP routes, and not iBGP routes. If you find a couple of these, then check them in the iBGP peers of the XO router. If they are using the XO router as their best path towards those destinations, then they won't advertise the route to the XO router.

Russ.W

gskhanna Wed, 10/01/2003 - 06:08

Hmm I see. I will give it a try tonight and check the routes. I just figured that it would actually keep all the routes from each peer in memory and the routing table would just be "best" path table.

Also I didn't relize XO had that many better routes then Yipes and Cogent (our 2 other providers). Just noticing they are 1 hop from at&t AS. That might be why :)

As was said earlier since their is no 'easy' way to shape traffic on unequal links. What is the proper way to do it?

I was told to put bigger AS's on my bigger links, to more traffic would go out there. Can you point me to a sample config on how to do this please?

Thanks guys. I really thought something was messed here, but seems it is working like it's supposed to :/

ruwhite Wed, 10/01/2003 - 07:02

It could be that XO is closer to some of the major providers than your other providers, and this is skewing routing towards them... If this is the case, there are several things you can do to route more traffic out towards the other two providers. For instance, you could set the local pref on some of the routes you're learning from the other providers higher, based on a range of addresses, or a given as path length.

But you'll have to do some manual tuning if you want the traffic to be loosely balanced, or wait until something like Optimized Edge Routing is available. :-)

Russ.W

gskhanna Wed, 10/01/2003 - 07:34

As I believe you are absolutely correct. XO seems to have much better peering with AT&T/Sprint and some other major backbones when compared to my other providers.

OER sounds great, but I need something till then :)

Two other questions on this topic:

Why does it take so long to converge? ie, it I see the router get the entire routing table from the ibgp peer, and then drop them down to 30k, then all the way back up to 110k, then back down. like 2-4 times before it settled at 30K.?

Can you point me to a sample config on how to have routes going to a certain AS take the path out a certain router?

ruwhite Thu, 10/02/2003 - 13:48

You aksed:

Why does it take so long to converge? ie, it I see the router get the entire routing table from the ibgp peer, and then drop them down to 30k, then all the way back up to 110k, then back down. like 2-4 times before it settled at 30K.?

--

I'd guess it's an issue with queueing, rather than the number of routes you're sending. Two things you could try to speed up convergence--increase you r input queues, and turn on path mtu discovery for the TCP implementation on the router.

http://www.cisco.com/en/US/tech/tk365/tk80/technologies_tech_note09186a00801c4f48.shtml#iptcpmtudisc

Isn't directly related, but it's in the right area anyway (and the other things listed on this page might actually help, as well). The second thing would be to reduce the minadvinterval, especially since you aren't transiting any traffic.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_command_summary_chapter09186a00800f0ab2.html#5335

I'd feel pretty safe setting it down to 1 second in this network. See if these make any difference, along with the other issues you're having with the write queue getting stuck.

:-)

Russ.W

Correct Answer
ruwhite Thu, 10/02/2003 - 14:02

Second Question:

Can you point me to a sample config on how to have routes going to a certain AS take the path out a certain router?

--

There aren't any that I know of, or that I could fine by poking around the CCO docs.... What you want to do is to use an as path access-list to match on each provider, and then set the local preference for a match. So, say your two providers are AS65000 and AS65001, and you want to push some of the traffic over to AS65000. You can make it so AS65000 is preferred for 3 hop paths, even if the connection through AS65001 is normally preferred:

ip as-path access-list 100 permit ^[0-9]*$

ip as-path access-list 100 permit ^[0-9]*_[0-9]*$

ip as-path access-list 100 permit ^[0-9]*_[0-9]*_[0-9]*$

!

route-map prefer65000 permit 10

match as-path 100

set local-preference 110

!

router bgp x

neighbor x.x.x.x remote-as 65000

neighbor x.x.x.x route-map prefer65000 in

(from memory, not on a router, so I could have something wrong here)

This should match any routes of three AS hops, and force them to go through AS65000, even if you have a two hop route going through AS65001. You can adjust the outbound traffic by adjusting the number of [0-9]*_'s included in the as path access list--two, and it should prefer any two hop as paths to go through AS65000, three for any three hop paths, etc. So, for instance, if you want to influence more distant networks, where there's less likelihood of suboptimal routing, then add statements with 3 and 4 [0-9]*_'s.

I hope this makes sense....

:-)

Russ.W

gskhanna Thu, 10/02/2003 - 21:59

Makes perfect sense, and your syntax was perfect also!

Thanks to both of you I now have a good stable network that works v well.

But one thing, :) The XO router is still getting too much traffic compared to the other links. I have added 4 of the [0-9]*_ to it allready. I will add another 1 or 2 and see how it goes. XO obviously has a LOT better routing then Yipes (main Link).

I'm soo happy. Thank you again! :)

ipotts Fri, 10/03/2003 - 04:11

These changes will only affect outgoing traffic, not traffic incoming from XO. To affect this you need AS path pre-pending, when the routes in your AS are advertised.

ruwhite Fri, 10/03/2003 - 04:19

Cool! I'm glad we helped!

So, two things.... I assume you're leaving in the two hop filter when you add the three hop filter, etc.

^[0-9]*$

^[0-9]*_[09-]*$

Catches one and two hops.

^[0-9]*$

^[0-9]*_[09-]*$

^[0-9]*_[0-9]*_[0-9]*$

Catched one, two, and three hops.... You have to include all of them, since the three hop won't catch the two hop (because of the spaces in the regex). At least I don't think it does....

Second, is this inbound or outbound traffic? The filters above will only inpact outbound, not inbound, and you need to try and balance both, if you're trying to get your money's worth out of the links.... The only real option at this point is as path prepend for inbound traffic (well there's another one, which I'll talk about below). The syntax for this should be:

route-map prefer65000 permit 10

set as-path prepend x x x

With your AS number in place of each x. Try with just one first, and see what that does to the traffic flows. Increase the number of prepends 'til you get the balance right. You might need to prepend towards more than one upstream ISP to get things to work right.

Another option is to work with your ISP to set the local preferences within their AS to something that prefers the route through another of your upstreams. This is generally easy to do--you set some community on your side, then you ask them to translate that community into a local preference on their side. Most ISP's already have this sort of thing set up, you just need the "magical community list."

Note, however, this could cut your traffic entirely out from one of your upstreams, pushing it all over to the other one, so.... It might not work as well as as path prepend, as limited as that approach really is.

:-)

Russ.W

gskhanna Sun, 10/05/2003 - 04:57

Actually for inbound the prepend would work nice, but I actually did something different.

We have a /19 for our network, and we are advertising the entire /19 on all 3 routers. Now, I am advertising /21 and /24 out of that /19 on one router or another. and inbound traffic is actually routed to the right place because outside networks see the route as being closer due to "longest match". on the router with the /21 or /24 on it.

I know that some isp's ignore anything smaller then /20 I believe, but I'd say this has so far worked with 99.9%. I have yet to see a place that this didn't work with.

I will switch it over to the proper prepend method later or work with the community strings. 2 out of our 3 isp's allready gave us that info.

One more question for outbound traffic. I used the 2/3hop as path filtering. and I added it as long as 9 hops now. and our smaller link which goes thru xo is still getting a lot more traffic then desirable.

What I would like to do is set a certain subnet to only have outbound through a specific router. Because along with our /19, we have a another /19 from our isp, that is only inbound on one router, but now it seems to be taking the "best path" out, whereas we only want it go out thru one isp.

-GK

ruwhite Sun, 10/05/2003 - 05:10

Most ISP's will accept anything under a /24, so this is an excellent scheme, much better than prepend, as long as you can get the granularity you want in controlling inbound load.

For the second question, hmmm.... You can mostly control that by controlling which router the ountbound traffic hits. So, adjust your igp metrics for that specific route so the outbound router you want to be chosen is always chosen, then it will choose its local link out, most likely.

As for the 9 hops, hmm.... Is the local pref actually being set on a numebr of routes when you try this filtering? Can you look at the other router's bgp table, and see if it is?

Russ.W

gskhanna Sun, 10/05/2003 - 05:43

Ya, the smallest we would need to advertise is a /24 so it works good.

The 9 hops. The local preference is set to 110. I noticed when I had it set to 4 hops, it showed about 50,000 routes from router #1, when I increased it to 8 it sent up to 85,000 routes. and 9 it's at 90,000 routes.

for instance:

* i12.1.96.0/24 66.90.64.50 0 100 0 16631 174 2914 19024 14359 23306 i

* 66.237.108.29 3 0 2828 3561 19024 14359 23306 i

*>i 66.90.64.49 0 110 0 6517 7911 2914 19024 14359 23306 i

the .50 is router #2, and shows it as ibgp path. The 2nd is .29 is the xo route. and the .49 choosen as best path is the router #1 that majority of the traffic to go thru.

So it is working, I just think the isp on router #1 (Yipes, also known as williams) is just a lot worse then XO so that might be why.

The static subnets that we receive from our isps, the default gateways for those networks are on the respective routers. So it is hitting it correctly, and then choosing best path out, instead of staying on that rouer :)

Can you give me syntax for keeping it on there?

ruwhite Sun, 10/05/2003 - 16:03

Hmmm.... If the XO router is pointing towards the router that connects to Yipes as its next hop, it should be directing traffic out through Yipes, rather than through XO. Could you post a show ip bgp route for just one route you're learning through both ISP's that should be impacted by the route map?

Russ.W

gskhanna Sun, 10/05/2003 - 19:04

Here is a show ip bgp from Xo router.

* 12.5.136.0/24 66.237.108.29 3 0 2828 209 16759 i

*>i 66.90.64.49 0 110 0 6517 7911 209 16759 i

As you can see, the 108.29 (xo isp bgp peer) is 3 as's away. while 64.49 (my yipes local router) shows it as 4 as hops away and it is alos the ibgp peer route, and it is also the > best route. because I have the route map set to a silly 14 AS hops. Yipes routing truly does suck it seems.

It works perfectly, as trace routing to that form the xo router i get:

1 gate.fdcservers.net (66.227.96.1) 4 msec 0 msec 4 msec

2 209.120.155.13 [AS 6517] 0 msec 0 msec 4 msec

3 chcgil1wcx1-gige15-0.wcg.net (64.200.247.237) [AS 7911] 0 msec 0 msec 4 msec

4 brvwil1wcx3-pos3-0.wcg.net (64.200.236.30) [AS 7911] [MPLS: Label 12330 Exp 0] 0 msec 0 msec 4 msec

5 chcgil9lch1-pos7-1.wcg.net (64.200.210.118) [AS 7911] 0 msec 0 msec 4 msec

6 chcgil9lcx1-pos9-0-oc48.wcg.net (64.200.103.109) [AS 7911] 0 msec 0 msec 4 msec

7 chcgil9lcx1-qwest-gige14-1.wcg.net (64.200.228.190) [AS 7911] 0 msec 0 msec 4 msec

8 chi-core-02.inet.qwest.net (205.171.220.57) [AS 209] 0 msec 0 msec 4 msec

9 cer-core-01.inet.qwest.net (205.171.205.34) [AS 209] [MPLS: Label 587110 Exp 0] 0 msec 0 msec 0 msec

10 cer-core-02.inet.qwest.net (205.171.139.2) [AS

etc.. (after this trace seems to be filtered) but it shows it took the route thru yipes which I wanted.

Now what I need to do, is set certain local subnets to go thru only certain routers.

ie, i have 66.227.96.0 /20 on my router Yipes router. I want it to statically only go out thru the Yipes router. I do not want it to choose the best path or anything, just go out that Router.

ruwhite Mon, 10/06/2003 - 04:55

Okay, that's cool.... The easy way to add this is by using a second level of local preference. So, on the Yipes router, which has no route map right now (correct? the route map is on the AO router at the moment?), you would do this:

access-list 10 permit 66.227.96.0 0.0.0.255

!

route-map preferme permit 10

match ip address 10

set local-preference 120

!

router bgp x

neighbor y

neighbor y route-map preferme in

Now, when you received routes that are within access list 10, they have a local preference of 120, which will beat the default local preference (100), or the local preference of 110 set elsewhere. This is simpler than doing excludes from the other filter, or anything like that.

You can also do this on the XO router, where the filter for as path length is already running, by adding another clause on the route map. Suppose you have this:

route-map prefer65000 permit 10

set local-preference 110

You can now add this to the config:

access-list 10 permit x.x.x.0 0.0.0.255

!

route-map prefer65000 permit 5

match ip address 10

set local-preference 120

You can also repel traffic from a router, by setting the local preference lower than 100.

Russ.W

gskhanna Mon, 10/06/2003 - 09:48

Yes, the Yipes router has no route map configured. Now when I want to set routes that are coming FROM my yipes (66.227.96.0 /20) I need to do

access-list 10 permit 66.227.96.0 0.0.0.255

!

route-map preferme permit 10

match ip address 10

set local-preference 120

!

router bgp x

neighbor y

neighbor y route-map preferme in

question, what do i put for the neighbor command? as I want the router I am putting this on, to have local preference of 120.

Oh doh. I think I misunderstood you. This routemap would go on the other two routers that I do not want it to go thru, and then use this list to match the route coming from the yipes router, and set all routes coming from that neighbor as a higher local preference. and therby thru ibgp, say yipes router (.49) has the best route (local preference 120) so go thru there.

Right?

ruwhite Tue, 10/07/2003 - 03:31

Yes, the config you gave above would be fine.... The route-map in would match the set of destinations you definitely want to send through yipes, setting their local preferences to 120, thus causing the other two SP routers to prefer this router for those destinations.

The same route learned on the other two routers will have, at the most, a local preference of 110.

(You could also use this on the other two routers, seeting the local preference lower, to repel traffic from them, and towards yipes, but it's easier to pull traffic towards yipes ont he yipes router than it is to push traffic towards yipes from the other two routers.)

Russ.W

gskhanna Wed, 10/08/2003 - 12:09

I didn't get a chance to try this yet. I will tonight. One more additional question.

Won't this just influence the path for "incoming" packets to the network to be sent to that router. instead of outbound packets sourced from 66.227.96.0 ?

Cause I have 66.227.96.0 on my Yipes router, and I want that traffic from there to only go out thru the yipes router.

-GK

gskhanna Wed, 10/08/2003 - 12:09

Someone just mentioned to me, that BGP won't help do this for outbound. That I need to do "policy routing" instead?

-GK

ruwhite Fri, 10/17/2003 - 08:14

No, you don't need policy routing for outbound traffic flow.... You can use that, but it's a complicated way to solve the problem. Policy routing is primarily designed to control the next hop of traffic based on the source address or TOS bits of the packet, rather than the destination address. If you can control the traffic using route maps based on the destination addresses, it's much easier, and much better, in the long run, to manage and to troubleshoot.

Russ.W

gskhanna Fri, 10/17/2003 - 08:59

Actually I ended up using policy based routing. As I needed to control the traffic based upon the "source" address, not the destination. I needed certain subnets on my network to be routed thru certain isps.

One question about the next-hop-statement that i used. It seems you can add more then one next-hop.

set ip next-hop 209.120.155.13 etc..

Does the 2nd next-hop only go into affect if the 1st one is unreachable?

Since I have bgp running, and if the first one is unreachable, will the packets be automatically sent to the other routers? or Do i need to specify the other routers as next-hop?

Thanks.

-GK

ruwhite Fri, 10/17/2003 - 10:12

The 2nd next hop is used if the first next hop is unreachable (not in the routing table). The next hop would normally be learned through an IGP (connected, static, etc), rather than through BGP (?), but once this route was removed from the table, the second next hop would be used.

Russ.W

gskhanna Fri, 10/17/2003 - 11:23

If it runs out of next-hop, but it has bgp neighbors, will it send the packet to one of them?

-GK

ruwhite Mon, 10/20/2003 - 06:02

In other words, if you do a match, then set the next hop, and none of the next hops exist, will it revert to normal routing? Yes, it will. If there is a route in the routing table, and the set next-hop fails, the router will then use the route in the routing table.

For instance:

access-list 101 permit ip host 208.0.9.12 any

!

route-map testnexthop permit 10

match ip address 101

set ip next-hop 1.1.1.1

!

interface Serial0/3

ip address 208.0.14.13 255.255.255.0

ip policy route-map testnexthop

!

2651C#ping

Protocol [ip]:

Target IP address: 208.0.10.1

Extended commands [n]: y

Source address or interface: 208.0.9.12

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 208.0.10.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

2651D#

2w4d: IP: s=208.0.9.12 (Serial0/3), d=208.0.10.1, len 100, policy match

2w4d: IP: route map testnexthop, item 10, permit

2w4d: IP: s=208.0.9.12 (Serial0/3), d=208.0.10.1 (Serial0/0), len 100, policy rejected -- normal forwarding

So, the set next-hop fails, and 26D falls back to the routing table, where the actual destination is directly connected.

Russ.W

Actions

Login or Register to take actions

This Discussion

Posted September 29, 2003 at 12:19 PM
Stats:
Replies:33 Avg. Rating:4
Views:227 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 2,069
2 1,732
3 1,675
4 1,624
5 1,529