Re: [AFMUG] Google Fiber is no more

[Mike Hammett]

As they should. Don't build where people who can't pay or don't want your 
service. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Rory Conaway"  
To: af@afmug.com 
Sent: Wednesday, October 26, 2016 11:28:52 PM 
Subject: Re: [AFMUG] Google Fiber is no more 



In other cities, they cherry picked. 

Rory 



From: Af [mailto:af-boun...@afmug.com] On Behalf Of Sterling Jacobson 
Sent: Wednesday, October 26, 2016 7:00 PM 
To: af@afmug.com 
Subject: Re: [AFMUG] Google Fiber is no more 

>From the director of one of the Google Fiber builds (in Provo) that is not the 
>case. 

He said they overspent on contractors MAJORLY. 
And that was just to expand the existing network to all homes in that area. 

He argued with his bosses about he extravagant added fees on construction but 
they just said to pay them, no questions asked. 

I had some of those figures from him at that conversation and some costs were 
over 80x what it should have been. 

My best guess is that all the fiber build in certain areas increased the 
contract cost of build into the stratosphere. 

And now they are reigning it in and going wireless to attempt to defray the 
costs. 

At least with Provo they were not allowed to cherry pick, it was build 
everyone. 
And it seems like they picked up a large portion of the communities, but I 
didn’t get overall take rate. 



From: Af [ mailto:af-boun...@afmug.com ] On Behalf Of Rory Conaway 
Sent: Wednesday, October 26, 2016 12:56 AM 
To: af@afmug.com 
Subject: Re: [AFMUG] Google Fiber is no more 

Absolutely they cherry picked. Then they went into MDU’s for pennies and lost 
their shirts. 

Rory 

From: Af [ mailto:af-boun...@afmug.com ] On Behalf Of Josh Reynolds 
Sent: Tuesday, October 25, 2016 9:34 PM 
To: af@afmug.com 
Subject: Re: [AFMUG] Google Fiber is no more 

I'd love to see their overall take rates. I have heard numbers of 75-85% in 
more affluent areas. They cherry picked neighborhoods for sure though. 



On Oct 25, 2016 10:15 PM, "Rory Conaway" < r...@triadwireless.net > wrote: 


Big surprise there. They built it and no one came. 

Rory 



From: Af [mailto: af-boun...@afmug.com ] On Behalf Of Tushar Patel 
Sent: Tuesday, October 25, 2016 7:14 PM 
To: af@afmug.com 
Subject: Re: [AFMUG] Google Fiber is no more 


Their contractor are still hiring installer in Austin. 



Need to probably understand why those cities not others? 

Tushar 




On Oct 25, 2016, at 9:06 PM, Josh Reynolds < j...@kyneticwifi.com > wrote: 



New ones. They're still deploying existing networks. They just opened up a few 
new areas in Kansas City recently. 



On Oct 25, 2016 9:03 PM, "Jaime Solorza" < losguyswirel...@gmail.com > wrote: 


Moving folks to wireless Aye Dios 



On Oct 25, 2016 7:56 PM, "Gino Villarini" < ginovi...@gmail.com > wrote: 


https://gizmodo.com/google-fiber-halts-operations-in-ten-cities-1788214992?rev=1477443092657&utm_campaign=socialflow_gizmodo_facebook&utm_source=gizmodo_facebook&utm_medium=socialflow
 

Re: [AFMUG] Mikrotik DNS Cache

[Mike Hammett]

I think we've all had issues with you. :-p 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Josh Luthman"  
To: af@afmug.com 
Sent: Wednesday, October 26, 2016 9:49:38 AM 
Subject: Re: [AFMUG] Mikrotik DNS Cache 


I had issues with just myself... 
Josh Luthman 
Office: 937-552-2340 
Direct: 937-552-2343 
1100 Wayne St 
Suite 1337 
Troy, OH 45373 


On Oct 26, 2016 10:45 AM, "Dennis Burgess" < dmburg...@linktechs.net > wrote: 


Does it work, yes it is the same as a high performance DNS server, no. Is a 
dedicated DNS resolvers expensive, no. Getting starting say under 100-150 
users, ok, for a while, once you go over that, really need to move to dedicated 
resolvers. 


Dennis Burgess – Network Solution Engineer – Consultant 
MikroTik Certified Trainer/Consultant – MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE 

For Wireless Hardware/Routers visit www.linktechs.net 
Radio Frequiency Coverages: www.towercoverage.com 
Office: 314-735-0270 
E-Mail: dmburg...@linktechs.net 

-Original Message- 
From: Af [mailto: af-boun...@afmug.com ] On Behalf Of Matt 
Sent: Wednesday, October 26, 2016 8:54 AM 
To: af@afmug.com 
Subject: [AFMUG] Mikrotik DNS Cache 

Is anyone using the Mikrotik DNS cache as there primary DNS resolver for there 
clients? Say use a CCR and your largest upstreams DNS server as parent. Should 
there be any issues with that? 

Re: [AFMUG] new powerinjector plus

[Forrest Christian (List Account)]

Can you tell me if there is a removable sticker on the top of that unit?

There is supposed to be a sticker which says exactly what George says
below...  either staff didn't put it on there, or I need to find out what
it says to make it clearer.



On Wed, Oct 26, 2016 at 11:55 AM, Ryan Mano 
wrote:

> Can someone tell me how to wire the 4 pin green connector
>
>
>
> It use to be 2 prong but its 4 now its labeled PowerA PowerB Comon and
> shield…am just powering up pmp100’s
>
>
>
> thanks
>



-- 
*Forrest Christian* *CEO**, PacketFlux Technologies, Inc.*
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
forre...@imach.com | http://www.packetflux.com
  

[AFMUG] Ubiquiti makes the big time...

[Mark Radabaugh]

The good news:  kit gets reviewed on a major IT website.
The bad news: kit gets reviewed on a major IT website.

http://www.theregister.co.uk/2016/10/27/ubiquiti_edgeswitch_review/

Mark

Re: [AFMUG] Trouble Identifying Throughput Issue

[Steve]

I agree.. make sure you have R1 and R2's connecting interfaces both set to 
manual 100FD because it can't go any higher anyway.  That is a mismatch.  Not 
sure if that is THE problem but it is definitely A problem. 

- Original Message -
From: "George Skorup" 
To: "af" 
Sent: Wednesday, October 26, 2016 5:24:07 PM
Subject: Re: [AFMUG] Trouble Identifying Throughput Issue

The manual 100FD interface... what is that talking to? The Auto 1G on 
R1? If that's the case, I'd bet that's your problem. Keep in mind that 
you cannot run auto on one side and fixed FDX on the other side. This 
results in a duplex mismatch. The interface in auto will fall back to 
HDX. If you did auto one side and HDX on the other side, they'd both be 
HDX, so it would work fine. But obviously half duplex sux.

On 10/26/2016 1:54 PM, Christopher Gray wrote:
> R1 is the only router with 1 Gbps ports. Everything is auto except 1 
> connection that requires manual settings.
>
> *R1* -- (Auto 1 G FD) ...Internet... (Manual 100 FD) -- *R2 *-- (Auto 
> 100 FD)  -- *R3* -- (Auto 100 FD) ...M5... (Auto 100 FD) -- *R4*
>
> MTU is set to 1500 on every port (and the UBNT link).
>
> Flow control is off, and none of the interfaces show any pause frames 
> received.
>
>
> This is a live link, but it is only running ~ 1 Mbps otherwise.
>
>
>
> On Wed, Oct 26, 2016 at 2:12 PM, Steve  > wrote:
>
> Few questions come to mind.
>
> Are all set to auto negotiate or are they fixed at 100Mbit?
> What are the MTU's of each connection?
> Flow control turned on?
>
>
> - Original Message -
> From: "Christopher Gray"  >
> To: "af" mailto:af@afmug.com>>
> Sent: Wednesday, October 26, 2016 1:57:56 PM
> Subject: [AFMUG] Trouble Identifying Throughput Issue
>
> I have a section of my network that is lacking something, and I can't
> figure out where the problem is. I'm looking for any thoughts /
> suggestions.
>
> 4x MikroTik routers
>
> Link speeds:
> R1 -- (30 Mbps IP / Transport) -- R2 -- (100 Mbps Eth) -- R3 --
> (75 Mbps
> UBNT M5) -- R4
>
> The limiting factor for traffic should be the Transport, and I
> expect to be
> able to get 30 Mbps across the system (one-way).
>
> Testing from R1 to R3 runs 30 Mbps.
>
> Testing from R2 to R4 runs 75 Mbps.
>
> Testing from R1 to R4 only runs 10 Mbps (instead of 30).
>
> Tests were one-way btest with 20 TCP streams.
>
> Any ideas for something that would cause this?
>
>

Re: [AFMUG] Ubiquiti makes the big time...

[Josh Reynolds]

I complained about the DAC issue during the Alpha, as I just wanted to plug
in the switch to a Juniper MX960 and throw some of the VM load on it. Sadly
I ended up having to use short patch cables and fiberstore transceivers,
which worked fine.

I didn't experience the crashes the author did, although I "whitelist" all
my hardware interfaces in my browser extensions... Maybe that was his/her
issue, I don't know.

Side note: the was about 6 months back

On Oct 27, 2016 7:33 AM, "Mark Radabaugh"  wrote:

> The good news:  kit gets reviewed on a major IT website.
> The bad news: kit gets reviewed on a major IT website.
>
> http://www.theregister.co.uk/2016/10/27/ubiquiti_edgeswitch_review/
>
> Mark
>

Re: [AFMUG] Ubiquiti makes the big time...

[Mike Hammett]

Anything that doesn't support DACs is fucking worthless. 


I've ditched all ad-block, privacy, etc. extensions. They're garbage. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Josh Reynolds"  
To: af@afmug.com 
Sent: Thursday, October 27, 2016 7:50:21 AM 
Subject: Re: [AFMUG] Ubiquiti makes the big time... 


I complained about the DAC issue during the Alpha, as I just wanted to plug in 
the switch to a Juniper MX960 and throw some of the VM load on it. Sadly I 
ended up having to use short patch cables and fiberstore transceivers, which 
worked fine. 
I didn't experience the crashes the author did, although I "whitelist" all my 
hardware interfaces in my browser extensions... Maybe that was his/her issue, I 
don't know. 
Side note: the was about 6 months back 


On Oct 27, 2016 7:33 AM, "Mark Radabaugh" < m...@amplex.net > wrote: 




The good news: kit gets reviewed on a major IT website. 
The bad news: kit gets reviewed on a major IT website. 


http://www.theregister.co.uk/2016/10/27/ubiquiti_edgeswitch_review/ 



Mark 

Re: [AFMUG] Ubiquiti makes the big time...

[Josh Luthman]

AdBlock is great.  Not what it used to be, taking money from both sides...

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Oct 27, 2016 8:57 AM, "Mike Hammett"  wrote:

> Anything that doesn't support DACs is fucking worthless.
>
>
> I've ditched all ad-block, privacy, etc. extensions. They're garbage.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
>
>
> 
> --
> *From: *"Josh Reynolds" 
> *To: *af@afmug.com
> *Sent: *Thursday, October 27, 2016 7:50:21 AM
> *Subject: *Re: [AFMUG] Ubiquiti makes the big time...
>
> I complained about the DAC issue during the Alpha, as I just wanted to
> plug in the switch to a Juniper MX960 and throw some of the VM load on it.
> Sadly I ended up having to use short patch cables and fiberstore
> transceivers, which worked fine.
>
> I didn't experience the crashes the author did, although I "whitelist" all
> my hardware interfaces in my browser extensions... Maybe that was his/her
> issue, I don't know.
>
> Side note: the was about 6 months back
>
> On Oct 27, 2016 7:33 AM, "Mark Radabaugh"  wrote:
>
>> The good news:  kit gets reviewed on a major IT website.
>> The bad news: kit gets reviewed on a major IT website.
>>
>> http://www.theregister.co.uk/2016/10/27/ubiquiti_edgeswitch_review/
>>
>> Mark
>>
>
>

Re: [AFMUG] Ubiquiti makes the big time...

[Mike Hammett]

I don't support ad-blocking in general. As an advertiser, how can I? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Josh Luthman"  
To: af@afmug.com 
Sent: Thursday, October 27, 2016 8:04:06 AM 
Subject: Re: [AFMUG] Ubiquiti makes the big time... 


AdBlock is great. Not what it used to be, taking money from both sides... 
Josh Luthman 
Office: 937-552-2340 
Direct: 937-552-2343 
1100 Wayne St 
Suite 1337 
Troy, OH 45373 


On Oct 27, 2016 8:57 AM, "Mike Hammett" < af...@ics-il.net > wrote: 




Anything that doesn't support DACs is fucking worthless. 


I've ditched all ad-block, privacy, etc. extensions. They're garbage. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 






From: "Josh Reynolds" < j...@kyneticwifi.com > 
To: af@afmug.com 
Sent: Thursday, October 27, 2016 7:50:21 AM 
Subject: Re: [AFMUG] Ubiquiti makes the big time... 


I complained about the DAC issue during the Alpha, as I just wanted to plug in 
the switch to a Juniper MX960 and throw some of the VM load on it. Sadly I 
ended up having to use short patch cables and fiberstore transceivers, which 
worked fine. 
I didn't experience the crashes the author did, although I "whitelist" all my 
hardware interfaces in my browser extensions... Maybe that was his/her issue, I 
don't know. 
Side note: the was about 6 months back 


On Oct 27, 2016 7:33 AM, "Mark Radabaugh" < m...@amplex.net > wrote: 




The good news: kit gets reviewed on a major IT website. 
The bad news: kit gets reviewed on a major IT website. 


http://www.theregister.co.uk/2016/10/27/ubiquiti_edgeswitch_review/ 



Mark 

Re: [AFMUG] Google Fiber is no more

[Brian Webster]

I worked directly on the San Jose and Sand Diego projects. I was brought in by 
one of the main contractors to help reduce costs and increase efficiency. 
Google had way too many “30 somethings” who failed to listen to experienced 
telecom professionals. That was one of their biggest faults. It was insane to 
try and build a network in San Jose that was going to have to be built mostly 
underground. That market already had new AT&T U-verse fiber and Time Warner 
with a very strong network. Heck I could get 100 meg speeds on Wi-Fi at the 
hotel I stayed in. Their Ego to build in their own backyard was pushing the 
build more than anything. 

 

The concept of cherry picking neighborhoods actually drove costs up. When they 
wanted a citywide network design, that is what they were delivered, but then 
try and build out only neighborhoods they wanted while still trying to figure 
out how much of their backbones, huts and neighborhood distribution system 
needed to be put in place to service the piecemeal buildout approach, when you 
were already having to open ditches, while having to be a mostly underground 
build? Yea that was a nightmare too! Then let’s talk about how they had no clue 
how hard the MDU market is to secure. They gave no real consideration to 
existing deals in the buildings, or the cost of having to wire on their own 
because the building owner did not actually own the existing cable plant and 
such. These projects were not just a simple math problem to solve. 

 

They naively thought every city was going to welcome them with open arms like 
Kansas City did. They believed the political hype the politicians told them to 
lure them to their cities, then when actual laws both of physics and real came 
in to play, the numbers looked a whole lot uglier. Underground building in 
established cities is a nightmare in both costs, regulations, logistics and 
amount of work required. Just simple things like trying to gather data on all 
the existing underground infrastructure (that has no central source of 
documentation) was painful and costly. You can’t get drawings approved without 
first showing you will not be interfering with existing utilities already 
underground. In many cases you have to manually locate this stuff and then map 
it and then do your design around that information. Other issues to overhead 
builds were poles that would not pass loading calculations, pole owners who 
were less than cooperative or that pulled out new loading rules that they 
themselves don’t follow and you can see where it was not a simple process. The 
employee count to deal with all of this on a large scale at the pace they 
wanted to move was not small by any stretch.

 

This was not new news. They pulled the plug on all of this stuff back at the 
beginning of July.

 

Thank You,

Brian Webster

www.wirelessmapping.com

www.Broadband-Mapping.com

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Mike Hammett
Sent: Thursday, October 27, 2016 7:32 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

 

As they should. Don't build where people who can't pay or don't want your 
service.



-
Mike Hammett
  Intelligent Computing Solutions
   
  
  
 
  Midwest Internet Exchange
   
  
 
  The Brothers WISP
   
 




  _  

From: "Rory Conaway" 
To: af@afmug.com
Sent: Wednesday, October 26, 2016 11:28:52 PM
Subject: Re: [AFMUG] Google Fiber is no more

In other cities, they cherry picked.

 

Rory

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Sterling Jacobson
Sent: Wednesday, October 26, 2016 7:00 PM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

 

>From the director of one of the Google Fiber builds (in Provo) that is not the 
>case.

 

He said they overspent on contractors MAJORLY.

And that was just to expand the existing network to all homes in that area.

 

He argued with his bosses about he extravagant added fees on construction but 
they just said to pay them, no questions asked.

 

I had some of those figures from him at that conversation and some costs were 
over 80x what it should have been.

 

My best guess is that all the fiber build in certain areas increased the 
contract cost of build into the stratosphere.

 

And now they are reigning it in and going wireless to attempt to defray the 
costs.

 

At least with Provo they were not allowed to cherry pick, it was build everyone.

And it seems like they picked up a large portion of the communities, but I 
di

Re: [AFMUG] Google Fiber is no more

[Robert]

Phd syndrome...  Getting an advanced degree at a big Uni gives you 
almost zero experience in the trenches...   The move to wireless means 
that they can buy their way into the FCC and move down from there...


On 10/27/16 6:40 AM, Brian Webster wrote:

I worked directly on the San Jose and Sand Diego projects. I was brought
in by one of the main contractors to help reduce costs and increase
efficiency. Google had way too many �30 somethings� who failed to listen
to experienced telecom professionals. That was one of their biggest
faults. It was insane to try and build a network in San Jose that was
going to have to be built mostly underground. That market already had
new AT&T U-verse fiber and Time Warner with a very strong network. Heck
I could get 100 meg speeds on Wi-Fi at the hotel I stayed in. Their Ego
to build in their own backyard was pushing the build more than anything.



The concept of cherry picking neighborhoods actually drove costs up.
When they wanted a citywide network design, that is what they were
delivered, but then try and build out only neighborhoods they wanted
while still trying to figure out how much of their backbones, huts and
neighborhood distribution system needed to be put in place to service
the piecemeal buildout approach, when you were already having to open
ditches, while having to be a mostly underground build? Yea that was a
nightmare too! Then let�s talk about how they had no clue how hard the
MDU market is to secure. They gave no real consideration to existing
deals in the buildings, or the cost of having to wire on their own
because the building owner did not actually own the existing cable plant
and such. These projects were not just a simple math problem to solve.



They naively thought every city was going to welcome them with open arms
like Kansas City did. They believed the political hype the politicians
told them to lure them to their cities, then when actual laws both of
physics and real came in to play, the numbers looked a whole lot uglier.
Underground building in established cities is a nightmare in both costs,
regulations, logistics and amount of work required. Just simple things
like trying to gather data on all the existing underground
infrastructure (that has no central source of documentation) was painful
and costly. You can�t get drawings approved without first showing you
will not be interfering with existing utilities already underground. In
many cases you have to manually locate this stuff and then map it and
then do your design around that information. Other issues to overhead
builds were poles that would not pass loading calculations, pole owners
who were less than cooperative or that pulled out new loading rules that
they themselves don�t follow and you can see where it was not a simple
process. The employee count to deal with all of this on a large scale at
the pace they wanted to move was not small by any stretch.



This was not new news. They pulled the plug on all of this stuff back at
the beginning of July.



Thank You,

Brian Webster

www.wirelessmapping.com 

www.Broadband-Mapping.com



*From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Mike Hammett
*Sent:* Thursday, October 27, 2016 7:32 AM
*To:* af@afmug.com
*Subject:* Re: [AFMUG] Google Fiber is no more



As they should. Don't build where people who can't pay or don't want
your service.



-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 







*From: *"Rory Conaway" mailto:r...@triadwireless.net>>
*To: *af@afmug.com 
*Sent: *Wednesday, October 26, 2016 11:28:52 PM
*Subject: *Re: [AFMUG] Google Fiber is no more

In other cities, they cherry picked.



Rory



*From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Sterling Jacobson
*Sent:* Wednesday, October 26, 2016 7:00 PM
*To:* af@afmug.com 
*Subject:* Re: [AFMUG] Google Fiber is no more



From the director of one of the Google Fiber builds (in Provo) that is
not the case.



He said they overspent on contractors MAJORLY.

And that was just to expand the existing network to all homes in that area.



He argued with his bosses about he extravagant added fees on
construction but they just said to pay them, no questions asked.



I had some of those figures from him at that conversation and some costs
were over 80x what it should have be

Re: [AFMUG] Mikrotik DNS Cache

[That One Guy /sarcasm]

[image: Inline image 1]

On Thu, Oct 27, 2016 at 6:48 AM, Mike Hammett  wrote:

> I think we've all had issues with you. :-p
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
>
>
> 
> --
> *From: *"Josh Luthman" 
> *To: *af@afmug.com
> *Sent: *Wednesday, October 26, 2016 9:49:38 AM
> *Subject: *Re: [AFMUG] Mikrotik DNS Cache
>
> I had issues with just myself...
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Oct 26, 2016 10:45 AM, "Dennis Burgess" 
> wrote:
>
>> Does it work, yes it is the same as a high performance DNS server, no.
>> Is a dedicated DNS resolvers expensive, no.  Getting starting say under
>> 100-150 users, ok, for a while, once you go over that, really need to move
>> to dedicated resolvers.
>>
>>
>> Dennis Burgess – Network Solution Engineer – Consultant
>> MikroTik Certified Trainer/Consultant – MTCNA, MTCRE, MTCWE, MTCTCE,
>> MTCINE
>>
>> For Wireless Hardware/Routers visit www.linktechs.net
>> Radio Frequiency Coverages: www.towercoverage.com
>> Office: 314-735-0270
>> E-Mail: dmburg...@linktechs.net
>>
>> -Original Message-
>> From: Af [mailto:af-boun...@afmug.com] On Behalf Of Matt
>> Sent: Wednesday, October 26, 2016 8:54 AM
>> To: af@afmug.com
>> Subject: [AFMUG] Mikrotik DNS Cache
>>
>> Is anyone using the Mikrotik DNS cache as there primary DNS resolver for
>> there clients?  Say use a CCR and your largest upstreams DNS server as
>> parent.  Should there be any issues with that?
>>
>
>


-- 
If you only see yourself as part of the team but you don't see your team as
part of yourself you have already failed as part of the team.

Re: [AFMUG] Mikrotik DNS Cache

[Josh Luthman]

Sad face

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Oct 27, 2016 10:20 AM, "That One Guy /sarcasm" 
wrote:

> [image: Inline image 1]
>
> On Thu, Oct 27, 2016 at 6:48 AM, Mike Hammett  wrote:
>
>> I think we've all had issues with you. :-p
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>>
>>
>> 
>> --
>> *From: *"Josh Luthman" 
>> *To: *af@afmug.com
>> *Sent: *Wednesday, October 26, 2016 9:49:38 AM
>> *Subject: *Re: [AFMUG] Mikrotik DNS Cache
>>
>> I had issues with just myself...
>>
>> Josh Luthman
>> Office: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>>
>> On Oct 26, 2016 10:45 AM, "Dennis Burgess" 
>> wrote:
>>
>>> Does it work, yes it is the same as a high performance DNS server, no.
>>> Is a dedicated DNS resolvers expensive, no.  Getting starting say under
>>> 100-150 users, ok, for a while, once you go over that, really need to move
>>> to dedicated resolvers.
>>>
>>>
>>> Dennis Burgess – Network Solution Engineer – Consultant
>>> MikroTik Certified Trainer/Consultant – MTCNA, MTCRE, MTCWE, MTCTCE,
>>> MTCINE
>>>
>>> For Wireless Hardware/Routers visit www.linktechs.net
>>> Radio Frequiency Coverages: www.towercoverage.com
>>> Office: 314-735-0270
>>> E-Mail: dmburg...@linktechs.net
>>>
>>> -Original Message-
>>> From: Af [mailto:af-boun...@afmug.com] On Behalf Of Matt
>>> Sent: Wednesday, October 26, 2016 8:54 AM
>>> To: af@afmug.com
>>> Subject: [AFMUG] Mikrotik DNS Cache
>>>
>>> Is anyone using the Mikrotik DNS cache as there primary DNS resolver for
>>> there clients?  Say use a CCR and your largest upstreams DNS server as
>>> parent.  Should there be any issues with that?
>>>
>>
>>
>
>
> --
> If you only see yourself as part of the team but you don't see your team
> as part of yourself you have already failed as part of the team.
>

Re: [AFMUG] Ubiquiti makes the big time...

[Josh Reynolds]

Well, I used to like DACs. Not so much anymore.

Some of it has to do with cable organization, and inventory is the other
angle.

Having transceivers and patches around is utilitarian. Having DACs around
is slightly cheaper, but those DACs are much harder to deal with from a
cable management perspective.

I don't hate DACs, I just dislike the tradeoffs.

On Oct 27, 2016 7:57 AM, "Mike Hammett"  wrote:

> Anything that doesn't support DACs is fucking worthless.
>
>
> I've ditched all ad-block, privacy, etc. extensions. They're garbage.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
>
>
> 
> --
> *From: *"Josh Reynolds" 
> *To: *af@afmug.com
> *Sent: *Thursday, October 27, 2016 7:50:21 AM
> *Subject: *Re: [AFMUG] Ubiquiti makes the big time...
>
> I complained about the DAC issue during the Alpha, as I just wanted to
> plug in the switch to a Juniper MX960 and throw some of the VM load on it.
> Sadly I ended up having to use short patch cables and fiberstore
> transceivers, which worked fine.
>
> I didn't experience the crashes the author did, although I "whitelist" all
> my hardware interfaces in my browser extensions... Maybe that was his/her
> issue, I don't know.
>
> Side note: the was about 6 months back
>
> On Oct 27, 2016 7:33 AM, "Mark Radabaugh"  wrote:
>
>> The good news:  kit gets reviewed on a major IT website.
>> The bad news: kit gets reviewed on a major IT website.
>>
>> http://www.theregister.co.uk/2016/10/27/ubiquiti_edgeswitch_review/
>>
>> Mark
>>
>
>

Re: [AFMUG] Ubiquiti makes the big time...

[Mike Hammett]

How is a DAC harder to manage? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Josh Reynolds"  
To: af@afmug.com 
Sent: Thursday, October 27, 2016 9:26:35 AM 
Subject: Re: [AFMUG] Ubiquiti makes the big time... 


Well, I used to like DACs. Not so much anymore. 
Some of it has to do with cable organization, and inventory is the other angle. 
Having transceivers and patches around is utilitarian. Having DACs around is 
slightly cheaper, but those DACs are much harder to deal with from a cable 
management perspective. 
I don't hate DACs, I just dislike the tradeoffs. 


On Oct 27, 2016 7:57 AM, "Mike Hammett" < af...@ics-il.net > wrote: 




Anything that doesn't support DACs is fucking worthless. 


I've ditched all ad-block, privacy, etc. extensions. They're garbage. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 






From: "Josh Reynolds" < j...@kyneticwifi.com > 
To: af@afmug.com 
Sent: Thursday, October 27, 2016 7:50:21 AM 
Subject: Re: [AFMUG] Ubiquiti makes the big time... 


I complained about the DAC issue during the Alpha, as I just wanted to plug in 
the switch to a Juniper MX960 and throw some of the VM load on it. Sadly I 
ended up having to use short patch cables and fiberstore transceivers, which 
worked fine. 
I didn't experience the crashes the author did, although I "whitelist" all my 
hardware interfaces in my browser extensions... Maybe that was his/her issue, I 
don't know. 
Side note: the was about 6 months back 


On Oct 27, 2016 7:33 AM, "Mark Radabaugh" < m...@amplex.net > wrote: 




The good news: kit gets reviewed on a major IT website. 
The bad news: kit gets reviewed on a major IT website. 


http://www.theregister.co.uk/2016/10/27/ubiquiti_edgeswitch_review/ 



Mark 

[AFMUG] Ammon City fiber

[Travis Johnson]

Hi,

This is a small "town" that is directly connected to my hometown of 
Idaho Falls. The road I drive to work on, the west side of that street 
is Idaho Falls, the east side is Ammon. We had a lot of wireless 
customers in the Ammon area when I was a WISP. They have been working on 
this fiber project for almost 10 years.


It's a very interesting way to do it. They have bundled the $3,000 
installation into a low interest "bond" kind of thing that is attached 
to the property... so that's about $15/month for 20 years. Then they 
have a small transport/utility fee for the fiber itself of $16.50/month.


The most amazing part is the user can switch between providers from a 
website, picking the speed and service that they want, and it changes 
their service immediately. It will be interesting to see how this goes. 
They are supposed to have their first residential customer live by the 
end of this year.


They are saying 100Mbps x 100Mbps service would be about $60-$70 per 
month total (with $0 installation cost).


http://arstechnica.com/information-technology/2016/06/what-if-switching-fiber-isps-was-as-easy-as-clicking-a-mouse/

Travis

Re: [AFMUG] Ubiquiti makes the big time...

[Josh Reynolds]

Cable management and sometimes airflow.They're much larger diameter than sm
or mm, require a larger bend radius than bend insensitive fiber, and you
can't exactly cut them to length. If you just have a few uplink DACs you
can make them work, but if you have a rack full of fiber strands and then
throw in a few dozen DACs, after awhile you're just like "this is
stupid..., brb grabbing some sfp+'s...".

