204.82.160.0/22 invisible

SL-MAE-W#sho ip route 204.82.160.0
Routing entry for 204.82.0.0 255.255.0.0, supernet
  Known via "bgp 1239", distance 20, metric 1
  Tag 3561, type external
  Last update from 198.32.136.12 05:00:20 ago
  Routing Descriptor Blocks:
  * 198.32.136.12, from 198.32.136.12, 05:00:20 ago
      Route metric is 1, traffic share count is 1

198.32.136.12 = mae-west.SanFrancisco.mci.net

seems ok to me.

We put the /22 route in on Monday on a temporary basis despite the
lack of a route object, but Sprint is not announcing it. The /16 was
already configured (last April based on the date in the route object).

> > Fix: Either get ANS to not insist on all routes being in the RADB or
> > submit an update to the RADB & wait for ANS to regenerate their
> > configs.

the latter is quicker and pragmatic. but i wish ans would quit splitting
hairs on the subnet mask, we would need to submit so many less route
objects..

- elliot alby/sprintlink

1 en-0.enss470.t3.ans.net (204.148.1.30) 2.265 ms 2.066 ms 2.01 ms
2 t0-0.cnss52.Hartford.t3.ans.net (192.103.65.9) 27.96 ms 27.349 ms 27.415 ms
3 mf-0.cnss48.Hartford.t3.ans.net (140.222.48.222) 28.37 ms 27.288 ms 27.306 ms
4 t3-2.cnss32.New-York.t3.ans.net (140.222.32.3) 30.487 ms 30.32 ms 30.806 ms
5 t3-0.enss218.t3.ans.net (140.222.218.1) 36.292 ms 35.376 ms 35.682 ms
6 sprintnap.mci.net (192.157.69.11) 37.03 ms 36.834 ms 37.303 ms
7 border2-hssi1-0.NewYork.mci.net (204.70.45.5) 48.143 ms 41.863 ms 40.864 ms
8 core-fddi-1.NewYork.mci.net (204.70.3.17) 44.199 ms 40.1 ms 43.824 ms
9 core1-hssi-2.WestOrange.mci.net (204.70.1.98) 83.528 ms 46.626 ms 207.889 ms
10 core1-hssi-3.NorthRoyalton.mci.net (204.70.1.101) 270.636 ms 53.234 ms 53.712 ms
11 core-hssi-2.Chicago.mci.net (204.70.1.93) 66.218 ms 61.415 ms 60.72 ms
12 border3-fddi-0.Chicago.mci.net (204.70.2.83) 68.132 ms 61.701 ms 62.365 ms
13 canet.Chicago.mci.net (204.70.26.10) 82.314 ms 75.986 ms 76.336 ms
14 205.207.238.141 (205.207.238.141) 82.569 ms 77.25 ms 78.517 ms
15 205.207.238.93 (205.207.238.93) 98.424 ms 95.948 ms 100.419 ms
16 regional2.nb.canet.ca (192.68.57.102) 100.123 ms 97.174 ms 97.565 ms
17 tel.nbnet.nb.ca (198.164.29.66) 105.887 ms 104.426 ms 112.008 ms
18 198.164.27.14 (198.164.27.14) 128.397 ms !H * 133.737 ms !H

We are seeing a black hole at a CANET aggregate. If Sprint would
announce the more specific /22 we would send the packet to Sprint
rather than to CANET by way of MCI. Below is the registered aggregate
(with the list of holes removed).

route: 204.82.0.0/16
advisory: AS690 1:3561(27) 2:3561(218) 3:3561(147) 4:3561(11) 5:3561(144)
descr: NB-SCHOOLS
origin: AS807
comm-list: CANET_PROXY_AGGRS
mnt-by: CANET-RC
changed: config@canet.ca 950406
source: CANET

Isn't this the form of aggregation without fully considering topology
that we discussed at NANOG. Sprint need to announce something more
specific than /16 and they need to register it so others know if you
are further aggregating the /22 or something.

Thanks,

Curtis