Re: NANOG 60 - Atlanta - Call For Presentations is open!

2013-12-03 Thread Greg Dendy
Reminder the submission period for NANOG 60 is still open, although the 
deadline is approaching fast!

Thanks,

Greg



On Oct 30, 2013, at 2:12 PM, Greg Dendy wrote:

NANOG Community,
I hope everyone enjoyed NANOG 59 in Phoenix, NANOG’s largest attended meeting.  
Fresh off a great meeting, and our NANOG annual elections, we are already 
starting to get ready for NANOG 60 in Atlanta.  If you have a topic you'd like 
to speak about, the program committee would love to consider it.  Please read 
http://www.nanog.org/meetings/nanog60/callforpresentations for more information.
We will continue with the Monday-Wednesday format, with Tracks on Monday 
afternoon and Tutorials to be scheduled on Tuesday morning.  The program will 
begin on Monday morning at 10:00AM followed by our popular Newcomers Lunch.  
The exact schedule layout can be found at 
http://www.nanog.org/meetings/nanog60/preagenda, please take this into account 
as you plan travel.  If you wish to submit a presentation, please keep these 
important dates in mind:

 *   Presentation Abstracts and Draft Slides Due: December 9, 2013
 *   Final Slides Due: January 6, 
2014
 *   Topic List Posted:   December 20, 2013
 *   Agenda Published:   January 13, 2014

Please submit your materials to http://pc.nanog.org.

Looking forward to seeing everyone in Atlanta!

Thanks,

Greg Dendy
Chair, NANOG Program Committee






Re: Anyone competent within AT&T Uverse?

2013-12-03 Thread Thomas
You need to talk to Alcatel Tac team.  They will be able to help you.  Prem 
tech don't have the knowledge or resources.  Tier one is useless and can only 
do basic diagnostics., tier two won't be able to help but they can open an AOTS 
ticket that can engage Alcatel Tac.  Good luck.  May need to insist on 
executive escalation.  Just saying. 

Thomas L Graves
Sent from my IPhone 


> On Dec 3, 2013, at 9:21 PM, Eric A Louie  wrote:
> 
> Ask to be escalated to Tier 2.  If they can't help, ask for another 
> escalation.  Show them traceroutes if you can (maybe from your phone or from 
> one of us) from other networks so they can see where it's dying.
> 
> 
> 
> 
> 
>> 
>> From: Phil Karn 
>> To: NANOG  
>> Sent: Tuesday, December 3, 2013 7:04 PM
>> Subject: Anyone competent within AT&T Uverse?
>> 
>> 
>> Does anyone know anyone within AT&T Uverse who actually knows what
>> TCP/IP is? Maybe even how to read a packet trace?
>> 
>> I've been trying to get my static IP block working again since Saturday
>> when they broke it while fixing an unrelated problem. I can't believe
>> how incompetent their tech support has been on this. An hour into a chat
>> with them and I finally realize they don't have a clue what I'm talking
>> about...this is very frustrating...
>> 
>> Their premise techs try very hard, but I get the strong impression that
>> the network support people randomly perturb provisioning until it works
>> again, and that's why they keep breaking unrelated things.
>> 
>> I'm still wondering if this Internet stuff is ready for prime time...
>> 
>> Thanks,
>> 
>> Phil
>> 
>> 
>> 
>> 



Re: Anyone competent within AT&T Uverse?

2013-12-03 Thread Eric A Louie
Ask to be escalated to Tier 2.  If they can't help, ask for another escalation. 
 Show them traceroutes if you can (maybe from your phone or from one of us) 
from other networks so they can see where it's dying.





>
> From: Phil Karn 
>To: NANOG  
>Sent: Tuesday, December 3, 2013 7:04 PM
>Subject: Anyone competent within AT&T Uverse?
> 
>
>Does anyone know anyone within AT&T Uverse who actually knows what
>TCP/IP is? Maybe even how to read a packet trace?
>
>I've been trying to get my static IP block working again since Saturday
>when they broke it while fixing an unrelated problem. I can't believe
>how incompetent their tech support has been on this. An hour into a chat
>with them and I finally realize they don't have a clue what I'm talking
>about...this is very frustrating...
>
>Their premise techs try very hard, but I get the strong impression that
>the network support people randomly perturb provisioning until it works
>again, and that's why they keep breaking unrelated things.
>
>I'm still wondering if this Internet stuff is ready for prime time...
>
>Thanks,
>
>Phil
>
>
>
>


Anyone competent within AT&T Uverse?

2013-12-03 Thread Phil Karn
Does anyone know anyone within AT&T Uverse who actually knows what
TCP/IP is? Maybe even how to read a packet trace?