On Oct 27, 2016 9:31 AM, "Mike Hammett"  wrote:

> How is a DAC harder to manage?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
>
>
> 
> --
> *From: *"Josh Reynolds" 
> *To: *af@afmug.com
> *Sent: *Thursday, October 27, 2016 9:26:35 AM
> *Subject: *Re: [AFMUG] Ubiquiti makes the big time...
>
> Well, I used to like DACs. Not so much anymore.
>
> Some of it has to do with cable organization, and inventory is the other
> angle.
>
> Having transceivers and patches around is utilitarian. Having DACs around
> is slightly cheaper, but those DACs are much harder to deal with from a
> cable management perspective.
>
> I don't hate DACs, I just dislike the tradeoffs.
>
> On Oct 27, 2016 7:57 AM, "Mike Hammett"  wrote:
>
>> Anything that doesn't support DACs is fucking worthless.
>>
>>
>> I've ditched all ad-block, privacy, etc. extensions. They're garbage.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>>
>>
>> 
>> --
>> *From: *"Josh Reynolds" 
>> *To: *af@afmug.com
>> *Sent: *Thursday, October 27, 2016 7:50:21 AM
>> *Subject: *Re: [AFMUG] Ubiquiti makes the big time...
>>
>> I complained about the DAC issue during the Alpha, as I just wanted to
>> plug in the switch to a Juniper MX960 and throw some of the VM load on it.
>> Sadly I ended up having to use short patch cables and fiberstore
>> transceivers, which worked fine.
>>
>> I didn't experience the crashes the author did, although I "whitelist"
>> all my hardware interfaces in my browser extensions... Maybe that was
>> his/her issue, I don't know.
>>
>> Side note: the was about 6 months back
>>
>> On Oct 27, 2016 7:33 AM, "Mark Radabaugh"  wrote:
>>
>>> The good news:  kit gets reviewed on a major IT website.
>>> The bad news: kit gets reviewed on a major IT website.
>>>
>>> http://www.theregister.co.uk/2016/10/27/ubiquiti_edgeswitch_review/
>>>
>>> Mark
>>>
>>
>>
>

Re: [AFMUG] Ammon City fiber

[Josh Luthman]

You drive to work?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Oct 27, 2016 10:35 AM, "Travis Johnson"  wrote:

> Hi,
>
> This is a small "town" that is directly connected to my hometown of Idaho
> Falls. The road I drive to work on, the west side of that street is Idaho
> Falls, the east side is Ammon. We had a lot of wireless customers in the
> Ammon area when I was a WISP. They have been working on this fiber project
> for almost 10 years.
>
> It's a very interesting way to do it. They have bundled the $3,000
> installation into a low interest "bond" kind of thing that is attached to
> the property... so that's about $15/month for 20 years. Then they have a
> small transport/utility fee for the fiber itself of $16.50/month.
>
> The most amazing part is the user can switch between providers from a
> website, picking the speed and service that they want, and it changes their
> service immediately. It will be interesting to see how this goes. They are
> supposed to have their first residential customer live by the end of this
> year.
>
> They are saying 100Mbps x 100Mbps service would be about $60-$70 per month
> total (with $0 installation cost).
>
> http://arstechnica.com/information-technology/2016/06/what-
> if-switching-fiber-isps-was-as-easy-as-clicking-a-mouse/
>
> Travis
>
>

Re: [AFMUG] Ubiquiti makes the big time...

[Josh Baird]

Yeah the ones that we generally use are thicker (there are ones that aren't
as thick) and can make running a ton of them through cable management sort
of crappy.

On Thu, Oct 27, 2016 at 10:35 AM, Josh Reynolds 
wrote:

> Cable management and sometimes airflow.They're much larger diameter than
> sm or mm, require a larger bend radius than bend insensitive fiber, and you
> can't exactly cut them to length. If you just have a few uplink DACs you
> can make them work, but if you have a rack full of fiber strands and then
> throw in a few dozen DACs, after awhile you're just like "this is
> stupid..., brb grabbing some sfp+'s...".
>
> On Oct 27, 2016 9:31 AM, "Mike Hammett"  wrote:
>
>> How is a DAC harder to manage?
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>>
>>
>> 
>> --
>> *From: *"Josh Reynolds" 
>> *To: *af@afmug.com
>> *Sent: *Thursday, October 27, 2016 9:26:35 AM
>> *Subject: *Re: [AFMUG] Ubiquiti makes the big time...
>>
>> Well, I used to like DACs. Not so much anymore.
>>
>> Some of it has to do with cable organization, and inventory is the other
>> angle.
>>
>> Having transceivers and patches around is utilitarian. Having DACs around
>> is slightly cheaper, but those DACs are much harder to deal with from a
>> cable management perspective.
>>
>> I don't hate DACs, I just dislike the tradeoffs.
>>
>> On Oct 27, 2016 7:57 AM, "Mike Hammett"  wrote:
>>
>>> Anything that doesn't support DACs is fucking worthless.
>>>
>>>
>>> I've ditched all ad-block, privacy, etc. extensions. They're garbage.
>>>
>>>
>>>
>>> -
>>> Mike Hammett
>>> Intelligent Computing Solutions 
>>> 
>>> 
>>> 
>>> 
>>> Midwest Internet Exchange 
>>> 
>>> 
>>> 
>>> The Brothers WISP 
>>> 
>>>
>>>
>>> 
>>> --
>>> *From: *"Josh Reynolds" 
>>> *To: *af@afmug.com
>>> *Sent: *Thursday, October 27, 2016 7:50:21 AM
>>> *Subject: *Re: [AFMUG] Ubiquiti makes the big time...
>>>
>>> I complained about the DAC issue during the Alpha, as I just wanted to
>>> plug in the switch to a Juniper MX960 and throw some of the VM load on it.
>>> Sadly I ended up having to use short patch cables and fiberstore
>>> transceivers, which worked fine.
>>>
>>> I didn't experience the crashes the author did, although I "whitelist"
>>> all my hardware interfaces in my browser extensions... Maybe that was
>>> his/her issue, I don't know.
>>>
>>> Side note: the was about 6 months back
>>>
>>> On Oct 27, 2016 7:33 AM, "Mark Radabaugh"  wrote:
>>>
 The good news:  kit gets reviewed on a major IT website.
 The bad news: kit gets reviewed on a major IT website.

 http://www.theregister.co.uk/2016/10/27/ubiquiti_edgeswitch_review/

 Mark

>>>
>>>
>>

Re: [AFMUG] Ammon City fiber

[Travis Johnson]

Yup... all 7 miles of it... takes me 10 minutes. :)

Travis


On 10/27/2016 8:37 AM, Josh Luthman wrote:


You drive to work?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Oct 27, 2016 10:35 AM, "Travis Johnson" > wrote:


Hi,

This is a small "town" that is directly connected to my hometown
of Idaho Falls. The road I drive to work on, the west side of that
street is Idaho Falls, the east side is Ammon. We had a lot of
wireless customers in the Ammon area when I was a WISP. They have
been working on this fiber project for almost 10 years.

It's a very interesting way to do it. They have bundled the $3,000
installation into a low interest "bond" kind of thing that is
attached to the property... so that's about $15/month for 20
years. Then they have a small transport/utility fee for the fiber
itself of $16.50/month.

The most amazing part is the user can switch between providers
from a website, picking the speed and service that they want, and
it changes their service immediately. It will be interesting to
see how this goes. They are supposed to have their first
residential customer live by the end of this year.

They are saying 100Mbps x 100Mbps service would be about $60-$70
per month total (with $0 installation cost).


http://arstechnica.com/information-technology/2016/06/what-if-switching-fiber-isps-was-as-easy-as-clicking-a-mouse/



Travis

[AFMUG] Tower Cameras

[Paul McCall]

We want to put a camera(s) at the top of a 400' tower.  Best way to get 360 
degree coverage?

Paul

Paul McCall, President
PDMNet, Inc. / Florida Broadband, Inc.
658 Old Dixie Highway
Vero Beach, FL 32962
772-564-6800
pa...@pdmnet.net
www.pdmnet.com
www.floridabroadband.com

Re: [AFMUG] Ammon City fiber

[Josh Luthman]

Horse n buggy?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Oct 27, 2016 10:52 AM, "Travis Johnson"  wrote:

> Yup... all 7 miles of it... takes me 10 minutes. :)
>
> Travis
>
>
> On 10/27/2016 8:37 AM, Josh Luthman wrote:
>
> You drive to work?
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Oct 27, 2016 10:35 AM, "Travis Johnson"  wrote:
>
>> Hi,
>>
>> This is a small "town" that is directly connected to my hometown of Idaho
>> Falls. The road I drive to work on, the west side of that street is Idaho
>> Falls, the east side is Ammon. We had a lot of wireless customers in the
>> Ammon area when I was a WISP. They have been working on this fiber project
>> for almost 10 years.
>>
>> It's a very interesting way to do it. They have bundled the $3,000
>> installation into a low interest "bond" kind of thing that is attached to
>> the property... so that's about $15/month for 20 years. Then they have a
>> small transport/utility fee for the fiber itself of $16.50/month.
>>
>> The most amazing part is the user can switch between providers from a
>> website, picking the speed and service that they want, and it changes their
>> service immediately. It will be interesting to see how this goes. They are
>> supposed to have their first residential customer live by the end of this
>> year.
>>
>> They are saying 100Mbps x 100Mbps service would be about $60-$70 per
>> month total (with $0 installation cost).
>>
>> http://arstechnica.com/information-technology/2016/06/what-i
>> f-switching-fiber-isps-was-as-easy-as-clicking-a-mouse/
>>
>> Travis
>>
>>
>

[AFMUG] Microsoft Store DNS

[Mike Hammett]

Do any of you know what DNS the Microsoft store users? I need to block access 
to the Microsoft store to prevent application updates. Blocking access to it 
through layer 7 inspection of DNS would seem to be the most effective.

-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
Brothers WISP

Re: [AFMUG] Microsoft Store DNS

[That One Guy /sarcasm]

It wont revert back to the local DNS?

On Thu, Oct 27, 2016 at 10:00 AM, Mike Hammett  wrote:

> Do any of you know what DNS the Microsoft store users? I need to block
> access to the Microsoft store to prevent application updates. Blocking
> access to it through layer 7 inspection of DNS would seem to be the most
> effective.
>
> -Mike HammettIntelligent Computing SolutionsMidwest Internet
> ExchangeThe Brothers WISP
>
>
>


-- 
If you only see yourself as part of the team but you don't see your team as
part of yourself you have already failed as part of the team.

Re: [AFMUG] Ammon City fiber

[Lewis Bergman]

We all expected you take a helicopter.

On Thu, Oct 27, 2016 at 9:53 AM Josh Luthman 
wrote:

> Horse n buggy?
>
> Josh Luthman
> Office: 937-552-2340 <(937)%20552-2340>
> Direct: 937-552-2343 <(937)%20552-2343>
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Oct 27, 2016 10:52 AM, "Travis Johnson"  wrote:
>
> Yup... all 7 miles of it... takes me 10 minutes. :)
>
> Travis
>
>
> On 10/27/2016 8:37 AM, Josh Luthman wrote:
>
> You drive to work?
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Oct 27, 2016 10:35 AM, "Travis Johnson"  wrote:
>
> Hi,
>
> This is a small "town" that is directly connected to my hometown of Idaho
> Falls. The road I drive to work on, the west side of that street is Idaho
> Falls, the east side is Ammon. We had a lot of wireless customers in the
> Ammon area when I was a WISP. They have been working on this fiber project
> for almost 10 years.
>
> It's a very interesting way to do it. They have bundled the $3,000
> installation into a low interest "bond" kind of thing that is attached to
> the property... so that's about $15/month for 20 years. Then they have a
> small transport/utility fee for the fiber itself of $16.50/month.
>
> The most amazing part is the user can switch between providers from a
> website, picking the speed and service that they want, and it changes their
> service immediately. It will be interesting to see how this goes. They are
> supposed to have their first residential customer live by the end of this
> year.
>
> They are saying 100Mbps x 100Mbps service would be about $60-$70 per month
> total (with $0 installation cost).
>
>
> http://arstechnica.com/information-technology/2016/06/what-if-switching-fiber-isps-was-as-easy-as-clicking-a-mouse/
>
> Travis
>
>
>

Re: [AFMUG] Microsoft Store DNS

[Mike Hammett]

I worded that poorly. I should have asked what FQDN it uses.

-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
Brothers WISP




- Original Message -
From: That One Guy /sarcasm 
To: af@afmug.com
Sent: Thu, 27 Oct 2016 10:03:58 -0500 (CDT)
Subject: Re: [AFMUG] Microsoft Store DNS

It wont revert back to the local DNS?

On Thu, Oct 27, 2016 at 10:00 AM, Mike Hammett  wrote:

> Do any of you know what DNS the Microsoft store users? I need to block
> access to the Microsoft store to prevent application updates. Blocking
> access to it through layer 7 inspection of DNS would seem to be the most
> effective.
>
> -Mike HammettIntelligent Computing SolutionsMidwest Internet
> ExchangeThe Brothers WISP
>
>
>


-- 
If you only see yourself as part of the team but you don't see your team as
part of yourself you have already failed as part of the team.

Re: [AFMUG] Tower Cameras

[Steve]

https://www.surveillance-video.com/180-360-cameras

Expensive!

- Original Message -
From: "Paul McCall" 
To: "af" 
Sent: Thursday, October 27, 2016 10:54:09 AM
Subject: [AFMUG] Tower Cameras

We want to put a camera(s) at the top of a 400' tower.  Best way to get 360 
degree coverage?

Paul

Paul McCall, President
PDMNet, Inc. / Florida Broadband, Inc.
658 Old Dixie Highway
Vero Beach, FL 32962
772-564-6800
pa...@pdmnet.net
www.pdmnet.com
www.floridabroadband.com

Re: [AFMUG] Tower Cameras

[Jaime Solorza]

What are trying to cover?  I know of cameras which can see miles...are you
trying to cover perimeter ?

On Oct 27, 2016 8:54 AM, "Paul McCall"  wrote:

> We want to put a camera(s) at the top of a 400’ tower.  Best way to get
> 360 degree coverage?
>
>
>
> Paul
>
>
>
> Paul McCall, President
>
> PDMNet, Inc. / Florida Broadband, Inc.
>
> 658 Old Dixie Highway
>
> Vero Beach, FL 32962
>
> 772-564-6800
>
> pa...@pdmnet.net
>
> www.pdmnet.com
>
> www.floridabroadband.com
>
>
>
>
>

Re: [AFMUG] Microsoft Store DNS

[Steve]

Also check out this  https://www.iblocklist.com/lists.php

Microsoft's known ranges here  
https://www.iblocklist.com/list?list=xshktygkujudfnjfioro



- Original Message -
From: "Mike Hammett" 
To: "af" 
Sent: Thursday, October 27, 2016 11:00:04 AM
Subject: [AFMUG] Microsoft Store DNS

Do any of you know what DNS the Microsoft store users? I need to block access 
to the Microsoft store to prevent application updates. Blocking access to it 
through layer 7 inspection of DNS would seem to be the most effective.

-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
Brothers WISP

Re: [AFMUG] Tower Cameras

[Paul McCall]

I am actually looking to see weather closing in on the horizon.  A general 
observation camera.  Would like to see all directions, but would settle for due 
West and due East so maybe the best option would be a couple fixed cameras with 
90 degrees?

We have zero real world experience with tower cameras. (and little knowledge 
with surveillance cameras either)

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Jaime Solorza
Sent: Thursday, October 27, 2016 11:12 AM
To: Animal Farm 
Subject: Re: [AFMUG] Tower Cameras


What are trying to cover?  I know of cameras which can see miles...are you 
trying to cover perimeter ?

On Oct 27, 2016 8:54 AM, "Paul McCall" 
mailto:pa...@pdmnet.net>> wrote:
We want to put a camera(s) at the top of a 400’ tower.  Best way to get 360 
degree coverage?

Paul

Paul McCall, President
PDMNet, Inc. / Florida Broadband, Inc.
658 Old Dixie Highway
Vero Beach, FL 32962
772-564-6800
pa...@pdmnet.net
www.pdmnet.com
www.floridabroadband.com

Re: [AFMUG] Ammon City fiber

[Ken Hohhof]

This is how DSL was originally envisioned to work, that's the main reason they 
used PPPoE, so you could authenticate and establish a session to whatever ISP 
you wanted.  GTE even had 2 billing methods, the transport could be billed by 
GTE on the customer's phone bill with the ISP billing for bandwidth, or the ISP 
could bill the customer for the total service and pay GTE for transport on a 
wholesale basis.  When Verizon bought GTE, they phased out the first method.  
At the beginning, I don't think GTE even planned to have their own in-house ISP 
competing with the other providers.

This all came from the dialup model, where customers could choose any ISP and 
have their modem call over the PSTN to the local access number for that ISP.

But the LECs especially the Baby Bells got it in their head that the grass was 
greener on the other side, that bandwidth and content providers were making all 
the money, and they vowed never again to be the "dumb pipe".  I think this 
explains a lot of LEC behavior to this day, like AT&T buying Time-Warner.

The funny thing is that DSL was originally developed for "Video On Demand" 
service to compete with the cable companies, which the telcos feared would 
start offering voice service.  The specs were for a 1.5M downstream channel to 
carry one MPEG2 DVD-quality video, plus a 16k bidirectional control channel.  
Later that was expanded to 6 Mbps to support up to 4 simultaneous videos, and 
later still the upstream channel was expanded to 640k because some people 
started thinking about a data network.  At first the LECs were slow to roll out 
the service despite successful technical and marketing trials, because they 
became convinced the cablecos were undercapitalized and were not as big a 
competitive threat as had been imagined.  By the time DSL was actually 
deployed, the focus had switched to Internet service, and the PPPoE protocol 
was developed and companies like Redback Networks were formed to support a 
model with multiple ISPs over the same physical network.


-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Travis Johnson
Sent: Thursday, October 27, 2016 9:35 AM
To: af@afmug.com
Subject: [AFMUG] Ammon City fiber

Hi,

This is a small "town" that is directly connected to my hometown of Idaho 
Falls. The road I drive to work on, the west side of that street is Idaho 
Falls, the east side is Ammon. We had a lot of wireless customers in the Ammon 
area when I was a WISP. They have been working on this fiber project for almost 
10 years.

It's a very interesting way to do it. They have bundled the $3,000 installation 
into a low interest "bond" kind of thing that is attached to the property... so 
that's about $15/month for 20 years. Then they have a small transport/utility 
fee for the fiber itself of $16.50/month.

The most amazing part is the user can switch between providers from a website, 
picking the speed and service that they want, and it changes their service 
immediately. It will be interesting to see how this goes. 
They are supposed to have their first residential customer live by the end of 
this year.

They are saying 100Mbps x 100Mbps service would be about $60-$70 per month 
total (with $0 installation cost).

http://arstechnica.com/information-technology/2016/06/what-if-switching-fiber-isps-was-as-easy-as-clicking-a-mouse/

Travis

Re: [AFMUG] Microsoft Store DNS

[That One Guy /sarcasm]

I would bet by design if you achieve what you are looking for youll have
that no internet icon in the corner all the time

On Thu, Oct 27, 2016 at 10:19 AM, Steve  wrote:

> Also check out this  https://www.iblocklist.com/lists.php
>
> Microsoft's known ranges here  https://www.iblocklist.com/
> list?list=xshktygkujudfnjfioro
>
>
>
> - Original Message -
> From: "Mike Hammett" 
> To: "af" 
> Sent: Thursday, October 27, 2016 11:00:04 AM
> Subject: [AFMUG] Microsoft Store DNS
>
> Do any of you know what DNS the Microsoft store users? I need to block
> access to the Microsoft store to prevent application updates. Blocking
> access to it through layer 7 inspection of DNS would seem to be the most
> effective.
>
> -Mike HammettIntelligent Computing SolutionsMidwest Internet
> ExchangeThe Brothers WISP
>



-- 
If you only see yourself as part of the team but you don't see your team as
part of yourself you have already failed as part of the team.

Re: [AFMUG] Microsoft Store DNS

[Josh Luthman]

Just allow that one host for that.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Oct 27, 2016 11:23 AM, "That One Guy /sarcasm" 
wrote:

> I would bet by design if you achieve what you are looking for youll have
> that no internet icon in the corner all the time
>
> On Thu, Oct 27, 2016 at 10:19 AM, Steve  wrote:
>
>> Also check out this  https://www.iblocklist.com/lists.php
>>
>> Microsoft's known ranges here  https://www.iblocklist.com/lis
>> t?list=xshktygkujudfnjfioro
>>
>>
>>
>> - Original Message -
>> From: "Mike Hammett" 
>> To: "af" 
>> Sent: Thursday, October 27, 2016 11:00:04 AM
>> Subject: [AFMUG] Microsoft Store DNS
>>
>> Do any of you know what DNS the Microsoft store users? I need to block
>> access to the Microsoft store to prevent application updates. Blocking
>> access to it through layer 7 inspection of DNS would seem to be the most
>> effective.
>>
>> -Mike HammettIntelligent Computing SolutionsMidwest Internet
>> ExchangeThe Brothers WISP
>>
>
>
>
> --
> If you only see yourself as part of the team but you don't see your team
> as part of yourself you have already failed as part of the team.
>

Re: [AFMUG] Microsoft Store DNS

[Steve]

Good luck with anything past Windows 7.  They've hard coded some of it into the 
kernel now. People have replaced entire host files with entire Microsoft 
domains and alt domains and it still manages to phone home, pull data etc.   

There is a way of clearing your system of telemetry though using the Tron 
script... check it out

https://www.reddit.com/r/TronScript/comments/55indl/tron_v960_20161002_aq_add_debug_log_upload_udl/

Read through that sub reddit and you'll find like minded people with other 
alternatives and recommendations as to how to proceed.  



- Original Message -
From: "Mike Hammett" 
To: "af" 
Sent: Thursday, October 27, 2016 11:00:04 AM
Subject: [AFMUG] Microsoft Store DNS

Do any of you know what DNS the Microsoft store users? I need to block access 
to the Microsoft store to prevent application updates. Blocking access to it 
through layer 7 inspection of DNS would seem to be the most effective.

-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
Brothers WISP

Re: [AFMUG] Microsoft Store DNS

[Ken Hohhof]

Define "Microsoft Store".  Do they have an app store like Google Play and 
iTunes?  I think of Microsoft Store as an online and bricks-and-mortar store 
that sells stuff like computers, I'm sure they sell software like Office 365 as 
well.  I am typing on a Dell laptop I bought at the Microsoft Store in Oakbrook 
Mall, pretty much a clone of an Apple Store.

If you mean where do Windows Updates come from, sometimes 
download.windowsupdate.com, sometimes not.


-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Mike Hammett
Sent: Thursday, October 27, 2016 10:06 AM
To: af@afmug.com
Subject: Re: [AFMUG] Microsoft Store DNS

I worded that poorly. I should have asked what FQDN it uses.

-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
Brothers WISP




- Original Message -
From: That One Guy /sarcasm 
To: af@afmug.com
Sent: Thu, 27 Oct 2016 10:03:58 -0500 (CDT)
Subject: Re: [AFMUG] Microsoft Store DNS

It wont revert back to the local DNS?

On Thu, Oct 27, 2016 at 10:00 AM, Mike Hammett  wrote:

> Do any of you know what DNS the Microsoft store users? I need to block 
> access to the Microsoft store to prevent application updates. Blocking 
> access to it through layer 7 inspection of DNS would seem to be the 
> most effective.
>
> -Mike HammettIntelligent Computing SolutionsMidwest Internet 
> ExchangeThe Brothers WISP
>
>
>


--
If you only see yourself as part of the team but you don't see your team as 
part of yourself you have already failed as part of the team.

Re: [AFMUG] Microsoft Store DNS

[Steve]

Because they are evil.  

- Original Message -
From: "Paul Stewart" 
To: "af" 
Sent: Thursday, October 27, 2016 11:26:26 AM
Subject: Re: [AFMUG] Microsoft Store DNS

Gotta ask… why would you want to block application updates?

Also, I don’t know specifically with “Microsoft Store” itself but Microsoft 
product updates are typically done via CDN’s depending your geographic location 
.. some via their own network but a lot of it done via Akamai for example


> On Oct 27, 2016, at 11:00 AM, Mike Hammett  wrote:
> 
> Do any of you know what DNS the Microsoft store users? I need to block access 
> to the Microsoft store to prevent application updates. Blocking access to it 
> through layer 7 inspection of DNS would seem to be the most effective.
> 
> -Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
> Brothers WISP
> 
>

Re: [AFMUG] Microsoft Store DNS

[Paul Stewart]

Gotta ask… why would you want to block application updates?

Also, I don’t know specifically with “Microsoft Store” itself but Microsoft 
product updates are typically done via CDN’s depending your geographic location 
.. some via their own network but a lot of it done via Akamai for example


> On Oct 27, 2016, at 11:00 AM, Mike Hammett  wrote:
> 
> Do any of you know what DNS the Microsoft store users? I need to block access 
> to the Microsoft store to prevent application updates. Blocking access to it 
> through layer 7 inspection of DNS would seem to be the most effective.
> 
> -Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
> Brothers WISP
> 
> 

Re: [AFMUG] Ubiquiti makes the big time...

[Paul Stewart]

Yup agree…. we have a couple of locations where there are many dozens of twinax 
cables used and same issue

> On Oct 27, 2016, at 10:35 AM, Josh Reynolds  wrote:
> 
> Cable management and sometimes airflow.They're much larger diameter than sm 
> or mm, require a larger bend radius than bend insensitive fiber, and you 
> can't exactly cut them to length. If you just have a few uplink DACs you can 
> make them work, but if you have a rack full of fiber strands and then throw 
> in a few dozen DACs, after awhile you're just like "this is stupid..., brb 
> grabbing some sfp+'s...".
> 
> 
> On Oct 27, 2016 9:31 AM, "Mike Hammett"  > wrote:
> How is a DAC harder to manage?
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions 
>   
>  
>  
> 
> Midwest Internet Exchange 
>   
>  
> 
> The Brothers WISP 
>  
> 
> 
>  
> From: "Josh Reynolds" mailto:j...@kyneticwifi.com>>
> To: af@afmug.com 
> Sent: Thursday, October 27, 2016 9:26:35 AM
> Subject: Re: [AFMUG] Ubiquiti makes the big time...
> 
> Well, I used to like DACs. Not so much anymore.
> 
> Some of it has to do with cable organization, and inventory is the other 
> angle.
> 
> Having transceivers and patches around is utilitarian. Having DACs around is 
> slightly cheaper, but those DACs are much harder to deal with from a cable 
> management perspective.
> 
> I don't hate DACs, I just dislike the tradeoffs.
> 
> 
> On Oct 27, 2016 7:57 AM, "Mike Hammett"  > wrote:
> Anything that doesn't support DACs is fucking worthless.
> 
> 
> I've ditched all ad-block, privacy, etc. extensions. They're garbage.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions 
>   
>  
>  
> 
> Midwest Internet Exchange 
>   
>  
> 
> The Brothers WISP 
>  
> 
> 
>  
> From: "Josh Reynolds" mailto:j...@kyneticwifi.com>>
> To: af@afmug.com 
> Sent: Thursday, October 27, 2016 7:50:21 AM
> Subject: Re: [AFMUG] Ubiquiti makes the big time...
> 
> I complained about the DAC issue during the Alpha, as I just wanted to plug 
> in the switch to a Juniper MX960 and throw some of the VM load on it. Sadly I 
> ended up having to use short patch cables and fiberstore transceivers, which 
> worked fine.
> 
> I didn't experience the crashes the author did, although I "whitelist" all my 
> hardware interfaces in my browser extensions... Maybe that was his/her issue, 
> I don't know.
> 
> Side note: the was about 6 months back
> 
> 
> On Oct 27, 2016 7:33 AM, "Mark Radabaugh"  > wrote:
> The good news:  kit gets reviewed on a major IT website.
> The bad news: kit gets reviewed on a major IT website.
> 
> http://www.theregister.co.uk/2016/10/27/ubiquiti_edgeswitch_review/ 
> 
> Mark
> 
> 

Re: [AFMUG] Tower Cameras

[Ken Hohhof]

Are you looking for a PTZ camera, or some sort of fisheye that covers the 
entire 360 degrees?  And will it be pointed at the ground beneath the tower, or 
the horizon?  AT 400 feet, everything may look like ants.

At this point I'd be scared of anything from China, which means an expensive 
camera from Europe like Axis or Mobotix.  For around $2000 you should be able 
to get an IP67 PTZ camera.


-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Steve
Sent: Thursday, October 27, 2016 10:11 AM
To: af 
Subject: Re: [AFMUG] Tower Cameras

https://www.surveillance-video.com/180-360-cameras

Expensive!

- Original Message -
From: "Paul McCall" 
To: "af" 
Sent: Thursday, October 27, 2016 10:54:09 AM
Subject: [AFMUG] Tower Cameras

We want to put a camera(s) at the top of a 400' tower.  Best way to get 360 
degree coverage?

Paul

Paul McCall, President
PDMNet, Inc. / Florida Broadband, Inc.
658 Old Dixie Highway
Vero Beach, FL 32962
772-564-6800
pa...@pdmnet.net
www.pdmnet.com
www.floridabroadband.com

Re: [AFMUG] Microsoft Store DNS

[That One Guy /sarcasm]

