BGP route filtering using as-path access-list

jude56g

Hi All,

I'm looking for some advice here. I have 3 BGP peers from 3 different providers, and I'm receiving the full table + a default route from each. I'm the tricky situation where my Internet routers (Cisco 6500 w/ 3BXL) are reaching their IPv4 route limit. I know I can re-allocate the TCAM table to allow for a greater number of routes, but this requires a reboot, I really don't want to reboot this router- its been up for many many years, and I have the sinking feeling it may not come back. I have a replacement on order but I'm not sure how long it will take to arrive. I'm looking for a way to mitigate this issue in the meantime.

So, I had considered filtering some routes from each provider using an as-path access-list. Consider the following current setup.

ISP-1 (AS65001) full table + a default
ISP-2 (AS65002) full table + a default
ISP-3 (AS65003) full table + a default

I would then filter as such.

ISP-1 (AS65001) full table + a default [filter routes originating from 65002 & 65003]
ISP-2 (AS65002) full table + a default [filter routes originating from 65001 & 65003]
ISP-3 (AS65003) full table + a default [filter routes originating from 65001 & 65002]

This would reduce the number of routes in my BGP tables, but I'm not sure if this would fully accomplish reducing the size of the routing table.

Another thought I had was to filter routes longer than x number of AS hops, or networks with masks longer than /23, or even just receive a default route from each peer. My only concern here is that any of these options will mess with my outbound paths, and I don't want to do that.

Any thoughts or suggestions would be very helpful.

Thanks!

fredrikjj

The BGP RIBs themselves are stored in some other memory and not in the TCAM, which is the memory structure that is running out of space. This means that it won't have any effect to filter something that isn't an active prefix. So basically you need to remove prefixes from the FIB/TCAM while making sure that they are covered by some other prefix in order to not lose reachability. In your case, since you have default routes, you will always have reachability and it's only a question of how suboptimal your routing is allowed to get.

The most extreme solution would be to filter everything from all providers, except the default routes. The problem with that approach is, like you mention, that it could mess with the outbound paths. If one provider has a better path to a prefix, only having defaults means that traffic would just use the best default. On the other hand, maybe outbound path aren't terribly important to you? I guess that depends on what kind of enterprise you are supporting.

A more sensible solution would to filter everything above a certain as-path length. I think that this is the best solution since you could make the argument that once the path length gets large enough, it doesn't really matter what provider you use, or perhaps one provider simply routes the long distance traffic better and have better connections to other providers. You could make sure that the default route from this "best provider" is the one that is preferred. You still retain the ability to use a better path to ASes that are close to each provider.

A potential problem with this solution (defaults + partial table) is that if your outbound links are heavily loaded today with a traffic volume that exceeds what one link can handle, moving to a single outbound link for the default traffic wouldn't work if you are currently load sharing based on having full information. In that case you would need to make sure you use bgp multipath.

networker050184

You could always just accept local routes and a default from the providers. Depending on the provider they may have communities you can match on to get their local and customer routes, or you could use AS path to filter routes originating in or directly connected to that AS. That would keep your routing efficient to your local providers. Next you can use floating statics to prefer a certain provider's default and have backups.

phoeneous

My bgp learning is a bit premature but by full table do you mean the entire current bgp table of some 52,000 prefixes?

deth1k

lol 52k prefixes? are we in 1999?

Can you run: "show platform hardware capacity pfc" I have a feeling you are over 512k either way. I agree with Networker, get partial feed plus default from all three providers.

networker050184

I think you forgot a 0 there (we're sitting at over 500,000 routes on the internet right now), but yes that is generally what a 'full table' refers to. Also referred to as 'full routes' when talking about advertisements from a provider.

phoeneous

networker050184 wrote: »

I think you forgot a 0 there (we're sitting at over 500,000 routes on the internet right now), but yes that is generally what a 'full table' refers to. Also referred to as 'full routes' when talking about advertisements from a provider.

Yup, typo, meant to say 520k.

Question then for my own curiosity, why would a non-isp need the full internet table?

Dieg0M

phoeneous wrote: »

Yup, typo, meant to say 520k.

Question then for my own curiosity, why would a non-isp need the full internet table?

Traffic engineering

networker050184

As Dieg0M pointed out, to engineer (control) your traffic. Say for example you have two providers and you want to route as efficiently as possible. Provider A is directly connected to Client A and Provider B is directly connected to Client B. You wouldn't want to route through Provider A to Provider B (and any other providers in between them) just to get to Client B.

If you only have a single provider then yeah, it doesn't make too much sense.

phoeneous

Understood, thank you.

jude56g

The decision was made to re-allocate the memory for IPv4 routes, and reboot. That is the way we went, and all is good now. Thanks for all the feedback and suggestions!!