> Poking at this futher, Sprint is announcing 204.82.160/22; Digex is
> behind ANS; this route is not in the RADB; and since ANS insists on all
> routes being in the RADB, they are not accepting it, so Digex is not
> seeing it.
not so (see below) i see only 204.82.0.0
We are configured to hear this announcement at the Sprint NAP and
Mae-East via AS1239 but it is not being announced.
Could someone tell me *where* Sprint is announcing 204.82.160/22? I don't
see it at the CIX or at any point where ANS peers with Sprint. It
appears as if only 204.82/16 is being announced by MCI:
SL-MAE-E#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 192.41.177.181 05:06:43 ago
Routing Descriptor Blocks:
* 192.41.177.181, from 192.41.177.181, 05:06:43 ago
Route metric is 1, traffic share count is 1
ICM-MAE-E#sho ip route 204.82.160.0
Routing entry for 204.82.0.0 255.255.0.0, supernet
Known via "bgp 1800", distance 20, metric 0
Tag 3561, type external
Last update from 192.41.177.181 3d13 ago
Routing Descriptor Blocks:
* 192.41.177.181, from 192.41.177.181, 3d13 ago
Route metric is 0, traffic share count is 1
192.41.177.181 = cpe2.Washington.mci.net
checking arbitrarily on sprintlink backbone:
SL-FW-8#sho ip route 204.82.160.0
Routing entry for 204.82.0.0 255.255.0.0, supernet
Known via "bgp 1791", distance 20, metric 1
Tag 1239, type external
Last update from 144.228.105.1 04:10:01 ago
Routing Descriptor Blocks:
* 144.228.105.1, from 144.228.30.5, 04:10:01 ago
Route metric is 1, traffic share count is 1
144.228.105.1 = sl-mae-w.sprintlink.net
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.
>
> 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