Can you control it through WSUS? We are just now having domain clients
moving to w10, If I had my druthers we would remove the toy store from the
OS completely but I believe its intertwined with windows update now. As I
understand it if office 2016 isnt updated (via the store if youre using the
app) it will no longer make use of the onedrive benefits. In our case that
would kill us regarding the use of OneNote

On Thu, Oct 27, 2016 at 10:27 AM, Steve  wrote:

> Because they are evil.
>
> - Original Message -
> From: "Paul Stewart" 
> To: "af" 
> Sent: Thursday, October 27, 2016 11:26:26 AM
> Subject: Re: [AFMUG] Microsoft Store DNS
>
> Gotta ask… why would you want to block application updates?
>
> Also, I don’t know specifically with “Microsoft Store” itself but
> Microsoft product updates are typically done via CDN’s depending your
> geographic location .. some via their own network but a lot of it done via
> Akamai for example
>
>
> > On Oct 27, 2016, at 11:00 AM, Mike Hammett  wrote:
> >
> > Do any of you know what DNS the Microsoft store users? I need to block
> access to the Microsoft store to prevent application updates. Blocking
> access to it through layer 7 inspection of DNS would seem to be the most
> effective.
> >
> > -Mike HammettIntelligent Computing SolutionsMidwest Internet
> ExchangeThe Brothers WISP
> >
> >
>



-- 
If you only see yourself as part of the team but you don't see your team as
part of yourself you have already failed as part of the team.

Re: [AFMUG] Tower Cameras

[Jaime Solorza]

Well it depends on lens more than anything else... 400 ft.  Pointing down
at people or cars is very different from looking towards horizon looking
for storms.  A standard Hikvision TurboHD Bullet would work well for that
and they are Day/Night.Get a couple and NVR with decent hard drive.
Get some outdoor housing with or without heaters and decent mounts.   They
have PTZ versions if you want to pay more.   The regular ones have digital
zoom if you don't need PTZ.You'd been under 500/600 dollars I will
send a picture from one I had installed by airport..

On Oct 27, 2016 9:20 AM, "Paul McCall"  wrote:

> I am actually looking to see weather closing in on the horizon.  A general
> observation camera.  Would like to see all directions, but would settle for
> due West and due East so maybe the best option would be a couple fixed
> cameras with 90 degrees?
>
>
>
> We have zero real world experience with tower cameras. (and little
> knowledge with surveillance cameras either)
>
>
>
> *From:* Af [mailto:af-boun...@afmug.com] *On Behalf Of *Jaime Solorza
> *Sent:* Thursday, October 27, 2016 11:12 AM
> *To:* Animal Farm 
> *Subject:* Re: [AFMUG] Tower Cameras
>
>
>
> What are trying to cover?  I know of cameras which can see miles...are you
> trying to cover perimeter ?
>
>
>
> On Oct 27, 2016 8:54 AM, "Paul McCall"  wrote:
>
> We want to put a camera(s) at the top of a 400’ tower.  Best way to get
> 360 degree coverage?
>
>
>
> Paul
>
>
>
> Paul McCall, President
>
> PDMNet, Inc. / Florida Broadband, Inc.
>
> 658 Old Dixie Highway
>
> Vero Beach, FL 32962
>
> 772-564-6800
>
> pa...@pdmnet.net
>
> www.pdmnet.com
>
> www.floridabroadband.com
>
>
>
>
>
>

Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

[Chuck McCown]

Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc.  
We all need this or will need this.  

From: Faisal Imtiaz 
Sent: Wednesday, October 26, 2016 8:31 PM
To: af 
Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

An excellent detailed solution  (from one of the other forums).

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net




  From: "Tim Way" 
  To: "WISPA General List" 
  Sent: Tuesday, October 25, 2016 9:01:51 PM
  Subject: Re: [WISPA] IPV6 deploymernt

  Art,

  So I know of two solid methods that could solve your problem. Neither are 
super awesome and both would involve NAT.

  1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only 
connectivity
  2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, and IPv6 Global 
Unicast running in Dual Stack

  Either one would work. I apologize in advance for the long post that follows.

  I've only done the configurations on Cisco routers with the radios just 
passing traffic at layer 2. I'd have to check the feature set of your routers 
routing wise but it shouldn't be hard. It also could be built in a lab with 
static routing largely. I think Mikrotik supports NAT64 but again for a lab 
environment any recent Cisco device could be used with IP Services licensing.

  Your address plan for your global unicast IPv6 space comes into play. This is 
how I would lab it up including moving routing to the tower with the CPE in 
bridge mode:

  Your fictional IPv6 prefix: :::/32

  Your NAT64 Prefix: ::cc00::/96

  Customer DHCPv6-PD Allocation Prefix: ::aa00::/40

  Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
  Your fictional customer #2: The Billings' Family, ::aa00:0200::/56

  Fictional Tower 1
  ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
  ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
  ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
  ISP Router at the tower on VLAN 12: ::bb00:0012::1/64


  The Johnson Family Setup:
  ISP CPE VLAN 11 IP: ::bb00:0011::f/64
  Customer's Netgear WAN Interface: ::bb00:0012::f/64
  Customer's Netgear LAN Interface: ::aa00:010a::1/64
  Customer's Netgear Guest WiFi: ::aa00:010b::1/64

  The Billings' Family Setup:

  ISP CPE VLAN 11 IP: ::bb00:0011::e/64
  Customer's Netgear WAN Interface: ::bb00:0012::e/64
  Customer's Netgear LAN Interface: ::aa00:020a::1/64
  Customer's Netgear Guest WiFi: ::aa00:020b::1/64

  1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the 
native VLAN and put the IP on VLAN 11.
  2. If you use static routing and manual address assignment to eliminate 
variables in the lab you'll want to add static routes on the tower router for 
the ::/56 prefixes that would be allocated to each customer. Normally these 
routes will be injected into the routing table at the DHCPv6 router and could 
be distributed from there.
  3. The last piece of the puzzle will be adding in the NAT64 and DNS64 
devices. BIND can do DNS64 and you could use a Cisco router to do the NAT64. 
You'd want the "Customer's Netgear" to use the DNS64 server as it's upstream 
DNS server to ensure that it receives  records for sites that only have A 
records. This is the fragile component of the DNS64 and NAT64 deployment 
because it requires the customers computer or router uses your resolver. You 
will want to ensure the router performing NAT64 is advertising the prefix it is 
using for NAT64 into your IGP or that your default routed traffic lands on that 
NAT64 to ensure it is routed correctly.

  This should get you a functional IPv6 only customer network that only returns 
 records for all DNS requests. It's a little late so I apologize for any 
mistakes in the addressing. Also I will think about doing this with routing at 
the CPE as well overnight and add that response. I'd be very intrigued to see 
this in a lab environment with the fictional customers all setup to see how 
NAT64 and DNS64 actually works in reality instead of just implementing CGN 
which I see as the less visible or resilient change for the customer. That said 
I see the pure IPv6 deployment with NAT64 and DNS64 as the better long term 
solution if you could reliably ensure your customers use your DHCP server or 
ensure that your tech support says to reset that right away. It also would 
break a customer using OpenDNS to restrict web-sites from their kid's for 
example.

  Thanks,

  Tim

  On Tue, Oct 25, 2016 at 4:42 PM, Art Stephens  wrote:

Tim,

So we are an IPV4 ISP not able to get any more IPV4 address space. We have 
IPV6 working in office, and on server network.  
I have working windows and linux IPV6 on

Re: [AFMUG] Google Fiber is no more

[Chuck McCown]

I predict the PhD syndrome is going to also affect the wireless end.  Vivant 
tried and failed.


30 somethings that slept through physics are going to run up against the 
hard limits of trees, hills and rain.


Doesn't matter how crazy the radio is, they will learn as everyone that 
tries RF distribution learns.


5 years they will be back to fiber.  Or deciding not to be part of the 
transport solution.


-Original Message- 
From: Robert

Sent: Thursday, October 27, 2016 7:49 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Phd syndrome...  Getting an advanced degree at a big Uni gives you
almost zero experience in the trenches...   The move to wireless means
that they can buy their way into the FCC and move down from there...

On 10/27/16 6:40 AM, Brian Webster wrote:

I worked directly on the San Jose and Sand Diego projects. I was brought
in by one of the main contractors to help reduce costs and increase
efficiency. Google had way too many �30 somethings� who failed to 
listen

to experienced telecom professionals. That was one of their biggest
faults. It was insane to try and build a network in San Jose that was
going to have to be built mostly underground. That market already had
new AT&T U-verse fiber and Time Warner with a very strong network. Heck
I could get 100 meg speeds on Wi-Fi at the hotel I stayed in. Their Ego
to build in their own backyard was pushing the build more than anything.



The concept of cherry picking neighborhoods actually drove costs up.
When they wanted a citywide network design, that is what they were
delivered, but then try and build out only neighborhoods they wanted
while still trying to figure out how much of their backbones, huts and
neighborhood distribution system needed to be put in place to service
the piecemeal buildout approach, when you were already having to open
ditches, while having to be a mostly underground build? Yea that was a
nightmare too! Then let�s talk about how they had no clue how hard the
MDU market is to secure. They gave no real consideration to existing
deals in the buildings, or the cost of having to wire on their own
because the building owner did not actually own the existing cable plant
and such. These projects were not just a simple math problem to solve.



They naively thought every city was going to welcome them with open arms
like Kansas City did. They believed the political hype the politicians
told them to lure them to their cities, then when actual laws both of
physics and real came in to play, the numbers looked a whole lot uglier.
Underground building in established cities is a nightmare in both costs,
regulations, logistics and amount of work required. Just simple things
like trying to gather data on all the existing underground
infrastructure (that has no central source of documentation) was painful
and costly. You can�t get drawings approved without first showing you
will not be interfering with existing utilities already underground. In
many cases you have to manually locate this stuff and then map it and
then do your design around that information. Other issues to overhead
builds were poles that would not pass loading calculations, pole owners
who were less than cooperative or that pulled out new loading rules that
they themselves don�t follow and you can see where it was not a simple
process. The employee count to deal with all of this on a large scale at
the pace they wanted to move was not small by any stretch.



This was not new news. They pulled the plug on all of this stuff back at
the beginning of July.



Thank You,

Brian Webster

www.wirelessmapping.com 

www.Broadband-Mapping.com



*From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Mike Hammett
*Sent:* Thursday, October 27, 2016 7:32 AM
*To:* af@afmug.com
*Subject:* Re: [AFMUG] Google Fiber is no more



As they should. Don't build where people who can't pay or don't want
your service.



-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 







*From: *"Rory Conaway" mailto:r...@triadwireless.net>>
*To: *af@afmug.com 
*Sent: *Wednesday, October 26, 2016 11:28:52 PM
*Subject: *Re: [AFMUG] Google Fiber is no more

In other cities, they cherry picked.



Rory



*From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Sterling Jacobson
*Sent:* Wednesday, October 26, 2

Re: [AFMUG] Ammon City fiber

[Chuck McCown]

Utopia tried that method in Brigham City and it didn't work so well (for a 
variety of reasons).


-Original Message- 
From: Travis Johnson

Sent: Thursday, October 27, 2016 8:35 AM
To: af@afmug.com
Subject: [AFMUG] Ammon City fiber

Hi,

This is a small "town" that is directly connected to my hometown of
Idaho Falls. The road I drive to work on, the west side of that street
is Idaho Falls, the east side is Ammon. We had a lot of wireless
customers in the Ammon area when I was a WISP. They have been working on
this fiber project for almost 10 years.

It's a very interesting way to do it. They have bundled the $3,000
installation into a low interest "bond" kind of thing that is attached
to the property... so that's about $15/month for 20 years. Then they
have a small transport/utility fee for the fiber itself of $16.50/month.

The most amazing part is the user can switch between providers from a
website, picking the speed and service that they want, and it changes
their service immediately. It will be interesting to see how this goes.
They are supposed to have their first residential customer live by the
end of this year.

They are saying 100Mbps x 100Mbps service would be about $60-$70 per
month total (with $0 installation cost).

http://arstechnica.com/information-technology/2016/06/what-if-switching-fiber-isps-was-as-easy-as-clicking-a-mouse/

Travis

Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

[Jason Wilson]

When Said consultant is ready, email me off list.


Jason Wilson
Remotely Located
Providing High Speed Internet to out of the way places.
530-651-1736
530-748-9608 Cell
www.remotelylocated.com

On Thu, Oct 27, 2016 at 8:59 AM, Chuck McCown  wrote:

> Some consultant needs to specialize in this and help folks provision,
> configure, deploy, test etc.
> We all need this or will need this.
>
> *From:* Faisal Imtiaz
> *Sent:* Wednesday, October 26, 2016 8:31 PM
> *To:* af
> *Subject:* [AFMUG] Fwd: [WISPA] IPV6 deploymernt
>
> An excellent detailed solution  (from one of the other forums).
>
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
>
> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>
> --
>
> *From: *"Tim Way" 
> *To: *"WISPA General List" 
> *Sent: *Tuesday, October 25, 2016 9:01:51 PM
> *Subject: *Re: [WISPA] IPV6 deploymernt
>
> Art,
> So I know of two solid methods that could solve your problem. Neither are
> super awesome and both would involve NAT.
>
> 1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only
> connectivity
> 2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, and IPv6 Global
> Unicast running in Dual Stack
>
> Either one would work. I apologize in advance for the long post that
> follows.
>
> I've only done the configurations on Cisco routers with the radios just
> passing traffic at layer 2. I'd have to check the feature set of your
> routers routing wise but it shouldn't be hard. It also could be built in a
> lab with static routing largely. I think Mikrotik supports NAT64 but again
> for a lab environment any recent Cisco device could be used with IP
> Services licensing.
>
> Your address plan for your global unicast IPv6 space comes into play. This
> is how I would lab it up including moving routing to the tower with the CPE
> in bridge mode:
>
> Your fictional IPv6 prefix: :::/32
>
> Your NAT64 Prefix: ::cc00::/96
>
> Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
> Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
> Your fictional customer #2: The Billings' Family, ::aa00:0200::/56
>
> Fictional Tower 1
> ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
> ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
> ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
> ISP Router at the tower on VLAN 12: ::bb00:0012::1/64
>
> The Johnson Family Setup:
> ISP CPE VLAN 11 IP: ::bb00:0011::f/64
> Customer's Netgear WAN Interface: ::bb00:0012::f/64
> Customer's Netgear LAN Interface: ::aa00:010a::1/64
> Customer's Netgear Guest WiFi: ::aa00:010b::1/64
>
> The Billings' Family Setup:
> ISP CPE VLAN 11 IP: ::bb00:0011::e/64
> Customer's Netgear WAN Interface: ::bb00:0012::e/64
> Customer's Netgear LAN Interface: ::aa00:020a::1/64
> Customer's Netgear Guest WiFi: ::aa00:020b::1/64
>
> 1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the
> native VLAN and put the IP on VLAN 11.
> 2. If you use static routing and manual address assignment to eliminate
> variables in the lab you'll want to add static routes on the tower router
> for the ::/56 prefixes that would be allocated to each customer. Normally
> these routes will be injected into the routing table at the DHCPv6 router
> and could be distributed from there.
> 3. The last piece of the puzzle will be adding in the NAT64 and DNS64
> devices. BIND can do DNS64 and you could use a Cisco router to do the
> NAT64. You'd want the "Customer's Netgear" to use the DNS64 server as it's
> upstream DNS server to ensure that it receives  records for sites that
> only have A records. This is the fragile component of the DNS64 and NAT64
> deployment because it requires the customers computer or router uses your
> resolver. You will want to ensure the router performing NAT64 is
> advertising the prefix it is using for NAT64 into your IGP or that your
> default routed traffic lands on that NAT64 to ensure it is routed correctly.
>
> This should get you a functional IPv6 only customer network that only
> returns  records for all DNS requests. It's a little late so I
> apologize for any mistakes in the addressing. Also I will think about doing
> this with routing at the CPE as well overnight and add that response. I'd
> be very intrigued to see this in a lab environment with the fictional
> customers all setup to see how NAT64 and DNS64 actually works in reality
> instead of just implementing CGN which I see as the less visible or
> resilient change for the customer. That said I see the pure IPv6 deployment
> with NAT64 and DNS64 as the better long term solution if you could reliably
> ensure your customers use your DHCP server or ensure that your tech support
> says to reset that right away. It also would break a customer using OpenDNS
> to restrict web-sites 

Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

[Chris Wright]

Would be nice. I can’t even get a straight answer from AT&T what the smallest 
public ipv6 prefix I can send them via BGP is. I’m hearing /32 from one guy and 
/48 from the next.

This is reminiscent of my moment of enlightenment when I realized the best kept 
secret of adulthood is that we’re all just taller children and most of us are 
assumptively credited intelligence simply because we survived puberty.

Chris Wright
Network Administrator

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
Sent: Thursday, October 27, 2016 9:00 AM
To: af@afmug.com
Subject: Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc.
We all need this or will need this.

From: Faisal Imtiaz
Sent: Wednesday, October 26, 2016 8:31 PM
To: af
Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

An excellent detailed solution  (from one of the other forums).

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: 
supp...@snappytelecom.net


From: "Tim Way" mailto:t...@way.vg>>
To: "WISPA General List" mailto:wirel...@wispa.org>>
Sent: Tuesday, October 25, 2016 9:01:51 PM
Subject: Re: [WISPA] IPV6 deploymernt
Art,
So I know of two solid methods that could solve your problem. Neither are super 
awesome and both would involve NAT.

1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only connectivity
2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, 
and IPv6 Global Unicast running in Dual Stack

Either one would work. I apologize in advance for the long post that follows.

I've only done the configurations on Cisco routers with the radios just passing 
traffic at layer 2. I'd have to check the feature set of your routers routing 
wise but it shouldn't be hard. It also could be built in a lab with static 
routing largely. I think Mikrotik supports NAT64 but again for a lab 
environment any recent Cisco device could be used with IP Services licensing.

Your address plan for your global unicast IPv6 space comes into play. This is 
how I would lab it up including moving routing to the tower with the CPE in 
bridge mode:

Your fictional IPv6 prefix: :::/32

Your NAT64 Prefix: ::cc00::/96

Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
Your fictional customer #2: The Billings' Family, ::aa00:0200::/56

Fictional Tower 1
ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
ISP Router at the tower on VLAN 12: ::bb00:0012::1/64

The Johnson Family Setup:
ISP CPE VLAN 11 IP: ::bb00:0011::f/64
Customer's Netgear WAN Interface: ::bb00:0012::f/64
Customer's Netgear LAN Interface: ::aa00:010a::1/64
Customer's Netgear Guest WiFi: ::aa00:010b::1/64

The Billings' Family Setup:
ISP CPE VLAN 11 IP: ::bb00:0011::e/64
Customer's Netgear WAN Interface: ::bb00:0012::e/64
Customer's Netgear LAN Interface: ::aa00:020a::1/64
Customer's Netgear Guest WiFi: ::aa00:020b::1/64

1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the 
native VLAN and put the IP on VLAN 11.
2. If you use static routing and manual address assignment to eliminate 
variables in the lab you'll want to add static routes on the tower router for 
the ::/56 prefixes that would be allocated to each customer. Normally these 
routes will be injected into the routing table at the DHCPv6 router and could 
be distributed from there.
3. The last piece of the puzzle will be adding in the NAT64 and DNS64 devices. 
BIND can do DNS64 and you could use a Cisco router to do the NAT64. You'd want 
the "Customer's Netgear" to use the DNS64 server as it's upstream DNS server to 
ensure that it receives  records for sites that only have A records. This 
is the fragile component of the DNS64 and NAT64 deployment because it requires 
the customers computer or router uses your resolver. You will want to ensure 
the router performing NAT64 is advertising the prefix it is using for NAT64 
into your IGP or that your default routed traffic lands on that NAT64 to ensure 
it is routed correctly.

This should get you a functional IPv6 only customer network that only returns 
 records for all DNS requests. It's a little late so I apologize for any 
mistakes in the addressing. Also I will think about doing this with routing at 
the CPE as well overnight and add that response. I'd be very intrigued to see 
this in a lab environment with the fictional customers all setup to see how 
NAT64 and DNS64 actually works in reality instead of just implementing CGN 
which I see as the less visible or resilient change for the 

Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

[Cassidy B. Larson]

Normally it’s up to and including a /48 that most providers will accept.


> On Oct 27, 2016, at 10:20 AM, Chris Wright  wrote:
> 
> Would be nice. I can’t even get a straight answer from AT&T what the smallest 
> public ipv6 prefix I can send them via BGP is. I’m hearing /32 from one guy 
> and /48 from the next.
>  
> This is reminiscent of my moment of enlightenment when I realized the best 
> kept secret of adulthood is that we’re all just taller children and most of 
> us are assumptively credited intelligence simply because we survived puberty.
>  
> Chris Wright
> Network Administrator
>  
> From: Af [mailto:af-boun...@afmug.com ] On 
> Behalf Of Chuck McCown
> Sent: Thursday, October 27, 2016 9:00 AM
> To: af@afmug.com 
> Subject: Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt
>  
> Some consultant needs to specialize in this and help folks provision, 
> configure, deploy, test etc. 
> We all need this or will need this. 
>  
> From: Faisal Imtiaz
> Sent: Wednesday, October 26, 2016 8:31 PM
> To: af
> Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt
>  
> An excellent detailed solution  (from one of the other forums).
>  
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
> 
> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net 
> 
>  
> From: "Tim Way" mailto:t...@way.vg>>
> To: "WISPA General List" mailto:wirel...@wispa.org>>
> Sent: Tuesday, October 25, 2016 9:01:51 PM
> Subject: Re: [WISPA] IPV6 deploymernt
> Art,
> So I know of two solid methods that could solve your problem. Neither are 
> super awesome and both would involve NAT.
>  
> 1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only 
> connectivity
> 2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10 
> , and IPv6 Global Unicast running in Dual Stack
>  
> Either one would work. I apologize in advance for the long post that follows.
>  
> I've only done the configurations on Cisco routers with the radios just 
> passing traffic at layer 2. I'd have to check the feature set of your routers 
> routing wise but it shouldn't be hard. It also could be built in a lab with 
> static routing largely. I think Mikrotik supports NAT64 but again for a lab 
> environment any recent Cisco device could be used with IP Services licensing.
>  
> Your address plan for your global unicast IPv6 space comes into play. This is 
> how I would lab it up including moving routing to the tower with the CPE in 
> bridge mode:
>  
> Your fictional IPv6 prefix: :::/32
>  
> Your NAT64 Prefix: ::cc00::/96
>  
> Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
> Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
> Your fictional customer #2: The Billings' Family, ::aa00:0200::/56
>  
> Fictional Tower 1
> ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
> ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
> ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
> ISP Router at the tower on VLAN 12: ::bb00:0012::1/64
>  
> The Johnson Family Setup:
> ISP CPE VLAN 11 IP: ::bb00:0011::f/64
> Customer's Netgear WAN Interface: ::bb00:0012::f/64
> Customer's Netgear LAN Interface: ::aa00:010a::1/64
> Customer's Netgear Guest WiFi: ::aa00:010b::1/64
>  
> The Billings' Family Setup:
> ISP CPE VLAN 11 IP: ::bb00:0011::e/64
> Customer's Netgear WAN Interface: ::bb00:0012::e/64
> Customer's Netgear LAN Interface: ::aa00:020a::1/64
> Customer's Netgear Guest WiFi: ::aa00:020b::1/64
>  
> 1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the 
> native VLAN and put the IP on VLAN 11.
> 2. If you use static routing and manual address assignment to eliminate 
> variables in the lab you'll want to add static routes on the tower router for 
> the ::/56 prefixes that would be allocated to each customer. Normally these 
> routes will be injected into the routing table at the DHCPv6 router and could 
> be distributed from there.
> 3. The last piece of the puzzle will be adding in the NAT64 and DNS64 
> devices. BIND can do DNS64 and you could use a Cisco router to do the NAT64. 
> You'd want the "Customer's Netgear" to use the DNS64 server as it's upstream 
> DNS server to ensure that it receives  records for sites that only have A 
> records. This is the fragile component of the DNS64 and NAT64 deployment 
> because it requires the customers computer or router uses your resolver. You 
> will want to ensure the router performing NAT64 is advertising the prefix it 
> is using for NAT64 into your IGP or that your default routed traffic lands on 
> that NAT64 to ensure it is routed correctly.
> 
> This should get you a functional IPv6 only customer network that only returns 
>  records for all DNS requests. It's a little late so I ap

[AFMUG] Netonix DIN-8-10-12

[Sovereen, David A]

Vendors, do any of you have this in stock?  Just need 1 ASAP.

Please contact me off-list.

Thanks,

Dave

Re: [AFMUG] Google Fiber is no more

[Ken Hohhof]

Microwave to MTU/MDU rooftop.  Proven business model.  Ask Teligent,
Winstar, Nextlink.  In fairness, now almost 20 years later, there is more
demand for what they are selling.  But also more competition.

And it's not like nobody is doing this already.  Like in Chicago SilverIP
comes to mind.


-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
Sent: Thursday, October 27, 2016 11:05 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

I predict the PhD syndrome is going to also affect the wireless end.  Vivant
tried and failed.

30 somethings that slept through physics are going to run up against the
hard limits of trees, hills and rain.

Doesn't matter how crazy the radio is, they will learn as everyone that
tries RF distribution learns.

5 years they will be back to fiber.  Or deciding not to be part of the
transport solution.

-Original Message-
From: Robert
Sent: Thursday, October 27, 2016 7:49 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Phd syndrome...  Getting an advanced degree at a big Uni gives you
almost zero experience in the trenches...   The move to wireless means
that they can buy their way into the FCC and move down from there...

On 10/27/16 6:40 AM, Brian Webster wrote:
> I worked directly on the San Jose and Sand Diego projects. I was 
> brought in by one of the main contractors to help reduce costs and 
> increase efficiency. Google had way too many �30 somethings� who 
> failed to listen to experienced telecom professionals. That was one of 
> their biggest faults. It was insane to try and build a network in San 
> Jose that was going to have to be built mostly underground. That 
> market already had new AT&T U-verse fiber and Time Warner with a very 
> strong network. Heck I could get 100 meg speeds on Wi-Fi at the hotel 
> I stayed in. Their Ego to build in their own backyard was pushing the 
> build more than anything.
>
>
>
> The concept of cherry picking neighborhoods actually drove costs up.
> When they wanted a citywide network design, that is what they were 
> delivered, but then try and build out only neighborhoods they wanted 
> while still trying to figure out how much of their backbones, huts and 
> neighborhood distribution system needed to be put in place to service 
> the piecemeal buildout approach, when you were already having to open 
> ditches, while having to be a mostly underground build? Yea that was a 
> nightmare too! Then let�s talk about how they had no clue how hard 
> the MDU market is to secure. They gave no real consideration to 
> existing deals in the buildings, or the cost of having to wire on 
> their own because the building owner did not actually own the existing 
> cable plant and such. These projects were not just a simple math problem
to solve.
>
>
>
> They naively thought every city was going to welcome them with open 
> arms like Kansas City did. They believed the political hype the 
> politicians told them to lure them to their cities, then when actual 
> laws both of physics and real came in to play, the numbers looked a whole
lot uglier.
> Underground building in established cities is a nightmare in both 
> costs, regulations, logistics and amount of work required. Just simple 
> things like trying to gather data on all the existing underground 
> infrastructure (that has no central source of documentation) was 
> painful and costly. You can�t get drawings approved without first 
> showing you will not be interfering with existing utilities already 
> underground. In many cases you have to manually locate this stuff and 
> then map it and then do your design around that information. Other 
> issues to overhead builds were poles that would not pass loading 
> calculations, pole owners who were less than cooperative or that 
> pulled out new loading rules that they themselves don�t follow and 
> you can see where it was not a simple process. The employee count to 
> deal with all of this on a large scale at the pace they wanted to move was
not small by any stretch.
>
>
>
> This was not new news. They pulled the plug on all of this stuff back 
> at the beginning of July.
>
>
>
> Thank You,
>
> Brian Webster
>
> www.wirelessmapping.com 
>
> www.Broadband-Mapping.com
>
>
>
> *From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Mike Hammett
> *Sent:* Thursday, October 27, 2016 7:32 AM
> *To:* af@afmug.com
> *Subject:* Re: [AFMUG] Google Fiber is no more
>
>
>
> As they should. Don't build where people who can't pay or don't want 
> your service.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions  
>  omputingSolutionsDeKalb> computing-solutions>
> Midwest Internet Exchange  
> 

Re: [AFMUG] Ammon City fiber

[can...@believewireless.net]

Seems like a race to the bottom on pricing. I'm sure spammers and DCMA
violators will love it!

On Thu, Oct 27, 2016 at 12:05 PM, Chuck McCown  wrote:

> Utopia tried that method in Brigham City and it didn't work so well (for a
> variety of reasons).
>
> -Original Message- From: Travis Johnson
> Sent: Thursday, October 27, 2016 8:35 AM
>
> To: af@afmug.com
> Subject: [AFMUG] Ammon City fiber
>
> Hi,
>
> This is a small "town" that is directly connected to my hometown of
> Idaho Falls. The road I drive to work on, the west side of that street
> is Idaho Falls, the east side is Ammon. We had a lot of wireless
> customers in the Ammon area when I was a WISP. They have been working on
> this fiber project for almost 10 years.
>
> It's a very interesting way to do it. They have bundled the $3,000
> installation into a low interest "bond" kind of thing that is attached
> to the property... so that's about $15/month for 20 years. Then they
> have a small transport/utility fee for the fiber itself of $16.50/month.
>
> The most amazing part is the user can switch between providers from a
> website, picking the speed and service that they want, and it changes
> their service immediately. It will be interesting to see how this goes.
> They are supposed to have their first residential customer live by the
> end of this year.
>
> They are saying 100Mbps x 100Mbps service would be about $60-$70 per
> month total (with $0 installation cost).
>
> http://arstechnica.com/information-technology/2016/06/what-
> if-switching-fiber-isps-was-as-easy-as-clicking-a-mouse/
>
> Travis
>
>

