________________________________ From: "nanog-request@nanog.org" <nanog-request@nanog.org> To: nanog@nanog.org Sent: Thu, June 17, 2010 8:00:02 AM Subject: NANOG Digest, Vol 29, Issue 51 Send NANOG mailing list submissions to nanog@nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request@nanog.org You can reach the person managing the list at nanog-owner@nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: Todd Underwood was a little late (Jon Lewis) 2. Re: Todd Underwood was a little late (Mark Andrews) 3. Re: Todd Underwood was a little late (Roy) 4. Re: Todd Underwood was a little late (Garrett Skjelstad) 5. AT&T's blue network SMS<->SMTP off the air (John Todd) 6. AAAA being added for i.root-servers.net (Lindqvist Kurt Erik) ---------------------------------------------------------------------- Message: 1 Date: Wed, 16 Jun 2010 22:43:11 -0400 (EDT) From: Jon Lewis <jlewis@lewis.org> Subject: Re: Todd Underwood was a little late To: Mark Andrews <marka@isc.org> Cc: nanog@nanog.org Message-ID: <Pine.LNX.4.61.1006162237180.5148@soloth.lewis.org> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Thu, 17 Jun 2010, Mark Andrews wrote:
Why was this traffic hitting your DNS server in the first place? It should have been rejected by the ingress filters preventing spoofing of the local network.
When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do. I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ------------------------------ Message: 2 Date: Thu, 17 Jun 2010 13:27:09 +1000 From: Mark Andrews <marka@isc.org> Subject: Re: Todd Underwood was a little late To: Jon Lewis <jlewis@lewis.org> Cc: nanog@nanog.org Message-ID: <201006170327.o5H3R9fA072599@drugs.dv.isc.org> In message <Pine.LNX.4.61.1006162237180.5148@soloth.lewis.org>, Jon Lewis write s:
On Thu, 17 Jun 2010, Mark Andrews wrote:
Why was this traffic hitting your DNS server in the first place? It should have been rejected by the ingress filters preventing spoofing of the local network.
When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do.
One can never do a perfect job but one can stop a large percentage of the crap. You should know the multi-homed customers and their address ranges so they become exceptions. You also run filters on internal routers. There are internal ingress/egress points as well as interconnects.
I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice?
---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
------------------------------ Message: 3 Date: Wed, 16 Jun 2010 21:38:42 -0700 From: Roy <r.engehausen@gmail.com> Subject: Re: Todd Underwood was a little late Cc: nanog@nanog.org Message-ID: <4C19A6D2.6030603@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 6/16/2010 7:43 PM, Jon Lewis wrote:
On Thu, 17 Jun 2010, Mark Andrews wrote:
Why was this traffic hitting your DNS server in the first place? It should have been rejected by the ingress filters preventing spoofing of the local network.
When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do.
I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice?
-
Sounds like a good use of URPF. ------------------------------ Message: 4 Date: Wed, 16 Jun 2010 22:07:10 -0700 From: Garrett Skjelstad <garrett@skjelstad.org> Subject: Re: Todd Underwood was a little late To: Roy <r.engehausen@gmail.com> Cc: nanog@nanog.org Message-ID: <AANLkTim-6WCFwrPNyBwXV1P7CwWReCa6DauH-rHvvo_a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 RFC 2827 anyone? On Wed, Jun 16, 2010 at 9:38 PM, Roy <r.engehausen@gmail.com> wrote:
On 6/16/2010 7:43 PM, Jon Lewis wrote:
On Thu, 17 Jun 2010, Mark Andrews wrote:
Why was this traffic hitting your DNS server in the first place? It
should have been rejected by the ingress filters preventing spoofing of the local network.
When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do.
I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice?
-
Sounds like a good use of URPF.
------------------------------ Message: 5 Date: Wed, 16 Jun 2010 23:26:30 -0700 From: John Todd <jtodd@loligo.com> Subject: AT&T's blue network SMS<->SMTP off the air To: nanog@nanog.org Message-ID: <7A699AC1-EF4E-4731-8D81-FAEDC3CE1C01@loligo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes To those of you who may rely upon AT&T to deliver your email-to-SMS messages for monitoring: some of you may be currently out of luck. I would just send this to the "outages@puck.nether.net" list, but it does seem to be a meta-network failure in that for better or worse many of us use SMS as a method to monitor outages, so this perhaps moves it up a notch in the importance hierarchy enough to warrant a NANOG post. I am experiencing failures on my email transmissions to my older "blue" (aka: Cingular) AT&T devices at the moment, for both incoming and outgoing. Many of you may be using older "blue" cards in your NOC phones, SMS gateway devices, or perhaps even your personal mobile devices for those of you who still live in the dark ages of phones that aren't [2.5,3,4,x]G capable. I am unable to diagnose the problems fully, but at least some (if not all) of the SMS-to-email gateway failures are due to mmode.com's MX hosts (in the "airdata.com" zone) being unreachable due to absence of functioning authoritative resolvers for that zone, and possibly other failures as well. This appears to be causing "550 Access Denied" messages being returned to my mobile devices that are sending to email addresses, and mail spooling on my Internet SMTP hosts that are trying to send to the "NPAxxxyyyy@mmode.com" addresses for SMTP-to-SMS relay. There is a rumor that this is NOT related to the deactivation of the "downloads" components of the blue network on the 15th, but I suspect that someone just decided to pull the plug on everything. Reading to the end of the thread below, there is someone who states AT&T claims it will be back online by the evening of the 17th at the surprisingly accurate time of 9:55 PM (timezone unstated.) More speculation: http://forums.wireless.att.com/t5/mMode/URGENT-mmode-down-again-Their-mta01-... I don't know if this is causing problems with anyone using TAP interfaces, or with any of AT&T's other SMTP<->SMS gateway services like @txt.att.net. SMS, and mobile devices in general, are a single point of failure for contacting on-call staff for various problems - perhaps it's time to insist that everyone carries two mobile devices, on different frequency and technology platforms, with different carriers, and split messages to both due to the anecdotally increasing failure rates of mobile networks. Conspiracy theories of how collusive unreliability would increase ARPU across the board for all carriers would be interesting to hear... but not in this forum, I suspect. :-) JT ------------------------------ Message: 6 Date: Thu, 17 Jun 2010 10:31:57 +0200 From: Lindqvist Kurt Erik <kurtis@kurtis.pp.se> Subject: AAAA being added for i.root-servers.net To: NANOG list <nanog@nanog.org> Message-ID: <E85117CB-7A03-488E-A8DB-A8764A5C3CD1@kurtis.pp.se> Content-Type: text/plain; charset="iso-8859-1" All, This is to inform you that, we (Netnod/Autonomica, operators of i.root-servers.net) have been notified by IANA that on our request an AAAA record will be added to the root-zone with serial number 2010061700. Best regards, - kurtis - --- Kurt Erik Lindqvist, CEO kurtis@netnod.se, Direct: +46-8-562 860 11, Switch: +46-8-562 860 00 Please note our new address: Franz?ngatan 5 | SE-112 51 Stockholm | Sweden
participants (1)
-
T Kawasaki