Re: not rewriting next-hop, pointing default, ...
I hate when contact numbers are disconnected. Does anyone have a good contact for MAI.net? -scott huddle@new6% whois -h rs.internic.net mai.net MAI Network Services (MAI3-DOM) 8200 Greensboro Drive Suite 1400 McLean, VA 22102 Domain Name: MAI.NET Administrative Contact, Technical Contact, Zone Contact: Bono, Vincent J. [1LT] (VB14) vbono@MAI.NET 703-734-8602 1-800-918-0524 (FAX) 1-703-506-1436 Record last updated on 04-Jun-96. Record created on 28-Jun-95. Database last updated on 10-Sep-97 04:58:14 EDT. Domain servers in listed order: NS1.MAI.NET 204.152.42.33 NS2.MAI.NET 204.152.42.12 The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. Randy Bush <randy@psg.com> wrote
a senior engineer at a well-known provider just pointed out to us that a weenie provider at mae-east was o not rewriting next-hop o sending our routes to others o sending others' routes to us o likely pointing default at us
their noc phone was answered by a modem. we suspended peering with them and wrote to their noc. we got back a snotty message. we have ceased peering with them.
we installed packet filters. our traffic on the east fddi dropped noticeably.
when the larger providers decline to peer with the smaller, there is a sad reason. traceroute -g is your friend.
randy
I hate when contact numbers are disconnected. Does anyone have a good contact for MAI.net?
no neighbor 192.41.177.73
randy
MAI's Internet division has been acquired by Comstor. I believe Vinny can be reached chez Comstor in Northern VA. Avi
I hate when contact numbers are disconnected. Does anyone have a good contact for MAI.net?
no neighbor 192.41.177.73 ^^^^^^^^^^^^^^^^^^^^^^^^^ they should not care if you peer with them or not, they can have the upstream provider to give them your routes, then: ! set nexthop 192.41.177.121 !
randy
- Naiming Shen MCI - MCI Internet Engineering 2100 Reston Parkway - +1 703-715-7056 fax:703-715-7066 v272-7056 Reston, VA 20191
no neighbor 192.41.177.73 they should not care if you peer with them or not, they can have the upstream provider to give them your routes, then: ! set nexthop 192.41.177.121
Yes, folk seem to be doing this kind of thing, as shocking and disgusting as it seems. The problem is not agreements. The problem is, as Scott says, detecting violation thereof is not easy. But traceroute -g is your friend. E.g. UUNET's peering policy seems to be far more liberal than the press would have us believe. [ undoubtedly some of these are valid UUNET peers. ] I also think it may be time we refuse to peer with anyone who inhibits LSR, as it seems that validation is now mandatory. I think we should be sending out a "LSR is mandatory" notice to our peers. Comments? Smaller peers. A non-trivial few are doing seriously disgusting things which are going to cost you a lot of pain and some cash. There is little incentive for larger folk to peer with smaller ones. Hence, larger peers will simply cut the smaller masses off rather than spending the resource to differentiate the bad apples from the good. Maybe you want to do something about it. And soon. randy 5 kirk.mae-east.verio.net (205.238.56.57) 168 ms 84 ms 107 ms 6 mae-east-01.ix.ai.net (192.41.177.98) 152 ms 136 ms 130 ms 7 * br2.tco1.alter.net (192.41.177.249) 150 ms 134 ms 5 kirk.mae-east.verio.net (205.238.56.57) 82 ms 84 ms 83 ms 6 mae-east.mai.net (192.41.177.73) 116 ms 111 ms 104 ms 7 br2.tco1.alter.net (192.41.177.249) 120 ms 127 ms 113 ms 5 kirk.mae-east.verio.net (205.238.56.57) 83 ms 82 ms 83 ms 6 mae-east-fddi2.servint.net (192.41.177.66) 103 ms 87 ms 88 ms 7 * br2.tco1.alter.net (192.41.177.249) 310 ms 231 ms 5 kirk.mae-east.verio.net (205.238.56.57) 84 ms 82 ms 89 ms 6 mae-east.wdc.ixe.net (192.41.177.18) 100 ms 85 ms 94 ms 7 958.Hssi5-0.GW1.TCO1.ALTER.NET (157.130.32.109) 202 ms 219 ms 222 ms 5 kirk.mae-east.verio.net (205.238.56.57) 84 ms 82 ms 88 ms 6 mae-east.iconnet.net (192.41.177.75) 86 ms 88 ms 88 ms 7 br2.tco1.alter.net (192.41.177.249) 132 ms 123 ms 258 ms rip:/home/randy/rain/config> traceroute -g 192.41.177.90 www.uu.net traceroute to www.uu.net (199.170.0.30), 30 hops max, 40 byte packets 1 gw (147.28.0.58) 179 ms 4 ms 4 ms 2 fr0.sea.verio.net (205.238.52.65) 24 ms 11 ms 13 ms 3 sea1.sea.verio.net (205.238.56.101) 11 ms 12 ms 11 ms 4 sea.kirk.verio.net (205.238.56.69) 12 ms 12 ms 14 ms 5 kirk.mae-east.verio.net (205.238.56.57) 83 ms 82 ms 84 ms 6 SR1.TCO1.ALTER.NET (137.39.127.1) 295 ms 273 ms 394 ms 7 Fddi0-0.CR2.TCO1.ALTER.NET (137.39.11.20) 334 ms 277 ms 123 ms 8 Fddi0-0.CR2.TCO1.ALTER.NET (137.39.11.20) 126 ms 189.Hssi1-0.GW2.FFX1.Alter.Net (137.39.70.69) 179 ms Fddi0-0.CR2.TCO1.ALTER.NET (137.39.11.20) 135 ms 9 charlotte01.va.pubnix.com (199.170.0.30) 185 ms 187 ms 401 ms huh? 5 kirk.mae-east.verio.net (205.238.56.57) 83 ms 88 ms 82 ms 6 mae-east.dx.net (192.41.177.92) 86 ms 91 ms 87 ms 7 904.Hssi3-0.GW1.DCA1.ALTER.NET (137.39.128.93) 104 ms 147 ms 108 ms 5 kirk.mae-east.verio.net (205.238.56.57) 82 ms 84 ms 85 ms 6 mae-east-01.ix.ai.net (192.41.177.98) 111 ms 118 ms 130 ms 7 br2.tco1.alter.net (192.41.177.249) 124 ms 122 ms 131 ms 5 kirk.mae-east.verio.net (205.238.56.57) 85 ms 84 ms 83 ms 6 fddi3-0.cr1.dca.globalcenter.net (192.41.177.113) 83 ms 84 ms 89 ms 7 Fddi9-0.BR2.TCO1.ALTER.NET (198.32.186.249) 433 ms * 138 ms 5 kirk.mae-east.verio.net (205.238.56.57) 83 ms 107 ms 108 ms 6 mae-east.above.net (192.41.177.152) 99 ms 105 ms 92 ms 7 901.Hssi5-0.GW2.TCO1.ALTER.NET (157.130.33.113) 137 ms 117 ms 109 ms rip:/home/randy/rain/config> traceroute -g 192.41.177.160 www.uu.net traceroute to www.uu.net (199.170.0.30), 30 hops max, 40 byte packets 1 gw (147.28.0.58) 4 ms 4 ms 4 ms 2 fr0.sea.verio.net (205.238.52.65) 13 ms 11 ms 10 ms 3 sea1.sea.verio.net (205.238.56.101) 10 ms 10 ms 19 ms 4 sea.kirk.verio.net (205.238.56.69) 12 ms 13 ms 12 ms 5 kirk.mae-east.verio.net (205.238.56.57) 83 ms 85 ms 82 ms 6 br2.tco1.alter.net (192.41.177.249) 138 ms 136 ms 126 ms 7 332.atm10-0.cr2.tco1.alter.net (137.39.13.18) 118 ms br2.tco1.alter.net (192.41.177.249) 131 ms 332.atm10-0.cr2.tco1.alter.net (137.39.13.18) 131 ms 8 332.atm10-0.cr2.tco1.alter.net (137.39.13.18) 141 ms 114 ms 140 ms 9 189.Hssi1-0.GW2.FFX1.Alter.Net (137.39.70.69) 107 ms^C At this point my lunch was ruined, and I gave up. randy
no neighbor 192.41.177.73 they should not care if you peer with them or not, they can have the upstream provider to give them your routes, then: ! set nexthop 192.41.177.121
The danger with this approach is, obviously, that the router that you try to do this to can go away. In which case you shoot yourself in the foot. Some day, someone will send me a valid use of 'set ip next-hop' but I haven't seen a good one yet.
The problem is not agreements. The problem is, as Scott says, detecting violation thereof is not easy. But traceroute -g is your friend. <snip> I also think it may be time we refuse to peer with anyone who inhibits LSR, as it seems that validation is now mandatory. I think we should be sending out a "LSR is mandatory" notice to our peers. Comments?
We have LSR turned off. We periodically run XP mappers that insert temporary /32 routes to map who sends traffic to whom, and to flag asymmetry so a human can look at it. A few routing engineers are on a mini-mailing-list that I have to get that info, esp. wrt who sends next-hop to them and who defaults to them. (eunet defaulting into uunet is OK, anyone else isn't) It's a perl/expect combo - no trace -g required.
Smaller peers. A non-trivial few are doing seriously disgusting things which are going to cost you a lot of pain and some cash. There is little incentive for larger folk to peer with smaller ones. Hence, larger peers will simply cut the smaller masses off rather than spending the resource to differentiate the bad apples from the good. Maybe you want to do something about it. And soon.
It's a danger, so the smaller peers should warn the larger peers and each other when they see extreme funniness happening.
randy
Avi
On Thu, 11 Sep 1997, Avi Freedman wrote:
foot. Some day, someone will send me a valid use of 'set ip next-hop' but I haven't seen a good one yet.
Vixie's blackhole feed. pbd -- "Seems she thought of me as some mystic, fatalistic, mystical guru Me, I haven't got a clue." -- Tears for Fears, "Cold"
On Sep 11, 21:15, Avi Freedman <freedman@netaxs.com> wrote:
them. (eunet defaulting into uunet is OK
Huhh? -- ------ ___ --- Per G. Bilse, Director Network Eng & Ops ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at domain
On Sep 11, 21:15, Avi Freedman <freedman@netaxs.com> wrote:
them. (eunet defaulting into uunet is OK
Huhh?
My most sincere apologies. I meant to say *pipex* but I had a brain-o (not a typo, where your fingers type the wrong thing but you should know better; a brain-o is when your brain knows the right party but says the wrong thing). Randy has suggested that I put the whole mess online, for MAE-East at least - but it amounts to a peering matrix as well as a funniness detector, and some have invoked "what if the marketing people use it to say so-and-so-sucks-because-they-don't-peer-with-so-and-so-else". I'll take an opinion count @ NANOG next month...
------ ___ --- Per G. Bilse, Director Network Eng & Ops ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
Anyway, very sorry... Here is a partial list of the default violations of April 22, 1996's run: At the time UUNET said that pipex had permission... As I look at it, 192.41.177.90 might be someone else now. Pipex's mae routers might not be online any more. ins.net is still defaulting into uunet now, and as I recall they had permission as well: ----------------------- mae-netaxs(config)#ip route 3.4.5.6 255.255.255.255 192.41.177.112 mae-netaxs(config)#end mae-netaxs#trace 3.4.5.6 1 192.41.177.112 [AS 1800] 12 msec 12 msec 8 msec 2 192.41.177.249 [AS 1800] 12 msec 20 msec 4 msec 3 * * ----------------------- Again, sorry for the pipex/eunet confusion. Avi -------- -------- below is a snip from the 4/22/96 mae-mapper run -------- -------------------- to nowhere through [mae-east-gw.pol.net] trace 3.4.5.6 Type escape sequence to abort. Tracing the route to 3.4.5.6 1 mae-east-gw.pol.net (192.41.177.90) [AS 3491] 8 msec 8 msec 8 msec 2 Vienna1.VA.ALTER.NET (137.39.127.1) [AS 701] 156 msec 204 msec 208 msec 3 Vienna1.VA.ALTER.NET (137.39.127.1) [AS 701] !H * !H -------------------- to nowhere through [e0-10m.mae-east.netrail.net] trace 3.4.5.6 Type escape sequence to abort. Tracing the route to 3.4.5.6 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 8 msec 4 msec 8 msec 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 12 msec 12 msec 8 msec 3 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] !H !H !H -------------------- to nowhere through [maeegw1.us.insnet.net] trace 3.4.5.6 Type escape sequence to abort. Tracing the route to 3.4.5.6 1 maeegw1.us.insnet.net (192.41.177.112) [AS 3491] 8 msec 4 msec 8 msec 2 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] 4 msec 8 msec 4 msec 3 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] !H * * -------------------- to nowhere through [was-gw1.pipex.net] trace 3.4.5.6 Type escape sequence to abort. Tracing the route to 3.4.5.6 1 was-gw1.pipex.net (192.41.177.190) [AS 3491] 8 msec 4 msec 8 msec 2 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] 8 msec 8 msec 12 msec 3 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] !H * !H -------------------- to nowhere through [(unknown)] trace 3.4.5.6 Type escape sequence to abort. Tracing the route to 3.4.5.6 1 192.41.177.191 [AS 3491] 4 msec 8 msec 4 msec 2 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] 8 msec 8 msec 8 msec 3 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] !H * *
I was not and will not ever point default to anyone. I am transit free, and have no need to point default to UUNet or anyone else. Nathan Stratton President, CTO, NetRail,Inc. ------------------------------------------------------------------------ Phone (888)NetRail NetRail, Inc. Fax (404)522-1939 230 Peachtree Suite 500 WWW http://www.netrail.net/ Atlanta, GA 30303 ------------------------------------------------------------------------ "No king is saved by the size of his army; no warrior escapes by his great strength. - Psalm 33:16 On Fri, 12 Sep 1997, Avi Freedman wrote:
On Sep 11, 21:15, Avi Freedman <freedman@netaxs.com> wrote:
them. (eunet defaulting into uunet is OK
Huhh?
My most sincere apologies. I meant to say *pipex* but I had a brain-o (not a typo, where your fingers type the wrong thing but you should know better; a brain-o is when your brain knows the right party but says the wrong thing).
Randy has suggested that I put the whole mess online, for MAE-East at least - but it amounts to a peering matrix as well as a funniness detector, and some have invoked "what if the marketing people use it to say so-and-so-sucks-because-they-don't-peer-with-so-and-so-else".
I'll take an opinion count @ NANOG next month...
------ ___ --- Per G. Bilse, Director Network Eng & Ops ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
Anyway, very sorry...
Here is a partial list of the default violations of April 22, 1996's run: At the time UUNET said that pipex had permission... As I look at it, 192.41.177.90 might be someone else now. Pipex's mae routers might not be online any more. ins.net is still defaulting into uunet now, and as I recall they had permission as well:
----------------------- mae-netaxs(config)#ip route 3.4.5.6 255.255.255.255 192.41.177.112 mae-netaxs(config)#end mae-netaxs#trace 3.4.5.6
1 192.41.177.112 [AS 1800] 12 msec 12 msec 8 msec 2 192.41.177.249 [AS 1800] 12 msec 20 msec 4 msec 3 * * -----------------------
Again, sorry for the pipex/eunet confusion.
Avi
-------- -------- below is a snip from the 4/22/96 mae-mapper run --------
-------------------- to nowhere through [mae-east-gw.pol.net]
trace 3.4.5.6
Type escape sequence to abort. Tracing the route to 3.4.5.6
1 mae-east-gw.pol.net (192.41.177.90) [AS 3491] 8 msec 8 msec 8 msec 2 Vienna1.VA.ALTER.NET (137.39.127.1) [AS 701] 156 msec 204 msec 208 msec 3 Vienna1.VA.ALTER.NET (137.39.127.1) [AS 701] !H * !H
-------------------- to nowhere through [e0-10m.mae-east.netrail.net]
trace 3.4.5.6
Type escape sequence to abort. Tracing the route to 3.4.5.6
1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 8 msec 4 msec 8 msec 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 12 msec 12 msec 8 msec 3 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] !H !H !H
-------------------- to nowhere through [maeegw1.us.insnet.net]
trace 3.4.5.6
Type escape sequence to abort. Tracing the route to 3.4.5.6
1 maeegw1.us.insnet.net (192.41.177.112) [AS 3491] 8 msec 4 msec 8 msec 2 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] 4 msec 8 msec 4 msec 3 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] !H * *
-------------------- to nowhere through [was-gw1.pipex.net]
trace 3.4.5.6
Type escape sequence to abort. Tracing the route to 3.4.5.6
1 was-gw1.pipex.net (192.41.177.190) [AS 3491] 8 msec 4 msec 8 msec 2 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] 8 msec 8 msec 12 msec 3 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] !H * !H
-------------------- to nowhere through [(unknown)]
trace 3.4.5.6
Type escape sequence to abort. Tracing the route to 3.4.5.6
1 192.41.177.191 [AS 3491] 4 msec 8 msec 4 msec 2 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] 8 msec 8 msec 8 msec 3 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] !H * *
I was not and will not ever point default to anyone. I am transit free, and have no need to point default to UUNet or anyone else.
Nathan Stratton President, CTO, NetRail,Inc.
In the particular snapshot below it doesn't even show you defaulting to UUNET; I don't know why you take objection! I included it as an example of what a default-route probe should look like :) I never said that you were defaulting to UUNET in 4/96. But since you raise the issue, 3 of our other (at the time, monthly) logs from '96 do show netrail defaulting into UUNET over MAE-East; maybe it was a simple config error, though. Avi
-------------------- to nowhere through [e0-10m.mae-east.netrail.net]
trace 3.4.5.6
Type escape sequence to abort. Tracing the route to 3.4.5.6
1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 8 msec 4 msec 8 msec 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 12 msec 12 msec 8 msec 3 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] !H !H !H
1 maeegw1.us.insnet.net (192.41.177.112) [AS 3491] 8 msec 4 msec 8 msec 2 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] 4 msec 8 msec 4 msec 3 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] !H * *
Before you throw too many stones, these guys (I happen to know) take transit from UUnet, and not, before you ask, over the MAE. Personally I don't see a problem with this behaviour as a last resort. Alex Bligh Xara Networks
On Fri, 12 Sep 1997, Alex.Bligh wrote:
1 maeegw1.us.insnet.net (192.41.177.112) [AS 3491] 8 msec 4 msec 8 msec 2 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] 4 msec 8 msec 4 msec 3 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] !H * *
Before you throw too many stones, these guys (I happen to know) take transit from UUnet, and not, before you ask, over the MAE. Personally I don't see a problem with this behaviour as a last resort.
If they buy transit, or do not buy transit from UUNet makes no difference. You don't see a problem with pointing default at UUNet or any other provider? This trace was to a network that did not exist, so it should not have been sent to UUNet. Nathan Stratton President, CTO, NetRail,Inc. ------------------------------------------------------------------------ Phone (888)NetRail NetRail, Inc. Fax (404)522-1939 230 Peachtree Suite 500 WWW http://www.netrail.net/ Atlanta, GA 30303 ------------------------------------------------------------------------ "No king is saved by the size of his army; no warrior escapes by his great strength. - Psalm 33:16
Before you throw too many stones, these guys (I happen to know) take transit from UUnet, and not, before you ask, over the MAE. Personally I don't see a problem with this behaviour as a last resort.
If they buy transit, or do not buy transit from UUNet makes no difference. You don't see a problem with pointing default at UUNet or any other provider? This trace was to a network that did not exist, so it should not have been sent to UUNet.
I'm not parsing your query. The trace was to a network that did not exist and was sent to UUNet because someone, with UUNet's permission presumably, had a preexisting default route. I have network. You want access. You buy T3 to me. I send you routes. Also, you default to me over a common exchange point as a backup. T3 goes down. Things fall over due to default route automagically. Yes, it can be done with BGP and metrics over the common XP but sometimes isn't. Some question whether the XPs should be used for customer connectivity, but that's a separate issue. Or is that what you're driving at?
Nathan Stratton President, CTO, NetRail,Inc.
Avi
On Fri, 12 Sep 1997, Avi Freedman wrote:
I have network. You want access. You buy T3 to me. I send you routes. Also, you default to me over a common exchange point as a backup. T3 goes down. Things fall over due to default route automagically. Yes, it can be done with BGP and metrics over the common XP but sometimes isn't.
Some question whether the XPs should be used for customer connectivity, but that's a separate issue.
Or is that what you're driving at?
YES, just look at the data going over MAE-East and MAE-West a large amount of that traffic is for customer connectivity. I guess it will not mater most NSPs are setting up private peering, so the NAPs will soon just turn into a place to sell transit. I just think it did not need to turn out that way. Also of the current defaults at MAE-East most of them are not there with permission from the provider they are point to. I have had 2 peers at MAE-East point default to me in the last 3 months. Nathan Stratton President, CTO, NetRail,Inc. ------------------------------------------------------------------------ Phone (888)NetRail NetRail, Inc. Fax (404)522-1939 230 Peachtree Suite 500 WWW http://www.netrail.net/ Atlanta, GA 30303 ------------------------------------------------------------------------ "No king is saved by the size of his army; no warrior escapes by his great strength. - Psalm 33:16
On Fri, 12 Sep 1997 15:59:38 +0000 (GMT) Nathan Stratton <nathan@netrail.net> wrote:
YES, just look at the data going over MAE-East and MAE-West a large amount of that traffic is for customer connectivity. I guess it will not mater most NSPs are setting up private peering, so the NAPs will soon just turn into a place to sell transit. I just think it did not need to turn out that way. Also of the current defaults at MAE-East most of them are not there with permission from the provider they are point to. I have had 2 peers at MAE-East point default to me in the last 3 months.
I've no hands on experience at MAE East or West, but I do have some experience at some of the EU exchanges. One reason that the LINX works well IMO is that nobody sells transit at the LINX. It is an exchange point that really does _only_ exchange traffic between Internationally connected ISP's. Cheers, Neil. -- Neil J. McRae. Alive and Kicking. Domino: In the glow of the night. neil@DOMINO.ORG NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>
If they buy transit, or do not buy transit from UUNet makes no difference. You don't see a problem with pointing default at UUNet or any other provider? This trace was to a network that did not exist, so it should not have been sent to UUNet.
Nathan Stratton President, CTO, NetRail,Inc.
Hum. network that did not exist..... Interesting concept. can you ensure that the prefix was not seen inside the UUnet AS bound? --bill
On Fri, 12 Sep 1997, Nathan Stratton wrote:
If they buy transit, or do not buy transit from UUNet makes no difference. You don't see a problem with pointing default at UUNet or any other provider?
Ummm...correct me if I am wrong, but isn't transit usually defined as being given explicit permission to send any and all traffic to the party from whom transit is being bought? You mean ISP X who buys transit from NSP Y can't point default at them? Why not? Isn't that what they are paying for? Or did you get confused and really mean that NSP X shouldn't be providing transit over a public exchange point? As Alex pointed out, it was only as a last resort that transit traffic would flow over the XP. pbd -- "Seems she thought of me as some mystic, fatalistic, mystical guru Me, I haven't got a clue." -- Tears for Fears, "Cold"
On Fri, 12 Sep 1997, Bradley Dunn wrote:
On Fri, 12 Sep 1997, Nathan Stratton wrote:
If they buy transit, or do not buy transit from UUNet makes no difference. You don't see a problem with pointing default at UUNet or any other provider?
Ummm...correct me if I am wrong, but isn't transit usually defined as being given explicit permission to send any and all traffic to the party from whom transit is being bought? You mean ISP X who buys transit from NSP Y can't point default at them? Why not? Isn't that what they are paying for?
Ok, say I sell transit, say over a point to point 10 meg ethernet from my POP to the customer. This customer may also be connected to MAE-East with say a gigaswitch port. Just because I provide this customer a 10 meg transit connection does NOT give them the right to point default to me at MAE-East or any other NAP. If it was OK for providers to do that, then I have a great new business. Why not start a www farm and provide hosting for very good prices. We then buy a T1 into any major NSP and get a gigaswitch connection at MAE-East. So we are spending around 7K a month for access, now we just point default to a NSP and we are set. Since you are a web farm, most of your data is outgoing so for a little money you get a lot of bandwidth. Am I the only one out there the thinks it is not ethical to point default to a provider over a NAP without their permission? Just because someone sells you transit does not give you the right to point default to them at a NAP. Sure you can point default all day long over the connection you are buying, but not over a NAP without their permission. Nathan Stratton President, CTO, NetRail,Inc. ------------------------------------------------------------------------ Phone (888)NetRail NetRail, Inc. Fax (404)522-1939 230 Peachtree Suite 500 WWW http://www.netrail.net/ Atlanta, GA 30303 ------------------------------------------------------------------------ "No king is saved by the size of his army; no warrior escapes by his great strength. - Psalm 33:16
Am I the only one out there the thinks it is not ethical to point default to a provider over a NAP without their permission? Just because someone sells you transit does not give you the right to point default to them at a NAP. Sure you can point default all day long over the connection you are buying, but not over a NAP without their permission.
Nathan Stratton President, CTO, NetRail,Inc.
Nathan, Noone's suggesting that it's ethical to point default at people without their permission. But some large carriers DO allow people to pay for that privelege, over the public exchanges - or point default from some of their routers (owned by one subsidiary) to other of their routers. Avi
If they buy transit, or do not buy transit from UUNet makes no difference. You don't see a problem with pointing default at UUNet or any other provider? This trace was to a network that did not exist, so it should not have been sent to UUNet.
You are correct. I do not see a problem with people who buy transit pointing default at those whom they buy transit from. We sell transit, and I'm happy for customers to do this. There are several reasonably good reasons, such as (a) they don't want to carry full routing everywhere, and (b) in the event that tehy run route dampening or similar and for some reason my route table splurges as does that of their other transit provider (but in a manner where their announcements to me remain static), they can still reach the world to some extent automatically, without frantically having to go around clearing dampening. Given that the first default free router on the way will just return !H, and it's on bandwidth the customer is paying for, I'm not sure what the problem is here. Alex Bligh Xara Networks
1 maeegw1.us.insnet.net (192.41.177.112) [AS 3491] 8 msec 4 msec 8 msec 2 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] 4 msec 8 msec 4 msec 3 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] !H * *
Before you throw too many stones, these guys (I happen to know) take transit from UUnet, and not, before you ask, over the MAE. Personally I don't see a problem with this behaviour as a last resort.
Alex Bligh Xara Networks
I happen to know the same thing :) I never said that insnet or pipex didn't have every right to default into UUNET, as a primary or as a last resort... Avi
participants (11)
-
Alex Rubenstein -
Alex.Bligh -
Avi Freedman -
bmanning＠ISI.EDU -
Bradley Dunn -
Naiming Shen -
Nathan Stratton -
Neil J. McRae -
Per Gregers Bilse -
Randy Bush -
Scott Huddle