Re: [AFMUG] Google Fiber is no more

[Chuck McCown]

But how about microwave to the home?  That is what people expect when they 
hear Google is coming to town.  GigE to the home.  I think the MTU market 
may eventually struggle with getting enough BW via microwave as well.  With 
an apartment building with 250 people all expecting a gig, hard to do with 
microwave.


-Original Message- 
From: Ken Hohhof

Sent: Thursday, October 27, 2016 10:27 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Microwave to MTU/MDU rooftop.  Proven business model.  Ask Teligent,
Winstar, Nextlink.  In fairness, now almost 20 years later, there is more
demand for what they are selling.  But also more competition.

And it's not like nobody is doing this already.  Like in Chicago SilverIP
comes to mind.


-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
Sent: Thursday, October 27, 2016 11:05 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

I predict the PhD syndrome is going to also affect the wireless end.  Vivant
tried and failed.

30 somethings that slept through physics are going to run up against the
hard limits of trees, hills and rain.

Doesn't matter how crazy the radio is, they will learn as everyone that
tries RF distribution learns.

5 years they will be back to fiber.  Or deciding not to be part of the
transport solution.

-Original Message-
From: Robert
Sent: Thursday, October 27, 2016 7:49 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Phd syndrome...  Getting an advanced degree at a big Uni gives you
almost zero experience in the trenches...   The move to wireless means
that they can buy their way into the FCC and move down from there...

On 10/27/16 6:40 AM, Brian Webster wrote:

I worked directly on the San Jose and Sand Diego projects. I was
brought in by one of the main contractors to help reduce costs and
increase efficiency. Google had way too many �30 somethings� who
failed to listen to experienced telecom professionals. That was one of
their biggest faults. It was insane to try and build a network in San
Jose that was going to have to be built mostly underground. That
market already had new AT&T U-verse fiber and Time Warner with a very
strong network. Heck I could get 100 meg speeds on Wi-Fi at the hotel
I stayed in. Their Ego to build in their own backyard was pushing the
build more than anything.



The concept of cherry picking neighborhoods actually drove costs up.
When they wanted a citywide network design, that is what they were
delivered, but then try and build out only neighborhoods they wanted
while still trying to figure out how much of their backbones, huts and
neighborhood distribution system needed to be put in place to service
the piecemeal buildout approach, when you were already having to open
ditches, while having to be a mostly underground build? Yea that was a
nightmare too! Then let�s talk about how they had no clue how hard
the MDU market is to secure. They gave no real consideration to
existing deals in the buildings, or the cost of having to wire on
their own because the building owner did not actually own the existing
cable plant and such. These projects were not just a simple math problem

to solve.




They naively thought every city was going to welcome them with open
arms like Kansas City did. They believed the political hype the
politicians told them to lure them to their cities, then when actual
laws both of physics and real came in to play, the numbers looked a whole

lot uglier.

Underground building in established cities is a nightmare in both
costs, regulations, logistics and amount of work required. Just simple
things like trying to gather data on all the existing underground
infrastructure (that has no central source of documentation) was
painful and costly. You can�t get drawings approved without first
showing you will not be interfering with existing utilities already
underground. In many cases you have to manually locate this stuff and
then map it and then do your design around that information. Other
issues to overhead builds were poles that would not pass loading
calculations, pole owners who were less than cooperative or that
pulled out new loading rules that they themselves don�t follow and
you can see where it was not a simple process. The employee count to
deal with all of this on a large scale at the pace they wanted to move was

not small by any stretch.




This was not new news. They pulled the plug on all of this stuff back
at the beginning of July.



Thank You,

Brian Webster

www.wirelessmapping.com 

www.Broadband-Mapping.com



*From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Mike Hammett
*Sent:* Thursday, October 27, 2016 7:32 AM
*To:* af@afmug.com
*Subject:* Re: [AFMUG] Google Fiber is no more



As they should. Don't build where people who can't pay or don't want
your service.



-
Mike Hammett
Intelligent Computing Solutions 

Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

[That One Guy /sarcasm]

Im getting fed up with "consultants"

On Thu, Oct 27, 2016 at 11:22 AM, Cassidy B. Larson 
wrote:

> Normally it’s up to and including a /48 that most providers will accept.
>
>
>
> On Oct 27, 2016, at 10:20 AM, Chris Wright  wrote:
>
> Would be nice. I can’t even get a straight answer from AT&T what the
> smallest public ipv6 prefix I can send them via BGP is. I’m hearing /32
> from one guy and /48 from the next.
>
> This is reminiscent of my moment of enlightenment when I realized the best
> kept secret of adulthood is that we’re all just taller children and most of
> us are assumptively credited intelligence simply because we survived
> puberty.
>
> Chris Wright
> Network Administrator
>
> *From:* Af [mailto:af-boun...@afmug.com ] *On
> Behalf Of *Chuck McCown
> *Sent:* Thursday, October 27, 2016 9:00 AM
> *To:* af@afmug.com
> *Subject:* Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt
>
> Some consultant needs to specialize in this and help folks provision,
> configure, deploy, test etc.
> We all need this or will need this.
>
> *From:* Faisal Imtiaz
> *Sent:* Wednesday, October 26, 2016 8:31 PM
> *To:* af
> *Subject:* [AFMUG] Fwd: [WISPA] IPV6 deploymernt
>
> An excellent detailed solution  (from one of the other forums).
>
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
>
> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>
> --
>
> *From: *"Tim Way" 
> *To: *"WISPA General List" 
> *Sent: *Tuesday, October 25, 2016 9:01:51 PM
> *Subject: *Re: [WISPA] IPV6 deploymernt
>
> Art,
> So I know of two solid methods that could solve your problem. Neither are
> super awesome and both would involve NAT.
>
> 1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only
> connectivity
> 2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, and IPv6 Global
> Unicast running in Dual Stack
>
> Either one would work. I apologize in advance for the long post that
> follows.
>
> I've only done the configurations on Cisco routers with the radios just
> passing traffic at layer 2. I'd have to check the feature set of your
> routers routing wise but it shouldn't be hard. It also could be built in a
> lab with static routing largely. I think Mikrotik supports NAT64 but again
> for a lab environment any recent Cisco device could be used with IP
> Services licensing.
>
> Your address plan for your global unicast IPv6 space comes into play. This
> is how I would lab it up including moving routing to the tower with the CPE
> in bridge mode:
>
> Your fictional IPv6 prefix: :::/32
>
> Your NAT64 Prefix: ::cc00::/96
>
> Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
> Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
> Your fictional customer #2: The Billings' Family, ::aa00:0200::/56
>
> Fictional Tower 1
> ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
> ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
> ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
> ISP Router at the tower on VLAN 12: ::bb00:0012::1/64
>
> The Johnson Family Setup:
> ISP CPE VLAN 11 IP: ::bb00:0011::f/64
> Customer's Netgear WAN Interface: ::bb00:0012::f/64
> Customer's Netgear LAN Interface: ::aa00:010a::1/64
> Customer's Netgear Guest WiFi: ::aa00:010b::1/64
>
> The Billings' Family Setup:
> ISP CPE VLAN 11 IP: ::bb00:0011::e/64
> Customer's Netgear WAN Interface: ::bb00:0012::e/64
> Customer's Netgear LAN Interface: ::aa00:020a::1/64
> Customer's Netgear Guest WiFi: ::aa00:020b::1/64
>
> 1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the
> native VLAN and put the IP on VLAN 11.
> 2. If you use static routing and manual address assignment to eliminate
> variables in the lab you'll want to add static routes on the tower router
> for the ::/56 prefixes that would be allocated to each customer. Normally
> these routes will be injected into the routing table at the DHCPv6 router
> and could be distributed from there.
> 3. The last piece of the puzzle will be adding in the NAT64 and DNS64
> devices. BIND can do DNS64 and you could use a Cisco router to do the
> NAT64. You'd want the "Customer's Netgear" to use the DNS64 server as it's
> upstream DNS server to ensure that it receives  records for sites that
> only have A records. This is the fragile component of the DNS64 and NAT64
> deployment because it requires the customers computer or router uses your
> resolver. You will want to ensure the router performing NAT64 is
> advertising the prefix it is using for NAT64 into your IGP or that your
> default routed traffic lands on that NAT64 to ensure it is routed correctly.
>
> This should get you a functional IPv6 only customer network that only
> returns  records for all DNS requests. It's a little late so I
> apologize for any mistakes in the addressing. Also I will

Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

[Seth Mattinen]

On 10/27/16 09:20, Chris Wright wrote:

Would be nice. I can’t even get a straight answer from AT&T what the
smallest public ipv6 prefix I can send them via BGP is. I’m hearing /32
from one guy and /48 from the next.



AT&T will accept a /48. I'm announcing a /32 and /48 to AS7018.

~Seth

Re: [AFMUG] Ammon City fiber

[Jaime Solorza]

Nah.. Transporter was what I thought he would use.

On Oct 27, 2016 9:05 AM, "Lewis Bergman"  wrote:

> We all expected you take a helicopter.
>
> On Thu, Oct 27, 2016 at 9:53 AM Josh Luthman 
> wrote:
>
>> Horse n buggy?
>>
>> Josh Luthman
>> Office: 937-552-2340 <(937)%20552-2340>
>> Direct: 937-552-2343 <(937)%20552-2343>
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>>
>> On Oct 27, 2016 10:52 AM, "Travis Johnson"  wrote:
>>
>> Yup... all 7 miles of it... takes me 10 minutes. :)
>>
>> Travis
>>
>>
>> On 10/27/2016 8:37 AM, Josh Luthman wrote:
>>
>> You drive to work?
>>
>> Josh Luthman
>> Office: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>>
>> On Oct 27, 2016 10:35 AM, "Travis Johnson"  wrote:
>>
>> Hi,
>>
>> This is a small "town" that is directly connected to my hometown of Idaho
>> Falls. The road I drive to work on, the west side of that street is Idaho
>> Falls, the east side is Ammon. We had a lot of wireless customers in the
>> Ammon area when I was a WISP. They have been working on this fiber project
>> for almost 10 years.
>>
>> It's a very interesting way to do it. They have bundled the $3,000
>> installation into a low interest "bond" kind of thing that is attached to
>> the property... so that's about $15/month for 20 years. Then they have a
>> small transport/utility fee for the fiber itself of $16.50/month.
>>
>> The most amazing part is the user can switch between providers from a
>> website, picking the speed and service that they want, and it changes their
>> service immediately. It will be interesting to see how this goes. They are
>> supposed to have their first residential customer live by the end of this
>> year.
>>
>> They are saying 100Mbps x 100Mbps service would be about $60-$70 per
>> month total (with $0 installation cost).
>>
>> http://arstechnica.com/information-technology/2016/
>> 06/what-if-switching-fiber-isps-was-as-easy-as-clicking-a-mouse/
>>
>> Travis
>>
>>
>>

Re: [AFMUG] Ubiquiti makes the big time...

[Sterling Jacobson]

+1

SFP+ MM modules and cable are dirt cheap and are a lot easier to work with.

Even the few DAC we use plug up the raceway and cable management worse than 
Ethernet.

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Paul Stewart
Sent: Thursday, October 27, 2016 9:28 AM
To: af@afmug.com
Subject: Re: [AFMUG] Ubiquiti makes the big time...

Yup agree…. we have a couple of locations where there are many dozens of twinax 
cables used and same issue

On Oct 27, 2016, at 10:35 AM, Josh Reynolds 
mailto:j...@kyneticwifi.com>> wrote:

Cable management and sometimes airflow.They're much larger diameter than sm or 
mm, require a larger bend radius than bend insensitive fiber, and you can't 
exactly cut them to length. If you just have a few uplink DACs you can make 
them work, but if you have a rack full of fiber strands and then throw in a few 
dozen DACs, after awhile you're just like "this is stupid..., brb grabbing some 
sfp+'s...".

On Oct 27, 2016 9:31 AM, "Mike Hammett" 
mailto:af...@ics-il.net>> wrote:
How is a DAC harder to manage?


-
Mike Hammett
Intelligent Computing Solutions
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
Midwest Internet Exchange
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
The Brothers WISP
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png]




From: "Josh Reynolds" mailto:j...@kyneticwifi.com>>
To: af@afmug.com
Sent: Thursday, October 27, 2016 9:26:35 AM
Subject: Re: [AFMUG] Ubiquiti makes the big time...
Well, I used to like DACs. Not so much anymore.
Some of it has to do with cable organization, and inventory is the other angle.
Having transceivers and patches around is utilitarian. Having DACs around is 
slightly cheaper, but those DACs are much harder to deal with from a cable 
management perspective.
I don't hate DACs, I just dislike the tradeoffs.

On Oct 27, 2016 7:57 AM, "Mike Hammett" 
mailto:af...@ics-il.net>> wrote:
Anything that doesn't support DACs is fucking worthless.


I've ditched all ad-block, privacy, etc. extensions. They're garbage.


-
Mike Hammett
Intelligent Computing Solutions
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
Midwest Internet Exchange
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
The Brothers WISP
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png]




From: "Josh Reynolds" mailto:j...@kyneticwifi.com>>
To: af@afmug.com
Sent: Thursday, October 27, 2016 7:50:21 AM
Subject: Re: [AFMUG] Ubiquiti makes the big time...
I complained about the DAC issue during the Alpha, as I just wanted to plug in 
the switch to a Juniper MX960 and throw some of the VM load on it. Sadly I 
ended up having to use short patch cables and fiberstore transceivers, which 
worked fine.
I didn't experience the crashes the author did, although I "whitelist" all my 
hardware interfaces in my browser extensions... Maybe that was his/her issue, I 
don't know.
Side note: the was about 6 months back

On Oct 27, 2016 7:33 AM, "Mark Radabaugh" 
mailto:m...@amplex.net>> wrote:
The good news:  kit gets reviewed on a major IT website.
The bad news: kit gets reviewed on a major IT website.

http://www.theregister.co.uk/2016/10/27/ubiquiti_edgeswitch_review/

Mark

Re: [AFMUG] Google Fiber is no more

[Jaime Solorza]

PhD=push here dummy

On Oct 27, 2016 7:49 AM, "Robert"  wrote:

> Phd syndrome...  Getting an advanced degree at a big Uni gives you almost
> zero experience in the trenches...   The move to wireless means that they
> can buy their way into the FCC and move down from there...
>
> On 10/27/16 6:40 AM, Brian Webster wrote:
>
>> I worked directly on the San Jose and Sand Diego projects. I was brought
>> in by one of the main contractors to help reduce costs and increase
>> efficiency. Google had way too many �30 somethings� who failed to
>> listen
>> to experienced telecom professionals. That was one of their biggest
>> faults. It was insane to try and build a network in San Jose that was
>> going to have to be built mostly underground. That market already had
>> new AT&T U-verse fiber and Time Warner with a very strong network. Heck
>> I could get 100 meg speeds on Wi-Fi at the hotel I stayed in. Their Ego
>> to build in their own backyard was pushing the build more than anything.
>>
>>
>>
>> The concept of cherry picking neighborhoods actually drove costs up.
>> When they wanted a citywide network design, that is what they were
>> delivered, but then try and build out only neighborhoods they wanted
>> while still trying to figure out how much of their backbones, huts and
>> neighborhood distribution system needed to be put in place to service
>> the piecemeal buildout approach, when you were already having to open
>> ditches, while having to be a mostly underground build? Yea that was a
>> nightmare too! Then let�s talk about how they had no clue how hard the
>> MDU market is to secure. They gave no real consideration to existing
>> deals in the buildings, or the cost of having to wire on their own
>> because the building owner did not actually own the existing cable plant
>> and such. These projects were not just a simple math problem to solve.
>>
>>
>>
>> They naively thought every city was going to welcome them with open arms
>> like Kansas City did. They believed the political hype the politicians
>> told them to lure them to their cities, then when actual laws both of
>> physics and real came in to play, the numbers looked a whole lot uglier.
>> Underground building in established cities is a nightmare in both costs,
>> regulations, logistics and amount of work required. Just simple things
>> like trying to gather data on all the existing underground
>> infrastructure (that has no central source of documentation) was painful
>> and costly. You can�t get drawings approved without first showing you
>> will not be interfering with existing utilities already underground. In
>> many cases you have to manually locate this stuff and then map it and
>> then do your design around that information. Other issues to overhead
>> builds were poles that would not pass loading calculations, pole owners
>> who were less than cooperative or that pulled out new loading rules that
>> they themselves don�t follow and you can see where it was not a simple
>> process. The employee count to deal with all of this on a large scale at
>> the pace they wanted to move was not small by any stretch.
>>
>>
>>
>> This was not new news. They pulled the plug on all of this stuff back at
>> the beginning of July.
>>
>>
>>
>> Thank You,
>>
>> Brian Webster
>>
>> www.wirelessmapping.com 
>>
>> www.Broadband-Mapping.com
>>
>>
>>
>> *From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Mike Hammett
>> *Sent:* Thursday, October 27, 2016 7:32 AM
>> *To:* af@afmug.com
>> *Subject:* Re: [AFMUG] Google Fiber is no more
>>
>>
>>
>> As they should. Don't build where people who can't pay or don't want
>> your service.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> > telligentComputingSolutionsDeKalb>> company/intelligent-computing-solutions>
>> Midwest Internet Exchange 
>> > com/company/midwest-internet-exchange>
>> The Brothers WISP 
>> 
>>
>>
>> 
>>
>> 
>>
>> *From: *"Rory Conaway" > >
>> *To: *af@afmug.com 
>> *Sent: *Wednesday, October 26, 2016 11:28:52 PM
>> *Subject: *Re: [AFMUG] Google Fiber is no more
>>
>> In other cities, they cherry picked.
>>
>>
>>
>> Rory
>>
>>
>>
>> *From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Sterling Jacobson
>> *Sent:* Wednesday, October 26, 2016 7:00 PM
>> *To:* af@afmug.com 
>> *Subject:* Re: [AFMUG] Google Fiber is no more
>>
>>
>>
>> From the director of one of the Google Fiber builds (in Provo) that is
>> n

Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

[Sterling Jacobson]

Dennis did our deployment of IPv6 on top of our IPv4 and it works great.

However, he still needs to reply to my email on availability, so there’s that 
problem of timeliness and not enough Dennis to go around, lol!

Butch also helped me with great classes that were Mikrotik implementation that 
I used with previous company and IPv6 as well.



From: Af [mailto:af-boun...@afmug.com] On Behalf Of That One Guy /sarcasm
Sent: Thursday, October 27, 2016 10:30 AM
To: af@afmug.com
Subject: Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

Im getting fed up with "consultants"

On Thu, Oct 27, 2016 at 11:22 AM, Cassidy B. Larson 
mailto:c...@infowest.com>> wrote:
Normally it’s up to and including a /48 that most providers will accept.



On Oct 27, 2016, at 10:20 AM, Chris Wright 
mailto:ch...@velociter.net>> wrote:

Would be nice. I can’t even get a straight answer from AT&T what the smallest 
public ipv6 prefix I can send them via BGP is. I’m hearing /32 from one guy and 
/48 from the next.

This is reminiscent of my moment of enlightenment when I realized the best kept 
secret of adulthood is that we’re all just taller children and most of us are 
assumptively credited intelligence simply because we survived puberty.

Chris Wright
Network Administrator

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
Sent: Thursday, October 27, 2016 9:00 AM
To: af@afmug.com
Subject: Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc.
We all need this or will need this.

From: Faisal Imtiaz
Sent: Wednesday, October 26, 2016 8:31 PM
To: af
Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

An excellent detailed solution  (from one of the other forums).

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: 
supp...@snappytelecom.net


From: "Tim Way" mailto:t...@way.vg>>
To: "WISPA General List" mailto:wirel...@wispa.org>>
Sent: Tuesday, October 25, 2016 9:01:51 PM
Subject: Re: [WISPA] IPV6 deploymernt
Art,
So I know of two solid methods that could solve your problem. Neither are super 
awesome and both would involve NAT.

1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only connectivity
2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, 
and IPv6 Global Unicast running in Dual Stack

Either one would work. I apologize in advance for the long post that follows.

I've only done the configurations on Cisco routers with the radios just passing 
traffic at layer 2. I'd have to check the feature set of your routers routing 
wise but it shouldn't be hard. It also could be built in a lab with static 
routing largely. I think Mikrotik supports NAT64 but again for a lab 
environment any recent Cisco device could be used with IP Services licensing.

Your address plan for your global unicast IPv6 space comes into play. This is 
how I would lab it up including moving routing to the tower with the CPE in 
bridge mode:

Your fictional IPv6 prefix: :::/32

Your NAT64 Prefix: ::cc00::/96

Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
Your fictional customer #2: The Billings' Family, ::aa00:0200::/56

Fictional Tower 1
ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
ISP Router at the tower on VLAN 12: ::bb00:0012::1/64

The Johnson Family Setup:
ISP CPE VLAN 11 IP: ::bb00:0011::f/64
Customer's Netgear WAN Interface: ::bb00:0012::f/64
Customer's Netgear LAN Interface: ::aa00:010a::1/64
Customer's Netgear Guest WiFi: ::aa00:010b::1/64

The Billings' Family Setup:
ISP CPE VLAN 11 IP: ::bb00:0011::e/64
Customer's Netgear WAN Interface: ::bb00:0012::e/64
Customer's Netgear LAN Interface: ::aa00:020a::1/64
Customer's Netgear Guest WiFi: ::aa00:020b::1/64

1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the 
native VLAN and put the IP on VLAN 11.
2. If you use static routing and manual address assignment to eliminate 
variables in the lab you'll want to add static routes on the tower router for 
the ::/56 prefixes that would be allocated to each customer. Normally these 
routes will be injected into the routing table at the DHCPv6 router and could 
be distributed from there.
3. The last piece of the puzzle will be adding in the NAT64 and DNS64 devices. 
BIND can do DNS64 and you could use a Cisco router to do the NAT64. You'd want 
the "Customer's Netgear" to use the DNS64 server as it's upstream DNS server to 
ensure that it receives  records for sites that only have A records. This 
is the fragile component of the DNS

Re: [AFMUG] Google Fiber is no more

[Ken Hohhof]

The way I read their change in direction is they are focusing now on high
rise apartment and office buildings where they can beam bandwidth to the
rooftop.  No more gigabit to individual homes.  Not a Vivint play.  Maybe
I'm wrong.

As far as 250 people all expecting a gig, not sure what they are planning.
Maybe they figure there's enough spectrum in millimeter wave to do whatever
they need to do.  Maybe creative marketing.  Let's face it, most big ISPs
now sell best effort speeds.  Well, to residential.  Businesses may still
expect to actually get what they were promised and maybe even to actually
use it.

-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
Sent: Thursday, October 27, 2016 11:32 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

But how about microwave to the home?  That is what people expect when they
hear Google is coming to town.  GigE to the home.  I think the MTU market
may eventually struggle with getting enough BW via microwave as well.  With
an apartment building with 250 people all expecting a gig, hard to do with
microwave.

-Original Message-
From: Ken Hohhof
Sent: Thursday, October 27, 2016 10:27 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Microwave to MTU/MDU rooftop.  Proven business model.  Ask Teligent,
Winstar, Nextlink.  In fairness, now almost 20 years later, there is more
demand for what they are selling.  But also more competition.

And it's not like nobody is doing this already.  Like in Chicago SilverIP
comes to mind.


-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
Sent: Thursday, October 27, 2016 11:05 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

I predict the PhD syndrome is going to also affect the wireless end.  Vivant
tried and failed.

30 somethings that slept through physics are going to run up against the
hard limits of trees, hills and rain.

Doesn't matter how crazy the radio is, they will learn as everyone that
tries RF distribution learns.

5 years they will be back to fiber.  Or deciding not to be part of the
transport solution.

-Original Message-
From: Robert
Sent: Thursday, October 27, 2016 7:49 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Phd syndrome...  Getting an advanced degree at a big Uni gives you
almost zero experience in the trenches...   The move to wireless means
that they can buy their way into the FCC and move down from there...

On 10/27/16 6:40 AM, Brian Webster wrote:
> I worked directly on the San Jose and Sand Diego projects. I was 
> brought in by one of the main contractors to help reduce costs and 
> increase efficiency. Google had way too many �30 somethings� who 
> failed to listen to experienced telecom professionals. That was one of 
> their biggest faults. It was insane to try and build a network in San 
> Jose that was going to have to be built mostly underground. That 
> market already had new AT&T U-verse fiber and Time Warner with a very 
> strong network. Heck I could get 100 meg speeds on Wi-Fi at the hotel 
> I stayed in. Their Ego to build in their own backyard was pushing the 
> build more than anything.
>
>
>
> The concept of cherry picking neighborhoods actually drove costs up.
> When they wanted a citywide network design, that is what they were 
> delivered, but then try and build out only neighborhoods they wanted 
> while still trying to figure out how much of their backbones, huts and 
> neighborhood distribution system needed to be put in place to service 
> the piecemeal buildout approach, when you were already having to open 
> ditches, while having to be a mostly underground build? Yea that was a 
> nightmare too! Then let�s talk about how they had no clue how hard 
> the MDU market is to secure. They gave no real consideration to 
> existing deals in the buildings, or the cost of having to wire on 
> their own because the building owner did not actually own the existing 
> cable plant and such. These projects were not just a simple math 
> problem
to solve.
>
>
>
> They naively thought every city was going to welcome them with open 
> arms like Kansas City did. They believed the political hype the 
> politicians told them to lure them to their cities, then when actual 
> laws both of physics and real came in to play, the numbers looked a 
> whole
lot uglier.
> Underground building in established cities is a nightmare in both 
> costs, regulations, logistics and amount of work required. Just simple 
> things like trying to gather data on all the existing underground 
> infrastructure (that has no central source of documentation) was 
> painful and costly. You can�t get drawings approved without first 
> showing you will not be interfering with existing utilities already 
> underground. In many cases you have to manually locate this stuff and 
> then map it and then do your design around that information. Other 
> issues

Re: [AFMUG] Ammon City fiber

[Sterling Jacobson]

I like the idea of the bond, but I don’t like the idea of a split 
responsibility/ISP where one entity owns the fiber and others bill and provide 
service over it.


From: Af [mailto:af-boun...@afmug.com] On Behalf Of can...@believewireless.net
Sent: Thursday, October 27, 2016 10:32 AM
To: af@afmug.com
Subject: Re: [AFMUG] Ammon City fiber

Seems like a race to the bottom on pricing. I'm sure spammers and DCMA 
violators will love it!

On Thu, Oct 27, 2016 at 12:05 PM, Chuck McCown 
mailto:ch...@wbmfg.com>> wrote:
Utopia tried that method in Brigham City and it didn't work so well (for a 
variety of reasons).

-Original Message- From: Travis Johnson
Sent: Thursday, October 27, 2016 8:35 AM

To: af@afmug.com
Subject: [AFMUG] Ammon City fiber

Hi,

This is a small "town" that is directly connected to my hometown of
Idaho Falls. The road I drive to work on, the west side of that street
is Idaho Falls, the east side is Ammon. We had a lot of wireless
customers in the Ammon area when I was a WISP. They have been working on
this fiber project for almost 10 years.

It's a very interesting way to do it. They have bundled the $3,000
installation into a low interest "bond" kind of thing that is attached
to the property... so that's about $15/month for 20 years. Then they
have a small transport/utility fee for the fiber itself of $16.50/month.

The most amazing part is the user can switch between providers from a
website, picking the speed and service that they want, and it changes
their service immediately. It will be interesting to see how this goes.
They are supposed to have their first residential customer live by the
end of this year.

They are saying 100Mbps x 100Mbps service would be about $60-$70 per
month total (with $0 installation cost).

http://arstechnica.com/information-technology/2016/06/what-if-switching-fiber-isps-was-as-easy-as-clicking-a-mouse/

Travis

Re: [AFMUG] Google Fiber is no more

[Travis Johnson]

"Up to" is the key wording... "Up to"


On 10/27/2016 10:32 AM, Chuck McCown wrote:
But how about microwave to the home?  That is what people expect when 
they hear Google is coming to town.  GigE to the home.  I think the 
MTU market may eventually struggle with getting enough BW via 
microwave as well.  With an apartment building with 250 people all 
expecting a gig, hard to do with microwave.


-Original Message- From: Ken Hohhof
Sent: Thursday, October 27, 2016 10:27 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Microwave to MTU/MDU rooftop.  Proven business model.  Ask Teligent,
Winstar, Nextlink.  In fairness, now almost 20 years later, there is more
demand for what they are selling.  But also more competition.

And it's not like nobody is doing this already.  Like in Chicago SilverIP
comes to mind.


-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
Sent: Thursday, October 27, 2016 11:05 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

I predict the PhD syndrome is going to also affect the wireless end.  
Vivant

tried and failed.

30 somethings that slept through physics are going to run up against the
hard limits of trees, hills and rain.

Doesn't matter how crazy the radio is, they will learn as everyone that
tries RF distribution learns.

5 years they will be back to fiber.  Or deciding not to be part of the
transport solution.

