|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: 204.82.160.0/22 invisible
In message <[email protected]>, E lliot Alby writes: > > 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: [email protected] 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
|