204.82.160.0/22 invisible

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.

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:

BGP routing table entry for 204.82.0.0/255.255.0.0, version 724795
Paths: (1 available, best #1) advertised over EBGP
  1280 3561 577 807 (aggregated by 577 192.68.66.14)
    149.20.5.1 from 149.20.5.1 (149.20.64.1)
      Origin EGP, valid, external, atomic-aggregate, best

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.

Kai: Please don't widly accuse folks before poking into the facts.
  --asp@uunet.uu.net (Andrew Partan)

Thanks.

<markd>

> 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