-Original Message-
From: Robert
Sent: Thursday, October 27, 2016 7:49 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Phd syndrome...  Getting an advanced degree at a big Uni gives you
almost zero experience in the trenches...   The move to wireless means
that they can buy their way into the FCC and move down from there...

On 10/27/16 6:40 AM, Brian Webster wrote:

I worked directly on the San Jose and Sand Diego projects. I was
brought in by one of the main contractors to help reduce costs and
increase efficiency. Google had way too many �30 somethings� who
failed to listen to experienced telecom professionals. That was one of
their biggest faults. It was insane to try and build a network in San
Jose that was going to have to be built mostly underground. That
market already had new AT&T U-verse fiber and Time Warner with a very
strong network. Heck I could get 100 meg speeds on Wi-Fi at the hotel
I stayed in. Their Ego to build in their own backyard was pushing the
build more than anything.



The concept of cherry picking neighborhoods actually drove costs up.
When they wanted a citywide network design, that is what they were
delivered, but then try and build out only neighborhoods they wanted
while still trying to figure out how much of their backbones, huts and
neighborhood distribution system needed to be put in place to service
the piecemeal buildout approach, when you were already having to open
ditches, while having to be a mostly underground build? Yea that was a
nightmare too! Then let�s talk about how they had no clue how hard
the MDU market is to secure. They gave no real consideration to
existing deals in the buildings, or the cost of having to wire on
their own because the building owner did not actually own the existing
cable plant and such. These projects were not just a simple math problem

to solve.




They naively thought every city was going to welcome them with open
arms like Kansas City did. They believed the political hype the
politicians told them to lure them to their cities, then when actual
laws both of physics and real came in to play, the numbers looked a 
whole

lot uglier.

Underground building in established cities is a nightmare in both
costs, regulations, logistics and amount of work required. Just simple
things like trying to gather data on all the existing underground
infrastructure (that has no central source of documentation) was
painful and costly. You can�t get drawings approved without first
showing you will not be interfering with existing utilities already
underground. In many cases you have to manually locate this stuff and
then map it and then do your design around that information. Other
issues to overhead builds were poles that would not pass loading
calculations, pole owners who were less than cooperative or that
pulled out new loading rules that they themselves don�t follow and
you can see where it was not a simple process. The employee count to
deal with all of this on a large scale at the pace they wanted to 
move was

not small by any stretch.




This was not new news. They pulled the plug on all of this stuff back
at the beginning of July.



Thank You,

Brian Webster

www.wirelessmapping.com 

www.Broadband-Mapping.com



*From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Mike Hammett
*Sent:* Thursday, October 27, 2016 7:32 AM
*To:* af@afmug.com
*Subject:* Re: [AFMUG] Google Fiber is no more



As they should. Don't build where people who can't pay or do

Re: [AFMUG] Google Fiber is no more

[Rory Conaway]

Low-hanging fruit, MDU's.  Not the same as Vivint.  Vivint went into the 
trenches.

Rory

-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Ken Hohhof
Sent: Thursday, October 27, 2016 9:48 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

The way I read their change in direction is they are focusing now on high rise 
apartment and office buildings where they can beam bandwidth to the rooftop.  
No more gigabit to individual homes.  Not a Vivint play.  Maybe I'm wrong.

As far as 250 people all expecting a gig, not sure what they are planning.
Maybe they figure there's enough spectrum in millimeter wave to do whatever 
they need to do.  Maybe creative marketing.  Let's face it, most big ISPs now 
sell best effort speeds.  Well, to residential.  Businesses may still expect to 
actually get what they were promised and maybe even to actually use it.

-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
Sent: Thursday, October 27, 2016 11:32 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

But how about microwave to the home?  That is what people expect when they hear 
Google is coming to town.  GigE to the home.  I think the MTU market may 
eventually struggle with getting enough BW via microwave as well.  With an 
apartment building with 250 people all expecting a gig, hard to do with 
microwave.

-Original Message-
From: Ken Hohhof
Sent: Thursday, October 27, 2016 10:27 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Microwave to MTU/MDU rooftop.  Proven business model.  Ask Teligent, Winstar, 
Nextlink.  In fairness, now almost 20 years later, there is more demand for 
what they are selling.  But also more competition.

And it's not like nobody is doing this already.  Like in Chicago SilverIP comes 
to mind.


-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
Sent: Thursday, October 27, 2016 11:05 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

I predict the PhD syndrome is going to also affect the wireless end.  Vivant 
tried and failed.

30 somethings that slept through physics are going to run up against the hard 
limits of trees, hills and rain.

Doesn't matter how crazy the radio is, they will learn as everyone that tries 
RF distribution learns.

5 years they will be back to fiber.  Or deciding not to be part of the 
transport solution.

-Original Message-
From: Robert
Sent: Thursday, October 27, 2016 7:49 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Phd syndrome...  Getting an advanced degree at a big Uni gives you
almost zero experience in the trenches...   The move to wireless means
that they can buy their way into the FCC and move down from there...

On 10/27/16 6:40 AM, Brian Webster wrote:
> I worked directly on the San Jose and Sand Diego projects. I was 
> brought in by one of the main contractors to help reduce costs and 
> increase efficiency. Google had way too many �30 somethings� who 
> failed to listen to experienced telecom professionals. That was one of 
> their biggest faults. It was insane to try and build a network in San 
> Jose that was going to have to be built mostly underground. That 
> market already had new AT&T U-verse fiber and Time Warner with a very 
> strong network. Heck I could get 100 meg speeds on Wi-Fi at the hotel 
> I stayed in. Their Ego to build in their own backyard was pushing the 
> build more than anything.
>
>
>
> The concept of cherry picking neighborhoods actually drove costs up.
> When they wanted a citywide network design, that is what they were 
> delivered, but then try and build out only neighborhoods they wanted 
> while still trying to figure out how much of their backbones, huts and 
> neighborhood distribution system needed to be put in place to service 
> the piecemeal buildout approach, when you were already having to open 
> ditches, while having to be a mostly underground build? Yea that was a 
> nightmare too! Then let�s talk about how they had no clue how hard 
> the MDU market is to secure. They gave no real consideration to 
> existing deals in the buildings, or the cost of having to wire on 
> their own because the building owner did not actually own the existing 
> cable plant and such. These projects were not just a simple math 
> problem
to solve.
>
>
>
> They naively thought every city was going to welcome them with open 
> arms like Kansas City did. They believed the political hype the 
> politicians told them to lure them to their cities, then when actual 
> laws both of physics and real came in to play, the numbers looked a 
> whole
lot uglier.
> Underground building in established cities is a nightmare in both 
> costs, regulations, logistics and amount of work required. Just simple 
> things like trying to gather data on all the existing underground 
> infrastructure (that has no central source of documentatio

Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

[Dennis Burgess]

Dude you got a ticket in? I don’t see one ☹


Dennis Burgess – Network Solution Engineer – Consultant
MikroTik Certified 
Trainer/Consultant
 – MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE

For Wireless Hardware/Routers visit www.linktechs.net
Radio Frequiency Coverages: www.towercoverage.com
Office: 314-735-0270
E-Mail: dmburg...@linktechs.net

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Sterling Jacobson
Sent: Thursday, October 27, 2016 11:46 AM
To: af@afmug.com
Subject: Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

Dennis did our deployment of IPv6 on top of our IPv4 and it works great.

However, he still needs to reply to my email on availability, so there’s that 
problem of timeliness and not enough Dennis to go around, lol!

Butch also helped me with great classes that were Mikrotik implementation that 
I used with previous company and IPv6 as well.



From: Af [mailto:af-boun...@afmug.com] On Behalf Of That One Guy /sarcasm
Sent: Thursday, October 27, 2016 10:30 AM
To: af@afmug.com
Subject: Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

Im getting fed up with "consultants"

On Thu, Oct 27, 2016 at 11:22 AM, Cassidy B. Larson 
mailto:c...@infowest.com>> wrote:
Normally it’s up to and including a /48 that most providers will accept.



On Oct 27, 2016, at 10:20 AM, Chris Wright 
mailto:ch...@velociter.net>> wrote:

Would be nice. I can’t even get a straight answer from AT&T what the smallest 
public ipv6 prefix I can send them via BGP is. I’m hearing /32 from one guy and 
/48 from the next.

This is reminiscent of my moment of enlightenment when I realized the best kept 
secret of adulthood is that we’re all just taller children and most of us are 
assumptively credited intelligence simply because we survived puberty.

Chris Wright
Network Administrator

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
Sent: Thursday, October 27, 2016 9:00 AM
To: af@afmug.com
Subject: Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc.
We all need this or will need this.

From: Faisal Imtiaz
Sent: Wednesday, October 26, 2016 8:31 PM
To: af
Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

An excellent detailed solution  (from one of the other forums).

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: 
supp...@snappytelecom.net


From: "Tim Way" mailto:t...@way.vg>>
To: "WISPA General List" mailto:wirel...@wispa.org>>
Sent: Tuesday, October 25, 2016 9:01:51 PM
Subject: Re: [WISPA] IPV6 deploymernt
Art,
So I know of two solid methods that could solve your problem. Neither are super 
awesome and both would involve NAT.

1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only connectivity
2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, 
and IPv6 Global Unicast running in Dual Stack

Either one would work. I apologize in advance for the long post that follows.

I've only done the configurations on Cisco routers with the radios just passing 
traffic at layer 2. I'd have to check the feature set of your routers routing 
wise but it shouldn't be hard. It also could be built in a lab with static 
routing largely. I think Mikrotik supports NAT64 but again for a lab 
environment any recent Cisco device could be used with IP Services licensing.

Your address plan for your global unicast IPv6 space comes into play. This is 
how I would lab it up including moving routing to the tower with the CPE in 
bridge mode:

Your fictional IPv6 prefix: :::/32

Your NAT64 Prefix: ::cc00::/96

Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
Your fictional customer #2: The Billings' Family, ::aa00:0200::/56

Fictional Tower 1
ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
ISP Router at the tower on VLAN 12: ::bb00:0012::1/64

The Johnson Family Setup:
ISP CPE VLAN 11 IP: ::bb00:0011::f/64
Customer's Netgear WAN Interface: ::bb00:0012::f/64
Customer's Netgear LAN Interface: ::aa00:010a::1/64
Customer's Netgear Guest WiFi: ::aa00:010b::1/64

The Billings' Family Setup:
ISP CPE VLAN 11 IP: ::bb00:0011::e/64
Customer's Netgear WAN Interface: ::bb00:0012::e/64
Customer's Netgear LAN Interface: ::aa00:020a::1/64
Customer's Netgear Guest WiFi: ::aa00:020b::1/64

1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the 
native VLAN and put the IP on VL

Re: [AFMUG] Google Fiber is no more

[George Skorup]

So splain me this. If the google is interested in 3.5GHz, and they're 
also going to run one of the SAS's... is that not a conflict of 
interest? I mean I'd hate to go all Trumpian about it, but they could 
very easily rig the system.

Re: [AFMUG] Google Fiber is no more

[Josh Luthman]

Google get's the gear but Alphabet controls one of the SAS



Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Thu, Oct 27, 2016 at 1:05 PM, George Skorup  wrote:

> So splain me this. If the google is interested in 3.5GHz, and they're also
> going to run one of the SAS's... is that not a conflict of interest? I mean
> I'd hate to go all Trumpian about it, but they could very easily rig the
> system.
>

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Paul Stewart]

while I’m not a fan of NAT64, CGN etc (but understand in some situations the 
need for it), I completely agree that companies will be looking for consultants 
to help with this in some scenarios (both large and small companies alike) - 
this has been ongoing in some larger companies for many years already (IPv6 
adoption) and often through resident engineer placements from vendors 


> On Oct 27, 2016, at 11:59 AM, Chuck McCown  wrote:
> 
> Some consultant needs to specialize in this and help folks provision, 
> configure, deploy, test etc. 
> We all need this or will need this. 
>  
> From: Faisal Imtiaz <>
> Sent: Wednesday, October 26, 2016 8:31 PM
> To: af <>
> Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt
>  
> An excellent detailed solution  (from one of the other forums).
>  
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
> 
> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>  
>> From: "Tim Way" 
>> To: "WISPA General List" 
>> Sent: Tuesday, October 25, 2016 9:01:51 PM
>> Subject: Re: [WISPA] IPV6 deploymernt
> 
>> Art,
>> So I know of two solid methods that could solve your problem. Neither are 
>> super awesome and both would involve NAT.
>>  
>> 1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only 
>> connectivity
>> 2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10 
>> , and IPv6 Global Unicast running in Dual Stack
>>  
>> Either one would work. I apologize in advance for the long post that follows.
>>  
>> I've only done the configurations on Cisco routers with the radios just 
>> passing traffic at layer 2. I'd have to check the feature set of your 
>> routers routing wise but it shouldn't be hard. It also could be built in a 
>> lab with static routing largely. I think Mikrotik supports NAT64 but again 
>> for a lab environment any recent Cisco device could be used with IP Services 
>> licensing.
>>  
>> Your address plan for your global unicast IPv6 space comes into play. This 
>> is how I would lab it up including moving routing to the tower with the CPE 
>> in bridge mode:
>>  
>> Your fictional IPv6 prefix: :::/32
>>  
>> Your NAT64 Prefix: ::cc00::/96
>>  
>> Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
>> Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
>> Your fictional customer #2: The Billings' Family, ::aa00:0200::/56
>>  
>> Fictional Tower 1
>> ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
>> ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
>> ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
>> ISP Router at the tower on VLAN 12: ::bb00:0012::1/64
>>  
>> The Johnson Family Setup:
>> ISP CPE VLAN 11 IP: ::bb00:0011::f/64
>> Customer's Netgear WAN Interface: ::bb00:0012::f/64
>> Customer's Netgear LAN Interface: ::aa00:010a::1/64
>> Customer's Netgear Guest WiFi: ::aa00:010b::1/64
>>  
>> The Billings' Family Setup:
>> ISP CPE VLAN 11 IP: ::bb00:0011::e/64
>> Customer's Netgear WAN Interface: ::bb00:0012::e/64
>> Customer's Netgear LAN Interface: ::aa00:020a::1/64
>> Customer's Netgear Guest WiFi: ::aa00:020b::1/64
>>  
>> 1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the 
>> native VLAN and put the IP on VLAN 11.
>> 2. If you use static routing and manual address assignment to eliminate 
>> variables in the lab you'll want to add static routes on the tower router 
>> for the ::/56 prefixes that would be allocated to each customer. Normally 
>> theseroutes will be injected into the routing table at the DHCPv6 router 
>> and could be distributed from there.
>> 3. The last piece of the puzzle will be adding in the NAT64 and DNS64 
>> devices. BIND can do DNS64 and you could use a Cisco router to do the NAT64. 
>> You'd want the "Customer's Netgear" to use the DNS64 server as it's upstream 
>> DNS server to ensure that it receives  records for sites that only have 
>> A records. This is the fragile component of the DNS64 and NAT64 deployment 
>> because it requires the customers computer or router uses your resolver. You 
>> will want to ensure the router performing NAT64 is advertising the prefix it 
>> is using for NAT64 into your IGP or that your default routed traffic lands 
>> on that NAT64 to ensure it is routed correctly.
>> 
>> This should get you a functional IPv6 only customer network that only 
>> returns  records for all DNS requests. It's a little late so I apologize 
>> for any mistakes in the addressing. Also I will think about doing this with 
>> routing at the CPE as well overnight and add that response. I'd be very 
>> intrigued to see this in a lab environment with the fictional customers all 
>> setup to see how NAT64 and DNS64 actually works in reality instead of just 
>> implementing CGN which I see as the less visible or resilient change for t

Re: [AFMUG] Google Fiber is no more

[Gino Villarini]

Webpass? that¹s the reason they bought it! Proven business model operating
in top cities

On 10/27/16, 12:27 PM, "Af on behalf of Ken Hohhof"  wrote:

>Microwave to MTU/MDU rooftop.  Proven business model.  Ask Teligent,
>Winstar, Nextlink.  In fairness, now almost 20 years later, there is more
>demand for what they are selling.  But also more competition.
>
>And it's not like nobody is doing this already.  Like in Chicago SilverIP
>comes to mind.
>
>
>-Original Message-
>From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
>Sent: Thursday, October 27, 2016 11:05 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>I predict the PhD syndrome is going to also affect the wireless end.
>Vivant
>tried and failed.
>
>30 somethings that slept through physics are going to run up against the
>hard limits of trees, hills and rain.
>
>Doesn't matter how crazy the radio is, they will learn as everyone that
>tries RF distribution learns.
>
>5 years they will be back to fiber.  Or deciding not to be part of the
>transport solution.
>
>-Original Message-
>From: Robert
>Sent: Thursday, October 27, 2016 7:49 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>Phd syndrome...  Getting an advanced degree at a big Uni gives you
>almost zero experience in the trenches...   The move to wireless means
>that they can buy their way into the FCC and move down from there...
>
>On 10/27/16 6:40 AM, Brian Webster wrote:
>> I worked directly on the San Jose and Sand Diego projects. I was
>> brought in by one of the main contractors to help reduce costs and
>> increase efficiency. Google had way too many ï¿1Ž230 somethingsï¿1Ž2 who
>> failed to listen to experienced telecom professionals. That was one of
>> their biggest faults. It was insane to try and build a network in San
>> Jose that was going to have to be built mostly underground. That
>> market already had new AT&T U-verse fiber and Time Warner with a very
>> strong network. Heck I could get 100 meg speeds on Wi-Fi at the hotel
>> I stayed in. Their Ego to build in their own backyard was pushing the
>> build more than anything.
>>
>>
>>
>> The concept of cherry picking neighborhoods actually drove costs up.
>> When they wanted a citywide network design, that is what they were
>> delivered, but then try and build out only neighborhoods they wanted
>> while still trying to figure out how much of their backbones, huts and
>> neighborhood distribution system needed to be put in place to service
>> the piecemeal buildout approach, when you were already having to open
>> ditches, while having to be a mostly underground build? Yea that was a
>> nightmare too! Then letï¿1Ž2s talk about how they had no clue how hard
>> the MDU market is to secure. They gave no real consideration to
>> existing deals in the buildings, or the cost of having to wire on
>> their own because the building owner did not actually own the existing
>> cable plant and such. These projects were not just a simple math problem
>to solve.
>>
>>
>>
>> They naively thought every city was going to welcome them with open
>> arms like Kansas City did. They believed the political hype the
>> politicians told them to lure them to their cities, then when actual
>> laws both of physics and real came in to play, the numbers looked a
>>whole
>lot uglier.
>> Underground building in established cities is a nightmare in both
>> costs, regulations, logistics and amount of work required. Just simple
>> things like trying to gather data on all the existing underground
>> infrastructure (that has no central source of documentation) was
>> painful and costly. You canï¿1Ž2t get drawings approved without first
>> showing you will not be interfering with existing utilities already
>> underground. In many cases you have to manually locate this stuff and
>> then map it and then do your design around that information. Other
>> issues to overhead builds were poles that would not pass loading
>> calculations, pole owners who were less than cooperative or that
>> pulled out new loading rules that they themselves donï¿1Ž2t follow and
>> you can see where it was not a simple process. The employee count to
>> deal with all of this on a large scale at the pace they wanted to move
>>was
>not small by any stretch.
>>
>>
>>
>> This was not new news. They pulled the plug on all of this stuff back
>> at the beginning of July.
>>
>>
>>
>> Thank You,
>>
>> Brian Webster
>>
>> www.wirelessmapping.com 
>> 
>>
>> www.Broadband-Mapping.com
>>
>>
>>
>> *From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Mike Hammett
>> *Sent:* Thursday, October 27, 2016 7:32 AM
>> *To:* af@afmug.com
>> *Subject:* Re: [AFMUG] Google Fiber is no more
>>
>>
>>
>> As they should. Don't build where people who can't pay or don't want
>> your service.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 

[AFMUG] SNMP v1 Ubiquiti?

[Paul Stewart]

I’m involved with a project to provide better visibility into our UBNT 
deployments and just realized that, so far, their equipment only supports SNMP 
v1?  Is this right?

Example is a AirFiber 24Ghz link that I’m testing against right now

If correct …. ummm… wow!

Thanks,
Paul

[AFMUG] For sale Ignitenet 60GHz sector

[Brett A Mansfield]

I have two of the 60Ghz Ignitenet 30 degree sectors for sale.  They are both 
brand new. I opened one to play with for a week, the other is still an unopened 
box. $400/ea.

Thank you,
Brett A Mansfield

Re: [AFMUG] Google Fiber is no more

[Gino Villarini]

Ken, we have been doing MDUs in PR and FL for about 18 months now. WE are
using AF24 units to each bldg in a ring format with no more of 10 blds in
the ring. Endpoints are fiber pops.  WE sell up to 500 Mbps, usage is in
resitential ins avg 25-30 mbs, we only see 500 mbps whrn they go to the
speed tests sites.

On 10/27/16, 12:47 PM, "Af on behalf of Ken Hohhof"  wrote:

>The way I read their change in direction is they are focusing now on high
>rise apartment and office buildings where they can beam bandwidth to the
>rooftop.  No more gigabit to individual homes.  Not a Vivint play.  Maybe
>I'm wrong.
>
>As far as 250 people all expecting a gig, not sure what they are planning.
>Maybe they figure there's enough spectrum in millimeter wave to do
>whatever
>they need to do.  Maybe creative marketing.  Let's face it, most big ISPs
>now sell best effort speeds.  Well, to residential.  Businesses may still
>expect to actually get what they were promised and maybe even to actually
>use it.
>
>-Original Message-
>From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
>Sent: Thursday, October 27, 2016 11:32 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>But how about microwave to the home?  That is what people expect when they
>hear Google is coming to town.  GigE to the home.  I think the MTU market
>may eventually struggle with getting enough BW via microwave as well.
>With
>an apartment building with 250 people all expecting a gig, hard to do with
>microwave.
>
>-Original Message-
>From: Ken Hohhof
>Sent: Thursday, October 27, 2016 10:27 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>Microwave to MTU/MDU rooftop.  Proven business model.  Ask Teligent,
>Winstar, Nextlink.  In fairness, now almost 20 years later, there is more
>demand for what they are selling.  But also more competition.
>
>And it's not like nobody is doing this already.  Like in Chicago SilverIP
>comes to mind.
>
>
>-Original Message-
>From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
>Sent: Thursday, October 27, 2016 11:05 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>I predict the PhD syndrome is going to also affect the wireless end.
>Vivant
>tried and failed.
>
>30 somethings that slept through physics are going to run up against the
>hard limits of trees, hills and rain.
>
>Doesn't matter how crazy the radio is, they will learn as everyone that
>tries RF distribution learns.
>
>5 years they will be back to fiber.  Or deciding not to be part of the
>transport solution.
>
>-Original Message-
>From: Robert
>Sent: Thursday, October 27, 2016 7:49 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>Phd syndrome...  Getting an advanced degree at a big Uni gives you
>almost zero experience in the trenches...   The move to wireless means
>that they can buy their way into the FCC and move down from there...
>
>On 10/27/16 6:40 AM, Brian Webster wrote:
>> I worked directly on the San Jose and Sand Diego projects. I was
>> brought in by one of the main contractors to help reduce costs and
>> increase efficiency. Google had way too many ï¿1Ž230 somethingsï¿1Ž2 who
>> failed to listen to experienced telecom professionals. That was one of
>> their biggest faults. It was insane to try and build a network in San
>> Jose that was going to have to be built mostly underground. That
>> market already had new AT&T U-verse fiber and Time Warner with a very
>> strong network. Heck I could get 100 meg speeds on Wi-Fi at the hotel
>> I stayed in. Their Ego to build in their own backyard was pushing the
>> build more than anything.
>>
>>
>>
>> The concept of cherry picking neighborhoods actually drove costs up.
>> When they wanted a citywide network design, that is what they were
>> delivered, but then try and build out only neighborhoods they wanted
>> while still trying to figure out how much of their backbones, huts and
>> neighborhood distribution system needed to be put in place to service
>> the piecemeal buildout approach, when you were already having to open
>> ditches, while having to be a mostly underground build? Yea that was a
>> nightmare too! Then letï¿1Ž2s talk about how they had no clue how hard
>> the MDU market is to secure. They gave no real consideration to
>> existing deals in the buildings, or the cost of having to wire on
>> their own because the building owner did not actually own the existing
>> cable plant and such. These projects were not just a simple math
>> problem
>to solve.
>>
>>
>>
>> They naively thought every city was going to welcome them with open
>> arms like Kansas City did. They believed the political hype the
>> politicians told them to lure them to their cities, then when actual
>> laws both of physics and real came in to play, the numbers looked a
>> whole
>lot uglier.
>> Underground building in established cities is a nightmare in both
>> costs, regulations, logistics and amount 

Re: [AFMUG] SNMP v1 Ubiquiti?

[Mike Hammett]

I saw that somewhere recently... maybe in #LibreNMS? I haven't had a chance to 
confirm. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Paul Stewart"  
To: "Animal Farm"  
Sent: Thursday, October 27, 2016 12:26:26 PM 
Subject: [AFMUG] SNMP v1 Ubiquiti? 

I’m involved with a project to provide better visibility into our UBNT 
deployments and just realized that, so far, their equipment only supports SNMP 
v1? Is this right? 

Example is a AirFiber 24Ghz link that I’m testing against right now 

If correct …. ummm… wow! 

Thanks, 
Paul 

Re: [AFMUG] SNMP v1 Ubiquiti?

[George Skorup]

And you need v2c for 64-bit interface counters. On an airFiber though, 
does it really matter? Doesn't bother me, I monitor the router/switch 
port for traffic anyway.


On 10/27/2016 12:26 PM, Paul Stewart wrote:

I’m involved with a project to provide better visibility into our UBNT 
deployments and just realized that, so far, their equipment only supports SNMP 
v1?  Is this right?

Example is a AirFiber 24Ghz link that I’m testing against right now

If correct …. ummm… wow!

Thanks,
Paul

Re: [AFMUG] Google Fiber is no more

[Ken Hohhof]

Yes, but isn’t Webpass new enough at the wireless-to-a-building thing that they 
haven’t really tested what happens when adoption goes over the first handful of 
customers within the building?

 

Also, it looks like they sell 100M, 200M, 500M and 1G service, and define speed 
as upload+download on a symmetric service, so 1G would actually be 500M 
symmetric?

 

I’m also a bit confused about their pricing, they list $60/mo, and then the 
different speeds, so is that the price for the lowest speed?  Seems like some 
creative marketing is involved.

 

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Gino Villarini
Sent: Thursday, October 27, 2016 12:25 PM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

 

Webpass? that¹s the reason they bought it! Proven business model operating
in top cities

On 10/27/16, 12:27 PM, "Af on behalf of Ken Hohhof" mailto:af...@kwisp.com> > wrote:

>Microwave to MTU/MDU rooftop.  Proven business model.  Ask Teligent,
>Winstar, Nextlink.  In fairness, now almost 20 years later, there is more
>demand for what they are selling.  But also more competition.
>
>And it's not like nobody is doing this already.  Like in Chicago SilverIP
>comes to mind.
>
>
>-Original Message-
>From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
>Sent: Thursday, October 27, 2016 11:05 AM
>To: af@afmug.com  
>Subject: Re: [AFMUG] Google Fiber is no more
>
>I predict the PhD syndrome is going to also affect the wireless end.
>Vivant
>tried and failed.
>
>30 somethings that slept through physics are going to run up against the
>hard limits of trees, hills and rain.
>
>Doesn't matter how crazy the radio is, they will learn as everyone that
>tries RF distribution learns.
>
>5 years they will be back to fiber.  Or deciding not to be part of the
>transport solution.
>
>-Original Message-
>From: Robert
>Sent: Thursday, October 27, 2016 7:49 AM
>To: af@afmug.com  
>Subject: Re: [AFMUG] Google Fiber is no more
>
>Phd syndrome...  Getting an advanced degree at a big Uni gives you
>almost zero experience in the trenches...   The move to wireless means
>that they can buy their way into the FCC and move down from there...
>
>On 10/27/16 6:40 AM, Brian Webster wrote:
>> I worked directly on the San Jose and Sand Diego projects. I was
>> brought in by one of the main contractors to help reduce costs and
>> increase efficiency. Google had way too many ï¿1Ž230 somethingsï¿1Ž2 who
>> failed to listen to experienced telecom professionals. That was one of
>> their biggest faults. It was insane to try and build a network in San
>> Jose that was going to have to be built mostly underground. That
>> market already had new AT&T U-verse fiber and Time Warner with a very
>> strong network. Heck I could get 100 meg speeds on Wi-Fi at the hotel
>> I stayed in. Their Ego to build in their own backyard was pushing the
>> build more than anything.
>>
>>
>>
>> The concept of cherry picking neighborhoods actually drove costs up.
>> When they wanted a citywide network design, that is what they were
>> delivered, but then try and build out only neighborhoods they wanted
>> while still trying to figure out how much of their backbones, huts and
>> neighborhood distribution system needed to be put in place to service
>> the piecemeal buildout approach, when you were already having to open
>> ditches, while having to be a mostly underground build? Yea that was a
>> nightmare too! Then letï¿1Ž2s talk about how they had no clue how hard
>> the MDU market is to secure. They gave no real consideration to
>> existing deals in the buildings, or the cost of having to wire on
>> their own because the building owner did not actually own the existing
>> cable plant and such. These projects were not just a simple math problem
>to solve.
>>
>>
>>
>> They naively thought every city was going to welcome them with open
>> arms like Kansas City did. They believed the political hype the
>> politicians told them to lure them to their cities, then when actual
>> laws both of physics and real came in to play, the numbers looked a
>>whole
>lot uglier.
>> Underground building in established cities is a nightmare in both
>> costs, regulations, logistics and amount of work required. Just simple
>> things like trying to gather data on all the existing underground
>> infrastructure (that has no central source of documentation) was
>> painful and costly. You canï¿1Ž2t get drawings approved without first
>> showing you will not be interfering with existing utilities already
>> underground. In many cases you have to manually locate this stuff and
>> then map it and then do your design around that information. Other
>> issues to overhead builds were poles that would not pass loading
>> calculations, pole owners who were less than cooperative or that
>> pulled out new loading rules that they themselves donï¿1Ž2t follow and
>> you can see where it was not a simple process. The employ

