- Test - lists.nanog.org

New reverse DNS filter at Merit
by Susan Harris 22 Mar '04

22 Mar '04

Greetings - I wanted to let you know that in an effort to reduce spam, Merit will implement reverse DNS checking on incoming mail on Monday, March 29. This means that if your IP address doesn't match the DNS zone information for your domain name, or if your IP address can't be verified because an IN.ADDR.ARPA file for your address block doesn't exist, the lookup will fail and your mail will be (eek) rejected. If this happens, you'll receive a custom message from Merit outlining the reason for the rejection. Merit is making the change to comply with RFCs 1123 and 1912. You'll find more info about reverse DNS checking, plus a tool you can use to check your site's IP addresses and DNS records here: www.merit.edu/mn/support/reversedns.html Please send any questions to nanog-support(a)nanog.org .

1 0

Re: iMPLS benefit
by W. Mark Townsley 22 Mar '04

22 Mar '04

Enke Chen wrote: > Hi, Mark: > I was no vacation and just became aware of this thread. Lucky you! > I have some clarifications here: > > (1) The relevant implementation is "Encapsulating MPLS in IP or Generic > Routing Encapsulation (GRE)" for L3VPN (draft-ietf-mpls-in-ip-or-gre-xx.txt) This draft describes encapsulation and decapsulation of MPLS over IP, MPLS over GRE (with and without optional GRE fields), and (in more recent versions) touches on all of these encapsulation modes in the presence of IPsec. There is no detail on dynamic establishment of GRE tunnels here. > > (2) Redback's implementation does not require manual configuration of > and GRE tunnels in this case. We have tested the interoprability > with another implementation that does require manual configuration. I don't doubt that this can be made to work. However, there are out-of-band assumptions here beyond simple support for "MPLS over GRE" which was my initial point. e.g., in order to interoperate, a "soft" GRE tunnel node must make assumptions that every node it is sending a GRE encapsulated MPLS packet to is either (1) manually configured to accept MPLS over GRE from that endpoint, or (2) is a PE which is participating in the same "soft" GRE system, learning endpoints from BGP updates or some other method. This is, of course, made easier when nodes are simply configured to allow MPLS over GRE/IP from any source IP address, but this also substantially increases the spoofing concerns for MPLS over GRE/IP at that node. IMHO, if an implementation is going to be made to dynamically learn the destination address for an MPLS over IP enabled endpoint from BGP, including an attribute to explicitly identify the ability to receive said MPLS over IP packets goes a long way to overcome blackhole situations where one could end up sending tunneled packets to a PE which isn't able to receive and process them correctly. Thanks, - Mark > > Regards, > > -- Enke > > * From: W. Mark Townsley > * Date: Mon Mar 15 13:19:37 2004 > > Please see inline. > > >>Yakov Rekhter wrote: > > > ------------------------------------------------------- > >>>Mark, >>> >>>i heard there is a way to run MPLS for layer3 VPN(2547) >>>service without needing to run label switching in the >>>core(LDP/TDP/RSVP) but straight IP (aka iMPLS). >>> >>> ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-01.txt >>> >>> See also Mark's talk from the last NANOG >>> >>> http://nanog.org/mtg-0402/townsley.html >>> >>>That requires to run L2TP. An alternative is to run GRE (or even plain >>>IP). The latter (GRE) is implemented by quite a few vendors (and is >>>known to be interoperable among multiple vendors). >>> >>>The only multi-vendor interoperable mode of GRE that I am aware of requires >>>manual provisioning of point-to-point GRE tunnels between MPLS networks >>>and to each and every IP-only reachable PE. > > >>I guess you are *not* aware of the Redback implementation of 2547 >>over GRE, as this implementation is (a) available today, (b) >>interoperable with other implementations of 2547 over GRE, and (c) >>does *not* require manual provisioning of point-to-point GRE tunnels >>between MPLS networks and to each and every IP-only reachable PE. >> >>And, just for the record, (stating the obvious) I don't work for Redback. > > ------------------------------------------------------------------------ > > Are you referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt? > (Just guessing as the principal author used to work for Redback). > Thanks for the update, I was in fact not aware that companies other > than Redback had implemented it. You didn't name those companies, but > I will happily stand corrected here. > > In any case, the point I was trying to make was that there is more than > one way to do "MPLS over GRE" and that they are not all necessarily > interoperable as you seemed to imply in your message. You have helped > to make that quite clear. > > The BGP extension defined in the draft below allows "iMPLS" for 2547 VPN > support without requiring any manually provisioned tunnels (and works for > "mGRE" or L2TPv3). > > http://www.watersprings.org/pub/id/draft-nalawade-kapoor-tunnel-safi-01.txt > > The question to ask is whether the extension you mentioned above is > truly necessary for supporting 2547 over GRE. The Redback implementation > I mentioned above is an existence proof that the extension is *not* > necessary for 2547 over GRE that does *not* involve manually provisioned > GRE tunnels. > > [clip] > > - Mark > >

