- Test - lists.nanog.org

Correspondence to the FCC re: preemption of local government as a source of regulation
by Eric Brunner-Williams 25 Jul '14

25 Jul '14

For those interested, first in my morning's inbox is a letter from Oregon State Senator Bruce Starr (R-15, Hillsboro), and Nevada State Senator Debbie Smith (D-13), President and President-elect, respectively, of the National Conference of State Legislatures to FCC Chairman Thomas Wheeler, expressing their firm conviction as of Tuesday of this week that states have the constitutional authority to preempt municipalities in the domain of communications infrastructure. The letter is not a legal memo, so it expresses little of any use. Anyone wanting a copy can probably find it on either the FCC or the NCSL websites. Next is "by hand" of today from Jim Baller, retained by the Electrical Power Board of the City of Chatanooga, to the FCC. It is a 64pp legal memo constituting a "Petition for Removal of Barriers to Broadband Investment and Competition", that is, an argument that Section 706 of the Telecommunication Act of 1996 takes precedence over Tenn. Code Ann. § 7-52-601 ("Section 601"). Here is the link: https://www.epb.net/downloads/legal/EPB-FCCPetition.pdf I expect the second correspondence will make more interesting reading. Eric

5 6

Re: TCP Window Scaling issue
by Larry Sheldon 25 Jul '14

25 Jul '14

On 7/24/2014 10:26 PM, Roland Dobbins wrote: > > On Jul 25, 2014, at 9:13 AM, Larry Sheldon <LarrySheldon(a)cox.net> > wrote: > >> One other possibility--traffic not routed by most direct, >> fire-wall-free route, but being detoured through a firewall. > > Or a transparent layer-2 firewall that's in-line somewhere in the > path . . . Are people still using "traffic shapers"? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0

Re: TCP Window Scaling issue
by Larry Sheldon 25 Jul '14

25 Jul '14

[Sorry about the null reply.] On 7/24/2014 11:51 AM, Zach Hill wrote: > Also just to reiterate I would lean more heavily on something fishing in > the WAN cloud if all traffic from Site 1 to Site 2 were not seeing tcp > window scaling properly, however it's only for Server A that is seeing > this. Server A is able to properly TCP window scale for any local traffic. I don't have enough data to make a detailed guess, but the broad brush is that on A, B, the router A talks to, the router B talks to, or a router in the path has got an ACL that knows A's IP or MAC address that has an unplanned affect. I'd turn off all ACL's on the path and check again and if clear, turn them back on one at a time. It is not going to be something you intended to do. One other possibility--traffic not routed by most direct, fire-wall-free route, but being detoured through a firewall. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

2 1

Re: TCP Window Scaling issue
by Larry Sheldon 25 Jul '14

25 Jul '14

On 7/24/2014 11:51 AM, Zach Hill wrote: > Also just to reiterate I would lean more heavily on something fishing in > the WAN cloud if all traffic from Site 1 to Site 2 were not seeing tcp > window scaling properly, however it's only for Server A that is seeing > this. Server A is able to properly TCP window scale for any local traffic. > > > On Thu, Jul 24, 2014 at 12:47 PM, Zach Hill <zach.reborn(a)gmail.com> wrote: > >> Hi Machael, >> >> Let me setup another packet capture at each side to see if the initial >> packets are being modified at all. >> >> Thanks, >> >> >> On Thu, Jul 24, 2014 at 12:39 PM, Michael Brown <michael(a)supermathie.net> >> wrote: >> >>> On 14-07-24 12:30 PM, Zach Hill wrote: >>>> Hi Tony. No firewall in the way. >>>> >>>> Physical flow is as below. >>>> >>>> Server A -> Nexus 7k -> 3845 router -> Sprint MPLS -> 3845 router -> >>> Cisco >>>> 3750x stack -> Server B >>>> >>> I blame the cloud. >>> >>> Dump the actual packets as they leave Server A and arrive at Server B >>> (and vice-versa!). Does it get modified en route? >>> >>> M. >>> >>> -- >>> Michael Brown | The true sysadmin does not adjust his behaviour >>> Systems Administrator | to fit the machine. He adjusts the machine >>> michael(a)supermathie.net | until it behaves properly. With a hammer, >>> | if necessary. - Brian >>> >>> >> > -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0

