Milo,

Dennis, I'd really second the suggestion you made about pulling the default. If a pile of people are pointing default at the NSFNet, and then you are pushing it to Dante, there is probably a pile of garbage traffic that is being passed along to Dante rather than being stopped at the entry point into NSFNet. So besides confusing where the problem is, it's also probably creating network "hot spots".

If you don't need the default anymore, I'd really reccommend you get rid of it.

Thanks, Milo

One of the reasons that we have continued with default is that some folks will loose connectivity to nets behind ASs such as NSI which don't point default. Jeff had sent a note indicating that you all were almost ready to deploy something which would address this. Has that been done? I wouldn't want to stop pointing default to AS1133 if a set of folks will loose connectivity to the Pacific Rim. --Elise

From: Dennis Ferguson <dennis@ans.net> Subject: Re: CIDR deployment Erik-Jan,

NET ASN REGIONAL COUNTRY RESULT ------------ -------- -------------------- ------------- --------- 133.11.0.0 AS372(?) NSN-AMES-AS(?) Japan Unreach 128.250.0.0 AS372(?) NSN-AMES-AS(?) Australia Unreach

This is not actually NSI's problem, it is caused by the fact that the NSFnet has not been configured to accept 192.87.111/22 and hence is not carrying it. The confusing part is that connectivity through there to most places still works because the NSFnet has a default route pointing at Washington2.Dante.net, which runs without route filters. What this breaks, however, is that since NASA doesn't default to anyone they won't be able to reach anything which isn't explicitly announced to them, but we don't have the route to send to them. Dennis, could you comment about the state of the registries? For the past week, BARRnet has been attempting to get our CIDR blocks into the registries, BARRnet says they are advertising our networks to ANS, but I don't see the route on the other side at the ICM. At the current state of the art, then, you really need to have the aggregate configured into the NSFnet database before this will work well. We should also consider pulling the default route from the backbone, it is in principle no longer needed and causes no end of confusion about where the problems are occurring. In principle, I agree with you 100%, however, I'd like some assurances that the Merit registries aren't completely AFU since some folks have already done their withdrawls, and if you've got a problem inside ANS, they default route may be their only saving grace. On the other side, I do agree with you that if there is a NSF/Merit/ANS problem, we need to be able to discover where the problem lies with existing network tools. Would someone in NSI care to coment about routing? Are you folks carrying a default to your FIX-W router or what?

Paul and Dennis, The routing database has consistent and reliable information. There are two reports available on nic.merit.edu:nsfnet/announced.networks which list classless nets in the routing database. The file names are: nets.non-classful and nets.nestings. Like everyone who is dealing with CIDR/BGP4 we are learning what works and what doesn't. BARRNET submitted the request and in doing a routine routing check we discovered that the aggregate and the previously registered component networks had inconsistent policies. That delayed the configuration of the aggregate and caused us to reevaluate the process for handling these types of inconsistencies. If you all want to check to see if there are any inconsistencies between classful nets and the classless net that should be configured in the NSFNET database, you can use a tool that Merit has implemented. Issue the command: whois -h prdb.merit.edu 'aggchk <agg>' --Elise

Paul,

...

Dennis, could you comment about the state of the registries? For the past week, BARRnet has been attempting to get our CIDR blocks into the registries, BARRnet says they are advertising our networks to ANS, but I don't see the route on the other side at the ICM.

I haven't been paying nearly enough attention to the input end of the registration process (I have a number of people annoyed with me about this) but I know that the configuration files which come out the output end seem to have all the right stuff. I know the BARRnet aggregates didn't get configured due to some misunderstanding which I hope is exceptional, if they're not in tomorrow I'll configure them by hand. I know of no endemic problems at all.

...

already done their withdrawls, and if you've got a problem inside ANS, they default route may be their only saving grace. On the other side, I do agree with you that if there is a NSF/Merit/ANS problem, we need to be able to discover where the problem lies with existing network tools.

Yes, this is exactly my problem with the default. I would really like to get remaining bugs out of ANS' network and the routing with our neighbours as soon as possible, but it has progressed to the point where the only way I have to do this is to listen for the screams of people who might be affected by them. If the default route is "fixing" some people's problems (and I suspect it may be since there have been way too few screams given the magnitude of the change that was just made) then we aren't fixing the problems. I'd much rather hear some screaming at this point.

Dennis