Re: [AFMUG] Google Fiber is no more

[Gino Villarini]

They offer $60 symetric best effort,  some bldgs is up to 500 mbps or up to 1 
Gig depending on the backhaul they have in place

From: Af mailto:af-boun...@afmug.com>> on behalf of Ken 
Hohhof mailto:af...@kwisp.com>>
Reply-To: "af@afmug.com" 
mailto:af@afmug.com>>
Date: Thursday, October 27, 2016 at 1:37 PM
To: "af@afmug.com" mailto:af@afmug.com>>
Subject: Re: [AFMUG] Google Fiber is no more

Yes, but isn’t Webpass new enough at the wireless-to-a-building thing that they 
haven’t really tested what happens when adoption goes over the first handful of 
customers within the building?

Also, it looks like they sell 100M, 200M, 500M and 1G service, and define speed 
as upload+download on a symmetric service, so 1G would actually be 500M 
symmetric?

I’m also a bit confused about their pricing, they list $60/mo, and then the 
different speeds, so is that the price for the lowest speed?  Seems like some 
creative marketing is involved.


From: Af [mailto:af-boun...@afmug.com] On Behalf Of Gino Villarini
Sent: Thursday, October 27, 2016 12:25 PM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Webpass? that¹s the reason they bought it! Proven business model operating
in top cities

On 10/27/16, 12:27 PM, "Af on behalf of Ken Hohhof" 
mailto:af-boun...@afmug.com>



Gino Villarini

President

Metro Office Park #18 Suite 304 Guaynabo, Puerto Rico 00968


[cid:image001.png@01D2304E.DE173190]
on behalf of af...@kwisp.com> wrote:

>Microwave to MTU/MDU rooftop.  Proven business model.  Ask Teligent,
>Winstar, Nextlink.  In fairness, now almost 20 years later, there is more
>demand for what they are selling.  But also more competition.
>
>And it's not like nobody is doing this already.  Like in Chicago SilverIP
>comes to mind.
>
>



Gino Villarini


President
Metro Office Park #18 Suite 304 Guaynabo, Puerto Rico 00968

[cid:aeronet-logo_310cfc3e-6691-4f69-bd49-b37b834b9238.png]

>-Original Message-
>From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
>Sent: Thursday, October 27, 2016 11:05 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>I predict the PhD syndrome is going to also affect the wireless end.
>Vivant
>tried and failed.
>
>30 somethings that slept through physics are going to run up against the
>hard limits of trees, hills and rain.
>
>Doesn't matter how crazy the radio is, they will learn as everyone that
>tries RF distribution learns.
>
>5 years they will be back to fiber.  Or deciding not to be part of the
>transport solution.
>
>-Original Message-
>From: Robert
>Sent: Thursday, October 27, 2016 7:49 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>Phd syndrome...  Getting an advanced degree at a big Uni gives you
>almost zero experience in the trenches...   The move to wireless means
>that they can buy their way into the FCC and move down from there...
>
>On 10/27/16 6:40 AM, Brian Webster wrote:
>> I worked directly on the San Jose and Sand Diego projects. I was
>> brought in by one of the main contractors to help reduce costs and
>> increase efficiency. Google had way too many ï¿1Ž230 somethingsï¿1Ž2 who
>> failed to listen to experienced telecom professionals. That was one of
>> their biggest faults. It was insane to try and build a network in San
>> Jose that was going to have to be built mostly underground. That
>> market already had new AT&T U-verse fiber and Time Warner with a very
>> strong network. Heck I could get 100 meg speeds on Wi-Fi at the hotel
>> I stayed in. Their Ego to build in their own backyard was pushing the
>> build more than anything.
>>
>>
>>
>> The concept of cherry picking neighborhoods actually drove costs up.
>> When they wanted a citywide network design, that is what they were
>> delivered, but then try and build out only neighborhoods they wanted
>> while still trying to figure out how much of their backbones, huts and
>> neighborhood distribution system needed to be put in place to service
>> the piecemeal buildout approach, when you were already having to open
>> ditches, while having to be a mostly underground build? Yea that was a
>> nightmare too! Then letï¿1Ž2s talk about how they had no clue how hard
>> the MDU market is to secure. They gave no real consideration to
>> existing deals in the buildings, or the cost of having to wire on
>> their own because the building owner did not actually own the existing
>> cable plant and such. These projects were not just a simple math problem
>to solve.
>>
>>
>>
>> They naively thought every city was going to welcome them with open
>> arms like Kansas City did. They believed the political hype the
>> politicians told them to lure them to their cities, then when actual
>> laws both of physics and real came in to play, the numbers looked a
>>whole
>lot uglier.
>> Underground building in established cities is a night

Re: [AFMUG] SNMP v1 Ubiquiti?

[Paul Stewart]

We want to monitor the radios themselves and I was just shocked at the v1 
support on a device that is “powered by linux” ….

But yes, I’d like to track several things on these radios including throughput, 
SNR etc .. I’m just starting to look at MIB support now - one example would be 
tracking what the radio link is capable of (speed wise) which without 64 bit 
counters is going to be a real problem 


> On Oct 27, 2016, at 1:36 PM, George Skorup  wrote:
> 
> And you need v2c for 64-bit interface counters. On an airFiber though, does 
> it really matter? Doesn't bother me, I monitor the router/switch port for 
> traffic anyway.
> 
> On 10/27/2016 12:26 PM, Paul Stewart wrote:
>> I’m involved with a project to provide better visibility into our UBNT 
>> deployments and just realized that, so far, their equipment only supports 
>> SNMP v1?  Is this right?
>> 
>> Example is a AirFiber 24Ghz link that I’m testing against right now
>> 
>> If correct …. ummm… wow!
>> 
>> Thanks,
>> Paul
>> 
> 

Re: [AFMUG] SNMP v1 Ubiquiti?

[George Skorup]

You mean like this?



On 10/27/2016 1:01 PM, Paul Stewart wrote:

We want to monitor the radios themselves and I was just shocked at the v1 
support on a device that is “powered by linux” ….

But yes, I’d like to track several things on these radios including throughput, 
SNR etc .. I’m just starting to look at MIB support now - one example would be 
tracking what the radio link is capable of (speed wise) which without 64 bit 
counters is going to be a real problem



On Oct 27, 2016, at 1:36 PM, George Skorup  wrote:

And you need v2c for 64-bit interface counters. On an airFiber though, does it 
really matter? Doesn't bother me, I monitor the router/switch port for traffic 
anyway.

On 10/27/2016 12:26 PM, Paul Stewart wrote:

I’m involved with a project to provide better visibility into our UBNT 
deployments and just realized that, so far, their equipment only supports SNMP 
v1?  Is this right?

Example is a AirFiber 24Ghz link that I’m testing against right now

If correct …. ummm… wow!

Thanks,
Paul

Re: [AFMUG] SNMP v1 Ubiquiti?

[Josh Reynolds]

I would consider using firmware that supports persistence. (Contact UBNT).
Then write a simple scraper agent.

On Oct 27, 2016 1:01 PM, "Paul Stewart"  wrote:

We want to monitor the radios themselves and I was just shocked at the v1
support on a device that is “powered by linux” ….

But yes, I’d like to track several things on these radios including
throughput, SNR etc .. I’m just starting to look at MIB support now - one
example would be tracking what the radio link is capable of (speed wise)
which without 64 bit counters is going to be a real problem


> On Oct 27, 2016, at 1:36 PM, George Skorup  wrote:
>
> And you need v2c for 64-bit interface counters. On an airFiber though,
does it really matter? Doesn't bother me, I monitor the router/switch port
for traffic anyway.
>
> On 10/27/2016 12:26 PM, Paul Stewart wrote:
>> I’m involved with a project to provide better visibility into our UBNT
deployments and just realized that, so far, their equipment only supports
SNMP v1?  Is this right?
>>
>> Example is a AirFiber 24Ghz link that I’m testing against right now
>>
>> If correct …. ummm… wow!
>>
>> Thanks,
>> Paul
>>
>

Re: [AFMUG] Google Fiber is no more

[Seth Mattinen]

On 10/27/16 10:37, Ken Hohhof wrote:

Yes, but isn’t Webpass new enough at the wireless-to-a-building thing
that they haven’t really tested what happens when adoption goes over the
first handful of customers within the building?



Webpass has been doing the building MDU thing via microwave for at least 
a decade before Google came along and bought them. Maximum speed 
depended on the backhaul to the building you were in and what everyone 
else was doing at the moment in your building.


~Seth

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Chuck McCown]

What we all need, is a low cost solution to stop needing more V4 IPs.  

If it is CGN at the edge with a limited pool of V4, so be it.  

But I want a solid solution that can be trusted.
And I want and expert to come drop it into my company.  

From: Paul Stewart 
Sent: Thursday, October 27, 2016 11:23 AM
To: af@afmug.com 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt

while I’m not a fan of NAT64, CGN etc (but understand in some situations the 
need for it), I completely agree that companies will be looking for consultants 
to help with this in some scenarios (both large and small companies alike) - 
this has been ongoing in some larger companies for many years already (IPv6 
adoption) and often through resident engineer placements from vendors  


  On Oct 27, 2016, at 11:59 AM, Chuck McCown  wrote:

  Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc.  
  We all need this or will need this.  

  From: Faisal Imtiaz 
  Sent: Wednesday, October 26, 2016 8:31 PM
  To: af 
  Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

  An excellent detailed solution  (from one of the other forums).

  Faisal Imtiaz
  Snappy Internet & Telecom
  7266 SW 48 Street
  Miami, FL 33155
  Tel: 305 663 5518 x 232

  Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net


--

From: "Tim Way" 
To: "WISPA General List" 
Sent: Tuesday, October 25, 2016 9:01:51 PM
Subject: Re: [WISPA] IPV6 deploymernt

Art,

So I know of two solid methods that could solve your problem. Neither are 
super awesome and both would involve NAT.

1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only 
connectivity
2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, and IPv6 Global 
Unicast running in Dual Stack

Either one would work. I apologize in advance for the long post that 
follows.

I've only done the configurations on Cisco routers with the radios just 
passing traffic at layer 2. I'd have to check the feature set of your routers 
routing wise but it shouldn't be hard. It also could be built in a lab with 
static routing largely. I think Mikrotik supports NAT64 but again for a lab 
environment any recent Cisco device could be used with IP Services licensing.

Your address plan for your global unicast IPv6 space comes into play. This 
is how I would lab it up including moving routing to the tower with the CPE in 
bridge mode:

Your fictional IPv6 prefix: :::/32

Your NAT64 Prefix: ::cc00::/96

Customer DHCPv6-PD Allocation Prefix: ::aa00::/40

Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
Your fictional customer #2: The Billings' Family, ::aa00:0200::/56

Fictional Tower 1
ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
ISP Router at the tower on VLAN 12: ::bb00:0012::1/64


The Johnson Family Setup:
ISP CPE VLAN 11 IP: ::bb00:0011::f/64
Customer's Netgear WAN Interface: ::bb00:0012::f/64
Customer's Netgear LAN Interface: ::aa00:010a::1/64
Customer's Netgear Guest WiFi: ::aa00:010b::1/64

The Billings' Family Setup:

ISP CPE VLAN 11 IP: ::bb00:0011::e/64
Customer's Netgear WAN Interface: ::bb00:0012::e/64
Customer's Netgear LAN Interface: ::aa00:020a::1/64
Customer's Netgear Guest WiFi: ::aa00:020b::1/64

1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the 
native VLAN and put the IP on VLAN 11.
2. If you use static routing and manual address assignment to eliminate 
variables in the lab you'll want to add static routes on the tower router for 
the ::/56 prefixes that would be allocated to each customer. Normally these 
routes will be injected into the routing table at the DHCPv6 router and could 
be distributed from there.
3. The last piece of the puzzle will be adding in the NAT64 and DNS64 
devices. BIND can do DNS64 and you could use a Cisco router to do the NAT64. 
You'd want the "Customer's Netgear" to use the DNS64 server as it's upstream 
DNS server to ensure that it receives  records for sites that only have A 
records. This is the fragile component of the DNS64 and NAT64 deployment 
because it requires the customers computer or router uses your resolver. You 
will want to ensure the router performing NAT64 is advertising the prefix it is 
using for NAT64 into your IGP or that your default routed traffic lands on that 
NAT64 to ensure it is routed correctly.

This should get you a functional IPv6 only customer network that only 
returns  records for all DNS requests. It's a little late so I apologize 
for any mistakes in the addressing. Also I will think about doing 

Re: [AFMUG] Google Fiber is no more

[Chuck McCown]

What are you using for customer control and rate limiting?  I know Netonix 
works well for smaller deployments.  
What ring protocol are you using?

From: Gino Villarini 
Sent: Thursday, October 27, 2016 11:27 AM
To: af@afmug.com 
Subject: Re: [AFMUG] Google Fiber is no more

Ken, we have been doing MDUs in PR and FL for about 18 months now. WE are
using AF24 units to each bldg in a ring format with no more of 10 blds in
the ring. Endpoints are fiber pops.  WE sell up to 500 Mbps, usage is in
resitential ins avg 25-30 mbs, we only see 500 mbps whrn they go to the
speed tests sites.

On 10/27/16, 12:47 PM, "Af on behalf of Ken Hohhof"  wrote:

>The way I read their change in direction is they are focusing now on high
>rise apartment and office buildings where they can beam bandwidth to the
>rooftop.  No more gigabit to individual homes.  Not a Vivint play.  Maybe
>I'm wrong.
>
>As far as 250 people all expecting a gig, not sure what they are planning.
>Maybe they figure there's enough spectrum in millimeter wave to do
>whatever
>they need to do.  Maybe creative marketing.  Let's face it, most big ISPs
>now sell best effort speeds.  Well, to residential.  Businesses may still
>expect to actually get what they were promised and maybe even to actually
>use it.
>
>-Original Message-
>From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
>Sent: Thursday, October 27, 2016 11:32 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>But how about microwave to the home?  That is what people expect when they
>hear Google is coming to town.  GigE to the home.  I think the MTU market
>may eventually struggle with getting enough BW via microwave as well.
>With
>an apartment building with 250 people all expecting a gig, hard to do with
>microwave.
>
>-Original Message-
>From: Ken Hohhof
>Sent: Thursday, October 27, 2016 10:27 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>Microwave to MTU/MDU rooftop.  Proven business model.  Ask Teligent,
>Winstar, Nextlink.  In fairness, now almost 20 years later, there is more
>demand for what they are selling.  But also more competition.
>
>And it's not like nobody is doing this already.  Like in Chicago SilverIP
>comes to mind.
>
>
>-Original Message-
>From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
>Sent: Thursday, October 27, 2016 11:05 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>I predict the PhD syndrome is going to also affect the wireless end.
>Vivant
>tried and failed.
>
>30 somethings that slept through physics are going to run up against the
>hard limits of trees, hills and rain.
>
>Doesn't matter how crazy the radio is, they will learn as everyone that
>tries RF distribution learns.
>
>5 years they will be back to fiber.  Or deciding not to be part of the
>transport solution.
>
>-Original Message-
>From: Robert
>Sent: Thursday, October 27, 2016 7:49 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>Phd syndrome...  Getting an advanced degree at a big Uni gives you
>almost zero experience in the trenches...   The move to wireless means
>that they can buy their way into the FCC and move down from there...
>
>On 10/27/16 6:40 AM, Brian Webster wrote:
>> I worked directly on the San Jose and Sand Diego projects. I was
>> brought in by one of the main contractors to help reduce costs and
>> increase efficiency. Google had way too many ï¿1Ž230 somethingsï¿1Ž2 who
>> failed to listen to experienced telecom professionals. That was one of
>> their biggest faults. It was insane to try and build a network in San
>> Jose that was going to have to be built mostly underground. That
>> market already had new AT&T U-verse fiber and Time Warner with a very
>> strong network. Heck I could get 100 meg speeds on Wi-Fi at the hotel
>> I stayed in. Their Ego to build in their own backyard was pushing the
>> build more than anything.
>>
>>
>>
>> The concept of cherry picking neighborhoods actually drove costs up.
>> When they wanted a citywide network design, that is what they were
>> delivered, but then try and build out only neighborhoods they wanted
>> while still trying to figure out how much of their backbones, huts and
>> neighborhood distribution system needed to be put in place to service
>> the piecemeal buildout approach, when you were already having to open
>> ditches, while having to be a mostly underground build? Yea that was a
>> nightmare too! Then letï¿1Ž2s talk about how they had no clue how hard
>> the MDU market is to secure. They gave no real consideration to
>> existing deals in the buildings, or the cost of having to wire on
>> their own because the building owner did not actually own the existing
>> cable plant and such. These projects were not just a simple math
>> problem
>to solve.
>>
>>
>>
>> They naively thought every city was going to welcome them with open
>> arms like Kansas City did. They believed the political hype the
>

Re: [AFMUG] Microsoft Store DNS

[Mike Hammett]

You can't sysprep a machine that has had Windows Store application updates. The 
rest of the computer is fine to be on the Internet and updated. 

I know how the content is distributed, just not the FQDN they check for the 
store. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Paul Stewart"  
To: af@afmug.com 
Sent: Thursday, October 27, 2016 10:26:26 AM 
Subject: Re: [AFMUG] Microsoft Store DNS 

Gotta ask… why would you want to block application updates? 

Also, I don’t know specifically with “Microsoft Store” itself but Microsoft 
product updates are typically done via CDN’s depending your geographic location 
.. some via their own network but a lot of it done via Akamai for example 


> On Oct 27, 2016, at 11:00 AM, Mike Hammett  wrote: 
> 
> Do any of you know what DNS the Microsoft store users? I need to block access 
> to the Microsoft store to prevent application updates. Blocking access to it 
> through layer 7 inspection of DNS would seem to be the most effective. 
> 
> -Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
> Brothers WISP 
> 
> 

[AFMUG] FYI Cambium PTP doesn't sync with PMP

[Jon Langeler]

I don't think their support department understands the concept of sync. But as 
of now we have given up on PTP products syncing 100% with PMP products. Oh well 

Jon Langeler
Michwave Technologies, Inc.

Re: [AFMUG] Microsoft Store DNS

[Mike Hammett]

Sorry, Windows Store is the official name. It made its debut in Windows 8 as a 
place to get apps. 

No, I don't mean Microsoft Updates. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Ken Hohhof"  
To: af@afmug.com 
Sent: Thursday, October 27, 2016 10:26:49 AM 
Subject: Re: [AFMUG] Microsoft Store DNS 

Define "Microsoft Store". Do they have an app store like Google Play and 
iTunes? I think of Microsoft Store as an online and bricks-and-mortar store 
that sells stuff like computers, I'm sure they sell software like Office 365 as 
well. I am typing on a Dell laptop I bought at the Microsoft Store in Oakbrook 
Mall, pretty much a clone of an Apple Store. 

If you mean where do Windows Updates come from, sometimes 
download.windowsupdate.com, sometimes not. 


-Original Message- 
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Mike Hammett 
Sent: Thursday, October 27, 2016 10:06 AM 
To: af@afmug.com 
Subject: Re: [AFMUG] Microsoft Store DNS 

I worded that poorly. I should have asked what FQDN it uses. 

-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
Brothers WISP 




- Original Message - 
From: That One Guy /sarcasm  
To: af@afmug.com 
Sent: Thu, 27 Oct 2016 10:03:58 -0500 (CDT) 
Subject: Re: [AFMUG] Microsoft Store DNS 

It wont revert back to the local DNS? 

On Thu, Oct 27, 2016 at 10:00 AM, Mike Hammett  wrote: 

> Do any of you know what DNS the Microsoft store users? I need to block 
> access to the Microsoft store to prevent application updates. Blocking 
> access to it through layer 7 inspection of DNS would seem to be the 
> most effective. 
> 
> -Mike HammettIntelligent Computing SolutionsMidwest Internet 
> ExchangeThe Brothers WISP 
> 
> 
> 


-- 
If you only see yourself as part of the team but you don't see your team as 
part of yourself you have already failed as part of the team. 

Re: [AFMUG] FYI Cambium PTP doesn't sync with PMP

[Josh Luthman]

I don't believe they're supposed to, assuming ptp650?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Oct 27, 2016 2:37 PM, "Jon Langeler"  wrote:

> I don't think their support department understands the concept of sync.
> But as of now we have given up on PTP products syncing 100% with PMP
> products. Oh well
>
> Jon Langeler
> Michwave Technologies, Inc.
>
>

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Dennis Burgess]

You can do quite a bit using MTs, just not as “simple” and logging stinks.  You 
can do it easily enough.  Just not in a “automated” way.



Dennis Burgess – Network Solution Engineer – Consultant
MikroTik Certified 
Trainer/Consultant
 – MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE

For Wireless Hardware/Routers visit www.linktechs.net
Radio Frequiency Coverages: www.towercoverage.com
Office: 314-735-0270
E-Mail: dmburg...@linktechs.net

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
Sent: Thursday, October 27, 2016 1:27 PM
To: af@afmug.com
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt

What we all need, is a low cost solution to stop needing more V4 IPs.

If it is CGN at the edge with a limited pool of V4, so be it.

But I want a solid solution that can be trusted.
And I want and expert to come drop it into my company.

From: Paul Stewart
Sent: Thursday, October 27, 2016 11:23 AM
To: af@afmug.com
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt

while I’m not a fan of NAT64, CGN etc (but understand in some situations the 
need for it), I completely agree that companies will be looking for consultants 
to help with this in some scenarios (both large and small companies alike) - 
this has been ongoing in some larger companies for many years already (IPv6 
adoption) and often through resident engineer placements from vendors


On Oct 27, 2016, at 11:59 AM, Chuck McCown 
mailto:ch...@wbmfg.com>> wrote:

Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc.
We all need this or will need this.

From: Faisal Imtiaz
Sent: Wednesday, October 26, 2016 8:31 PM
To: af
Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

An excellent detailed solution  (from one of the other forums).

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: 
supp...@snappytelecom.net


From: "Tim Way" mailto:t...@way.vg>>
To: "WISPA General List" mailto:wirel...@wispa.org>>
Sent: Tuesday, October 25, 2016 9:01:51 PM
Subject: Re: [WISPA] IPV6 deploymernt
Art,
So I know of two solid methods that could solve your problem. Neither are super 
awesome and both would involve NAT.

1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only connectivity
2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, 
and IPv6 Global Unicast running in Dual Stack

Either one would work. I apologize in advance for the long post that follows.

I've only done the configurations on Cisco routers with the radios just passing 
traffic at layer 2. I'd have to check the feature set of your routers routing 
wise but it shouldn't be hard. It also could be built in a lab with static 
routing largely. I think Mikrotik supports NAT64 but again for a lab 
environment any recent Cisco device could be used with IP Services licensing.

Your address plan for your global unicast IPv6 space comes into play. This is 
how I would lab it up including moving routing to the tower with the CPE in 
bridge mode:

Your fictional IPv6 prefix: :::/32

Your NAT64 Prefix: ::cc00::/96

Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
Your fictional customer #2: The Billings' Family, ::aa00:0200::/56

Fictional Tower 1
ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
ISP Router at the tower on VLAN 12: ::bb00:0012::1/64

The Johnson Family Setup:
ISP CPE VLAN 11 IP: ::bb00:0011::f/64
Customer's Netgear WAN Interface: ::bb00:0012::f/64
Customer's Netgear LAN Interface: ::aa00:010a::1/64
Customer's Netgear Guest WiFi: ::aa00:010b::1/64

The Billings' Family Setup:
ISP CPE VLAN 11 IP: ::bb00:0011::e/64
Customer's Netgear WAN Interface: ::bb00:0012::e/64
Customer's Netgear LAN Interface: ::aa00:020a::1/64
Customer's Netgear Guest WiFi: ::aa00:020b::1/64

1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the 
native VLAN and put the IP on VLAN 11.
2. If you use static routing and manual address assignment to eliminate 
variables in the lab you'll want to add static routes on the tower router for 
the ::/56 prefixes that would be allocated to each customer. Normally these 
routes will be injected into the routing table at the DHCPv6 router and could 
be distributed from there.
3. The last piece of the puzzle will be adding in the NAT64 and DNS64 devices. 
BIND can do DNS64 and you could use a Cisco router to do the NAT64. You'd want 
the "Customer's Netgear" to use the DNS64 ser

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Paul Stewart]

Actually in my opinion what we need is better IPv6 adoption in general and this 
becomes a non-problem quickly :)

I know .. good theory … and “we” are getting better though …. a lot of 
providers have gotten their heads out of the clouds in the past few years alone 
….


> On Oct 27, 2016, at 2:26 PM, Chuck McCown  wrote:
> 
> What we all need, is a low cost solution to stop needing more V4 IPs. 
>  
> If it is CGN at the edge with a limited pool of V4, so be it. 
>  
> But I want a solid solution that can be trusted.
> And I want and expert to come drop it into my company. 
>  
> From: Paul Stewart <>
> Sent: Thursday, October 27, 2016 11:23 AM
> To: af@afmug.com <>
> Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt
>  
> while I’m not a fan of NAT64, CGN etc (but understand in some situations the 
> need for it), I completely agree that companies will be looking for 
> consultants to help with this in some scenarios (both large and small 
> companies alike) - this has been ongoing in some larger companies for many 
> years already (IPv6 adoption) and often through resident engineer placements 
> from vendors 
>  
>  
>> On Oct 27, 2016, at 11:59 AM, Chuck McCown > wrote:
>>  
>> Some consultant needs to specialize in this and help folks provision, 
>> configure, deploy, test etc. 
>> We all need this or will need this. 
>>  
>> From: Faisal Imtiaz <>
>> Sent: Wednesday, October 26, 2016 8:31 PM
>> To: af <>
>> Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt
>>  
>> An excellent detailed solution  (from one of the other forums).
>>  
>> Faisal Imtiaz
>> Snappy Internet & Telecom
>> 7266 SW 48 Street
>> Miami, FL 33155
>> Tel: 305 663 5518 x 232
>> 
>> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net <>
>>  
>>> From: "Tim Way" >
>>> To: "WISPA General List" >
>>> Sent: Tuesday, October 25, 2016 9:01:51 PM
>>> Subject: Re: [WISPA] IPV6 deploymernt
>> 
>>> Art,
>>> So I know of two solid methods that could solve your problem. Neither are 
>>> super awesome and both would involve NAT.
>>>  
>>> 1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only 
>>> connectivity
>>> 2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10 
>>> , and IPv6 Global Unicast running in Dual Stack
>>>  
>>> Either one would work. I apologize in advance for the long post that 
>>> follows.
>>>  
>>> I've only done the configurations on Cisco routers with the radios just 
>>> passing traffic at layer 2. I'd have to check the feature set of your 
>>> routers routing wise but it shouldn't be hard. It also could be built in a 
>>> lab with static routing largely. I think Mikrotik supports NAT64 but again 
>>> for a lab environment any recent Cisco device could be used with IP 
>>> Services licensing.
>>>  
>>> Your address plan for your global unicast IPv6 space comes into play. This 
>>> is how I would lab it up including moving routing to the tower with the CPE 
>>> in bridge mode:
>>>  
>>> Your fictional IPv6 prefix: :::/32
>>>  
>>> Your NAT64 Prefix: ::cc00::/96
>>>  
>>> Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
>>> Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
>>> Your fictional customer #2: The Billings' Family, ::aa00:0200::/56
>>>  
>>> Fictional Tower 1
>>> ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
>>> ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
>>> ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
>>> ISP Router at the tower on VLAN 12: ::bb00:0012::1/64
>>>  
>>> The Johnson Family Setup:
>>> ISP CPE VLAN 11 IP: ::bb00:0011::f/64
>>> Customer's Netgear WAN Interface: ::bb00:0012::f/64
>>> Customer's Netgear LAN Interface: ::aa00:010a::1/64
>>> Customer's Netgear Guest WiFi: ::aa00:010b::1/64
>>>  
>>> The Billings' Family Setup:
>>> ISP CPE VLAN 11 IP: ::bb00:0011::e/64
>>> Customer's Netgear WAN Interface: ::bb00:0012::e/64
>>> Customer's Netgear LAN Interface: ::aa00:020a::1/64
>>> Customer's Netgear Guest WiFi: ::aa00:020b::1/64
>>>  
>>> 1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the 
>>> native VLAN and put the IP on VLAN 11.
>>> 2. If you use static routing and manual address assignment to eliminate 
>>> variables in the lab you'll want to add static routes on the tower router 
>>> for the ::/56 prefixes that would be allocated to each customer. Normally 
>>> these routes will be injected into the routing table at the DHCPv6 router 
>>> and could be distributed from there.
>>> 3. The last piece of the puzzle will be adding in the NAT64 and DNS64 
>>> devices. BIND can do DNS64 and you could use a Cisco router to do the 
>>> NAT64. You'd want the "Customer's Netgear" to use the DNS64 server as it's 
>>> upstream DNS server to ensure that it receives  records for sites that 
>>> only have A records. This is the fragile component of the DNS64 and NAT64 
>>> deploym