Re: Starting a greenfield(ish) small (10k subs?) multihomed (two ASN) , dual stacked, wireless ISP - i can haz advice?
by Larry Sheldon 25 Jul '14

25 Jul '14

On 7/24/2014 4:10 AM, hayden wrote: > Sorry, no feedback from me.. I have couple of questions though, how > much licensing do you need to go through, to actually start a WISP? > Also, Kansas.. Are you concerned that you’ll have to compete with > Google Fiber at some point? I used to correspond with a man out of Hays, Kansas who started a WISP using silos--last I heard he had gotten big enough that somebody bough him out. Sorry, age-related memory rot denies me his name--there are probably lurkers here who know of him. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0

TCP Window Scaling issue
by Zach Hill 24 Jul '14

24 Jul '14

Hello, I know this isn't precisely on topic but I'm having an issue that I could use some assistance with. I'm currently seeing a very interesting issue for a single server. File transfers from Server A to Server B are relatively slow and not using up much of the circuit. Upon further inspection the TCP window size remains at default 65535 and window scaling doesn't negotiate. What's interesting is this is only affecting a single server and only when traffic is going over the WAN circuit. Testing from Server A to any server on it's network shows it is negotiating window scaling just fine. Below I'll try and draw out a better idea of what is happening. Let the letters represent the server in question and let the .# represent which subnet they are on to show whether transversal of the WAN circuit is occurring. Server A.1 -> Server B.2 = No window scaling Server A.1 -> Server C.1 = Window scaling Server B.2 -> Server A.1 = Window scaling Server C.1 -> Server B.2 = Window scaling The net result here is when window scaling is properly being used I'm seeing about 30-40 Mbps of bandwidth usage, without scaling I'm only seeing 2.8Mbps. Any thoughts?

5 12

Connectivity issue between Verizon and Amazon EC2
by Ray Van Dolson 24 Jul '14

24 Jul '14

I'm short some important details on this one, but hopefully can fill in more shortly. We're seeing poor performance (very slow download speeds -- < 100KB/sec) to certain EC2 instances via our Verizon hosted circuits. The issue is reproducible on both our production Gigabit circuit as well as a consumer grade Verizion FIOS line. Speeds are normal (10MB/sec plus) via non-Verizon circuits we've tested. Source IP's are in the 198.102.62.0/24 range and destination on the EC2 side is 54.197.239.228. I'm not sure in which availability zone the latter IP sits, but hope to find out shortly. MTR traceroute details are as follows: Host Loss% Snt Drop Avg Best Wrst StDev 1. 198.102.62.253 0.0% 526 0 0.2 0.2 0.5 0.0 2. 152.179.250.141 0.0% 526 0 14.1 7.0 19.4 3.6 3. 140.222.225.135 37.5% 526 197 7.7 6.8 35.8 1.9 4. 129.250.8.85 0.0% 526 0 8.1 7.4 11.7 0.3 5. 129.250.2.229 10.3% 525 54 11.4 7.1 85.7 9.6 6. 129.250.2.169 41.5% 525 218 63.0 45.5 130.7 10.3 7. 129.250.2.154 0.2% 525 1 59.9 44.5 69.0 4.0 8. ??? 9. 54.240.229.96 7.8% 525 41 76.6 71.3 119.9 8.6 54.240.229.104 54.240.229.106 10. 54.240.229.2 6.9% 525 36 74.7 71.6 109.1 4.9 54.240.229.4 54.240.229.20 54.240.229.8 54.240.229.14 54.240.228.254 54.240.229.16 54.240.229.10 11. 54.240.229.174 5.5% 525 29 76.0 71.7 109.0 7.3 54.240.229.162 54.240.229.160 54.240.229.170 54.240.229.172 54.240.229.168 54.240.229.164 12. 54.240.228.167 94.5% 525 495 76.4 71.7 126.0 11.6 54.240.228.169 54.240.228.165 54.240.228.163 13. 72.21.220.108 5.1% 525 27 75.2 71.3 112.6 6.8 205.251.244.12 72.21.220.8 205.251.244.64 72.21.220.96 205.251.244.8 72.21.220.6 205.251.244.4 14. 72.21.220.45 9.0% 525 47 74.0 71.6 199.5 8.5 72.21.220.149 72.21.220.29 72.21.220.125 72.21.220.37 72.21.220.61 72.21.220.2 72.21.220.69 15. 72.21.222.33 10.5% 525 55 73.4 71.5 87.1 1.5 205.251.245.65 72.21.222.149 72.21.222.35 72.21.220.29 72.21.222.131 72.21.222.147 72.21.220.37 16. 205.251.245.65 93.9% 525 492 73.1 72.2 76.2 1.2 72.21.222.35 72.21.222.131 17. ??? 18. ??? 19. 216.182.224.79 13.5% 524 71 77.9 72.4 101.2 5.4 216.182.224.81 216.182.224.95 216.182.224.77 20. 216.182.224.81 94.1% 524 492 77.9 72.8 93.0 6.3 216.182.224.95 216.182.224.77 21. ??? The 140.222.225.135 shows up in the traceroutes via our Verizon Business FIOS line as well. Will be opening a ticket with both Verizon and AWS to assist, but hoping someone out there can take a look or chime in. Feel free to reply off list. Thanks, Ray