I've been trying to get my static IP block working again since Saturday
when they broke it while fixing an unrelated problem. I can't believe
how incompetent their tech support has been on this. An hour into a chat
with them and I finally realize they don't have a clue what I'm talking
about...this is very frustrating...

Their premise techs try very hard, but I get the strong impression that
the network support people randomly perturb provisioning until it works
again, and that's why they keep breaking unrelated things.

I'm still wondering if this Internet stuff is ready for prime time...

Thanks,

Phil



Re: AT&T UVERSE Native IPv6, a HOWTO

2013-12-03 Thread Mark Andrews

In message <529d9492.8020...@inblock.ru>, Nikolay Shopik writes:
> On 03/12/13 02:54, Owen DeLong wrote:
> > I have talked to my bean counters. We give out /48s to anyone who wants 
> > them and we don't charge for IPv6 add
> ress space.
> 
> There is some ISP who afraid their users will be reselling their
> connectivity to other users around. While I didin't see that in years
> (probably last time in 2005) but still this exist in poor regions.

And if they didn't resell it they probably wouldn't have a customer
in the first place.  Unless you offer "unlimited" plans the ISP
isn't losing anything here.  The bandwidth being used is being paid
for.  If it isn't the ISP needs to adjust the price points to cover
their costs rather than hoping that people won't use all of the
bandwidth they have purchased.

It's two maybe sales vs one confirmed sale.

This is like the whole tethered debate.  Why should the ISP care
about which device the packets are source from.  The customer is
buying so many gigabytes of traffic a month.  They should be able
to use them anyway they see fit without actually breaking the laws
of the land.

I let my daughter's friends use the net at home here.  If they burn
through my monthly allotment well then I need to pony up more money
or take a reduced service level until the month ends.  It's none
of my ISP's concern how the bandwidth I have purchased from them
is being used.

Note there really isn't unlimited.  There is pipe width * 29-30
days of traffic.  If you have purchased a "unlimited" service then
you should be able to pull that amount of traffic without the ISP
complaining.

> Other than that, completely agree on /56y default and /48 on request,
> but most ISPs here are give-out just single /64.

Which is just plain stupid.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org



Re: Advice on v4 NAT for farm of file transfer clients

2013-12-03 Thread Christopher Morrow
1) why not just use public ips?
2) why not (if not 1) have more than 1 outbound path/nat-device?

On Tue, Dec 3, 2013 at 5:05 PM, Andy Litzinger
 wrote:
> Hi all,
>   We have a pool of around 100 file transfer clients.  They reach out to 
> publicly addressed servers on the net to get and put files.  Rather than burn 
> 100 public v4 addresses for the clients, we've traditionally had these guys 
> behind a firewall performing source NAT/PAT overloading about 10 IPs.
>
> Recently we've been seeing increases in the amount of throughput to/from the 
> servers through the FW.  Within the next 12 mos I expect we'll want to 
> support 10Gbps.  Since buying a firewall that supports 10Gbps is fairly 
> expensive I thought i'd seek out alternative ideas before we blindly purchase 
> a bigger firewall.  Also, a stateful firewall seems like a bit of overkill 
> for what is actually required.  I'm confident we can limit our FTP support to 
> passive connections which should remove the requirement of using a device 
> that supports active FTP (i.e. application inspection).
>
> currently we're using a Juniper SRX550 to do this (which replaced an 
> overwhelmed ASA 5520).  Avg packet size we see according to the SRX is 1000 
> bytes.
>
> thanks!
>  -andy



Advice on v4 NAT for farm of file transfer clients

2013-12-03 Thread Andy Litzinger
Hi all,
  We have a pool of around 100 file transfer clients.  They reach out to 
publicly addressed servers on the net to get and put files.  Rather than burn 
100 public v4 addresses for the clients, we've traditionally had these guys 
behind a firewall performing source NAT/PAT overloading about 10 IPs.

Recently we've been seeing increases in the amount of throughput to/from the 
servers through the FW.  Within the next 12 mos I expect we'll want to support 
10Gbps.  Since buying a firewall that supports 10Gbps is fairly expensive I 
thought i'd seek out alternative ideas before we blindly purchase a bigger 
firewall.  Also, a stateful firewall seems like a bit of overkill for what is 
actually required.  I'm confident we can limit our FTP support to passive 
connections which should remove the requirement of using a device that supports 
active FTP (i.e. application inspection).

currently we're using a Juniper SRX550 to do this (which replaced an 
overwhelmed ASA 5520).  Avg packet size we see according to the SRX is 1000 
bytes.

thanks!
 -andy


Re: AT&T UVERSE Native IPv6, a HOWTO

