Re: Route table growth and hardware limits...talk to the filter
From: owner-nanog@merit.edu on behalf of Jared Mauch Sent: Sat 9/8/2007 8:17 AM To: William Allen Simpson Cc: nanog@nanog.org Subject: Re: Route table growth and hardware limits...talk to the filter
I think this is the most important point so far. There are a lot of providers that think that their announcements need to be global to manage link/load balancing with their peers/upstreams. Proper use of no-export (or similar) on the more specifics and the aggregate being sent out will reduce the global noise significantly.
Perhaps some of the providers to these networks will nudge them a bit more to use proper techniques.
I'm working on routing leaks this month. There have already been over 2600 leak events today that could have been prevented with as-path filters of some sort, either on a cutomer or peer. (this would obviously be in-addition to prefix-list filters).
- Jared
Maybe this is a dumb question, but why isn't there a BGP option to just filter more specific routes that have the same AS path as the larger aggregate? This would allow the networks that announce more specifics for traffic engineering to still accomplish that, while throwing away the garbage from someone else that decides to announce their /19 as 33 routes for no apparent reason. Sure, this would fail if a network decided to only announce /24's for example without a larger aggregate, but how many networks are really doing that? Forrest
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Maybe this is a dumb question, but why isn't there a BGP option to just filter more specific routes that have the same AS path as the larger aggregate? This would allow the networks that announce more specifics for traffic engineering to still accomplish that, while throwing away the garbage from someone else that decides to announce their /19 as 33 routes for no apparent reason. Sure, this would fail if a network decided to only announce /24's for example without a larger aggregate, but how many networks are really doing that?
http://www3.ietf.org/proceedings/03nov/I-D/draft-grow-bounded-longest-match-... As a matter of fact. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG4x6KER27sUhU9OQRAs/ZAJ9LARtnoo7YUshwBCuGyj/fVO7MJACg/2AI Qe6P+ImcLKnan97HlwmYVjQ= =zgmF -----END PGP SIGNATURE-----
On Sat, 8 Sep 2007, Russ White wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Maybe this is a dumb question, but why isn't there a BGP option to just filter more specific routes that have the same AS path as the larger aggregate? This would allow the networks that announce more specifics for traffic engineering to still accomplish that, while throwing away the garbage from someone else that decides to announce their /19 as 33 routes for no apparent reason. Sure, this would fail if a network decided to only announce /24's for example without a larger aggregate, but how many networks are really doing that?
http://www3.ietf.org/proceedings/03nov/I-D/draft-grow-bounded-longest-match-...
As a matter of fact.
:-)
Russ
That draft seems pretty sensible and in my opinion does more good than the other options like filtering all routes that are longer than the RIR minimum or hoping that the offenders magically wake up one day and decide to clean up their announcements. I think my suggestion is less complicated than what is contained in the draft however. I'm simply saying that we need an option, we'll call it squash-worthless-more-specifics, that you can apply on any specific BGP neighbor. Supposing you receive the following routes...... 192.168.0.0/16 AS11111 AS22222 AS33333 192.168.1.0/24 AS11111 AS22222 AS33333 192.168.2.0/24 AS11111 AS55555 AS44444 AS33333 192.168.3.0/24 AS11111 AS22222 AS33333 It would keep the 192.168.0.0/16 and 192.168.2.0/24 because they have different AS Paths and throw away 192.168.1.0/24 and 192.168.3.0/24. Judging from the CIDR-REPORT this would eliminate alot of garbage without affecting connectivity to people that are multi-homing with smaller PA blocks, or announcing more specifics to different providers for traffic engineering. Forrest
"Forrest" == Forrest <forrest@almighty.c64.org> writes:
Forrest> Sure, this would fail if a network decided to only announce Forrest> /24's for example without a larger aggregate, but how many Forrest> networks are really doing that? More than you probably imagine. Consider the following table: asn | count | c24 | c23 ----------+-------+------+----- 9583 | 1100 | 1014 | 42 7018 | 1140 | 764 | 125 17488 | 560 | 557 | 0 19916 | 568 | 532 | 6 701 | 729 | 501 | 38 1221 | 474 | 380 | 14 1239 | 572 | 359 | 24 577 | 417 | 337 | 19 209 | 587 | 329 | 38 17557 | 291 | 270 | 1 10292 | 270 | 267 | 2 4802 | 345 | 259 | 25 6140 | 315 | 243 | 16 4323 | 483 | 242 | 12 7474 | 284 | 228 | 8 2386 | 295 | 218 | 9 3301 | 307 | 217 | 30 702 | 392 | 206 | 34 6746 | 279 | 200 | 41 In this, "count" is the number of prefixes originated by the AS that are not covered by any longer prefix (without regard to origin); "c24" is the number of those prefixes which are /24s; "c23" is the number which are /23s. I've cut this table off at 200 - the total number of uncovered /24 routes across all ASes is 51811. Some of the above numbers would be worse if not for the presence of over-large route announcements from other providers (for example, Chinanet announce 125.96.0.0/14 even though 125.99.0.0/16 belongs to hathway.net in India (AS 17488); approximately 230 _more_ /24 routes announced by Hathway are in this range). -- Andrew, Supernews http://www.supernews.com
On Sat, 8 Sep 2007, Andrew - Supernews wrote:
"Forrest" == Forrest <forrest@almighty.c64.org> writes:
Forrest> Sure, this would fail if a network decided to only announce Forrest> /24's for example without a larger aggregate, but how many Forrest> networks are really doing that?
More than you probably imagine.
Consider the following table:
asn | count | c24 | c23 ----------+-------+------+----- 9583 | 1100 | 1014 | 42 7018 | 1140 | 764 | 125 17488 | 560 | 557 | 0 19916 | 568 | 532 | 6 701 | 729 | 501 | 38 1221 | 474 | 380 | 14 1239 | 572 | 359 | 24 577 | 417 | 337 | 19 209 | 587 | 329 | 38 17557 | 291 | 270 | 1 10292 | 270 | 267 | 2 4802 | 345 | 259 | 25 6140 | 315 | 243 | 16 4323 | 483 | 242 | 12 7474 | 284 | 228 | 8 2386 | 295 | 218 | 9 3301 | 307 | 217 | 30 702 | 392 | 206 | 34 6746 | 279 | 200 | 41
In this, "count" is the number of prefixes originated by the AS that are not covered by any longer prefix (without regard to origin); "c24" is the number of those prefixes which are /24s; "c23" is the number which are /23s. I've cut this table off at 200 - the total number of uncovered /24 routes across all ASes is 51811.
Some of the above numbers would be worse if not for the presence of over-large route announcements from other providers (for example, Chinanet announce 125.96.0.0/14 even though 125.99.0.0/16 belongs to hathway.net in India (AS 17488); approximately 230 _more_ /24 routes announced by Hathway are in this range).
You're right, that's way more than I would have imagined. Ok, why not combine the idea of throwing away more specific routes that have the same AS path as the larger aggregate with a mechanism that will do something like the CIDR-REPORT and aggregate bunches of routes that all have the same AS path. Or is the processing power/memory just not available to accomplish that? It seems either option would be better for not breaking connectivity than to simply reject anything longer than a /21 in 64/7 for example. Forrest
On Sat, Sep 08, 2007 at 05:50:25PM -0500, Forrest wrote: [snip]
It seems either option would be better for not breaking connectivity than [snip] Flatly, in my experience breaking connectivity for the apathetic or clueless folks abusing the commons is the only way to get them to change behavior. At worst, your own customers are inconvenienced while the other party gets rulers and prepares for a locker room measuring contest, and you relevent first poking a hole in a policy. At best, clued technical people trapped in the remote networks' organization get an "I told you so" reason to Do The Right Thing.
You can rathole the discussion on specific implementations and memory structures all the livelong day, but that won't change any individual operator's behavior. Are your confident YFRV will deliver any updated feature[s] in a timescale that fits your own networks' projected FIB & memory crush? Will it actually address the problem or just move the curve a little further into the future? Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
On Sun, 9 Sep 2007, Joe Provo wrote:
On Sat, Sep 08, 2007 at 05:50:25PM -0500, Forrest wrote: [snip]
It seems either option would be better for not breaking connectivity than [snip] Flatly, in my experience breaking connectivity for the apathetic or clueless folks abusing the commons is the only way to get them to change behavior. At worst, your own customers are inconvenienced while the other party gets rulers and prepares for a locker room measuring contest, and you relevent first poking a hole in a policy. At best, clued technical people trapped in the remote networks' organization get an "I told you so" reason to Do The Right Thing.
With the option of filtering on the RIR minimums, I'm not terribly worried about breaking connectivity to the people announcing all /24s instead of their /19. Broken connectivity for them is probably the only way they will ever look at cleaning up their announcements. The organizations that are hurt unnecessarily by filtering on the RIR minimums are the ones multi-homing with smaller PA space or announcing a few more specifics here and there for traffic engineering.
You can rathole the discussion on specific implementations and memory structures all the livelong day, but that won't change any individual operator's behavior. Are your confident YFRV will deliver any updated feature[s] in a timescale that fits your own networks' projected FIB & memory crush? Will it actually address the problem or just move the curve a little further into the future?
Cheers,
Joe
I'm not confident on getting any change implemented, or of it's effectiveness. I'm just trying to generate ideas to get people thinking of better methods of reducing routing table bloat without hurting everyone. Forrest
Thus spake "Forrest" <forrest@almighty.c64.org>
With the option of filtering on the RIR minimums, I'm not terribly worried about breaking connectivity to the people announcing all /24s instead of their /19. Broken connectivity for them is probably the only way they will ever look at cleaning up their announcements. The organizations that are hurt unnecessarily by filtering on the RIR minimums are the ones multi-homing with smaller PA space
Sucks to be them. If they do not have enough PA space to meet the RIR minima, the community has decided they're not "worthy" of a slot in the DFZ by denying them PI space. OTOH, most providers are happy to give out as much PA space as you need, as long as you pay for it. If you only have a /25 today and you need a /24 for your PA route to be heard, call your upstream's sales droid and request a /24.
or announcing a few more specifics here and there for traffic engineering.
Such folks would lose the effects of their TE, if their TE routes are longer than RIR minima, but not connectivity in general. Also, TE is only useful a few AS hops away, so the filter being discussed could be combined with another solution being proposed to allow longer-than-RIR-minima routes with a short AS PATH. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
Stephen Sprunk wrote:
Sucks to be them. If they do not have enough PA space to meet the RIR minima, the community has decided they're not "worthy" of a slot in the DFZ by denying them PI space.
Not true, there is an ARIN policy that allows you to get a /24 from one of your providers even if you only need 1 IP address: NPRM 4.2.3.6 "This policy allows a downstream customer's multihoming requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements." http://www.arin.net/policy/nrpm.html - Kevin
Thus spake "Kevin Loch" <kloch@kl.net>
Stephen Sprunk wrote:
Sucks to be them. If they do not have enough PA space to meet the RIR minima, the community has decided they're not "worthy" of a slot in the DFZ by denying them PI space.
Not true, there is an ARIN policy that allows you to get a /24 from one of your providers even if you only need 1 IP address:
NPRM 4.2.3.6
"This policy allows a downstream customer's multihoming requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements."
If the PA /24 is under 199/8 or 204-207/8, then the filters being discussed would allow their advertisement through, because ARIN's minimum allocation for those blocks is /24. In ARIN's 22 other /8s, the filters would not because the minimum is /20 (or /22, for 208/8). Let's also keep in mind that if other folks block a PA more-specific, the site doesn't lose connectivity unless they lose their upstream connection to the LIR that assigned them the block. I suspect that many of them already see that behavior today, at least partially; we're really discussing making it a near-complete outage versus a semi-outage. That's life if you don't qualify for a real routing slot via PI. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
I oppose wholesale filtering by allocation size policy as an acceptable metric for reducing your RIB. There are legitimate reasons to announce only /24s within a /21 or /22 PI allocation, for example. Perhaps an org has diverse networks in multiple cities and doesn't want to be beholden to upstream PA space. One may argue, "build a proper network, noob," but there may not be a business case for sufficient interconnect between sites to have a consistent origin AS. If one could filter in such a way that one only aggregated prefixes back to their allocated size when the AS path (or even origin AS) is the same, then you won't be breaking anyone, and will put the kibosh on the noobs who deagg for no good reason (but no vendor is giving us a 'filter-stupid' knob yet). Filtering/aggregating outside your local RIR seems like a better plan to me (for some networks, anyway). You're a whole lot less likely to have a bad/missing path, and you still have sufficient knobs to engineer most outbound flows. -Kevin Blackham (recently moved from provider to end network using non-XL PFC) On 9/10/07, Stephen Sprunk <stephen@sprunk.org> wrote:
Thus spake "Kevin Loch" <kloch@kl.net>
Stephen Sprunk wrote:
Sucks to be them. If they do not have enough PA space to meet the RIR minima, the community has decided they're not "worthy" of a slot in the DFZ by denying them PI space.
Not true, there is an ARIN policy that allows you to get a /24 from one of your providers even if you only need 1 IP address:
NPRM 4.2.3.6
"This policy allows a downstream customer's multihoming requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements."
If the PA /24 is under 199/8 or 204-207/8, then the filters being discussed would allow their advertisement through, because ARIN's minimum allocation for those blocks is /24. In ARIN's 22 other /8s, the filters would not because the minimum is /20 (or /22, for 208/8).
Let's also keep in mind that if other folks block a PA more-specific, the site doesn't lose connectivity unless they lose their upstream connection to the LIR that assigned them the block. I suspect that many of them already see that behavior today, at least partially; we're really discussing making it a near-complete outage versus a semi-outage. That's life if you don't qualify for a real routing slot via PI.
S
Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Mon, 10 Sep 2007, Stephen Sprunk wrote:
Sucks to be them. If they do not have enough PA space to meet the RIR minima, the community has decided they're not "worthy" of a slot in the DFZ by denying them PI space.
Not true, there is an ARIN policy that allows you to get a /24 from one of your providers even if you only need 1 IP address:
If the PA /24 is under 199/8 or 204-207/8, then the filters being discussed would allow their advertisement through, because ARIN's minimum allocation for those blocks is /24. In ARIN's 22 other /8s, the filters would not because the minimum is /20 (or /22, for 208/8).
As long as enough NSPs don't filter on RIR minimums, there's still a pretty good chance that when a small PA multihomer's IP space provider's connection is down, traffic routed towards that provider will get rerouted to their other provider(s). Breaking PA /24 multihoming would be unfortunate collateral damage. Perhaps someone could use the data from the cidr-report and RIRs to create a precision targeted prefix-list intended just to block unnecessary more specifics rather than across the board on RIR minimums? You could even do two different versions. A loose version that just throws out covered subnets with same as-path and a BOFH version that throws out all apparently gratuitous subnetting smaller than RIR minimums, but not all smaller than RIR minimum routes. I just wonder how huge the list would be and what the CPU and config size damage would be. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Tue, Sep 11, 2007, Jon Lewis wrote:
You could even do two different versions. A loose version that just throws out covered subnets with same as-path and a BOFH version that throws out all apparently gratuitous subnetting smaller than RIR minimums, but not all smaller than RIR minimum routes.
I just wonder how huge the list would be and what the CPU and config size damage would be.
If only people were charged for CPU time and RIB hardware space used on other peoples' routers to carry their stuff. (<tongue, cheek, etc />) Adrian
"Andrew" == "Andrew - Supernews" <andrew@supernews.net> writes:
[snip] Andrew> In this, "count" is the number of prefixes originated by the Andrew> AS that are not covered by any longer prefix (without regard Andrew> to origin); I of course meant "shorter", not "longer"... oops -- Andrew, Supernews http://www.supernews.com
Maybe this is a dumb question, but why isn't there a BGP option to just filter more specific routes that have the same AS path as the larger aggregate?
i think i filed that request case three or more years ago. zero response. randy
On Sun, 9 Sep 2007, Randy Bush wrote:
Maybe this is a dumb question, but why isn't there a BGP option to just filter more specific routes that have the same AS path as the larger aggregate?
i think i filed that request case three or more years ago. zero response.
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? Granted, the overhead involved would maybe be worth it on a platform like the 6500/7600, where you can end up with a surplus of RAM and not enough TCAM, if only the "active" routes were stored in TCAM, but 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. I just can't understand why they won't/haven't done a Sup32-3bxl for those using this platform but not moving enough Gbps to need the traffic capabilities of the Sup720-3bxl. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
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
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.
The problem with this is that if you reject the routes initially and then later need them, then they're not in your incoming BRIB to reconsider. BGP is an incremental protocol. You can either save an update or you can ignore it, but if you ignore it, it's just plain gone. If you do save it in your BRIB, then you can do this filtering between RIB and FIB. That turns out to be a completely local feature, requiring no protocol changes or additions whatsoever, and thus does not even require an RFC or Internet draft. This feature has been seen in some circles under the name "ORIB". Ask YFRV's PM for it. ;-) Note that this feature *is* CPU intensive. This also does not decrease the RP RAM usage the way that update filtering would. In fact, due to the overhead of tracking filtered and non-filtered prefixes, there is additional RP RAM usage. YMMV. Tony
If you do save it in your BRIB, then you can do this filtering between RIB and FIB. That turns out to be a completely local feature, requiring no protocol changes or additions whatsoever, and thus does not even require an RFC or Internet draft. This feature has been seen in some circles under the name "ORIB". Ask YFRV's PM for it. ;-)
Note that this feature *is* CPU intensive. This also does not decrease the RP RAM usage the way that update filtering would. In fact, due to the overhead of tracking filtered and non-filtered prefixes, there is additional RP RAM usage. YMMV.
so, bottom line, no help other than reducing fib? randy
On Sun, Sep 09, 2007, Randy Bush wrote:
so, bottom line, no help other than reducing fib?
Hm, are you going to communicate the filtered version of this BGP table to your BGP peers, or just pass everything but install the filtered RIB into FIB? (This is where someone pipes up with some modelling/research done into convergence as a function of npeers, CPU available, RIB, etc.) Adrian
The problem with this is that if you reject the routes initially and then later need them, then they're not in your incoming BRIB to reconsider. BGP is an incremental protocol. You can either save an update or you can ignore it, but if you ignore it, it's just plain gone.
If BGP is an incremental protocol (which of course, I know it is), why doesn't a certain vendor treat it that way? *cough* BGP Scanner *cough*. In any event, if the feature was implemented post-received routes (just like prefix-lists were with soft-reconfig), having a copy of the table that was sent to you by a peer, this would be trivial to do in code. Would it be CPU intensive? Perhaps, but so is having 225k routes and climbing. I'd submit that the CPU burned to do a route lookup on a BGP-RIB when a route is withdrawn or announced to see if something less specific exists would not in fact be that bad -- routing lookups, isn't that what a router is supposed to do? -- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net
On Sunday 09 September 2007 21:30, Alex Rubenstein wrote:
If BGP is an incremental protocol (which of course, I know it is), why doesn't a certain vendor treat it that way?
*cough* BGP Scanner *cough*.
Interesting you should mention this as we are planning to test an "improvement" to the BGP Scanner process, BGP Support for Next-Hop Address Tracking. Some notes from the vendor: "The BGP Support for Next-Hop Address Tracking feature is enabled by default when a supporting Cisco IOS software image is installed. BGP next-hop address tracking is event driven. BGP prefixes are automatically tracked as peering sessions are established. Next-hop changes are rapidly reported to the BGP routing process as they are updated in the RIB. This optimization improves overall BGP convergence by reducing the response time to next-hop changes for routes installed in the RIB. When a bestpath calculation is run in between BGP scanner cycles, only next-hop changes are tracked and processed." How much of an improvement this will make is what we are hoping to find out. Cheers, Mark.
I just can't understand why they won't/haven't done a Sup32-3bxl for those using this platform but not moving enough Gbps to need the traffic capabilities of the Sup720-3bxl.
This part here just boggles the mind. Not everybody out there that needs full routes is pushing enough bandwidth to justify the cost of a 720gbps backplane -- medium sized datacenters, regional ISPs, etc all really like full routes but may never see even 30gbps of traffic. Everybody I've talked to about this particular problem has the same feelings -- that big C is hanging their 6509 user base out to dry.
On 9 Sep 2007, at 08:02, randal k wrote:
This part here just boggles the mind. Not everybody out there that needs full routes is pushing enough bandwidth to justify the cost of a 720gbps backplane -- medium sized datacenters, regional ISPs, etc all really like full routes but may never see even 30gbps of traffic. Everybody I've talked to about this particular problem has the same feelings -- that big C is hanging their 6509 user base out to dry.
There are Vendor C platforms that can push much more than 30Gbit, and take a full table comfortably, that cost a lot less than 6500 series kit.
On 09/09/2007, Andy Davidson <andy@nosignal.org> wrote:
On 9 Sep 2007, at 08:02, randal k wrote:
This part here just boggles the mind. Not everybody out there that needs full routes is pushing enough bandwidth to justify the cost of a 720gbps backplane -- medium sized datacenters, regional ISPs, etc all really like full routes but may never see even 30gbps of traffic. Everybody I've talked to about this particular problem has the same feelings -- that big C is hanging their 6509 user base out to dry.
There are Vendor C platforms that can push much more than 30Gbit, and take a full table comfortably, that cost a lot less than 6500 series kit.
That sounds very nice, what box is that ? I can't remeber our C rep mentioning anything about that, but in C's defense I'm not always paying attention. -- Tony Sarendal - dualcyclone@gmail.com IP/Unix -= The scorpion replied, "I couldn't help it, it's my nature" =-
Forrest wrote:
Maybe this is a dumb question, but why isn't there a BGP option to just filter more specific routes that have the same AS path as the larger aggregate? This would allow the networks that announce more specifics for traffic engineering to still accomplish that, while throwing away the garbage from someone else that decides to announce their /19 as 33 routes for no apparent reason. Sure, this would fail if a network decided to only announce /24's for example without a larger aggregate, but how many networks are really doing that?
Forrest
There's a couple of feature requests open at Cisco that would do this. Rodney Dunn (at Cisco) pushed quite hard for these but couldn't get any traction. As he's previously pointed out it would have if people would vote for them (attach a case to). FORWARDED MESSAGE: Rodney Dunn wrote: Take your pick. :) CSCsa45474 Ability to block overlapping BGP prefixes from being installed in RIB or better: CSCsa46049 IOS RIB should not install overlapping routes with same next hop Rodney On Tue, Oct 03, 2006 at 05:26:51PM +0200, Gert Doering wrote:
Hi,
On Tue, Oct 03, 2006 at 11:09:16AM -0400, Rodney Dunn wrote:
I could never get them to agree to do it before and I have no reason to believe anything has changed.
Is there a CSC number that one could attach cases to?
gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert@greenie.muc.de fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de
_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
participants (17)
-
Adrian Chadd
-
Alex Rubenstein
-
Andrew - Supernews
-
Andy Davidson
-
Forrest
-
Joe Provo
-
Jon Lewis
-
Kevin Blackham
-
Kevin Loch
-
Mark Tinka
-
randal k
-
Randy Bush
-
Russ White
-
Sam Stickland
-
Stephen Sprunk
-
Tony Li
-
tony sarendal