help

T Kawasaki nanog2011 at yahoo.com
Thu Jun 17 09:55:01 CDT 2010





________________________________
From: "nanog-request at nanog.org" <nanog-request at nanog.org>
To: nanog at 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 at 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 at nanog.org

You can reach the person managing the list at
    nanog-owner at 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 at lewis.org>
Subject: Re: Todd Underwood was a little late 
To: Mark Andrews <marka at isc.org>
Cc: nanog at nanog.org
Message-ID: <Pine.LNX.4.61.1006162237180.5148 at 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 at isc.org>
Subject: Re: Todd Underwood was a little late 
To: Jon Lewis <jlewis at lewis.org>
Cc: nanog at nanog.org
Message-ID: <201006170327.o5H3R9fA072599 at drugs.dv.isc.org>


In message <Pine.LNX.4.61.1006162237180.5148 at 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 at isc.org



------------------------------

Message: 3
Date: Wed, 16 Jun 2010 21:38:42 -0700
From: Roy <r.engehausen at gmail.com>
Subject: Re: Todd Underwood was a little late
Cc: nanog at nanog.org
Message-ID: <4C19A6D2.6030603 at 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 at skjelstad.org>
Subject: Re: Todd Underwood was a little late
To: Roy <r.engehausen at gmail.com>
Cc: nanog at nanog.org
Message-ID:
    <AANLkTim-6WCFwrPNyBwXV1P7CwWReCa6DauH-rHvvo_a at 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 at 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 at loligo.com>
Subject: AT&T's blue network SMS<->SMTP off the air
To: nanog at nanog.org
Message-ID: <7A699AC1-EF4E-4731-8D81-FAEDC3CE1C01 at 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 at 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 at 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-cdpd-airdata-com-mail-server/td-p/1939480

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 at kurtis.pp.se>
Subject: AAAA being added for i.root-servers.net
To: NANOG list <nanog at nanog.org>
Message-ID: <E85117CB-7A03-488E-A8DB-A8764A5C3CD1 at 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 at 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

    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://mailman.nanog.org/pipermail/nanog/attachments/20100617/ab0ea84a/attachment-0001.pgp 

------------------------------

_______________________________________________
NANOG mailing list
NANOG at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog

End of NANOG Digest, Vol 29, Issue 51
*************************************



      


More information about the NANOG mailing list