Re: 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. 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)
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
In message <Pine.SV4.3.91.950927113347.18109C-100000@mercury.sprintlink.net>, 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: 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
Check 206.82.160/22 - there was a typo in the 1st message sent. There is still no RADB route object for this. --asp@uunet.uu.net (Andrew Partan) Vienna1-gw>sh ip b 206.82.0.0 255.255.0.0 l BGP table version is 2988688, local router ID is 137.39.2.31 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 206.82.160.0/22 192.41.177.241 86 0 1239 1794 ? *>i 198.32.136.11 22 100 0 1239 1794 ?
I must have missed the correction - thanks. 206.82.160/22 is now being routed on ANSnet. <markd>
Check 206.82.160/22 - there was a typo in the 1st message sent.
There is still no RADB route object for this. --asp@uunet.uu.net (Andrew Partan)
Vienna1-gw>sh ip b 206.82.0.0 255.255.0.0 l BGP table version is 2988688, local router ID is 137.39.2.31 Status codes: s suppressed, d damped, h history, * valid, > best, i - interna l Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path * 206.82.160.0/22 192.41.177.241 86 0 1239 1794 ? *>i 198.32.136.11 22 100 0 1239 1794 ?
I must have missed the correction - thanks.
206.82.160/22 is now being routed on ANSnet.
argh, thanks for pointing that out. the owner of 204.82.160 is a downstream cust of mine. coincidently, i just got mail from belcom (who have 204.82.160), and a separate route object is on the way. (i was WONDERING why someone would want us sending a route object on an mci cust..) - elliot/sprint
participants (4)
-
asp＠uunet.uu.net -
Curtis Villamizar -
Elliot Alby -
Mark Davisson