8 14

DDoS mitigation Equinix?
by Abuse Contact 24 Jul '14

24 Jul '14

Hi, I've heard that using Equinix has it's DDoS protection benefits like large companies such as CloudFlare use them for DDoS mitigation, I don't get it, how do they help with DDoS protection? You still get a 1Gbit from them or whatever and also do you guys know around how much they'd cost? Thanks!

5 10

Re: Muni Fiber and Politics
by Scott Helms 23 Jul '14

23 Jul '14

That's not an excuse, its simply the political reality here in the US. There is a narrow place band on the size scale for a municipality where its politically acceptable in most places AND there is a true gap in coverage. In nearly all of the larger areas, though there are some exceptions, there is very little reason for a muni to go through the pain, and it is most certainly painful, any time a city considers any kinds of moves in this direction a certain percentage of the voters there will have the same position that Bill Herrin has written from. It takes a real need to exist in the minds of enough voters to get past that and get to a place where spending money is politically feasible. I would add that this is much harder in some parts of the country than in others and this is one of the reasons that you see muni's building layer 3 networks rather than going for a more open approach. The people involved in the bond arrangements almost invariably see having the city the layer 3 provider as more reliable path to getting repaid than an open system. On Wed, Jul 23, 2014 at 1:31 AM, mcfbbqroast . <bbqroast(a)gmail.com> wrote: > > The chances that a muni network in North America has both 10-20k > apartments > and needs to build its own fiber are pretty much non-existent. We don't > have the population density that exists in much of Europe and our cities > are much less dense. > > I'm tired of seeing these excuses in the US. New Zealand is much less > dense than the US and has a good municipal style open access fiber network > being built. > >> >>

6 8

Re: Muni Fiber and Politics
by Larry Sheldon 23 Jul '14

23 Jul '14

On 7/23/2014 10:24 AM, Miles Fidelman wrote: > Funny story. There are a huge number of independent telcos in Iowa. The > reason: early on, farmers discovered that you could turn pairs of barbed > wired strands into party lines. Things developed from there. In California in the 1960s Pacific had tariffs for un-francised territories for "toll stations" and "farmer lines"--the later often terminating at a small cord board. I recall taking a clearance from a repairman as "somebody left the gate open". -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0