2013-12-03 Thread Owen DeLong

On Dec 3, 2013, at 00:21 , Nikolay Shopik  wrote:

> On 03/12/13 02:54, Owen DeLong wrote:
>> I have talked to my bean counters. We give out /48s to anyone who wants them 
>> and we don't charge for IPv6 address space.
> 
> There is some ISP who afraid their users will be reselling their
> connectivity to other users around. While I didin't see that in years
> (probably last time in 2005) but still this exist in poor regions.

I gotta say that, personally,  I think worrying about this is kind of silly. 
First, end-user connections don't have enough bandwidth to make sharing 
particularly appealing, especially in poor regions. Second, where it does 
happen, the ISP isn't really losing anything and it's not like they have some 
entitlement to the user not doing so. Third, addressing really isn't the hurdle 
that will stop this.

> 
> Other than that, completely agree on /56y default and /48 on request,
> but most ISPs here are give-out just single /64.

Ugh.

Owen




Philadelphia Internet Exchange

2013-12-03 Thread Chris Rogers
Hello NANOG,

We're in the process of starting up an IXP in Philadelphia, and I wanted to
see if there were any networks that would be interested in connecting.

Currently, we have just over 10 networks that have expressed interest.
(Listed on http://phlix.net/) If you would like to be added, please email
me off list with your company name, peering ASN, and any preferred colo(s)
where you would like to see PHLIX present.

Initially, we're expecting to have switches in 401 N Broad and 3701 Market,
with a link between the two buildings. If there's enough demand, we'd also
look at 2401 Locust and 833 Chestnut.

We are looking to run this as "revenue neutral", so to properly price out
ports, we need to get a rough idea who's interested in connecting.

Thanks!

-Chris Rogers
The Philadelphia Internet Exchange
http://phlix.net/


Routing Policy Survey Results

2013-12-03 Thread Phillipa Gill
Hi NANOG!

We’d like to thank everyone who answered our survey on routing policies and 
everyone who gave feedback on our presentation of preliminary survey results at 
NANOG56 (https://www.nanog.org/meetings/abstract?id=1996 ).

A more complete exposition of the survey results will be appearing in the 
January 2014 issue of ACM Computer Communications Review and can be found 
online at this URL: http://www.cs.stonybrook.edu/~phillipa/papers/CCR2014.pdf 

Thanks again to everyone who helped out with our efforts. 

- Phillipa Gill, Sharon Goldberg, Michael Schapira

Re: AT&T UVERSE Native IPv6, a HOWTO

2013-12-03 Thread Rob Seastrom

Cutler James R  writes:

> Does this mean we can all get back to solving real IPv6 deployment and 
> operations problems?

I sure hope so.  :)

> I certainly hope you all can finally see which is the better business choice 
> between: 
>
>  1. Using up to around 10% of IPv6 space to make our network operations 
> simpler for the next twenty years or more.

You're high by more than an order of magnitude.  Inasmuch as I don't
hail from Chicago, I'm not suggesting actually issuing addresses to
people who are dead (Eric's final datapoint).

>  2. Continuing to spend time and money on micromanagement of addressing 
> rather than real customer needs.
>
> One who cannot properly understand the business decision here perhaps should 
> not be debating network policies.
>
> "Strongly worded letter to follow."

Indeed.

-r




Re: AT&T UVERSE Native IPv6, a HOWTO

2013-12-03 Thread Seth Mos
On 2-12-2013 22:25, Ricky Beam wrote:
> On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom  wrote:

> Handing out /56's like Pez is just wasting address space -- someone *is*
> paying for that space. Yes, it's waste; giving everyone 256 networks

You clearly have no understanding of route aggregation which just made
it's entry into the soho.

The router will set up it's own DHCP-PD prefix delegation for downstream
routers. Without a /56 or larger it is very hard to do automatically.

It is not "wasting" it is "required" for proper operation of a routing
internet. You can't just NAT a downstream router and still have IPv6.

People buy extra wifi routers at their favorite shop and *will* plug the
cable into the "Internet" port. With IPv6 and DHCP-PD they will still
get working IPv6 internet. Great!

Cheers,
Seth



Re: AT&T UVERSE Native IPv6, a HOWTO

2013-12-03 Thread Nikolay Shopik
On 03/12/13 02:54, Owen DeLong wrote:
> I have talked to my bean counters. We give out /48s to anyone who wants them 
> and we don't charge for IPv6 address space.

There is some ISP who afraid their users will be reselling their
connectivity to other users around. While I didin't see that in years
(probably last time in 2005) but still this exist in poor regions.

Other than that, completely agree on /56y default and /48 on request,
but most ISPs here are give-out just single /64.