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

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 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

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

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."

http://www.arin.net/policy/nrpm.html

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 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

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

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

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

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 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" =-