1. Home
  2. Cisco Systems
  3. BGP Partial Routes Recommendation

BGP Partial Routes Recommendation

We are currently getting full BGP routes from 2 ISP's. We're running into a problem with our router not being able to support that number of routes. We're considering going with partial routes with each provider.

It was suggested we do the following:

Start with the ISP who is less preferred. Have them send us partial routes with a default route. (in our case outbound traffic is preferred through one provider. The other provider is there for failover)

Once we're sure that is working, then have the other provider do the same.

Then test failover.

I don't think we're are interested in prefix filtering.

I was told I would not have to make any changes on my end, and the changes will be transparent to me.

Does anyone have suggestions about this approach?

I need to avoid any downtime.

We're using a Cisco 6509 with FLEX WAN module. It can handle 256k routes according to Cisco.

Here's the relevant portion of the config

router bgp no synchronization bgp log-neighbor-changes network x.x.x.x mask 255.255.255.0 neighbor y.y.y.y remote-as neighbor y.y.y.y description BGP Session to Less Preferred ISP neighbor y.y.y.y ebgp-multihop 5 neighbor y.y.y.y update-source Multilink2 neighbor y.y.y.y distribute-list 50 out neighbor y.y.y.y route-map AS-PATH out neighbor y.y.y.y filter-list 40 out neighbor z.z.z.z remote-as neighbor z.z.z.z description BGP Session to Preferred ISP neighbor z.z.z.z update-source Multilink1 neighbor z.z.z.z distribute-list 50 out neighbor z.z.z.z route-map WEIGHT in neighbor z.z.z.z filter-list 40 out no auto-summary

Any help is appreciated.

Reply to
sillz
Loading thread data ...

Not sure why you are having issues on a 6500. What supervisor are you running. A sup2 might have issues, but a Sup720 should not have any problems handling a full routing table unless one or more of your ISP's are sending you routes smaller than a /24.

If your sending all of your outbound traffic out one provider, and the other is just for failover for outbound, then you only need one route from both ISP's and that's a default. The only reason to get anything other than a default is if you want to use both links for outbound traffic.

Reply to
Thrill5

Thanks, it is a SUP2. My understanding is that it is limited to 256k routes. We need failover for incoming traffic as well since we host services. Does this change the scenario?

Reply to
sillz

)Thanks, it is a SUP2. My understanding is that it is limited to 256k )routes. We need failover for incoming traffic as well since we host )services. Does this change the scenario?

Incoming traffic will be "load-balanced" as long as you have a BGP peeer to both ISP's and sending your AS and route. (and you have your own AS number) The full internet routing table is way less than 256K routes, but again your ISP should not be sending you anything less than /24 routes, which would take it to less than 125K routes.

Reply to
Thrill5

Careful - Sup720 comes in two sizes: The Sup720-3B supports forwarding tables of the same size as the Sup2, i.e. around 256K IPv4 routes[1]. The Sup720-3BXL has larger tables that can support about a million routes.

You can also default to both. We have five transit links to three different ISPs (on four different routers in two cities :-), and they all receive outbound traffic. We ask these upstream providers to send us default *and full routes*, but we usually ignore everything but default. When we want to shift outbound traffic, we can accept some routes from a given upstream - e.g. customer routes, or other routes that we trust that upstream to handle particularly well, or routes to destinations that we see that other transits have trouble with (very rare with the ones we have).

[1] In fact, because the Sup720 supports IPv6 in hardware too, the default configuration leaves less space for IPv4 routes - I think 224K or 192K. You can get close to 256K IPv4 routes by reducing the number of IPv6 routes you can support - something that might bite you in the future. The Sup32 is identical to the Sup720 forwarding-wise, except that the Sup32 doesn't have an "XL" version. The forwarding tables are on the PFC daughterboards, so the distinction is really between PFC3[BC] and PFC3[BC]XL.
Reply to
Simon Leinen

Also, a full route table is around 300K routes now...I actually bumped up against this not too long ago with a Juniper box that couldn't handle that. :-)

Reply to
fugettaboutit

As I write this, there are 279,932 network entries in the "full table" I am looking at: route-server.ip.att.net

Reply to
John Agosta

..

Ah yes - if you are working with internet routing the two important terms are "router server" and "looking glass".

Reply to
bod43

..

m...

Clearly I'm overloading my switch.

It was suggested we do the following:

Start with the ISP who is less preferred. Have them send us partial routes with a default route. (in our case outbound traffic is preferred through one provider. The other provider is there for failover)

Once we're sure that is working, then have the other provider do the same.

Then test failover.

I don't think we're are interested in prefix filtering.

I was told I would not have to make any changes on my end, and the changes will be transparent to me.

Does anyone have suggestions about this approach?

I need to avoid any downtime.

Thanks!

Reply to
sillz

How do you want to handle INBOUND traffic? Nothing inherently wrong with asymmetrical routing, but you might have a local reason to handle inbound traffic a certain way...

In your case, and as a start, I'd take a default route from both providers and increase the LOCAL_PREF for the provider you want to send traffic to. On the secondary provider, I'd do an AS_PATH prepend of my netblock out so that inbound traffic will prefer the primary provider. That will get you started and won't cause any downtime sans a few seconds while the global route tables adjust. The secondary provider will pretty much be idle. You can then play around with partial routes and such in an effort to utilize the secondary link.

Reply to
fugettaboutit

...

om...

Thanks,

I ended up getting a default route and partial routes from both providers. I started with the less preferred neighbor. They adjusted the routes which had no affect until I did a soft reset on nmy BGP session with that neighbor. The required a config change:

Router(config)#router bgp 1111 (asn) Router(config-bgp)#neighbor a.b.c.d soft-reconfiguration inbound

Then I cleared the session with no downtime with

neighbor a.b.c.d soft-reconfiguration inbound

The second provider had to reconfigure the neighbor, so we had a quick interruption in service, but I ran the same commands as above to clear the session.

As soon as the routing table rebuilt, I got a positive message from the 6509 that routing was now occurring in hardware not software.

No issues at all.

Reply to
sillz

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.