nanog mailing list archives
Re: Route table growth and hardware limits...talk to the filter
From: Forrest <forrest () almighty c64 org>
Date: Sat, 8 Sep 2007 23:13:52 -0500 (CDT)
On Sat, 8 Sep 2007, Jon Lewis wrote:
IIRC, this has come up on cisco-nsp before, and the response has been that it's very "icky" to do and doesn't really save anything on most platforms. In the example case of 1) 192.168.0.0/16 AS11111 AS22222 AS33333 2) 192.168.1.0/24 AS11111 AS22222 AS33333 3) 192.168.2.0/24 AS11111 AS55555 AS44444 AS33333 4) 192.168.3.0/24 AS11111 AS22222 AS33333 Forrest says the router should be smart and reject paths 2 and 4 because they're covered by 1. Now what happens when 1 is revoked? Do we lose connectivity to 2 and 4, or does the router have to keep track of all these dependant routes and reinstall 2 and 4 when 1 is lost?
Based on what seems to be reported by the CIDR-REPORT, I would say that if #1 is revoked then it's likely all of the routes with the same AS Path will be revoked anyway. But if not, rather than the router having to recalculate whether the more specifics should or should not be accepted at each routing update, you could apply the same principles that route flap dampening uses. Reject paths #2 and #4 for X number of minutes before you bother checking again to see if the larger aggregate is still there.
it's not exactly in cisco's best interest to extend the life of gear they'd like to see replaced with new cisco gear.
Perhaps that's true, but perhaps another company like Juniper would implement it feeling that it would give their equipment an edge over their competitors. If the number of routes was causing me a large problem with my routers, I would certainly look more closely at another vendor's gear if it offered a better solution for dealing with the problem than filtering based on RIR minimums. Forrest
Current thread:
- Re: Route table growth and hardware limits...talk to the filter, (continued)
- Re: Route table growth and hardware limits...talk to the filter Forrest (Sep 09)
- Re: Route table growth and hardware limits...talk to the filter Stephen Sprunk (Sep 10)
- Re: Route table growth and hardware limits...talk to the filter Kevin Loch (Sep 10)
- Re: Route table growth and hardware limits...talk to the filter Stephen Sprunk (Sep 10)
- Re: Route table growth and hardware limits...talk to the filter Kevin Blackham (Sep 10)
- Re: Route table growth and hardware limits...talk to the filter Jon Lewis (Sep 11)
- Re: Route table growth and hardware limits...talk to the filter Adrian Chadd (Sep 11)
- Re: Route table growth and hardware limits...talk to the filter Andrew - Supernews (Sep 08)
- Re: Route table growth and hardware limits...talk to the filter Jon Lewis (Sep 08)
- Re: Route table growth and hardware limits...talk to the filter Forrest (Sep 08)
- Re: Route table growth and hardware limits...talk to the filter Tony Li (Sep 08)
- Re: Route table growth and hardware limits...talk to the filter Randy Bush (Sep 08)
- Re: Route table growth and hardware limits...talk to the filter Adrian Chadd (Sep 09)
- Message not available
- Re: Route table growth and hardware limits...talk to the filter Randy Bush (Sep 09)
- Re: Route table growth and hardware limits...talk to the filter William Allen Simpson (Sep 09)
- Re: Route table growth and hardware limits...talk to the filter Randy Bush (Sep 09)