- Test - lists.nanog.org

@home, toronto(?) outage?
by Jim Mercer 20 Jul '00

20 Jul '00

since about 10:am this morning, my @home connection (in my house) has not been able to get packets outside of the local network. my peering with @home at TorIX seems to be spotty at best, allowing some reachability, but not all. i've hear their peering with CanIX is in the same boat. pings work to some places, but traceroutes to the same places lock up. the noc number for @home toronto is busy (has been since i noticed the outage). anyone got any words? -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

2 1

Solaris load balancing?
by foo 20 Jul '00

20 Jul '00

What are the various options for load balancing across multiple interfaces which are connected to distinct switches/routers on a Solaris box? FEC/trunking wont work because the connections are to difference switches. Multiple default routes in Solaris appear to behave badly when one of the dest's is down, such that the route is not removed from the routing table and traffic is still sent in that direction (subject to TCP behavior), and it's round-robin versus something more interesting like MAC-hasing. I think I can do equal cost multipath with two default routes in Gated as well, but I'm not sure if Gated is any smarter about removing an unreachable route. Will eqmp work if I'm injecting two defaults with OSPF? Any other ideas? -Brian

3 2

Re: OK.. WHo's the wise guy?
by Valdis.Kletnieks＠vt.edu 19 Jul '00

19 Jul '00

On Wed, 19 Jul 2000 17:16:13 +0200, Daniel Karrenberg said: > Note that the set of nameservers for > .org and for . is not identical, i.e. the string 'ROOT' is > not the string 'GTLD': Damn.. Why do problems always crop up before caffeine, and never when you're NOT hurrying to get into a meeting you've been ordered to attend? ;) Anybody want to take guesses how many times I watched that same info scroll by and it didn't sink in? All I can say in my defense is the *last* time I had to check at the roots because I didn't trust them, root-servers and gtld-servers were the same set of machines. Having said that, does anybody who's (at least somewhat) unbiased have any information on the current state of the ORBS/MAPS/above.net pissing contest? It's pretty sad, because I thought that the ORBS and MAPS guys were at least on the same side (even if they DO disagree on tactics). There's been a lot of allegations/denials of blackhole routing for the ORBS DNS and WWW servers. Anybody seeing anything one way or another (i.e. "Yes, we're seeing a blackhole route", or "No, we can confirm that if there was one, we'd see it". -- Valdis Kletnieks Operating Systems Analyst Virginia Tech

1 0