Re: [AFMUG] Google Fiber is no more

[Gino Villarini]

We rate limit at the procera. For ring we are using mstp, (small L2 rings, each 
mdu has a vlan that gets encasulated into a vpls once it hits the fiber node)

From: Af mailto:af-boun...@afmug.com>> on behalf of Chuck 
McCown mailto:ch...@wbmfg.com>>
Reply-To: "af@afmug.com" 
mailto:af@afmug.com>>
Date: Thursday, October 27, 2016 at 2:28 PM
To: "af@afmug.com" mailto:af@afmug.com>>
Subject: Re: [AFMUG] Google Fiber is no more




Gino Villarini


President
Metro Office Park #18 Suite 304 Guaynabo, Puerto Rico 00968

[cid:aeronet-logo_310cfc3e-6691-4f69-bd49-b37b834b9238.png]

What are you using for customer control and rate limiting?  I know Netonix 
works well for smaller deployments.
What ring protocol are you using?

From: Gino Villarini
Sent: Thursday, October 27, 2016 11:27 AM
To: af@afmug.com
Subject: Re: [AFMUG] Google Fiber is no more

Ken, we have been doing MDUs in PR and FL for about 18 months now. WE are
using AF24 units to each bldg in a ring format with no more of 10 blds in
the ring. Endpoints are fiber pops.  WE sell up to 500 Mbps, usage is in
resitential ins avg 25-30 mbs, we only see 500 mbps whrn they go to the
speed tests sites.

On 10/27/16, 12:47 PM, "Af on behalf of Ken Hohhof" 
mailto:af-boun...@afmug.com>



Gino Villarini


President
Metro Office Park #18 Suite 304 Guaynabo, Puerto Rico 00968

[cid:5CE2F7495C9B4D14AF40F62A14FB4FD0@ChuckMcCownPC]

on behalf of af...@kwisp.com> wrote:

>The way I read their change in direction is they are focusing now on high
>rise apartment and office buildings where they can beam bandwidth to the
>rooftop.  No more gigabit to individual homes.  Not a Vivint play.  Maybe
>I'm wrong.
>
>As far as 250 people all expecting a gig, not sure what they are planning.
>Maybe they figure there's enough spectrum in millimeter wave to do
>whatever
>they need to do.  Maybe creative marketing.  Let's face it, most big ISPs
>now sell best effort speeds.  Well, to residential.  Businesses may still
>expect to actually get what they were promised and maybe even to actually
>use it.
>
>-Original Message-
>From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
>Sent: Thursday, October 27, 2016 11:32 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>But how about microwave to the home?  That is what people expect when they
>hear Google is coming to town.  GigE to the home.  I think the MTU market
>may eventually struggle with getting enough BW via microwave as well.
>With
>an apartment building with 250 people all expecting a gig, hard to do with
>microwave.
>
>-Original Message-
>From: Ken Hohhof
>Sent: Thursday, October 27, 2016 10:27 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>Microwave to MTU/MDU rooftop.  Proven business model.  Ask Teligent,
>Winstar, Nextlink.  In fairness, now almost 20 years later, there is more
>demand for what they are selling.  But also more competition.
>
>And it's not like nobody is doing this already.  Like in Chicago SilverIP
>comes to mind.
>
>
>-Original Message-
>From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown
>Sent: Thursday, October 27, 2016 11:05 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>I predict the PhD syndrome is going to also affect the wireless end.
>Vivant
>tried and failed.
>
>30 somethings that slept through physics are going to run up against the
>hard limits of trees, hills and rain.
>
>Doesn't matter how crazy the radio is, they will learn as everyone that
>tries RF distribution learns.
>
>5 years they will be back to fiber.  Or deciding not to be part of the
>transport solution.
>
>-Original Message-
>From: Robert
>Sent: Thursday, October 27, 2016 7:49 AM
>To: af@afmug.com
>Subject: Re: [AFMUG] Google Fiber is no more
>
>Phd syndrome...  Getting an advanced degree at a big Uni gives you
>almost zero experience in the trenches...   The move to wireless means
>that they can buy their way into the FCC and move down from there...
>
>On 10/27/16 6:40 AM, Brian Webster wrote:
>> I worked directly on the San Jose and Sand Diego projects. I was
>> brought in by one of the main contractors to help reduce costs and
>> increase efficiency. Google had way too many ï¿1Ž230 somethingsï¿1Ž2 who
>> failed to listen to experienced telecom professionals. That was one of
>> their biggest faults. It was insane to try and build a network in San
>> Jose that was going to have to be built mostly underground. That
>> market already had new AT&T U-verse fiber and Time Warner with a very
>> strong network. Heck I could get 100 meg speeds on Wi-Fi at the hotel
>> I stayed in. Their Ego to build in their own backyard was pushing the
>> build more than anything.
>>
>>
>>
>> The concept of cherry picking neighborhoods actually drove costs up.
>> When they wanted a city

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Dennis Burgess]

I would totally agree here. We have deployed IPv6 quite a bit for clients, our 
networks etc.  However, the major issue is the hosting companies, most big 
guys, google, amazon, etc all support IPv6, heck even Sonar does now! Hahah, 
but until the cost of IPv4 addresses is so high that no one; even the major 
guys can afford it, IPv6 deployment will keep stalling.


Dennis Burgess – Network Solution Engineer – Consultant
MikroTik Certified 
Trainer/Consultant
 – MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE

For Wireless Hardware/Routers visit www.linktechs.net
Radio Frequiency Coverages: www.towercoverage.com
Office: 314-735-0270
E-Mail: dmburg...@linktechs.net

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Paul Stewart
Sent: Thursday, October 27, 2016 2:00 PM
To: af@afmug.com
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt

Actually in my opinion what we need is better IPv6 adoption in general and this 
becomes a non-problem quickly :)

I know .. good theory … and “we” are getting better though …. a lot of 
providers have gotten their heads out of the clouds in the past few years alone 
….


On Oct 27, 2016, at 2:26 PM, Chuck McCown 
mailto:ch...@wbmfg.com>> wrote:

What we all need, is a low cost solution to stop needing more V4 IPs.

If it is CGN at the edge with a limited pool of V4, so be it.

But I want a solid solution that can be trusted.
And I want and expert to come drop it into my company.

From: Paul Stewart
Sent: Thursday, October 27, 2016 11:23 AM
To: af@afmug.com
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt

while I’m not a fan of NAT64, CGN etc (but understand in some situations the 
need for it), I completely agree that companies will be looking for consultants 
to help with this in some scenarios (both large and small companies alike) - 
this has been ongoing in some larger companies for many years already (IPv6 
adoption) and often through resident engineer placements from vendors


On Oct 27, 2016, at 11:59 AM, Chuck McCown 
mailto:ch...@wbmfg.com>> wrote:

Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc.
We all need this or will need this.

From: Faisal Imtiaz
Sent: Wednesday, October 26, 2016 8:31 PM
To: af
Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

An excellent detailed solution  (from one of the other forums).

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: 
supp...@snappytelecom.net


From: "Tim Way" mailto:t...@way.vg>>
To: "WISPA General List" mailto:wirel...@wispa.org>>
Sent: Tuesday, October 25, 2016 9:01:51 PM
Subject: Re: [WISPA] IPV6 deploymernt
Art,
So I know of two solid methods that could solve your problem. Neither are super 
awesome and both would involve NAT.

1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only connectivity
2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, 
and IPv6 Global Unicast running in Dual Stack

Either one would work. I apologize in advance for the long post that follows.

I've only done the configurations on Cisco routers with the radios just passing 
traffic at layer 2. I'd have to check the feature set of your routers routing 
wise but it shouldn't be hard. It also could be built in a lab with static 
routing largely. I think Mikrotik supports NAT64 but again for a lab 
environment any recent Cisco device could be used with IP Services licensing.

Your address plan for your global unicast IPv6 space comes into play. This is 
how I would lab it up including moving routing to the tower with the CPE in 
bridge mode:

Your fictional IPv6 prefix: :::/32

Your NAT64 Prefix: ::cc00::/96

Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
Your fictional customer #2: The Billings' Family, ::aa00:0200::/56

Fictional Tower 1
ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
ISP Router at the tower on VLAN 12: ::bb00:0012::1/64

The Johnson Family Setup:
ISP CPE VLAN 11 IP: ::bb00:0011::f/64
Customer's Netgear WAN Interface: ::bb00:0012::f/64
Customer's Netgear LAN Interface: ::aa00:010a::1/64
Customer's Netgear Guest WiFi: ::aa00:010b::1/64

The Billings' Family Setup:
ISP CPE VLAN 11 IP: ::bb00:0011::e/64
Customer's Netgear WAN Interface: ::bb00:0012::e/64
Customer's Netgear LAN Interface: ::aa00:020a::1/64
Customer's Netgear Guest WiFi: ::aa00:020b::1/64

1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as the 
na

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Chuck McCown]

Costs are rising pretty fast.  But yeah, why change if you don’t have to.  So, 
Dennis, create V6 in a box that will allow us to assign only V6 to all new 
customers but will do the CGNAT for us at the edge for those times the 
customers have to visit V4 land.  

From: Dennis Burgess 
Sent: Thursday, October 27, 2016 1:12 PM
To: af@afmug.com 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt

I would totally agree here. We have deployed IPv6 quite a bit for clients, our 
networks etc.  However, the major issue is the hosting companies, most big 
guys, google, amazon, etc all support IPv6, heck even Sonar does now! Hahah, 
but until the cost of IPv4 addresses is so high that no one; even the major 
guys can afford it, IPv6 deployment will keep stalling.  

 

 

Dennis Burgess – Network Solution Engineer – Consultant 

MikroTik Certified Trainer/Consultant – MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE

 

For Wireless Hardware/Routers visit www.linktechs.net

Radio Frequiency Coverages: www.towercoverage.com 

Office: 314-735-0270

E-Mail: dmburg...@linktechs.net 

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Paul Stewart
Sent: Thursday, October 27, 2016 2:00 PM
To: af@afmug.com
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt

 

Actually in my opinion what we need is better IPv6 adoption in general and this 
becomes a non-problem quickly :)

 

I know .. good theory … and “we” are getting better though …. a lot of 
providers have gotten their heads out of the clouds in the past few years alone 
….

 

 

  On Oct 27, 2016, at 2:26 PM, Chuck McCown  wrote:

   

  What we all need, is a low cost solution to stop needing more V4 IPs.  

   

  If it is CGN at the edge with a limited pool of V4, so be it.  

   

  But I want a solid solution that can be trusted.

  And I want and expert to come drop it into my company.  

   

  From: Paul Stewart 

  Sent: Thursday, October 27, 2016 11:23 AM

  To: af@afmug.com 

  Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt

   

  while I’m not a fan of NAT64, CGN etc (but understand in some situations the 
need for it), I completely agree that companies will be looking for consultants 
to help with this in some scenarios (both large and small companies alike) - 
this has been ongoing in some larger companies for many years already (IPv6 
adoption) and often through resident engineer placements from vendors  

   

   

On Oct 27, 2016, at 11:59 AM, Chuck McCown  wrote:

 

Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc.  

We all need this or will need this.  

 

From: Faisal Imtiaz 

Sent: Wednesday, October 26, 2016 8:31 PM

To: af 

Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt

 

An excellent detailed solution  (from one of the other forums).

 

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net

 




  From: "Tim Way" 
  To: "WISPA General List" 
  Sent: Tuesday, October 25, 2016 9:01:51 PM
  Subject: Re: [WISPA] IPV6 deploymernt

  Art,

  So I know of two solid methods that could solve your problem. Neither are 
super awesome and both would involve NAT.

   

  1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only 
connectivity

  2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, and IPv6 Global 
Unicast running in Dual Stack

   

  Either one would work. I apologize in advance for the long post that 
follows.

   

  I've only done the configurations on Cisco routers with the radios just 
passing traffic at layer 2. I'd have to check the feature set of your routers 
routing wise but it shouldn't be hard. It also could be built in a lab with 
static routing largely. I think Mikrotik supports NAT64 but again for a lab 
environment any recent Cisco device could be used with IP Services licensing.

   

  Your address plan for your global unicast IPv6 space comes into play. 
This is how I would lab it up including moving routing to the tower with the 
CPE in bridge mode:

   

  Your fictional IPv6 prefix: :::/32

   

  Your NAT64 Prefix: ::cc00::/96

   

  Customer DHCPv6-PD Allocation Prefix: ::aa00::/40

  Your fictional customer #1: The Johnson Family, ::aa00:0100::/56

  Your fictional customer #2: The Billings' Family, ::aa00:0200::/56

   

  Fictional Tower 1

  ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64

  ISP Customer VLAN of CPE: 12, ::bb00:0012::/64

  ISP Router at the tower on VLAN 11: ::bb00:0011::1/64

  ISP Router at the tower on VLAN 12: ::bb00:0012::1/64

   

  The Johnson Family Setup:

  ISP CPE VLAN 11 IP

Re: [AFMUG] FYI Cambium PTP doesn't sync with PMP

[Jon Langeler]

Nah PMP450 with PTP450

Jon Langeler
Michwave Technologies, Inc.


> On Oct 27, 2016, at 2:44 PM, Josh Luthman  wrote:
> 
> I don't believe they're supposed to, assuming ptp650?
> 
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> 
> 
>> On Oct 27, 2016 2:37 PM, "Jon Langeler"  wrote:
>> I don't think their support department understands the concept of sync. But 
>> as of now we have given up on PTP products syncing 100% with PMP products. 
>> Oh well
>> 
>> Jon Langeler
>> Michwave Technologies, Inc.

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Mike Hammett]

There have been several reports that IPv6 is faster (likely due to NAT boxes). 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Chuck McCown"  
To: af@afmug.com 
Sent: Thursday, October 27, 2016 2:19:57 PM 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 




Costs are rising pretty fast. But yeah, why change if you don’t have to. So, 
Dennis, create V6 in a box that will allow us to assign only V6 to all new 
customers but will do the CGNAT for us at the edge for those times the 
customers have to visit V4 land. 




From: Dennis Burgess 
Sent: Thursday, October 27, 2016 1:12 PM 
To: af@afmug.com 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 



I would totally agree here. We have deployed IPv6 quite a bit for clients, our 
networks etc. However, the major issue is the hosting companies, most big guys, 
google, amazon, etc all support IPv6, heck even Sonar does now! Hahah, but 
until the cost of IPv4 addresses is so high that no one; even the major guys 
can afford it, IPv6 deployment will keep stalling. 



Dennis Burgess – Network Solution Engineer – Consultant 
MikroTik Certified Trainer/Consultant – MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE 

For Wireless Hardware/Routers visit www.linktechs.net 
Radio Frequiency Coverages: www.towercoverage.com 
Office: 314-735-0270 
E-Mail: dmburg...@linktechs.net 



From: Af [mailto:af-boun...@afmug.com] On Behalf Of Paul Stewart 
Sent: Thursday, October 27, 2016 2:00 PM 
To: af@afmug.com 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 

Actually in my opinion what we need is better IPv6 adoption in general and this 
becomes a non-problem quickly :) 



I know .. good theory … and “we” are getting better though …. a lot of 
providers have gotten their heads out of the clouds in the past few years alone 
…. 








On Oct 27, 2016, at 2:26 PM, Chuck McCown < ch...@wbmfg.com > wrote: 






What we all need, is a low cost solution to stop needing more V4 IPs. 



If it is CGN at the edge with a limited pool of V4, so be it. 



But I want a solid solution that can be trusted. 

And I want and expert to come drop it into my company. 






From: Paul Stewart 

Sent: Thursday, October 27, 2016 11:23 AM 

To: af@afmug.com 

Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 



while I’m not a fan of NAT64, CGN etc (but understand in some situations the 
need for it), I completely agree that companies will be looking for consultants 
to help with this in some scenarios (both large and small companies alike) - 
this has been ongoing in some larger companies for many years already (IPv6 
adoption) and often through resident engineer placements from vendors 









On Oct 27, 2016, at 11:59 AM, Chuck McCown < ch...@wbmfg.com > wrote: 







Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc. 

We all need this or will need this. 






From: Faisal Imtiaz 

Sent: Wednesday, October 26, 2016 8:31 PM 

To: af 

Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt 





An excellent detailed solution (from one of the other forums). 



Faisal Imtiaz 
Snappy Internet & Telecom 
7266 SW 48 Street 
Miami, FL 33155 
Tel: 305 663 5518 x 232 

Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net 


- Original Message -




From: "Tim Way" < t...@way.vg > 
To: "WISPA General List" < wirel...@wispa.org > 
Sent: Tuesday, October 25, 2016 9:01:51 PM 
Subject: Re: [WISPA] IPV6 deploymernt 






Art, 

So I know of two solid methods that could solve your problem. Neither are super 
awesome and both would involve NAT. 



1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only 
connectivity 

2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10 , and IPv6 Global 
Unicast running in Dual Stack 



Either one would work. I apologize in advance for the long post that follows. 



I've only done the configurations on Cisco routers with the radios just passing 
traffic at layer 2. I'd have to check the feature set of your routers routing 
wise but it shouldn't be hard. It also could be built in a lab with static 
routing largely. I think Mikrotik supports NAT64 but again for a lab 
environment any recent Cisco device could be used with IP Services licensing. 



Your address plan for your global unicast IPv6 space comes into play. This is 
how I would lab it up including moving routing to the tower with the CPE in 
bridge mode: 



Your fictional IPv6 prefix: :::/32 



Your NAT64 Prefix: ::cc00::/96 



Customer DHCPv6-PD Allocation Prefix: ::aa00::/40 

Your fictional customer #1: The Johnson Family, ::aa00:0100::/56 

Your fictional customer #2: The Billings' Family, ::aa00:0200::/56 



Fictional Tower 1 


ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64 

ISP Customer VLAN of CPE: 12, ::bb00:0012::/64 

ISP Router at the tower on VLAN 11: ::bb00:0011::1/64 

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Simon Westlake]

What do you mean, 'even Sonar'? We aren't chopped liver!

On 10/27/2016 2:12 PM, Dennis Burgess wrote:


I would totally agree here. We have deployed IPv6 quite a bit for 
clients, our networks etc.  However, the major issue is the hosting 
companies, most big guys, google, amazon, etc all support IPv6, heck 
even Sonar does now! Hahah, but until the cost of IPv4 addresses is so 
high that no one; even the major guys can afford it, IPv6 deployment 
will keep stalling.


