CIDR
Paul Traina
pst at cisco.com
Fri Mar 11 21:49:39 UTC 1994
1. Make sure no non-private ASs (for lack of a better work)
which are neigher CIDRized nor defaulting to other ASs.
Err, could you restate that? I'm having a bit of a problem parsing this.
2. Gain more confidenece with the newly deployed CIDR in the networks
More aggressive testing: injecting test CIDR routes to the
Internet, announce it to the bgpd list along with a couple
of pingable hosts in the aggregate.
Haven't we done enough of this already? I think that EVERY site should go
through this phase to verify their configurations and make sure their neighbors
aren't doing anything stupid, but I see no need for a site that has been
CIDR-clueful for 6 months to continue pussyfooting about.
3. Establish procedures for ASs to announce the replacement of
individual net routes to aid the detection of potential impact/probl
of removing such routes from the Internet.
Andrew(?) suggested that ASs announce to the bgpd mailing
list the list of individual intented to be replaced by
an aggregate route several days prior to the remove.
This should be a good start, shall we agree on do
that? Is 3 days in advance reasonable ?
Is everyone in the world (or at least on bgpd) going to go to the trouble
of checking to see if they have a -correct- aggregate route covering
the individual networks and report problems if they do not? Furthermore,
if they don't have the route, what tools are there in place for tracking
down the lack of said route? If I'm advertising
131.108.0.0
and 131.109.0.0
and I want to replace them with 131.108.0.0/15, we can't track down the
AS who is swallowing the CIDR route until we actually rip out one of
the less specific routes. Given that hurdle, I suggest cutting the
administriva and yanking the less specific routes at a nice slow managable
rate and watching the fireworks.
Then we send neutron tipped traceroutes to anyone who is still blackholing
CIDR connectivity. :-)
More information about the NANOG
mailing list