Re: Telco NOC vs. Internet NOCs (WAS: Wanted: Clueful Individual @ TeleGlobe.n
by Robert Cannon 19 Jul '00

19 Jul '00

I am not saying too much solid at all about how much the IXC's utilize each others networks. It is really just an impression. I suppose one that I am curious about how accurate it is. The impression again is that AT&T provides end to end service - which is quite different from the Internet where networks keep playing hot potato with the traffic. Sean's comments are interesting - I would love to see something more substantiated just for fun. I would be curious, where two networks exist, how much traffic they might exchange. And then there is the situation which was pointed out where one of two networks does not exist and the first must rely on the second to complete the transmission. I think regulatorily there has been a lot of attention paid to traffic exchanged between LEC and LEC - and traffic exchanged between LECs and IXCs - but not necessarily traffic exchanged between IXC and IXC (again, except in the case of network reliability where one IXC is down and relies upon the other). -B www.cybertelecom.org ------Original Message------ From: Ric Messier <rmessier(a)Genuity.NET> To: Robert Cannon <rmcannon(a)mail.com> Sent: July 18, 2000 4:40:44 PM GMT Subject: Re: Telco NOC vs. Internet NOCs (WAS: Wanted: Clueful Individual @ TeleGlobe.n On Tue, 18 Jul 2000, Robert Cannon wrote: > > I am curious how often you think that ATT telephone long distance would hand > traffic off to MCI telephone long distance. My impression of telephone long > distance is that it is largely an end to end service (one of the great > differences from the Internet). That as far as long distance goes, there is > not a great deal traffic hand off (one exception is times of network trouble > where carriers have agreements to hand off traffic to maintain network > reliability). > So, what you are saying is that all long-distance carriers have at least nationwide networks and never have to ride another carrier (except for the last-mile service provided by the LEC)? Just trying to understand your remarks. Ric ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup

1 0

HOUSE MOVES TO BAN SPAM
by Henry R. Linneweh 19 Jul '00

19 Jul '00

http://www.internetnews.com/isp-news/article/0,2171,8_417901,00.html -- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | |--------------------------------| Henry R. Linneweh

1 0

OK.. WHo's the wise guy?
by Valdis.Kletnieks＠vt.edu 19 Jul '00

19 Jul '00

The root nameservers seem a tad confused about the orbs.org domain this morning. A, E, F, and G seem to know about it, while B, C, D, and H-L don't. But even the 4 that know about it seem to be returning only a partial list of NS entries (possibly the others are secondaries - but if the roots aren't returning the NS entries, they'll never get referenced)? And yes, I know that the ORBS guys have shut down temporarily due to the above.net hassles they've been getting. But even the NS entries going poof? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech dig @a.root-servers.net orbs.org ns ; <<>> DiG 8.2 <<>> @a.root-servers.net orbs.org ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 4 ;; QUERY SECTION: ;; orbs.org, type = NS, class = IN ;; ANSWER SECTION: orbs.org. 2D IN NS NS.VUURWERK.NL. orbs.org. 2D IN NS NS1.MANAWATU.NET.NZ. orbs.org. 2D IN NS NS1.ABS.NET. orbs.org. 2D IN NS SKYNET.SIMKIN.COM. orbs.org. 2D IN NS DOUBTFUL.SIMKIN.COM. orbs.org. 2D IN NS NS3.AUSTRIA.EU.NET. orbs.org. 2D IN NS ORBSNS.PORT80.SE. ;; ADDITIONAL SECTION: NS1.ABS.NET. 2D IN A 207.114.0.130 SKYNET.SIMKIN.COM. 2D IN A 199.175.137.111 DOUBTFUL.SIMKIN.COM. 2D IN A 207.6.128.246 NS3.AUSTRIA.EU.NET. 2D IN A 193.154.160.110 dig @b.root-servers.net orbs.org ns ; <<>> DiG 8.2 <<>> @b.root-servers.net orbs.org ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 12, ADDITIONAL: 12 ;; QUERY SECTION: ;; orbs.org, type = NS, class = IN ;; AUTHORITY SECTION: ORG. 6D IN NS A.ROOT-SERVERS.NET. ORG. 6D IN NS G.ROOT-SERVERS.NET. ORG. 6D IN NS E.GTLD-SERVERS.NET. ORG. 6D IN NS F.GTLD-SERVERS.NET. ORG. 6D IN NS F.ROOT-SERVERS.NET. ORG. 6D IN NS J.GTLD-SERVERS.NET. ORG. 6D IN NS K.GTLD-SERVERS.NET. ORG. 6D IN NS A.GTLD-SERVERS.NET. ORG. 6D IN NS M.GTLD-SERVERS.NET. ORG. 6D IN NS H.GTLD-SERVERS.NET. ORG. 6D IN NS C.GTLD-SERVERS.NET. ORG. 6D IN NS I.GTLD-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 E.GTLD-SERVERS.NET. 6D IN A 207.200.81.69 F.GTLD-SERVERS.NET. 6D IN A 198.17.208.67 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 J.GTLD-SERVERS.NET. 6D IN A 198.41.0.21 K.GTLD-SERVERS.NET. 6D IN A 195.8.99.11 A.GTLD-SERVERS.NET. 6D IN A 198.41.3.38 M.GTLD-SERVERS.NET. 6D IN A 210.176.152.18 H.GTLD-SERVERS.NET. 6D IN A 216.33.75.82 C.GTLD-SERVERS.NET. 6D IN A 205.188.185.18 I.GTLD-SERVERS.NET. 6D IN A 192.36.144.253 dig @NS.VUURWERK.NL orbs.org ns ; <<>> DiG 8.2 <<>> @NS.VUURWERK.NL orbs.org ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 6 ;; QUERY SECTION: ;; orbs.org, type = NS, class = IN ;; ANSWER SECTION: orbs.org. 1D IN NS doubtful.simkin.com. orbs.org. 1D IN NS ns1.abs.net. orbs.org. 1D IN NS ns2.abs.net. orbs.org. 1D IN NS ns3.austria.eu.net. orbs.org. 1D IN NS ns.vuurwerk.nl. orbs.org. 1D IN NS orbsns.p80.net. orbs.org. 1D IN NS ns.uni2.net. orbs.org. 1D IN NS sunsite.auc.dk. orbs.org. 1D IN NS sunsite.icm.edu.pl. orbs.org. 1D IN NS monkeys.com. orbs.org. 1D IN NS dns-orbs.proxy.aol.com. orbs.org. 1D IN NS ns1.manawatu.net.nz. orbs.org. 1D IN NS ns2.manawatu.net.nz. orbs.org. 1D IN NS skynet.simkin.com. ;; ADDITIONAL SECTION: doubtful.simkin.com. 7h31m27s IN A 207.6.128.246 ns1.abs.net. 7h31m47s IN A 207.114.0.130 ns2.abs.net. 5h53m43s IN A 207.114.0.140 ns3.austria.eu.net. 3h35m44s IN A 193.154.160.110 ns.vuurwerk.nl. 1D IN A 194.178.232.2 ns.uni2.net. 7h31m27s IN A 129.142.7.99

1 0

CALEA Update
by Chip Sharp 19 Jul '00

19 Jul '00

At the NANOG meeting, I think I promised to provide an update on the CALEA meeting held at the end of June. Information on CALEA JEM II can be found at http://www.tiaonline.org/standards/CALEA_JEM/ This includes the meeting minutes and latest draft of the JEM Report under "contributions". I went away for 2 weeks vacation and when I returned I found that the Carnivore system that the FBI presented is now all over the news so there isn't much point going into it, although there is a lot of misinformation about what it does going around. Any technical questions or comments, feel free to email me. Chip ------------------------------------------------------------------- Chip Sharp, !Ph.D. JBM Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org -------------------------------------------------------------------

1 0

Re: RFC 1918
by Richard A. Steenbergen 19 Jul '00

19 Jul '00

On Tue, 18 Jul 2000, Eric A. Hall wrote: > "Richard A. Steenbergen" wrote: > > > > On Mon, 17 Jul 2000, Eric A. Hall wrote: > > > > > When ISPs choose to mark their packets with Internet-illegal > > > addresses, they are contributing to these problems. Sorry, but > > > you're not supposed to be using these addresses anyway. > > > > This is utterly stupid. You can use these addresses any way you see > > fit, you can source packets from them if you'd like, and they are as > > valid as any other address to use and be "on the internet". > > What's dumber? > > a) Filtering illegal packets from entering your network because > they use your internal address range, because they are classed > unroutable and should never appear on that interface, or both Unroutable means you can't reach where the packets came from, not that the packets can't reach you. Just because you can't reply doesn't mean someone shouldn't be allowed to send you an informative piece of information, like a traceroute ttl-exceed. > b) Sending packets that you KNOW will be dropped or filtered by > a good portion of their intended recipients. This is not true. For the people like you who think they need to filter it, you've accomplished your goal. For the rest of the world, they simply do not care. Obviously its not prefered by anyone to have RFC1918 sourced packets out there, mainly because they're not all that useful. But IMHO your belief that these are "Illegal bad wrong packets which should never appear on that interface" is incorrect. As for the DoS issue, as I explained to someone in private email, there are three distinctions you can break a filter into: 1) It provides security 2) It stops an attack 3) It reduces an attack RFC1918 filters obviously do not provide security. RFC1918 filters obviously do not "stop" any attacks outright. RFC1918 filters reduce the impact of attacks which can spoof by 3.19% I really don't see why you're wasting your time on it. Actually I really don't see why we're waiting our time argueing, this thread has long outlived its usefulness. But IMHO the RFC1918-nazi is not needed. :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

5 4

suggestions? hylafax/IXO/ITAP addressable pager companies in UK
by Jim Mercer 19 Jul '00

19 Jul '00

i've got a server in London, UK that from time to time needs some attention. i've been using hylafax here in canada to send off alpha and/or numeric messages using a dial-up into the pager company and the IXO or ITAP protocols. works quite nicely. in any case, i would like to do the same thing for the technicians in London, however, they aren't clue'd enough to ask their pager company the right questions and/or the pager companies i've called were not clue'd enough to understand what i was asking. any recommendations for direct-access pagers and/or cellphones in the UK? -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

5 6

Re: Filtering (was Re: RFC 1918)
by Paul Vixie 19 Jul '00

19 Jul '00

Valdis.Kletnieks(a)vt.edu writes: > OK.. I'll bite - what's in YOUR favorite list of things to filter? ;) networks owned by spam-friendly people or companies.

1 0