Re: A couple of possibly interesting stats.
A lot of the regional networks have more than one attachment point to ANSnet. Some use one as primary and one as backup. Most of the regional networks announce some of their networks as primary at one attachment point and other networks at another attachment point. This means that that regional could not aggregate before reaching ANSnet because to do so would mean losing the load balancing. One longer term way around this is to have ANS accept more specific routes plus an aggregate and propogate the more specific routes into it's IBGP but not propogate them further (just the aggregate). Is this really a common case? BARRNet has two attachments to ANS/NSFNET, but they are strictly primary/secondary, so the same aggregates will be advertised at both locations. Any network provider which is using multiple ANS/NSFNET connections to split load should have an addressing plan that assigns a different aggregate to each exit point. The basic rule is: for each routing policy you have, you should have different CIDR block. I thought we'd been over this in at least the Regional Techs forum before. --Vince
Vince,
Is this really a common case? BARRNet has two attachments to ANS/NSFNET, but they are strictly primary/secondary, so the same aggregates will be advertised at both locations.
Two regionals I can think of off hand are Suranet and CANET. NASA and ESNET and other agencies connected at both FIXes also load balance. There may be others.
Any network provider which is using multiple ANS/NSFNET connections to split load should have an addressing plan that assigns a different aggregate to each exit point. The basic rule is: for each routing policy you have, you should have different CIDR block. I thought we'd been over this in at least the Regional Techs forum before.
--Vince
We all know that and it is goodness. But the analysis that Tony did was based on AS aggregation of all network numbers including those in assigned prior to CIDR and those assigned in the early in the CIDR deployment when allocation may not have been quite as systematic. I'm not saying CIDR isn't going to be highly beneficial, it will be. I'm just saying that Tony's figures are optimistic. Since I don't have a better analysis to offer, and having made my minor point, I'll shut up now. :-) Curtis
Any network provider which is using multiple ANS/NSFNET connections to split load should have an addressing plan that assigns a different aggregate to each exit point. The basic rule is: for each routing policy you have, you should have different CIDR block. I thought we'd been over this in at least the Regional Techs forum before.
I have actually been aiming towards supporting having one's cake and eating it too, with route colouring. That is, a neighbour who wanted to split their load between several direct gateways, but who also wanted to advertise a provider aggregate, would advertise the aggregate route plus enough more specific routes to get us to the correct gateway. We would colour the more specific routes not to be advertised to anyone else, so only the aggregate route would be propagated elsewhere. This isn't quite done yet, but it is being worked on. This assumes, of course, that everyone else pulls enough routes out that we have the luxury of forwarding table space to support this. I suspect a 32M RS/6000 can carry a bigger routing load than a 16M cisco but not a whole lot more, so if we get to the point where 16M ciscos are crashing-and-burning more frequently we'll also be looking for ways to shed routing load. I think we're getting perilously close to a time when there will be no time to experiment with this stuff, it'll be do, or die, or make your router vendors very wealthy ordering upgrades. In fact the way things are going I sort of wish I'd found a job with a router vendor rather than an operator. Dennis Ferguson
In fact the way things are going I sort of wish I'd found a job with a router vendor rather than an operator.
The stock options are probably better ;-) Hey, it could be worse, you could work for the Government :-( Jeff
A lot of the regional networks have more than one attachment point to ANSnet. Some use one as primary and one as backup. Most of the regional networks announce some of their networks as primary at one attachment point and other networks at another attachment point. This means that that regional could not aggregate before reaching ANSnet because to do so would mean losing the load balancing. One longer term way around this is to have ANS accept more specific routes plus an aggregate and propogate the more specific routes into it's IBGP but not propogate them further (just the aggregate).
Is this really a common case? BARRNet has two attachments to ANS/NSFNET, but they are strictly primary/secondary, so the same aggregates will be advertised at both locations.
PREPnet is planning to put such a scheme into place in the near future.
Any network provider which is using multiple ANS/NSFNET connections to split load should have an addressing plan that assigns a different aggregate to each exit point. The basic rule is: for each routing policy you have, you should have different CIDR block. I thought we'd been over this in at least the Regional Techs forum before.
Unfortunately, PREPnet already has a CIDR block half allocated, and it doesn't match the policy needed to do traffic splitting into ANSnet. It would be wise to do this, but only when you can foresee what the policies will be in advance. If you can't guess what your policy will be in the future... I'm sure Noel would have inspiring comments to make about re-addressing at this point. --Jamshid
Any network provider which is using multiple ANS/NSFNET connections to split load should have an addressing plan that assigns a different aggregate to each exit point. The basic rule is: for each routing policy you have, you should have different CIDR block. I thought we'd been over this in at least the Regional Techs forum before.
Unfortunately, PREPnet already has a CIDR block half allocated, and it doesn't match the policy needed to do traffic splitting into ANSnet. It would be wise to do this, but only when you can foresee what the policies will be in advance. If you can't guess what your policy will be in the future...
Another future happy customer of Dennis's route coloring. Either that or we could make some configs that block announcements of IBGP refines of certain aggregates. More work for Dale and friends. Boy do we have job security! Curtis
This is an interesting twist that seems to validate a comment I made at one of the regional techs meetings. It is not sufficent to have the "backbone" providers CIDR capable, what is required is to have the regionals be cidr capable. So here's the plan. Invite everyone who has received a cidr block to turn in an announcement request for the cidr block to your provider. It won't hurt and will get us to the next step. You don't have to do much. - Turn in the NACR You don't have a vlsm-capable IGP deployed? Not to worry. Nail up a static route for the aggregate. This seems to work just fine if you are stuck w/ cisco IGRP. With RIP based nets, a few more statics will do the trick. Then its time to get to work on a local transition plan to a real IGP, like.... IISIS! -- Regards, Bill Manning
participants (6)
-
bmanning@is.rice.edu -
Curtis Villamizar -
Dennis Ferguson -
jeff@nsipo.nasa.gov -
mahdavi@tesla.psc.edu -
Vince Fuller