*/_Dennis Burgess_/**–**Network Solution Engineer – Consultant ***

MikroTik Certified Trainer/Consultant 
 – 
MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE


For Wireless Hardware/Routers visit www.linktechs.net 



Radio Frequiency Coverages: www.towercoverage.com 



Office: 314-735-0270

E-Mail: dmburg...@linktechs.net 

*From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Paul Stewart
*Sent:* Thursday, October 27, 2016 2:00 PM
*To:* af@afmug.com
*Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt

Actually in my opinion what we need is better IPv6 adoption in general 
and this becomes a non-problem quickly :)


I know .. good theory … and “we” are getting better though …. a lot of 
providers have gotten their heads out of the clouds in the past few 
years alone ….


On Oct 27, 2016, at 2:26 PM, Chuck McCown mailto:ch...@wbmfg.com>> wrote:

What we all need, is a low cost solution to stop needing more V4 IPs.

If it is CGN at the edge with a limited pool of V4, so be it.

But I want a solid solution that can be trusted.

And I want and expert to come drop it into my company.

*From:*Paul Stewart

*Sent:*Thursday, October 27, 2016 11:23 AM

*To:*af@afmug.com 

*Subject:*Re: [AFMUG] [WISPA] IPV6 deploymernt

while I’m not a fan of NAT64, CGN etc (but understand in some
situations the need for it), I completely agree that companies
will be looking for consultants to help with this in some
scenarios (both large and small companies alike) - this has been
ongoing in some larger companies for many years already (IPv6
adoption) and often through resident engineer placements from vendors

On Oct 27, 2016, at 11:59 AM, Chuck McCown mailto:ch...@wbmfg.com>> wrote:

Some consultant needs to specialize in this and help folks
provision, configure, deploy, test etc.

We all need this or will need this.

*From:*Faisal Imtiaz

*Sent:*Wednesday, October 26, 2016 8:31 PM

*To:*af

*Subject:*[AFMUG] Fwd: [WISPA] IPV6 deploymernt

An excellent detailed solution  (from one of the other forums).

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email:
supp...@snappytelecom.net 



*From: *"Tim Way" mailto:t...@way.vg>>
*To: *"WISPA General List" mailto:wirel...@wispa.org>>
*Sent: *Tuesday, October 25, 2016 9:01:51 PM
*Subject: *Re: [WISPA] IPV6 deploymernt

Art,

So I know of two solid methods that could solve your
problem. Neither are super awesome and both would involve NAT.

1. IPv6 only to the client with NAT64 and DNS64 to handle
IPv4 only connectivity

2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10
, and IPv6 Global Unicast running in
Dual Stack

Either one would work. I apologize in advance for the long
post that follows.

I've only done the configurations on Cisco routers with
the radios just passing traffic at layer 2. I'd have to
check the feature set of your routers routing wise but it
shouldn't be hard. It also could be built in a lab with
static routing largely. I think Mikrotik supports NAT64
but again for a lab environment any recent Cisco device
could be used with IP Services licensing.

Your address plan for your global unicast IPv6 space comes
into play. This is how I would lab it up including moving
routing to the tower with the CPE in bridge mode:

Your fictional IPv6 prefix: :::/32

Your NAT64 Prefix: ::cc00::/96

Customer DHCPv6-PD Allocation Prefix: ::aa00::/40

Your fictional customer #1: The Johnson Family,
::aa00:0100::/56

Your fictional customer #2: The Billings' Family,
::aa00:0200::/56

Fictional Tower 1

ISP Mgmt VLAN of CPE:

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Josh Reynolds]

He was talking about "you people".


;)

On Oct 27, 2016 2:37 PM, "Simon Westlake"  wrote:

> What do you mean, 'even Sonar'? We aren't chopped liver!
>
> On 10/27/2016 2:12 PM, Dennis Burgess wrote:
>
> I would totally agree here. We have deployed IPv6 quite a bit for clients,
> our networks etc.  However, the major issue is the hosting companies, most
> big guys, google, amazon, etc all support IPv6, heck even Sonar does now!
> Hahah, but until the cost of IPv4 addresses is so high that no one; even
> the major guys can afford it, IPv6 deployment will keep stalling.
>
>
>
>
>
> *Dennis Burgess** –** Network Solution Engineer – Consultant *
>
> MikroTik Certified Trainer/Consultant
>  –
> MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE
>
>
>
> For Wireless Hardware/Routers visit www.linktechs.net
>
> Radio Frequiency Coverages: www.towercoverage.com
>
> Office: 314-735-0270
>
> E-Mail: dmburg...@linktechs.net
>
>
>
> *From:* Af [mailto:af-boun...@afmug.com ] *On
> Behalf Of *Paul Stewart
> *Sent:* Thursday, October 27, 2016 2:00 PM
> *To:* af@afmug.com
> *Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt
>
>
>
> Actually in my opinion what we need is better IPv6 adoption in general and
> this becomes a non-problem quickly :)
>
>
>
> I know .. good theory … and “we” are getting better though …. a lot of
> providers have gotten their heads out of the clouds in the past few years
> alone ….
>
>
>
>
>
> On Oct 27, 2016, at 2:26 PM, Chuck McCown  wrote:
>
>
>
> What we all need, is a low cost solution to stop needing more V4 IPs.
>
>
>
> If it is CGN at the edge with a limited pool of V4, so be it.
>
>
>
> But I want a solid solution that can be trusted.
>
> And I want and expert to come drop it into my company.
>
>
>
> *From:* Paul Stewart
>
> *Sent:* Thursday, October 27, 2016 11:23 AM
>
> *To:* af@afmug.com
>
> *Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt
>
>
>
> while I’m not a fan of NAT64, CGN etc (but understand in some situations
> the need for it), I completely agree that companies will be looking for
> consultants to help with this in some scenarios (both large and small
> companies alike) - this has been ongoing in some larger companies for many
> years already (IPv6 adoption) and often through resident engineer
> placements from vendors
>
>
>
>
>
> On Oct 27, 2016, at 11:59 AM, Chuck McCown  wrote:
>
>
>
> Some consultant needs to specialize in this and help folks provision,
> configure, deploy, test etc.
>
> We all need this or will need this.
>
>
>
> *From:* Faisal Imtiaz
>
> *Sent:* Wednesday, October 26, 2016 8:31 PM
>
> *To:* af
>
> *Subject:* [AFMUG] Fwd: [WISPA] IPV6 deploymernt
>
>
>
> An excellent detailed solution  (from one of the other forums).
>
>
>
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
>
> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>
>
> --
>
> *From: *"Tim Way" 
> *To: *"WISPA General List" 
> *Sent: *Tuesday, October 25, 2016 9:01:51 PM
> *Subject: *Re: [WISPA] IPV6 deploymernt
>
> Art,
>
> So I know of two solid methods that could solve your problem. Neither are
> super awesome and both would involve NAT.
>
>
>
> 1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only
> connectivity
>
> 2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, and IPv6 Global
> Unicast running in Dual Stack
>
>
>
> Either one would work. I apologize in advance for the long post that
> follows.
>
>
>
> I've only done the configurations on Cisco routers with the radios just
> passing traffic at layer 2. I'd have to check the feature set of your
> routers routing wise but it shouldn't be hard. It also could be built in a
> lab with static routing largely. I think Mikrotik supports NAT64 but again
> for a lab environment any recent Cisco device could be used with IP
> Services licensing.
>
>
>
> Your address plan for your global unicast IPv6 space comes into play. This
> is how I would lab it up including moving routing to the tower with the CPE
> in bridge mode:
>
>
>
> Your fictional IPv6 prefix: :::/32
>
>
>
> Your NAT64 Prefix: ::cc00::/96
>
>
>
> Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
>
> Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
>
> Your fictional customer #2: The Billings' Family, ::aa00:0200::/56
>
>
>
> Fictional Tower 1
>
> ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
>
> ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
>
> ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
>
> ISP Router at the tower on VLAN 12: ::bb00:0012::1/64
>
>
>
> The Johnson Family Setup:
>
> ISP CPE VLAN 11 IP: ::bb00:0011::f/64
>
> Customer's Netgear WAN Interface: ::bb00:0012::f/64
>
> Customer's Netgear LAN Interface: ::aa00:010a::1/64
>
> Customer's Netgear Guest WiFi: ::aa00:010b::1/64
>
>

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Josh Reynolds]

It should be, but not more so than pure routed IPv4. NAT has additional
latency due to port mapping and lookup overhead.

On Oct 27, 2016 2:21 PM, "Mike Hammett"  wrote:

> There have been several reports that IPv6 is faster (likely due to NAT
> boxes).
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
>
>
> 
> --
> *From: *"Chuck McCown" 
> *To: *af@afmug.com
> *Sent: *Thursday, October 27, 2016 2:19:57 PM
> *Subject: *Re: [AFMUG] [WISPA] IPV6 deploymernt
>
> Costs are rising pretty fast.  But yeah, why change if you don’t have to.
> So, Dennis, create V6 in a box that will allow us to assign only V6 to all
> new customers but will do the CGNAT for us at the edge for those times the
> customers have to visit V4 land.
>
> *From:* Dennis Burgess
> *Sent:* Thursday, October 27, 2016 1:12 PM
> *To:* af@afmug.com
> *Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt
>
>
> I would totally agree here. We have deployed IPv6 quite a bit for clients,
> our networks etc.  However, the major issue is the hosting companies, most
> big guys, google, amazon, etc all support IPv6, heck even Sonar does now!
> Hahah, but until the cost of IPv4 addresses is so high that no one; even
> the major guys can afford it, IPv6 deployment will keep stalling.
>
>
>
>
>
> *Dennis Burgess** –** Network Solution Engineer – Consultant *
>
> MikroTik Certified Trainer/Consultant
>  –
> MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE
>
>
>
> For Wireless Hardware/Routers visit www.linktechs.net
>
> Radio Frequiency Coverages: www.towercoverage.com
>
> Office: 314-735-0270
>
> E-Mail: dmburg...@linktechs.net
>
>
>
> *From:* Af [mailto:af-boun...@afmug.com] *On Behalf Of *Paul Stewart
> *Sent:* Thursday, October 27, 2016 2:00 PM
> *To:* af@afmug.com
> *Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt
>
>
>
> Actually in my opinion what we need is better IPv6 adoption in general and
> this becomes a non-problem quickly :)
>
>
>
> I know .. good theory … and “we” are getting better though …. a lot of
> providers have gotten their heads out of the clouds in the past few years
> alone ….
>
>
>
>
>
> On Oct 27, 2016, at 2:26 PM, Chuck McCown  wrote:
>
>
>
> What we all need, is a low cost solution to stop needing more V4 IPs.
>
>
>
> If it is CGN at the edge with a limited pool of V4, so be it.
>
>
>
> But I want a solid solution that can be trusted.
>
> And I want and expert to come drop it into my company.
>
>
>
> *From:* Paul Stewart
>
> *Sent:* Thursday, October 27, 2016 11:23 AM
>
> *To:* af@afmug.com
>
> *Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt
>
>
>
> while I’m not a fan of NAT64, CGN etc (but understand in some situations
> the need for it), I completely agree that companies will be looking for
> consultants to help with this in some scenarios (both large and small
> companies alike) - this has been ongoing in some larger companies for many
> years already (IPv6 adoption) and often through resident engineer
> placements from vendors
>
>
>
>
>
> On Oct 27, 2016, at 11:59 AM, Chuck McCown  wrote:
>
>
>
> Some consultant needs to specialize in this and help folks provision,
> configure, deploy, test etc.
>
> We all need this or will need this.
>
>
>
> *From:* Faisal Imtiaz
>
> *Sent:* Wednesday, October 26, 2016 8:31 PM
>
> *To:* af
>
> *Subject:* [AFMUG] Fwd: [WISPA] IPV6 deploymernt
>
>
>
> An excellent detailed solution  (from one of the other forums).
>
>
>
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
>
> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>
>
> --
>
> *From: *"Tim Way" 
> *To: *"WISPA General List" 
> *Sent: *Tuesday, October 25, 2016 9:01:51 PM
> *Subject: *Re: [WISPA] IPV6 deploymernt
>
> Art,
>
> So I know of two solid methods that could solve your problem. Neither are
> super awesome and both would involve NAT.
>
>
>
> 1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only
> connectivity
>
> 2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, and IPv6 Global
> Unicast running in Dual Stack
>
>
>
> Either one would work. I apologize in advance for the long post that
> follows.
>
>
>
> I've only done the configurations on Cisco routers with the radios just
> passing traffic at layer 2. I'd have to check the feature set of your
> routers 

Re: [AFMUG] FYI Cambium PTP doesn't sync with PMP

[Nathan Anderson]

You want to re-use a distribution channel as a backhaul channel, too?  That 
seems like a bad idea anyway.

-- Nathan

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Jon Langeler
Sent: Thursday, October 27, 2016 12:21 PM
To: af@afmug.com
Subject: Re: [AFMUG] FYI Cambium PTP doesn't sync with PMP

Nah PMP450 with PTP450
Jon Langeler
Michwave Technologies, Inc.


On Oct 27, 2016, at 2:44 PM, Josh Luthman 
mailto:j...@imaginenetworksllc.com>> wrote:

I don't believe they're supposed to, assuming ptp650?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Oct 27, 2016 2:37 PM, "Jon Langeler" 
mailto:jon-ispli...@michwave.net>> wrote:
I don't think their support department understands the concept of sync. But as 
of now we have given up on PTP products syncing 100% with PMP products. Oh well

Jon Langeler
Michwave Technologies, Inc.

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Mike Hammett]

*shrugs* I just know what the reports say. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Josh Reynolds"  
To: af@afmug.com 
Sent: Thursday, October 27, 2016 2:36:28 PM 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 


It should be, but not more so than pure routed IPv4. NAT has additional latency 
due to port mapping and lookup overhead. 


On Oct 27, 2016 2:21 PM, "Mike Hammett" < af...@ics-il.net > wrote: 




There have been several reports that IPv6 is faster (likely due to NAT boxes). 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 






From: "Chuck McCown" < ch...@wbmfg.com > 
To: af@afmug.com 
Sent: Thursday, October 27, 2016 2:19:57 PM 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 




Costs are rising pretty fast. But yeah, why change if you don’t have to. So, 
Dennis, create V6 in a box that will allow us to assign only V6 to all new 
customers but will do the CGNAT for us at the edge for those times the 
customers have to visit V4 land. 




From: Dennis Burgess 
Sent: Thursday, October 27, 2016 1:12 PM 
To: af@afmug.com 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 



I would totally agree here. We have deployed IPv6 quite a bit for clients, our 
networks etc. However, the major issue is the hosting companies, most big guys, 
google, amazon, etc all support IPv6, heck even Sonar does now! Hahah, but 
until the cost of IPv4 addresses is so high that no one; even the major guys 
can afford it, IPv6 deployment will keep stalling. 



Dennis Burgess – Network Solution Engineer – Consultant 
MikroTik Certified Trainer/Consultant – MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE 

For Wireless Hardware/Routers visit www.linktechs.net 
Radio Frequiency Coverages: www.towercoverage.com 
Office: 314-735-0270 
E-Mail: dmburg...@linktechs.net 



From: Af [mailto: af-boun...@afmug.com ] On Behalf Of Paul Stewart 
Sent: Thursday, October 27, 2016 2:00 PM 
To: af@afmug.com 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 

Actually in my opinion what we need is better IPv6 adoption in general and this 
becomes a non-problem quickly :) 



I know .. good theory … and “we” are getting better though …. a lot of 
providers have gotten their heads out of the clouds in the past few years alone 
…. 








On Oct 27, 2016, at 2:26 PM, Chuck McCown < ch...@wbmfg.com > wrote: 






What we all need, is a low cost solution to stop needing more V4 IPs. 



If it is CGN at the edge with a limited pool of V4, so be it. 



But I want a solid solution that can be trusted. 

And I want and expert to come drop it into my company. 






From: Paul Stewart 

Sent: Thursday, October 27, 2016 11:23 AM 

To: af@afmug.com 

Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 



while I’m not a fan of NAT64, CGN etc (but understand in some situations the 
need for it), I completely agree that companies will be looking for consultants 
to help with this in some scenarios (both large and small companies alike) - 
this has been ongoing in some larger companies for many years already (IPv6 
adoption) and often through resident engineer placements from vendors 









On Oct 27, 2016, at 11:59 AM, Chuck McCown < ch...@wbmfg.com > wrote: 







Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc. 

We all need this or will need this. 






From: Faisal Imtiaz 

Sent: Wednesday, October 26, 2016 8:31 PM 

To: af 

Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt 





An excellent detailed solution (from one of the other forums). 



Faisal Imtiaz 
Snappy Internet & Telecom 
7266 SW 48 Street 
Miami, FL 33155 
Tel: 305 663 5518 x 232 

Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net 







From: "Tim Way" < t...@way.vg > 
To: "WISPA General List" < wirel...@wispa.org > 
Sent: Tuesday, October 25, 2016 9:01:51 PM 
Subject: Re: [WISPA] IPV6 deploymernt 






Art, 

So I know of two solid methods that could solve your problem. Neither are super 
awesome and both would involve NAT. 



1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only 
connectivity 

2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10 , and IPv6 Global 
Unicast running in Dual Stack 



Either one would work. I apologize in advance for the long post that follows. 



I've only done the configurations on Cisco routers with the radios just passing 
traffic at layer 2. I'd have to check the feature set of your routers routing 
wise but it shouldn't be hard. It also could be built in a lab with static 
routing largely. I think Mikrotik supports NAT64 but again for a lab 
environment any recent Cisco device could be used with IP Services licensing. 



Your address plan for your global unicast IPv6 space comes into play. This is 
how I would lab it up including moving routing to the tower with the CPE in 
bridge mode: 



Your fictional I

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Jason Wilson]

Is sonar the only CRM that supports IPV6?

I know currently Visp Does not.


Jason Wilson
Remotely Located
Providing High Speed Internet to out of the way places.
530-651-1736
530-748-9608 Cell
www.remotelylocated.com

On Thu, Oct 27, 2016 at 12:37 PM, Simon Westlake 
wrote:

> What do you mean, 'even Sonar'? We aren't chopped liver!
>
> On 10/27/2016 2:12 PM, Dennis Burgess wrote:
>
> I would totally agree here. We have deployed IPv6 quite a bit for clients,
> our networks etc.  However, the major issue is the hosting companies, most
> big guys, google, amazon, etc all support IPv6, heck even Sonar does now!
> Hahah, but until the cost of IPv4 addresses is so high that no one; even
> the major guys can afford it, IPv6 deployment will keep stalling.
>
>
>
>
>
> *Dennis Burgess** –** Network Solution Engineer – Consultant *
>
> MikroTik Certified Trainer/Consultant
>  –
> MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE
>
>
>
> For Wireless Hardware/Routers visit www.linktechs.net
>
> Radio Frequiency Coverages: www.towercoverage.com
>
> Office: 314-735-0270
>
> E-Mail: dmburg...@linktechs.net
>
>
>
> *From:* Af [mailto:af-boun...@afmug.com ] *On
> Behalf Of *Paul Stewart
> *Sent:* Thursday, October 27, 2016 2:00 PM
> *To:* af@afmug.com
> *Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt
>
>
>
> Actually in my opinion what we need is better IPv6 adoption in general and
> this becomes a non-problem quickly :)
>
>
>
> I know .. good theory … and “we” are getting better though …. a lot of
> providers have gotten their heads out of the clouds in the past few years
> alone ….
>
>
>
>
>
> On Oct 27, 2016, at 2:26 PM, Chuck McCown  wrote:
>
>
>
> What we all need, is a low cost solution to stop needing more V4 IPs.
>
>
>
> If it is CGN at the edge with a limited pool of V4, so be it.
>
>
>
> But I want a solid solution that can be trusted.
>
> And I want and expert to come drop it into my company.
>
>
>
> *From:* Paul Stewart
>
> *Sent:* Thursday, October 27, 2016 11:23 AM
>
> *To:* af@afmug.com
>
> *Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt
>
>
>
> while I’m not a fan of NAT64, CGN etc (but understand in some situations
> the need for it), I completely agree that companies will be looking for
> consultants to help with this in some scenarios (both large and small
> companies alike) - this has been ongoing in some larger companies for many
> years already (IPv6 adoption) and often through resident engineer
> placements from vendors
>
>
>
>
>
> On Oct 27, 2016, at 11:59 AM, Chuck McCown  wrote:
>
>
>
> Some consultant needs to specialize in this and help folks provision,
> configure, deploy, test etc.
>
> We all need this or will need this.
>
>
>
> *From:* Faisal Imtiaz
>
> *Sent:* Wednesday, October 26, 2016 8:31 PM
>
> *To:* af
>
> *Subject:* [AFMUG] Fwd: [WISPA] IPV6 deploymernt
>
>
>
> An excellent detailed solution  (from one of the other forums).
>
>
>
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
>
> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>
>
> --
>
> *From: *"Tim Way" 
> *To: *"WISPA General List" 
> *Sent: *Tuesday, October 25, 2016 9:01:51 PM
> *Subject: *Re: [WISPA] IPV6 deploymernt
>
> Art,
>
> So I know of two solid methods that could solve your problem. Neither are
> super awesome and both would involve NAT.
>
>
>
> 1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only
> connectivity
>
> 2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, and IPv6 Global
> Unicast running in Dual Stack
>
>
>
> Either one would work. I apologize in advance for the long post that
> follows.
>
>
>
> I've only done the configurations on Cisco routers with the radios just
> passing traffic at layer 2. I'd have to check the feature set of your
> routers routing wise but it shouldn't be hard. It also could be built in a
> lab with static routing largely. I think Mikrotik supports NAT64 but again
> for a lab environment any recent Cisco device could be used with IP
> Services licensing.
>
>
>
> Your address plan for your global unicast IPv6 space comes into play. This
> is how I would lab it up including moving routing to the tower with the CPE
> in bridge mode:
>
>
>
> Your fictional IPv6 prefix: :::/32
>
>
>
> Your NAT64 Prefix: ::cc00::/96
>
>
>
> Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
>
> Your fictional customer #1: The Johnson Family, ::aa00:0100::/56
>
> Your fictional customer #2: The Billings' Family, ::aa00:0200::/56
>
>
>
> Fictional Tower 1
>
> ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64
>
> ISP Customer VLAN of CPE: 12, ::bb00:0012::/64
>
> ISP Router at the tower on VLAN 11: ::bb00:0011::1/64
>
> ISP Router at the tower on VLAN 12: ::bb00:0012::1/64
>
>
>
> The Johnson Family Setup:
>
> ISP CPE VLAN 11 IP: ::bb00:0011::f/64
>
> Cus

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Mike Hammett]

Anyone in AWS won't, given AWS's poor to no IPv6 support. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Jason Wilson"  
To: af@afmug.com 
Sent: Thursday, October 27, 2016 2:48:07 PM 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 



Is sonar the only CRM that supports IPV6? 


I know currently Visp Does not. 






Jason Wilson 
Remotely Located 
Providing High Speed Internet to out of the way places. 
530-651-1736 
530-748-9608 Cell 
www.remotelylocated.com 

On Thu, Oct 27, 2016 at 12:37 PM, Simon Westlake < simon@sonar.software > 
wrote: 



What do you mean, 'even Sonar'? We aren't chopped liver! 


On 10/27/2016 2:12 PM, Dennis Burgess wrote: 




I would totally agree here. We have deployed IPv6 quite a bit for clients, our 
networks etc. However, the major issue is the hosting companies, most big guys, 
google, amazon, etc all support IPv6, heck even Sonar does now! Hahah, but 
until the cost of IPv4 addresses is so high that no one; even the major guys 
can afford it, IPv6 deployment will keep stalling. 



Dennis Burgess – Network Solution Engineer – Consultant 
MikroTik Certified Trainer/Consultant – MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE 

For Wireless Hardware/Routers visit www.linktechs.net 
Radio Frequiency Coverages: www.towercoverage.com 
Office: 314-735-0270 
E-Mail: dmburg...@linktechs.net 



From: Af [ mailto:af-boun...@afmug.com ] On Behalf Of Paul Stewart 
Sent: Thursday, October 27, 2016 2:00 PM 
To: af@afmug.com 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 

Actually in my opinion what we need is better IPv6 adoption in general and this 
becomes a non-problem quickly :) 



I know .. good theory … and “we” are getting better though …. a lot of 
providers have gotten their heads out of the clouds in the past few years alone 
…. 








On Oct 27, 2016, at 2:26 PM, Chuck McCown < ch...@wbmfg.com > wrote: 






What we all need, is a low cost solution to stop needing more V4 IPs. 



If it is CGN at the edge with a limited pool of V4, so be it. 



But I want a solid solution that can be trusted. 

And I want and expert to come drop it into my company. 






From: Paul Stewart 

Sent: Thursday, October 27, 2016 11:23 AM 

To: af@afmug.com 

Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt 



while I’m not a fan of NAT64, CGN etc (but understand in some situations the 
need for it), I completely agree that companies will be looking for consultants 
to help with this in some scenarios (both large and small companies alike) - 
this has been ongoing in some larger companies for many years already (IPv6 
adoption) and often through resident engineer placements from vendors 











On Oct 27, 2016, at 11:59 AM, Chuck McCown < ch...@wbmfg.com > wrote: 







Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc. 

We all need this or will need this. 






From: Faisal Imtiaz 

Sent: Wednesday, October 26, 2016 8:31 PM 

To: af 

Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt 





An excellent detailed solution (from one of the other forums). 



Faisal Imtiaz 
Snappy Internet & Telecom 
7266 SW 48 Street 
Miami, FL 33155 
Tel: 305 663 5518 x 232 

Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net 







From: "Tim Way" < t...@way.vg > 
To: "WISPA General List" < wirel...@wispa.org > 
Sent: Tuesday, October 25, 2016 9:01:51 PM 
Subject: Re: [WISPA] IPV6 deploymernt 






Art, 

So I know of two solid methods that could solve your problem. Neither are super 
awesome and both would involve NAT. 



1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only 
connectivity 

2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10 , and IPv6 Global 
Unicast running in Dual Stack 



Either one would work. I apologize in advance for the long post that follows. 



I've only done the configurations on Cisco routers with the radios just passing 
traffic at layer 2. I'd have to check the feature set of your routers routing 
wise but it shouldn't be hard. It also could be built in a lab with static 
routing largely. I think Mikrotik supports NAT64 but again for a lab 
environment any recent Cisco device could be used with IP Services licensing. 



Your address plan for your global unicast IPv6 space comes into play. This is 
how I would lab it up including moving routing to the tower with the CPE in 
bridge mode: 



Your fictional IPv6 prefix: :::/32 



Your NAT64 Prefix: ::cc00::/96 



Customer DHCPv6-PD Allocation Prefix: ::aa00::/40 

Your fictional customer #1: The Johnson Family, ::aa00:0100::/56 

Your fictional customer #2: The Billings' Family, ::aa00:0200::/56 



Fictional Tower 1 


ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64 

ISP Customer VLAN of CPE: 12, ::bb00:0012::/64 

ISP Router at the tower on VLAN 11: ::bb00:0011::1/64 

ISP Router at 

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Simon Westlake]

I'm not sure, but I think we are probably in a minority, as we're 
onboarding a lot of customers right now who came to us explicitly 
looking for IPv6 support.


On 10/27/2016 2:48 PM, Jason Wilson wrote:

Is sonar the only CRM that supports IPV6?

I know currently Visp Does not.


Jason Wilson
Remotely Located
Providing High Speed Internet to out of the way places.
530-651-1736
530-748-9608 Cell
www.remotelylocated.com 

On Thu, Oct 27, 2016 at 12:37 PM, Simon Westlake > wrote:


What do you mean, 'even Sonar'? We aren't chopped liver!

On 10/27/2016 2:12 PM, Dennis Burgess wrote:


I would totally agree here. We have deployed IPv6 quite a bit for
clients, our networks etc. However, the major issue is the
hosting companies, most big guys, google, amazon, etc all support
IPv6, heck even Sonar does now! Hahah, but until the cost of IPv4
addresses is so high that no one; even the major guys can afford
it, IPv6 deployment will keep stalling.

*/_Dennis Burgess_/**–**Network Solution Engineer – Consultant ***

MikroTik Certified Trainer/Consultant

– MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE

For Wireless Hardware/Routers visit www.linktechs.net


Radio Frequiency Coverages: www.towercoverage.com


Office: 314-735-0270 

E-Mail: dmburg...@linktechs.net 

*From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Paul Stewart
*Sent:* Thursday, October 27, 2016 2:00 PM
*To:* af@afmug.com 
*Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt

Actually in my opinion what we need is better IPv6 adoption in
general and this becomes a non-problem quickly :)

I know .. good theory … and “we” are getting better though …. a
lot of providers have gotten their heads out of the clouds in the
past few years alone ….

On Oct 27, 2016, at 2:26 PM, Chuck McCown mailto:ch...@wbmfg.com>> wrote:

What we all need, is a low cost solution to stop needing more
V4 IPs.

If it is CGN at the edge with a limited pool of V4, so be it.

But I want a solid solution that can be trusted.

And I want and expert to come drop it into my company.

*From:*Paul Stewart

*Sent:*Thursday, October 27, 2016 11:23 AM

*To:*af@afmug.com 

*Subject:*Re: [AFMUG] [WISPA] IPV6 deploymernt

while I’m not a fan of NAT64, CGN etc (but understand in some
situations the need for it), I completely agree that
companies will be looking for consultants to help with this
in some scenarios (both large and small companies alike) -
this has been ongoing in some larger companies for many years
already (IPv6 adoption) and often through resident engineer
placements from vendors

On Oct 27, 2016, at 11:59 AM, Chuck McCown
mailto:ch...@wbmfg.com>> wrote:

Some consultant needs to specialize in this and help
folks provision, configure, deploy, test etc.

We all need this or will need this.

*From:*Faisal Imtiaz

*Sent:*Wednesday, October 26, 2016 8:31 PM

*To:*af

*Subject:*[AFMUG] Fwd: [WISPA] IPV6 deploymernt

An excellent detailed solution (from one of the other
forums).

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518  x 232

Help-desk: (305)663-5518  Option 2
or Email: supp...@snappytelecom.net





*From: *"Tim Way" mailto:t...@way.vg>>
*To: *"WISPA General List" mailto:wirel...@wispa.org>>
*Sent: *Tuesday, October 25, 2016 9:01:51 PM
*Subject: *Re: [WISPA] IPV6 deploymernt

Art,

So I know of two solid methods that could solve your
problem. Neither are super awesome and both would
involve NAT.

1. IPv6 only to the client with NAT64 and DNS64 to
handle IPv4 only connectivity

2. IPv4 CGN Shared Address Space, RFC 6598
100.64.0.0/10 , and IPv6 Global
Unicast running in Dual Stack

Either one would work. I apologize in advance for the
long post that follows.

I've only done the configurations on Cisco routers
with the radios just passing traffic at layer 2. I'd
have to check the feature set of your routers 

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Chuck McCown]

Good marketing feature perhaps.

From: Jason Wilson 
Sent: Thursday, October 27, 2016 1:48 PM
To: af@afmug.com 
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt

Is sonar the only CRM that supports IPV6?

I know currently Visp Does not.



Jason Wilson
Remotely Located
Providing High Speed Internet to out of the way places.
530-651-1736
530-748-9608 Cell
www.remotelylocated.com

On Thu, Oct 27, 2016 at 12:37 PM, Simon Westlake  wrote:

  What do you mean, 'even Sonar'? We aren't chopped liver! 


  On 10/27/2016 2:12 PM, Dennis Burgess wrote:

I would totally agree here. We have deployed IPv6 quite a bit for clients, 
our networks etc.  However, the major issue is the hosting companies, most big 
guys, google, amazon, etc all support IPv6, heck even Sonar does now! Hahah, 
but until the cost of IPv4 addresses is so high that no one; even the major 
guys can afford it, IPv6 deployment will keep stalling.  





Dennis Burgess – Network Solution Engineer – Consultant 

MikroTik Certified Trainer/Consultant – MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE



For Wireless Hardware/Routers visit www.linktechs.net

Radio Frequiency Coverages: www.towercoverage.com 

Office: 314-735-0270

E-Mail: dmburg...@linktechs.net 



From: Af [mailto:af-boun...@afmug.com] On Behalf Of Paul Stewart
Sent: Thursday, October 27, 2016 2:00 PM
To: af@afmug.com
Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt



Actually in my opinion what we need is better IPv6 adoption in general and 
this becomes a non-problem quickly :)



I know .. good theory … and “we” are getting better though …. a lot of 
providers have gotten their heads out of the clouds in the past few years alone 
….





  On Oct 27, 2016, at 2:26 PM, Chuck McCown  wrote:



  What we all need, is a low cost solution to stop needing more V4 IPs.  



  If it is CGN at the edge with a limited pool of V4, so be it.  



  But I want a solid solution that can be trusted.

  And I want and expert to come drop it into my company.  



  From: Paul Stewart 

  Sent: Thursday, October 27, 2016 11:23 AM

  To: af@afmug.com 

  Subject: Re: [AFMUG] [WISPA] IPV6 deploymernt



  while I’m not a fan of NAT64, CGN etc (but understand in some situations 
the need for it), I completely agree that companies will be looking for 
consultants to help with this in some scenarios (both large and small companies 
alike) - this has been ongoing in some larger companies for many years already 
(IPv6 adoption) and often through resident engineer placements from vendors  





On Oct 27, 2016, at 11:59 AM, Chuck McCown  wrote:



Some consultant needs to specialize in this and help folks provision, 
configure, deploy, test etc.  

We all need this or will need this.  



From: Faisal Imtiaz 

Sent: Wednesday, October 26, 2016 8:31 PM

To: af 

Subject: [AFMUG] Fwd: [WISPA] IPV6 deploymernt



An excellent detailed solution  (from one of the other forums).



Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net






  From: "Tim Way" 
  To: "WISPA General List" 
  Sent: Tuesday, October 25, 2016 9:01:51 PM
  Subject: Re: [WISPA] IPV6 deploymernt

  Art,

  So I know of two solid methods that could solve your problem. Neither 
are super awesome and both would involve NAT.



  1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only 
connectivity

  2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, and IPv6 
Global Unicast running in Dual Stack



  Either one would work. I apologize in advance for the long post that 
follows.



  I've only done the configurations on Cisco routers with the radios 
just passing traffic at layer 2. I'd have to check the feature set of your 
routers routing wise but it shouldn't be hard. It also could be built in a lab 
with static routing largely. I think Mikrotik supports NAT64 but again for a 
lab environment any recent Cisco device could be used with IP Services 
licensing.



  Your address plan for your global unicast IPv6 space comes into play. 
This is how I would lab it up including moving routing to the tower with the 
CPE in bridge mode:



  Your fictional IPv6 prefix: :::/32



  Your NAT64 Prefix: ::cc00::/96



  Customer DHCPv6-PD Allocation Prefix: ::aa00::/40

  Your fictional customer #1: The Johnson Family, 
::aa00:0100::/56

  Your fictional customer #2: The Billings' Family, 
::aa00:0200::/56



  Fictional Tower 1

  ISP Mgmt VLAN of CPE: 11, ::bb00:0011::/64

  

Re: [AFMUG] [WISPA] IPV6 deploymernt

[Jason Wilson]

Simon. Let's talk.

On Oct 27, 2016 12:50 PM, "Simon Westlake"  wrote:

> I'm not sure, but I think we are probably in a minority, as we're
> onboarding a lot of customers right now who came to us explicitly looking
> for IPv6 support.
>
> On 10/27/2016 2:48 PM, Jason Wilson wrote:
>
> Is sonar the only CRM that supports IPV6?
>
> I know currently Visp Does not.
>
>
> Jason Wilson
> Remotely Located
> Providing High Speed Internet to out of the way places.
> 530-651-1736
> 530-748-9608 Cell
> www.remotelylocated.com
>
> On Thu, Oct 27, 2016 at 12:37 PM, Simon Westlake 
> wrote:
>
>> What do you mean, 'even Sonar'? We aren't chopped liver!
>>
>> On 10/27/2016 2:12 PM, Dennis Burgess wrote:
>>
>> I would totally agree here. We have deployed IPv6 quite a bit for
>> clients, our networks etc.  However, the major issue is the hosting
>> companies, most big guys, google, amazon, etc all support IPv6, heck even
>> Sonar does now! Hahah, but until the cost of IPv4 addresses is so high that
>> no one; even the major guys can afford it, IPv6 deployment will keep
>> stalling.
>>
>>
>>
>>
>>
>> *Dennis Burgess** –** Network Solution Engineer – Consultant *
>>
>> MikroTik Certified Trainer/Consultant
>>  –
>> MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE
>>
>>
>>
>> For Wireless Hardware/Routers visit www.linktechs.net
>>
>> Radio Frequiency Coverages: www.towercoverage.com
>>
>> Office: 314-735-0270
>>
>> E-Mail: dmburg...@linktechs.net
>>
>>
>>
>> *From:* Af [mailto:af-boun...@afmug.com ] *On
>> Behalf Of *Paul Stewart
>> *Sent:* Thursday, October 27, 2016 2:00 PM
>> *To:* af@afmug.com
>> *Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt
>>
>>
>>
>> Actually in my opinion what we need is better IPv6 adoption in general
>> and this becomes a non-problem quickly :)
>>
>>
>>
>> I know .. good theory … and “we” are getting better though …. a lot of
>> providers have gotten their heads out of the clouds in the past few years
>> alone ….
>>
>>
>>
>>
>>
>> On Oct 27, 2016, at 2:26 PM, Chuck McCown  wrote:
>>
>>
>>
>> What we all need, is a low cost solution to stop needing more V4 IPs.
>>
>>
>>
>> If it is CGN at the edge with a limited pool of V4, so be it.
>>
>>
>>
>> But I want a solid solution that can be trusted.
>>
>> And I want and expert to come drop it into my company.
>>
>>
>>
>> *From:* Paul Stewart
>>
>> *Sent:* Thursday, October 27, 2016 11:23 AM
>>
>> *To:* af@afmug.com
>>
>> *Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt
>>
>>
>>
>> while I’m not a fan of NAT64, CGN etc (but understand in some situations
>> the need for it), I completely agree that companies will be looking for
>> consultants to help with this in some scenarios (both large and small
>> companies alike) - this has been ongoing in some larger companies for many
>> years already (IPv6 adoption) and often through resident engineer
>> placements from vendors
>>
>>
>>
>>
>>
>> On Oct 27, 2016, at 11:59 AM, Chuck McCown  wrote:
>>
>>
>>
>> Some consultant needs to specialize in this and help folks provision,
>> configure, deploy, test etc.
>>
>> We all need this or will need this.
>>
>>
>>
>> *From:* Faisal Imtiaz
>>
>> *Sent:* Wednesday, October 26, 2016 8:31 PM
>>
>> *To:* af
>>
>> *Subject:* [AFMUG] Fwd: [WISPA] IPV6 deploymernt
>>
>>
>>
>> An excellent detailed solution  (from one of the other forums).
>>
>>
>>
>> Faisal Imtiaz
>> Snappy Internet & Telecom
>> 7266 SW 48 Street
>> Miami, FL 33155
>> Tel: 305 663 5518 <305%20663%205518> x 232
>>
>> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>>
>>
>> --
>>
>> *From: *"Tim Way" 
>> *To: *"WISPA General List" 
>> *Sent: *Tuesday, October 25, 2016 9:01:51 PM
>> *Subject: *Re: [WISPA] IPV6 deploymernt
>>
>> Art,
>>
>> So I know of two solid methods that could solve your problem. Neither are
>> super awesome and both would involve NAT.
>>
>>
>>
>> 1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only
>> connectivity
>>
>> 2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, and IPv6
>> Global Unicast running in Dual Stack
>>
>>
>>
>> Either one would work. I apologize in advance for the long post that
>> follows.
>>
>>
>>
>> I've only done the configurations on Cisco routers with the radios just
>> passing traffic at layer 2. I'd have to check the feature set of your
>> routers routing wise but it shouldn't be hard. It also could be built in a
>> lab with static routing largely. I think Mikrotik supports NAT64 but again
>> for a lab environment any recent Cisco device could be used with IP
>> Services licensing.
>>
>>
>>
>> Your address plan for your global unicast IPv6 space comes into play.
>> This is how I would lab it up including moving routing to the tower with
>> the CPE in bridge mode:
>>
>>
>>
>> Your fictional IPv6 prefix: :::/32
>>
>>
>>
>> Your NAT64 Prefix: ::cc00::/96
>>
>>
>>
>> Customer DHCPv6-PD Allocation Prefix: ::aa00::/40
>>
>> Your