1 0

UUNet->Teleglobe
by John Obi 22 Mar '04

22 Mar '04

Hello, Do you see any issue between UUNet and TeleGlobe in East coast? traceroute to ix-12-0-0.bb1.HongKong.teleglobe.net (64.86.126.18) from 195.129.70.25: 1-30 hops, 38 byte packets 1 ge-0-0-0.ams9eusoesr1.ams.ops.eu.uu.net (193.67.79.213) [AS702 - NLnet Pseudo blocks] 0.672 ms (ttl=254!) 0.306 ms (ttl=254!) 0.283 ms (ttl=254!) 2 ge-1-1-0.HR1.AMS9.ALTER.NET (212.136.185.117) [AS702 - NLnet Pseudo blocks] 0.351 ms (ttl=253!) 0.326 ms (ttl=253!) 0.299 ms (ttl=253!) 3 so-2-0-0.CR2.AMS9.ALTER.NET (212.136.185.109) [AS702 - NLnet Pseudo blocks] 0.352 ms (ttl=252!) 0.331 ms (ttl=252!) 0.311 ms (ttl=252!) 4 so-7-0-0.XR1.AMS6.ALTER.NET (212.136.185.105) [AS702 - NLnet Pseudo blocks] 0.395 ms (ttl=251!) 0.393 ms (ttl=251!) 0.371 ms (ttl=251!) 5 so-0-1-0.TR2.AMS2.ALTER.NET (146.188.8.82) [AS702 - UUNET-NET] 0.424 ms (ttl=250!) 0.427 ms (ttl=250!) 0.418 ms (ttl=250!) 6 so-4-0-0.IR1.DCA4.ALTER.NET (146.188.5.197) [AS702 - UUNET-NET] 82.1 ms (ttl=249!) 82.2 ms (ttl=249!) 82.1 ms (ttl=249!) 7 so-0-0-0.IL1.DCA6.ALTER.NET (146.188.13.33) [AS702 - UUNET-NET] 82.1 ms (ttl=248!) 82.1 ms (ttl=248!) 82.2 ms (ttl=248!) 8 0.so-1-0-0.TL1.DCA6.ALTER.NET (152.63.9.194) 82.2 ms (ttl=247!) 82.2 ms (ttl=247!) 82.2 ms (ttl=247!) 9 0.so-6-0-0.XL1.DCA6.ALTER.NET (152.63.38.70) 82.2 ms (ttl=246!) 82.2 ms (ttl=246!) 82.2 ms (ttl=246!) 10 POS6-0.BR3.DCA6.ALTER.NET (152.63.38.117) 82.8 ms 82.6 ms 82.6 ms 11 204.255.174.198 (204.255.174.198) 84.0 ms 84.0 ms 84.0 ms 12 if-2-0.core2.Newark.Teleglobe.net (64.86.83.213) 348 ms (ttl=236!) 348 ms (ttl=236!) 349 ms (ttl=236!) 13 if-1-0.core3.PaloAlto.teleglobe.net (64.86.138.125) 352 ms (ttl=237!) 353 ms (ttl=237!) 352 ms (ttl=237!) 14 if-10-0.core2.PaloAlto.Teleglobe.net (207.45.220.6) 351 ms (ttl=237!) 351 ms (ttl=237!) 353 ms (ttl=237!) 15 if-7-0.core2.LosAngeles.Teleglobe.net (207.45.222.25) 489 ms (ttl=239!) 384 ms (ttl=239!) 415 ms (ttl=239!) 16 if-5-0.core1.LosAngeles.Teleglobe.net (207.45.223.62) 348 ms 348 ms 348 ms 17 if-3-0.core1.HongKong.teleglobe.net (64.86.129.5) 351 ms (ttl=241!) 351 ms (ttl=241!) 351 ms (ttl=241!) 18 if-8-0-0.bb1.HongKong.Teleglobe.net (64.86.80.129) 352 ms (ttl=240!) 353 ms (ttl=240!) 352 ms (ttl=240!) 19 ix-12-0-0.bb1.HongKong.teleglobe.net (64.86.126.18) * 410 ms (ttl=241!) 410 ms (ttl=241!) Thanks, -J __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

