- Test - lists.nanog.org

is anyone else having trouble posting to nanog?
by Janet Sullivan 23 Mar '04

23 Mar '04

Is anyone else having trouble posting to nanog? My posts since Saturday haven't made it to the list, although the mail made it to merit.edu OK. Hopefully this email will make it through. :-)

1 1

verizon.net postmaster
by PJ Gallagher 23 Mar '04

23 Mar '04

sorry to do this but: Phone calls to their noc and emails a person (who said to email them with the server addresses) on Fri, 5 Mar 2004 12:04:43 -0800 (PST) and Mon, 8 Mar 2004 09:35:10 -0800 (PST) have gone unanswered and we're still being blocked.... Please contact me off-list..... Thanks, -PJ

1 0

contact at sbcglobal?
by bill＠daze.net 23 Mar '04

23 Mar '04

Looking for someone at sbcglobal that can help. DNSBL:To request removal ,send and E-mail to removeme(a)sbc.sbcglobal.net Getting no response from mail sent to removeme(a)sbc.sbcglobal.net and the people on the phone have no idea what we are talking about. They just refer us to the removeme(a)sbc.sbcglobal.net e-mail address. Regards, Bill Gerrard -- <=> ASK and you shall receive <=>

2 1

Re: Hi
by randy＠psg.com 23 Mar '04

23 Mar '04

1 0

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

23 Mar '04

>If someone is doing this, especially wrt to 1U servers, perhaps someone >could provide a pointer to a reboot solution that would allow a single >reboot device to control 42+ 1Us in a single rack. From my occasional >interest in this area, I've seen lots of reboot solutions. Most of them >take as many as 4-10 U to reboot 40 machines, which sort of obviates the >need to reboot 40 machines in a single rack in the first place. Unless >you use 10ft racks, I guess. 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. This may be worth having a workshop discussion at a NANOG meeting to define requirements. I envisage a standard control module with two external serial ports. One serial port is for a daisy-chained serial bus that can allow one control module to talk to other boxen. The other serial port is where the modem connection goes and could probably be designed to take either an RJ11 phone cable or an RJ45 serial terminal cable. The 1U box's power supply has a built-in relay that is switched by the control module. All external switches and indicators go through the control module. --Michael Dillon

5 4

Re: iMPLS benefit
by Enke Chen 23 Mar '04

23 Mar '04

Hi, Mark: > Message-ID: <405F05D9.1080301(a)cisco.com> > Date: Mon, 22 Mar 2004 16:27:21 +0100 > From: "W. Mark Townsley" <townsley(a)cisco.com> > To: Enke Chen <enke(a)redback.com> > Cc: David Meyer <dmm(a)1-4-5.net>, Yakov Rekhter <yakov(a)juniper.net>, > sonet twister <sonet1010(a)yahoo.com>, nanog(a)merit.edu > Subject: Re: iMPLS benefit > References: <20040319220615.A245D15D3C4(a)popserv1.redback.com> > > > 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. I should have mentioned the draft "Use of PE-PE GRE or IP in RFC2547 VPNs" (draft-ietf-l3vpn-gre-ip-2547-xx.txt), in which the notion of dynamic GRE tunnel is defined: ----------------------------------------------------------------------- 6.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE [...] The effect is to dynamically create an IP (or GRE) tunnel between the ingress and egress PE routers. No apriori configuration of the remote tunnel endpoints is needed. Note that these tunnels are NOT IGP- visible links, and routing adjacencies are not supported across these tunnel. Note also that the set of remote tunnel endpoints is NOT known in advance, but is learned dynamically via the BGP distribution of VPN-IP routes. ------------------------------------------------------------------------ Regards, -- Enke > > > > (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

Looking for Netscreen vendor recommendations
by Matt Bazan 22 Mar '04

22 Mar '04

I'm in the market for a couple of Netscreen appliances and would appreciate it if anyone could supply me (off list is fine) with some quality vendors. Thanks, Matt

1 0

UDP port 4000 traffic: likely a new worm
by Johannes B. Ullrich 22 Mar '04

22 Mar '04

Looks like there may be a worm going around hitting systems that run BlackIce. Common characteristics of the packets: Source port 4000 (but random target port) and the string "insert witty message here". details will be posted here: http://isc.sans.org/diary.html as I get them together. -- CTO SANS Internet Storm Center http://isc.sans.org phone: (617) 837 2807 jullrich(a)sans.org contact details: http://johannes.homepc.org/contact.htm

5 5

RE: Compromised Hosts?
by Dan Ellis 22 Mar '04

22 Mar '04

We're a regional broadband (cable/dsl) provider with 100K+ subs and we do act on any notification regarding any one of our IP's participating in a DDOS. The most useful into is to state it is a DDOS, it is affecting service for you, the time/date and the IP of the source. Traffic details always help. Our downfall is that due to the number of "notifications", our abuse team sometimes gets behind; sometimes issues are not acted on until after the DDOS has ceased. Regardless, they are contacted, warned, their account is noted, and if the behavior occurs again, they are disconnected until they are cleaned. I think it's difficult for the national guys to do this mainly because of the number of complaints that are received; most e-mails are automated, most from innocent probes or misconfigured firewalls - very few contain useful info or are DDOS's. --Dan -- Daniel Ellis, CTO - PenTeleData (610)826-9293 "The only way to predict the future is to invent it." --Alan Kay -----Original Message----- From: Deepak Jain [mailto:deepak@ai.net] Sent: Sunday, March 21, 2004 7:26 PM To: nanog(a)merit.edu Subject: Compromised Hosts? 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

3 2

VZW + Outlook2003 + SMTPS? MTU? Proxy?
by E.B. Dreger 22 Mar '04

22 Mar '04

Greetings, Has anyone encountered Mar 17 14:24:01 mail postfix/smtpd[32452]: SSL_accept error from unknown[166.154.120.211]: -1 Mar 17 14:24:01 mail postfix/smtpd[32452]: warning: Write failed in network_biopair_interop with errno=32: num_write=-1, provided=974 or similar using Outlook 2003 and SMTPS? Outlook reports a connection timeout, though Postfix obviously is seeing packets. I'm trying to determine why Outlook thinks Postfix isn't there, and why Postfix thinks the SSL negotiation was aborted. The op content: I'm asking in particular if any proxying[*], MTU issues, or other network creativity is known on the VZW network. PMTUd works on the Postfix end. I don't have the VZW-connected machine handy ATM to test further. SMTPS on that machine works correctly on non-VZW providers. I don't know about HTTPS, so I admittedly can't rule out PKI fun. [*] Yes, I know it would be foolish and futile to try proxying TCP/465 at the app level. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist(a)brics.com -or- alfra(a)intc.net -or- curbjmp(a)intc.net Sending mail to spambait addresses is a great way to get blocked.

1 0