Hank Nussbacher wrote:
On Thu, 17 Aug 1995 00:30:19 +0200 (MET DST) you said:
Simon Poole wrote:
Yakov, if you have data that CIDR is -not- working for new allocations please present it here.
Simon
CIDR doesn't work as it should. We had to inject all of the more specifics of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly.
Can someone explain this a bit more? This sounds like a showstopper for CIDR.
Xlink (AS517) was announcing 194.45.0.0/16 via Ebone. There are some networks within this block announced by PSI. Routing table at PSI looks like Mitch Levinn wrote:
Hi there,
I've to second Mitch! Looks like a Sprint problem to me!! Mitch, would you be so kind to provide "show ip bgp 194.45.0.0 255.255.0.0 subnet" from the PSI box? Unfortunately neither Sprint nor Ebone NOC did anything (since Friday morning local time!) but ignoring the problem. I would really appreciate if EOT or Ebone NOC would try to fix this problem!
Here's the output requested (from our MAE-East+ router):
show ip bgp 194.45.0.0 255.255.0.0 subnet BGP table version is 1444840, local router ID is 192.41.177.245 Status codes: s suppressed, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path *> 194.45.0.0 38.1.2.10 5 32768 i *> 194.45.0.0/16 192.41.177.241 0 1239 1800 1755 517 ? *> 194.45.1.0 38.1.2.10 5 32768 i *> 194.45.2.0 38.1.2.10 5 32768 i *> 194.45.3.0 38.1.2.10 5 32768 i *> 194.45.4.0 38.1.2.10 5 32768 i *> 194.45.5.0 38.1.2.10 5 32768 i *> 194.45.6.0 38.1.2.10 5 32768 i *> 194.45.7.0 38.1.2.10 5 32768 i *> 194.45.16.0 192.41.177.181 0 3561 1220 ?
This is just as it was last time the problem surfaced, I believe. Subnets 0 through 7 are properly being announced through us, subnet 16 goes to MCI, and the rest to Sprint.
-Mitch
But Sprintlink was routing
traceroute -g c.psi.net 194.45.41.1 traceroute to 194.45.41.1 (194.45.41.1), 30 hops max, 40 byte packets 1 KarlSruhe.Core.xlink.net (193.141.40.252) 2 ms 5 ms 2 muenchen.core.xlink.net (192.54.104.241) 18 ms 10 ms 3 Munich-EBS.EBONE.NET (192.121.158.13) 12 ms 13 ms 4 icm-dc-1-S2/5-1984k.icp.net (198.67.129.17) 210 ms 141 ms 5 icm-mae-e-H1/0-T3.icp.net (198.67.131.9) 310 ms 253 ms 6 mae-east.psi.net (192.41.177.245) 254 ms 266 ms 7 c.psi.net (192.33.4.12) 257 ms 289 ms 8 192.33.4.1 (192.33.4.1) 227 ms 257 ms 9 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 245 ms 250 ms 10 mae-east.psi.net (192.41.177.245) 203 ms 228 ms 11 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 215 ms 193 ms
TT to Sprintlink didn't help. After 4 days still no response. I've fixed this silly routing by announcing all more specifics.
Arnold
Hank
Arnold
In message <"xlink100.x.910:17.07.95.23.48.56"@xlink.net>, Arnold Nipper writes :
Hank Nussbacher wrote:
On Thu, 17 Aug 1995 00:30:19 +0200 (MET DST) you said:
Simon Poole wrote:
Yakov, if you have data that CIDR is -not- working for new allocations please present it here.
Simon
CIDR doesn't work as it should. We had to inject all of the more specifics of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly.
Can someone explain this a bit more? This sounds like a showstopper for CIDR.
Xlink (AS517) was announcing 194.45.0.0/16 via Ebone. There are some networks within this block announced by PSI. Routing table at PSI looks like
[ deleted for brevity ]
But Sprintlink was routing
[ deleted for brevity ]
TT to Sprintlink didn't help. After 4 days still no response. I've fixed this silly routing by announcing all more specifics.
Arnold
The way this is supposed to work is the originator announces the aggregate and registers in in the IRR. When confident that the aggregate is reaching where it needs to go, the originator stops announcing the components. If you are the originator of these routes, where is PSI getting the routes from? If you are not the originator and are doing a proxy aggregation, you have to be sure that anyone else that the originator is advertising the routes to is either also doing proxy aggregation, or is the intended primary for these routes (or more preferred than you are). In a coordinated multiprovider proxy aggregation, if you can't all withdraw the componenents simultaneously, the least preferred provider needs to withdraw the components first, then the next least preferred, etc, until all providers doing proxy have withdrawn the cpomponents. The only sure way to know if you are going to break things are: 1) check with a reliable IRR (the IRR exists, but there is some question about whether it can be called "reliable"), or 2) try it and see what breaks, or 3) do your best with the less than perfect IRR and the try 2). The problem was not with Sprint if PSI was annoncing the components, unless you were expecting Sprint to proxy aggregate for PSI (which perhaps they hadn't yet agreed to do). A TT would not be the way to request proxy aggregation from another provider. Curtis
Curtis Villamizar wrote:
In message <"xlink100.x.910:17.07.95.23.48.56"@xlink.net>, Arnold Nipper writes :
Hank Nussbacher wrote:
On Thu, 17 Aug 1995 00:30:19 +0200 (MET DST) you said:
Simon Poole wrote:
Yakov, if you have data that CIDR is -not- working for new allocations please present it here.
Simon
CIDR doesn't work as it should. We had to inject all of the more specifics of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly.
Can someone explain this a bit more? This sounds like a showstopper for CIDR.
Xlink (AS517) was announcing 194.45.0.0/16 via Ebone. There are some networks within this block announced by PSI. Routing table at PSI looks like
[ deleted for brevity ]
But Sprintlink was routing
[ deleted for brevity ]
TT to Sprintlink didn't help. After 4 days still no response. I've fixed this silly routing by announcing all more specifics.
Arnold
The way this is supposed to work is the originator announces the aggregate and registers in in the IRR. When confident that the aggregate is reaching where it needs to go, the originator stops announcing the components.
I think I've to clarify. AS517 is announcing 194.45.0.0/16 since a couple of months and we did *NOT* announce any more specific. On May, 17th 1995 routing for 194.45.0.0/16 broke the firt time. Here's what Vadim Antonov wrote: Date: Wed, 17 May 1995 19:13:42 -0400 From: Vadim Antonov <avg@sprint.net> Message-Id: <199505172313.TAA10358@titan.sprintlink.net> To: as174-trouble@merit.edu, as1800-trouble@merit.edu, avg@sprint.net, noc@mci.net, noc@xlink.net Subject: Re: Route for 194.45/16 194.45/24 Cc: uhl@hermes.hn-net.de Status: RO That's funny: ICM-MAE-E>sh ip bgp 194.45.0.0 255.255.0.0 s BGP table version is 4081305, local router ID is 198.67.131.49 Status codes: s suppressed, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 194.45.0.0 192.41.177.245 90 0 1239 174 i * i 192.157.65.25 90 0 1239 174 i *>i194.45.0.0/16 192.157.65.49 0 100 0 1755 517 ? *> 194.45.1.0 192.41.177.245 90 0 1239 174 i * i 192.157.65.25 90 0 1239 174 i *> 194.45.2.0 192.41.177.245 90 0 1239 174 i * i 192.157.65.25 90 0 1239 174 i *> 194.45.3.0 192.41.177.245 90 0 1239 174 i * i 192.157.65.25 90 0 1239 174 i *> 194.45.4.0 192.41.177.245 90 0 1239 174 i * i 192.157.65.25 90 0 1239 174 i *> 194.45.5.0 192.41.177.245 90 0 1239 174 i * i 192.157.65.25 90 0 1239 174 i *> 194.45.6.0 192.41.177.245 90 0 1239 174 i * i 192.157.65.25 90 0 1239 174 i *> 194.45.7.0 192.41.177.245 90 0 1239 174 i * i 192.157.65.25 90 0 1239 174 i ICM-MAE-E> Routing appears to be ok on our side, so i included MCI in the list. --vadim From nipper@xlink.net Wed May 17 16:22:13 1995 Received: from tiny.sprintlink.net (tiny.sprintlink.net [199.0.55.90]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id QAA09524 for <avg@titan.sprintlink.net>; Wed, 17 May 1995 16:22:10 -0400 Received: from xlink100.xlink.net (pp@xlink100.xlink.net [193.141.42.100]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id QAA06360 for <avg@sprint.net>; Wed, 17 May 1995 16:22:08 -0400 Received: from xlink.net by xlink100.xlink.net id <11082-0@xlink100.xlink.net>; Wed, 17 May 1995 22:21:38 +0200 Subject: Route for 194.45/16 194.45/24 To: as1800-trouble@merit.edu, as174-trouble@merit.edu, avg@sprint.net Date: Wed, 17 May 1995 22:21:20 +0200 (MET DST) Cc: noc@xlink.net (Xlink Network Operations Center), uhl@hermes.hn-net.de Priority: high Reply-To: noc@xlink.net (Xlink Network Operations Center) X-Organisation: NTG/Xlink GmbH, Karlsruhe/Germany X-Mailer: ELM [2.4 PL23] X-From: nipper@xlink.net (Arnold Nipper) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2870 From: Arnold Nipper <nipper@xlink.net> Sender: nipper@xlink.net Message-ID: <"xlink100.x.086:17.04.95.20.21.41"@xlink.net> Status: R Hi Sprint- and PSI - people, block 194.45/16 is assigned to Xlink (AS517) and visible via Ebone as 194.45/16. Networks 194.45/22, 194.45.4/23 194.45.6/23 are now routed via PSI (AS174) and visible as: 194.45.0/24 194.45.1/24 194.45.2/24 194.45.3/24 194.45.4/24 194.45.5/24 194.45.6/24 194.45.7/24 with AS path (relative to AS517): 1755 1800 1239 174 Could you please check routing for 194.45/16? Examples: trc -g 204.70.57.9 194.45.226.1 traceroute to 194.45.226.1 (194.45.226.1), 30 hops max, 40 byte packets 1 gw1.xlink.net (193.141.42.126) 3 ms 3 ms 2 gw8.xlink.net (193.141.40.252) 7 ms 9 ms 3 gw2.xlink.net (192.54.104.241) 14 ms 16 ms 4 Munich-EBS.EBONE.NET (192.121.158.13) 38 ms 19 ms 5 icm-dc-1-S2/5-1984k.icp.net (198.67.129.17) 171 ms 226 ms 6 icm-mae-e-H1/0-T3.icp.net (198.67.131.9) 238 ms 191 ms 7 192.41.177.181 (192.41.177.181) 177 ms 155 ms 8 border2-hssi4-0.Washington.mci.net (204.70.57.9) 144 ms 163 ms 9 mae-east-plusplus.Washington.mci.net (204.70.57.10) 180 ms 137 ms 10 mae-east.psi.net (192.41.177.245) 183 ms 176 ms 11 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 296 ms 351 ms 12 mae-east.psi.net (192.41.177.245) 541 ms 153 ms trc -g 204.70.57.9 194.45.197.50 traceroute to 194.45.197.50 (194.45.197.50), 30 hops max, 40 byte packets 1 gw1.xlink.net (193.141.42.126) 3 ms 2 ms 2 gw8.xlink.net (193.141.40.252) 12 ms 3 ms 3 gw2.xlink.net (192.54.104.241) 13 ms 13 ms 4 Munich-EBS.EBONE.NET (192.121.158.13) 17 ms 18 ms 5 icm-dc-1-S2/5-1984k.icp.net (198.67.129.17) 214 ms 229 ms 6 icm-mae-e-H1/0-T3.icp.net (198.67.131.9) 212 ms 475 ms 7 192.41.177.181 (192.41.177.181) 250 ms 132 ms 8 border2-hssi4-0.Washington.mci.net (204.70.57.9) 202 ms 136 ms 9 mae-east-plusplus.Washington.mci.net (204.70.57.10) 245 ms 229 ms 10 mae-east.psi.net (192.41.177.245) 314 ms 302 ms 11 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 547 ms 270 ms 12 mae-east.psi.net (192.41.177.245) 331 ms 234 ms All of our customers within block 194.45/16 have severe problems. >traceroute sunsite.unc.edu 1 hades (194.45.197.50) 2 ms 3 ms 2 ms 2 heilbronn.pop.xlink.net (193.141.43.74) 3 ms 3 ms 3 gw8.xlink.net (193.141.43.73) 51 ms 46 ms 43 ms 4 gw2.xlink.net (192.54.104.241) 52 ms 67 ms 58 ms 5 Munich-EBS.EBONE.NET (192.121.158.13) 64 ms 56 ms 58 ms 6 icm-dc-1-S2/5-1984k.icp.net (198.67.129.17) 164 ms 167 ms 176 ms 7 icm-mae-e-H1/0-T3.icp.net (198.67.131.9) 239 ms 228 ms 437 ms 8 * * * Thank you, Arnold -- Arnold Nipper / email: nipper@xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich Xlink /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany On July, 31st and August, 4th the same problem occurred. Unfortunately Sprint- link was unable (in fact they never sent an answer) to fix the problem. The *ONLY* solution for AS517 to give connectivity to our customers was to add all more specifics beside the /16. I would be very happy to withdraw the more specifics, but whenever I do connectivity is gone.
Curtis
Arnold
participants (2)
-
Arnold Nipper -
Curtis Villamizar