2 1

Re: Incoming Fax
by randy＠psg.com 22 Mar '04

22 Mar '04

1 0

Re: Personal Co-location Registry
by Brandon Butterworth 22 Mar '04

22 Mar '04

> IMHO the right way to do this is to build the power cycling > capability into the individual 1U boxen. Again, we > should be talking to the embedded systems folks to > give them a standard set of requirements that everyone > can support. See Sun Netra LOM. Done. > This may be worth having a workshop > discussion at a NANOG meeting to define requirements. Won't that lead to an over complicated kitchen sink (see Sun RSC)? This should be simple it's supposed to be more reliable than the system it's managing. > I envisage a standard control module with two external > serial ports. One serial, rj45 is fine The major complication is that 1U boxes are really built for Windows where this is useful but only does part of the job. As it doesn't remote the Windows desktop they don't bother including it. Likewise we're still stuck with Windows centric BIOS rather than an OPENBOOT alike. Both need doing to make 1U X86 worthwhile. Is the linux market isn't big enough to be worth designing for properly? brandon

1 0

Re: Personal Co-location Registry
by Michael.Dillon＠radianz.com 22 Mar '04

22 Mar '04

>Personally, I have a major dislike for daisy-chained control buses like this. >All it needs is one box at the start of the bus to go bad and you've lost >control all the other boxes on the bus. The same thing can happen with Ethernet or any communications protocol that uses a shared wire/medium. However, given the fact that RS-232 is an extremely well understood and simple technology, I don't think there is much risk in using an RS-232 daisy-chained control bus. Of course the embedded systems folks might be able to make a case for I2C or HP1B or something else that is used in industrial and laboratory control applications. --Michael Dillon

1 0

Remote control servers was:(Re: Personal Co-location Registry)
by Michael.Dillon＠radianz.com 22 Mar '04

22 Mar '04

>Weasel, like the sun implementation, allows remote reboot of wedged >machines. This is key, particularly when running on an Intel platform ><cough>. If there are any PC serial console implementations that >allow one to do this, I'd like to hear about it, since I'm not aware >of such. Buying a serial console server *plus* a power cycler fills >my heart with hatred. Given the fact that the guts of a server leave enough room in a 1U case for an additional computer, it's only a matter of time before someone puts together 1U Intel-based systems that include a serial console server and power cycler running on the separate control computer. And given that we now have devices like the Gumstix on the market http://www.gumstix.com/ it's only a matter of time before this capability gets built into even smaller boxen. We really do need to have a chat with some of the folks doing embedded systems work because if they knew that there was a need for these types of server control systems, it wouldn't take them very long to produce usable products. All the pieces needed are available off the shelf today. The only problem remaining is the integration and this is something that embedded systems people do very well. --Michael Dillon

1 0

standard transit arrangements
by Sven Huster 22 Mar '04

22 Mar '04

Hello I just wanted to find out what the "standard" arrangements are when one buys transit traffic. I've been left in charge of this now, without haven't been doing this before :-( So what normally you buy x amount of bandwidth over a physical line e.g. 45Mb/s over FastEthernet or so. They then charge you for excessive usage based on 95th percentile. Is there anything else I need to keep an eye on? Thanks Sven

1 1

Compromised Hosts?
by Deepak Jain 22 Mar '04

22 Mar '04

Nanogers - Would any broadband providers that received automated, detailed (time/date stamp, IP information) with hosts that are being used to attack (say as part of a DDOS attack) actually do anything about it? Would the letter have to include information like "x.x.x.x/32 has been blackholed until further notice or contact with you" to be effective? If even 5% of these were acted upon, it might make a difference. The question is... would even 1% be? Thanks for your opinions, DJ

5 4

Re: Hi
by milton＠isomedia.com 22 Mar '04

22 Mar '04

1 0