Re: [WISPA] Ubiquiti Radios as routers

2012-10-21 Thread Mike Hammett
I'm not saying what we do doesn't work. I'm saying what we do isn't the best.

I was referring to residential or small-business customers. CE or MPLS are for 
dedicated services.

There is no method known to me in the WISP industry to do what I have 
described, the ability to separate authentication\provisioning and IP address 
assignment without requiring extra management.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Faisal Imtiaz fai...@snappydsl.net
To: wireless@wispa.org
Sent: Friday, October 19, 2012 5:52:21 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers

i will respectfully disagree..WISP Industry is rather a broad 
Term... How one provider (WISP or otherwise) sets up  their Service  
DMARC / Delivery of the Service is totally dependent on the WISP and to 
Whom they are delivering the Service  to.

If you are saying what you are saying in the context of a Residential 
Service Provider, there is plenty of proven options on how to define 
that handoff...
If you are talking about Business service providers then the answer can 
be very different.

While this conversation is very interesting, I am thinking about how 
this applies to us We are not delivering Residential Service, and 
for businesses we do an Ethernet Hand-off, sometimes it is directly off 
the UBNT Radio, other times we install a Mikrotik Router as the Dmarc.

Doing this gives us the the ultimate flexibility to mix and match 
service for the Customer, even in cases where they are wanting to have 
L2 Transport and not internet access.. We use EoIP tunnels to accomplish 
that for them.

While it is nice to have an automated system, but keep in mind that 
automated system and Flexibility are polar opposites.  In my Opinion 
WISP's are specialty providers, and as such have to offer Flexibility...

In case of Residential Service ... There are existing documented ways of 
creating a Walled Garden, and letting the users Register, Cable Industry 
uses this approach for authenticating the Modems and matching them to a 
Subscriber Account..

However, I believe that what Fred is talking about is not something that 
applies fully to Residential Service (Remember all Resi BroadBand is 
classified as best effort, and there is a good reason for it...)

While I can understand Fred asking about CE (Carrier Ethernet) showing 
up in WISP's networks, I am still puzzled as to the need of CE in Radios 
or Routers... Mikrotiks are routers, and very flexible tools There 
is nothing stopping anyone today to deploy these in combination with CE 
switches...

The question of the day then becomes, is the problem the WISP's face, 
have to do with the equipment they are using (not having these 
functionality), or is the problem the WISP, building their network in a 
Layered approach so that the Common Denominators (of functionality) can 
be used as a mass provisioning tool

I personally think that most WISP's want their Radios / devices to do 
everything in the world for them, and do it extremely well, and do it 
for a very in-expensive cost. which of course is not reality.

Customer Provisioning  and Customer management are 'Systems' and not a 
device or protocol ATT / Comcast  / Verizon, have the CPE mfg. 
write special firmware for them to auto provision the devices, WISP's 
can accomplish the same or similar using a Systems approach.


Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/19/2012 4:50 PM, Mike Hammett wrote:
 What we're (well, I am anyway) saying is that the way the WISP industry does 
 it...  is sub-optimal. The customer should be able to supply whatever device 
 they want, be handed up to a configured maximum number of public IP addresses 
 (specified per account), but the CPE has managed all account authorization. 
 The customer should still be permitted to pass 1500 byte packets. The 
 customer shouldn't have any configuration on their behalf. You know...  how 
 cable does it.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: LTI - Dennis Burgess gmsm...@gmail.com
 To: WISPA General List wireless@wispa.org
 Sent: Friday, October 19, 2012 1:48:58 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers


 don't know why you would let the customer equipment auth. our network all 
 auth is done at the CPE that we control.


 On Fri, Oct 19, 2012 at 12:55 PM, Simon Westlake  si...@powercode.com  
 wrote:


 Mike,

 I completely agree and I think it is a goal the WISP industry needs to
 work towards - the provisioning of CPE is still a nightmare in
 comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably
 better than nothing but you shouldn't have to rely on the customer
 supplied equipment being configured correctly to just auth to the
 network - that's the job

Re: [WISPA] Ubiquiti Radios as routers

2012-10-21 Thread Mike Hammett
*smh*



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Butch Evans but...@butchevans.com
To: WISPA General List wireless@wispa.org
Sent: Friday, October 19, 2012 6:20:23 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers

On Fri, 2012-10-19 at 15:50 -0500, Mike Hammett wrote:
 What we're (well, I am anyway) saying is that the way 
 the WISP industry does it...  is sub-optimal. 

The way YOU are doing it may be sub-optimal.  It is not an industry wide
problem.  There are ways to accomplish what you want.

 The customer should be able to supply whatever device they want, be 
 handed up to a configured maximum number of public IP addresses (specified 
 per account), but the CPE has managed all account authorization. 

You are missing a key component here.  It is NEVER the CPE that manages
anything.  Even in the cable world.  It is the NETWORK that manages the
CPE.

 The customer should still be permitted to pass 1500 byte packets. The 
 customer shouldn't have any configuration on their behalf. You know...  
 how cable does it.

Your presumptions and statements tell me you really don't understand
what happens in a DOCSIS environment.  

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-21 Thread Mike Hammett
It wouldn't be hard to accomplish, no. RADIUS already tells MT the necessary 
information for PPPoE or DHCP. Canopy and UBNT already have manual methods of 
defining speed. Everything provides a method for authenticating the customer 
radio to the AP.

Since all of the pieces are already there in one form or another, it shouldn't 
be difficult to go the rest of the way. Other than custom solutions that cost 
thousands of dollars, there's no way of doing what I want.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Butch Evans but...@butchevans.com
To: WISPA General List wireless@wispa.org
Sent: Friday, October 19, 2012 6:11:39 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers

On Fri, 2012-10-19 at 16:49 -0500, Mike Hammett wrote:
 No.
 
 The cable modem (radio) does the authentication (therefore rate limiting, one 
 address per house, etc.) while the customer supplied device is the terminus 
 for the public IP and does the NAT. I install the radio, hand them the cat6 
 out of the back of the PoE and they plug it into whatever their heart 
 desires. That device receives my public IP address without any configuration, 
 yet the customer is still rate limited (automatically, not manual queues). If 
 they require two public IPs, I simply configure the back-end to allow two 
 DHCP leases from devices behind that CPE.

This is not that hard to accomplish.  I have a partnership in a WISP in
Texas that does almost exactly what you want.  It just takes a little
creativity, time and expertise.  Further, there is no client to client
communication through the wireless device, so broadcasts, even on a
local network, are eliminated.  This is already built into ubiquiti,
canopy, mikrotik and a number of other devices you could use as CPE
radios.  IF a customer want's a different speed plan, they visit their
portal and select it.  Within seconds, they have been upgraded (or
downgraded) to the new plan.  There is no human intervention required
beyond the effort that made it possible.  FWIW, this system uses all 3
of the manufacturers I mentioned above and the portal works
(automatically) with all 3.  That portal was written in PHP by a
programmer that I hired and he and I spent a total of about 400 hours
getting it together.  You want one?  Just find a programmer and tell him
what you want and how you accomplish it manually and let him do the
rest, OR start programming it yourself.  It isn't that hard, as Simon
said.

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-21 Thread Butch Evans
On Sun, 2012-10-21 at 09:25 -0500, Mike Hammett wrote:
 Other than custom solutions that cost thousands of dollars, 
 there's no way of doing what I want.

With this one statement, you have summarized the problem.  I will drop
this thread because it has become clear that the problem is not really
about creating or making a standard, but about the desire to have
something for nothing.  Good luck with that.

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-21 Thread Faisal Imtiaz

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/21/2012 9:53 AM, Mike Hammett wrote:
 There is no method known to me in the WISP industry to do what I have 
 described, the ability to separate authentication\provisioning and IP address 
 assignment without requiring extra management.

And what makes you think that such exists for any other segment of our 
industry (other than WiSP) ?

:)

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-21 Thread Faisal Imtiaz
See Comments Inline.

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/21/2012 10:25 AM, Mike Hammett wrote:
 It wouldn't be hard to accomplish, no. RADIUS already tells MT the necessary 
 information for PPPoE or DHCP. Canopy and UBNT already have manual methods of 
 defining speed. Everything provides a method for authenticating the customer 
 radio to the AP.
Ok. I am confused... PPPoe  DHCP are for Resi Services... what are you 
exactly needing ?


 Since all of the pieces are already there in one form or another, it 
 shouldn't be difficult to go the rest of the way.
Rest of the way to what ? I thought we just established that all the 
pieces exist, and all it needs is the 'Glue'... 'integration' to put it 
together for one's specific network.
   Other than custom solutions that cost thousands of dollars, there's no way 
 of doing what I want.
...Hehe.. It costs thousands, because it is worth 10's of Thousands 
integration is never cheap, never has been, nor it will ever be.
You can hire very sharp Russian or Indian programer to do this for you, 
and it will be less expensive than the going rate but  the decision 
you have to make is, what is your ROI going to be on it ?

Remember the 80/20 Rule of Life... It applies here too

:)



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Butch Evans but...@butchevans.com
 To: WISPA General List wireless@wispa.org
 Sent: Friday, October 19, 2012 6:11:39 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 On Fri, 2012-10-19 at 16:49 -0500, Mike Hammett wrote:
 No.

 The cable modem (radio) does the authentication (therefore rate limiting, 
 one address per house, etc.) while the customer supplied device is the 
 terminus for the public IP and does the NAT. I install the radio, hand them 
 the cat6 out of the back of the PoE and they plug it into whatever their 
 heart desires. That device receives my public IP address without any 
 configuration, yet the customer is still rate limited (automatically, not 
 manual queues). If they require two public IPs, I simply configure the 
 back-end to allow two DHCP leases from devices behind that CPE.
 This is not that hard to accomplish.  I have a partnership in a WISP in
 Texas that does almost exactly what you want.  It just takes a little
 creativity, time and expertise.  Further, there is no client to client
 communication through the wireless device, so broadcasts, even on a
 local network, are eliminated.  This is already built into ubiquiti,
 canopy, mikrotik and a number of other devices you could use as CPE
 radios.  IF a customer want's a different speed plan, they visit their
 portal and select it.  Within seconds, they have been upgraded (or
 downgraded) to the new plan.  There is no human intervention required
 beyond the effort that made it possible.  FWIW, this system uses all 3
 of the manufacturers I mentioned above and the portal works
 (automatically) with all 3.  That portal was written in PHP by a
 programmer that I hired and he and I spent a total of about 400 hours
 getting it together.  You want one?  Just find a programmer and tell him
 what you want and how you accomplish it manually and let him do the
 rest, OR start programming it yourself.  It isn't that hard, as Simon
 said.



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-21 Thread Mike Hammett
Well, it would still be a piece-meal operation even if you were able to code 
all of the management pieces. Lots of things in the chain to break.

What I would like to see is the radio platform authenticate the wireless client 
to the AP with RADIUS, providing rate limiting information. Something (whether 
the radio platform is inspecting packets or the DHCP server) has the 
intelligence to restrict the number of DHCP addresses devices behind that radio 
are permitted to have. In most cases, it would be one, but could be another 
amount.

I have a decreasing opinion of custom solutions. They're usually inflexible, 
have variable reliability and cost too much.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Faisal Imtiaz fai...@snappydsl.net
To: wireless@wispa.org
Sent: Sunday, October 21, 2012 1:51:35 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers

See Comments Inline.

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/21/2012 10:25 AM, Mike Hammett wrote:
 It wouldn't be hard to accomplish, no. RADIUS already tells MT the necessary 
 information for PPPoE or DHCP. Canopy and UBNT already have manual methods of 
 defining speed. Everything provides a method for authenticating the customer 
 radio to the AP.
Ok. I am confused... PPPoe  DHCP are for Resi Services... what are you 
exactly needing ?


 Since all of the pieces are already there in one form or another, it 
 shouldn't be difficult to go the rest of the way.
Rest of the way to what ? I thought we just established that all the 
pieces exist, and all it needs is the 'Glue'... 'integration' to put it 
together for one's specific network.
   Other than custom solutions that cost thousands of dollars, there's no way 
 of doing what I want.
...Hehe.. It costs thousands, because it is worth 10's of Thousands 
integration is never cheap, never has been, nor it will ever be.
You can hire very sharp Russian or Indian programer to do this for you, 
and it will be less expensive than the going rate but  the decision 
you have to make is, what is your ROI going to be on it ?

Remember the 80/20 Rule of Life... It applies here too

:)



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Butch Evans but...@butchevans.com
 To: WISPA General List wireless@wispa.org
 Sent: Friday, October 19, 2012 6:11:39 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 On Fri, 2012-10-19 at 16:49 -0500, Mike Hammett wrote:
 No.

 The cable modem (radio) does the authentication (therefore rate limiting, 
 one address per house, etc.) while the customer supplied device is the 
 terminus for the public IP and does the NAT. I install the radio, hand them 
 the cat6 out of the back of the PoE and they plug it into whatever their 
 heart desires. That device receives my public IP address without any 
 configuration, yet the customer is still rate limited (automatically, not 
 manual queues). If they require two public IPs, I simply configure the 
 back-end to allow two DHCP leases from devices behind that CPE.
 This is not that hard to accomplish.  I have a partnership in a WISP in
 Texas that does almost exactly what you want.  It just takes a little
 creativity, time and expertise.  Further, there is no client to client
 communication through the wireless device, so broadcasts, even on a
 local network, are eliminated.  This is already built into ubiquiti,
 canopy, mikrotik and a number of other devices you could use as CPE
 radios.  IF a customer want's a different speed plan, they visit their
 portal and select it.  Within seconds, they have been upgraded (or
 downgraded) to the new plan.  There is no human intervention required
 beyond the effort that made it possible.  FWIW, this system uses all 3
 of the manufacturers I mentioned above and the portal works
 (automatically) with all 3.  That portal was written in PHP by a
 programmer that I hired and he and I spent a total of about 400 hours
 getting it together.  You want one?  Just find a programmer and tell him
 what you want and how you accomplish it manually and let him do the
 rest, OR start programming it yourself.  It isn't that hard, as Simon
 said.



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-21 Thread Scott Reed
I have only been following this thread in a cursory manner, but I, too, 
am missing what you need that is not available.
Lots of radios can authenticate in multiple ways to the AP and accept 
rate limiting information.
If you are OK with the radio limiting the number addresses, make the CPE 
the DHCP server and limit the pool to the number addresses you want as 
the maximum.  Some will accept the pool addresses from Radius as well.

Custom solutions are as flexible on inflexible as the specification 
write makes them.  Having managed a custom solution shop, defining the 
specification correctly is the hard part.  I don't know why a custom 
solution would have different reducibility than an off-the-shelf 
solution.  The reliability is determined by the specification and the 
code writers,  not the intended audience. Custom solutions do not 
generally cost more to create, they are paid fr by fewer entities, 
therefore the cost per user is higher.  If you specify a flexible and 
robust solution, it should naturally move from custom to off-the-shelf 
as others learn about it.


On 10/21/2012 2:57 PM, Mike Hammett wrote:
 Well, it would still be a piece-meal operation even if you were able to code 
 all of the management pieces. Lots of things in the chain to break.

 What I would like to see is the radio platform authenticate the wireless 
 client to the AP with RADIUS, providing rate limiting information. Something 
 (whether the radio platform is inspecting packets or the DHCP server) has the 
 intelligence to restrict the number of DHCP addresses devices behind that 
 radio are permitted to have. In most cases, it would be one, but could be 
 another amount.

 I have a decreasing opinion of custom solutions. They're usually inflexible, 
 have variable reliability and cost too much.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Faisal Imtiaz fai...@snappydsl.net
 To: wireless@wispa.org
 Sent: Sunday, October 21, 2012 1:51:35 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 See Comments Inline.

 Faisal Imtiaz
 Snappy Internet  Telecom
 7266 SW 48 Street
 Miami, Fl 33155
 Tel: 305 663 5518 x 232
 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

 On 10/21/2012 10:25 AM, Mike Hammett wrote:
 It wouldn't be hard to accomplish, no. RADIUS already tells MT the necessary 
 information for PPPoE or DHCP. Canopy and UBNT already have manual methods 
 of defining speed. Everything provides a method for authenticating the 
 customer radio to the AP.
 Ok. I am confused... PPPoe  DHCP are for Resi Services... what are you
 exactly needing ?

 Since all of the pieces are already there in one form or another, it 
 shouldn't be difficult to go the rest of the way.
 Rest of the way to what ? I thought we just established that all the
 pieces exist, and all it needs is the 'Glue'... 'integration' to put it
 together for one's specific network.
Other than custom solutions that cost thousands of dollars, there's no 
 way of doing what I want.
 ...Hehe.. It costs thousands, because it is worth 10's of Thousands
 integration is never cheap, never has been, nor it will ever be.
 You can hire very sharp Russian or Indian programer to do this for you,
 and it will be less expensive than the going rate but  the decision
 you have to make is, what is your ROI going to be on it ?

 Remember the 80/20 Rule of Life... It applies here too

 :)


 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Butch Evans but...@butchevans.com
 To: WISPA General List wireless@wispa.org
 Sent: Friday, October 19, 2012 6:11:39 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 On Fri, 2012-10-19 at 16:49 -0500, Mike Hammett wrote:
 No.

 The cable modem (radio) does the authentication (therefore rate limiting, 
 one address per house, etc.) while the customer supplied device is the 
 terminus for the public IP and does the NAT. I install the radio, hand them 
 the cat6 out of the back of the PoE and they plug it into whatever their 
 heart desires. That device receives my public IP address without any 
 configuration, yet the customer is still rate limited (automatically, not 
 manual queues). If they require two public IPs, I simply configure the 
 back-end to allow two DHCP leases from devices behind that CPE.
 This is not that hard to accomplish.  I have a partnership in a WISP in
 Texas that does almost exactly what you want.  It just takes a little
 creativity, time and expertise.  Further, there is no client to client
 communication through the wireless device, so broadcasts, even on a
 local network, are eliminated.  This is already built into ubiquiti,
 canopy, mikrotik and a number of other devices you could use as CPE
 radios.  IF a customer want's a different speed plan, they visit their
 portal and select it.  Within seconds, they have been upgraded (or
 downgraded

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Fred Goldstein

At 10/19/2012 12:40 AM, Dennis Burgess wrote:


Maybe I should take this off-list but this would be a better 
question.  What RFC or industry standard features are you referring 
?  Specific items!  :)


It's not in RFCs; RFCs are the IETF vehicle, which is really all 
about TCP/IP.  Carrier Ethernet is not theirs.  It's standardized by 
the Metro Ethernet Forum, so the standards have MEF numbers.  MEF in 
turn largely cites IEEE specs from the 802 family, but assembles 
them, with its own touches, into its own packages.



inline comments

On Thu, Oct 18, 2012 at 3:05 PM, Fred Goldstein 
mailto:fgoldst...@ionary.comfgoldst...@ionary.com wrote:

At 10/18/2012 02:52 PM, Dennis Burgess wrote:
MPLS does run over a IP backbone, but can use VPLS tunnels to 
create what you are doing at layer 2.  Not to mention you would get 
all of the benefit of Traffic Engineering, and internal routing 
giving you the best of both worlds.  Why its sometimes called Layer 
2.5, as it creates tunnels inside your routed network, giving you 
fail over and multiple paths.  With TE you can also reserve bandwidth etc. :)


With some implementations of MPLS (TE required) and a whole lot of 
fiddling, you can build an MPLS network that does pretty much what 
Carrier Ethernet does, given enough skilled labor to keep it 
running.  But Carrier Ethernet is a big new market, selling like 
crazy, and there are thus a lot of CE networks out there.  (Cable 
companies and ILECs are both competing for it.)



Also, when you leave the ISP world and deal with the big-money 
IT custoemrs, they have their own MPLS networks, and need 
something to run them over.  CE makes a good substrate for 
MPLS.  Carrier MPLS does not carry customer MPLS as naturally.  In 
fact I think it would be fairly hard to configure that.  I know of 
some real users facing that, where a local fiber network went in 
using MPLS as its basic service, thinking that a government with its 
own MPLS would be able to use it, when they're different MPLS 
domains.  CE would be so much cleaner.  Unlike RINA, where there's 
never a conflict about recursing a layer, TCP/IP protocols tend to 
be written with brittle interfaces to others that are expected to be 
above and below them.


You can run MPLS tags inside a VPLS circuit.  You would simply build 
a VPLS circuit on top of your MPLS network, the MPLS network is 
really the transport, the VPLS is your private layer2 network (or if 
you got VRF or BGP VPLS, you can run in layer3). Thus giving you the 
ability to run another MPLS network over your existing MPLS 
network.  I am not disagreeing that CE could be cleaner, but I am 
not versed in all operations of CE, so its like comparing 
apples/oranges.The example that you used though was VLANs though.


Yes, you can go through some hoops to stack things, when that's 
supported.  (I'm not sure everyone who uses single-company MPLS would 
know how to do all of that though.)  The most extreme case of 
unexpected recursion is VoIP, of course, where an entire stack's 
application payload is in turn potentially just a layer 1 telephone 
call pipe.  Which, if good enough, might support a modem and another 
stack... (just kidding).


But CE does it all a lot more easily and cheaply, if you're trying to 
light a fiber network.  The customer can just plug the routers (with 
or without MPLS) in to the network (which can do its own tagging) and 
the EPL is just a point-to-point link. This btw is essentially the 
old TLS renamed.


Yeah, I'd like Ethernet ports on RouterOS boxes to be that easy to 
use. I think I know how bridges could be set up between them with a 
network in between.  I just don't know RouterOS well enough yet.



So while you can argue the merits of MPLS vs. CE for a brand-new 
metro network, if you are looking for CPE to go onto an existing 
network, you don't put an MPLS box on a CE network, or 
vice-versa!  I'm looking at a (different) real CE network going up 
now where there's an open question of what CPE to use.  I see a 
market opening for a Routerboard-priced SFP box.  But it doesn't 
matter if it costs $39, runs at 10 Gbps, washes windows and makes 
tea, if it doesn't mate with the network and its services.



I just posted another question then, what features with CE 
specifically are you looking for in this box?


Basically what's summed up in the MEF specs, and then I think the EPL 
(ptp) and EVPL (ptmp) options are more important than the LAN 
emulator option. I then want

- tagging (of untagged traffic coming into an EVPL)
- QinQ (carrying tagged traffic)
- CIR and EIR support
- Easy port configuration
- Some OAM capability

Note that in these two services, MAC address is basically treated as 
payload. No traditional bridging takes place.  The VLAN tag is 
really a virtual circuit ID, but for some reason a lot of folks don't 
like that term.


These networks typically end at a CPE that's a small switch (if 
shared) or router (which is part of the customer 

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Simon Westlake
Mike,

I completely agree and I think it is a goal the WISP industry needs to 
work towards - the provisioning of CPE is still a nightmare in 
comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably 
better than nothing but you shouldn't have to rely on the customer 
supplied equipment being configured correctly to just auth to the 
network - that's the job of the ISP CPE.

It's not even that hard of a problem to solve in the grand scheme of things.

On 10/13/2012 8:55 AM, Mike Hammett wrote:
 Well yes it is, but I believe the cable industry has it setup the best. It's 
 easy for the end user to BYOD and the ISP remains hand-off. The WISP industry 
 makes it difficult to do so. Currently everything I do is NATed at the CPE, 
 but I'd like to make that optional, not a requirement. Obviously for 
 enterprise\wholesale level connections I do something different, but there's 
 too many hands involved to do that for residential at this time.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Faisal Imtiaz fai...@snappydsl.net
 To: WISPA General List wireless@wispa.org
 Sent: Saturday, October 13, 2012 8:51:50 AM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 While this is your opinion, others have a different opinion...
 For what is it worth, It would be nice to have Radius attributes for
 provisioning the radio..It currently shows it to be on their todo list.
 As for your other item, I believe DHCP relay is built into the new
 firmware .

 As far as NAT is concerned, it has it's place.

 Regards.

 Faisal Imtiaz
 Snappy Internet  Telecom
 7266 SW 48 Street
 Miami, Fl 33155
 Tel: 305 663 5518 x 232
 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

 On 10/12/2012 10:50 PM, Mike Hammett wrote:
 I want to see the removal of doing anything other than DHCP to the client's 
 device. The CPE radio pulls it's rate-shaping information from RADIUS and 
 allows any number of DHCP clients on a per-CPE basis to pull a public IP.

 An ISP doing NAT is just silly.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Scott Reed sr...@nwwnet.net
 To: WISPA General List wireless@wispa.org
 Sent: Friday, October 12, 2012 8:16:43 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers


 NAT at the at a couple of towers, but not at the CPE.


 On 10/11/2012 6:52 PM, Sam Tetherow wrote:



 Not sure I under stand the no-NAT, so every device on the other side of the 
 CPE has it's own public IP?

 On 10/11/2012 4:53 PM, Scott Reed wrote:


 We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We run 
 them in as routers, but do not NAT. Same benefits others mentioned for 
 routing, just one fewer NAT. Never have a problem with it this way and can't 
 see any good reason to NAT there.


 On 10/11/2012 3:46 PM, Arthur Stephens wrote:


 We currently use Ubiquiti radios in bridge mode and assign a ip address to 
 the customers router.
 He have heard other wisp are using the Ubiquiti radio as a router.
 Would like feed back why one would do this when it appears customers would 
 be double natted when they hook up their routers?
 Or does it not matter from the customer experience?


 Thanks


 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless

-- 
Simon Westlake
Powercode.com
(920) 351-1010




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Josh Luthman
It does build a security, though.  Security = 1/convenience*0.72

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


On Fri, Oct 19, 2012 at 1:55 PM, Simon Westlake si...@powercode.com wrote:

 Mike,

 I completely agree and I think it is a goal the WISP industry needs to
 work towards - the provisioning of CPE is still a nightmare in
 comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably
 better than nothing but you shouldn't have to rely on the customer
 supplied equipment being configured correctly to just auth to the
 network - that's the job of the ISP CPE.

 It's not even that hard of a problem to solve in the grand scheme of
 things.

 On 10/13/2012 8:55 AM, Mike Hammett wrote:
  Well yes it is, but I believe the cable industry has it setup the best.
 It's easy for the end user to BYOD and the ISP remains hand-off. The WISP
 industry makes it difficult to do so. Currently everything I do is NATed at
 the CPE, but I'd like to make that optional, not a requirement. Obviously
 for enterprise\wholesale level connections I do something different, but
 there's too many hands involved to do that for residential at this time.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: Faisal Imtiaz fai...@snappydsl.net
  To: WISPA General List wireless@wispa.org
  Sent: Saturday, October 13, 2012 8:51:50 AM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
  While this is your opinion, others have a different opinion...
  For what is it worth, It would be nice to have Radius attributes for
  provisioning the radio..It currently shows it to be on their todo list.
  As for your other item, I believe DHCP relay is built into the new
  firmware .
 
  As far as NAT is concerned, it has it's place.
 
  Regards.
 
  Faisal Imtiaz
  Snappy Internet  Telecom
  7266 SW 48 Street
  Miami, Fl 33155
  Tel: 305 663 5518 x 232
  Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net
 
  On 10/12/2012 10:50 PM, Mike Hammett wrote:
  I want to see the removal of doing anything other than DHCP to the
 client's device. The CPE radio pulls it's rate-shaping information from
 RADIUS and allows any number of DHCP clients on a per-CPE basis to pull a
 public IP.
 
  An ISP doing NAT is just silly.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: Scott Reed sr...@nwwnet.net
  To: WISPA General List wireless@wispa.org
  Sent: Friday, October 12, 2012 8:16:43 PM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
 
  NAT at the at a couple of towers, but not at the CPE.
 
 
  On 10/11/2012 6:52 PM, Sam Tetherow wrote:
 
 
 
  Not sure I under stand the no-NAT, so every device on the other side of
 the CPE has it's own public IP?
 
  On 10/11/2012 4:53 PM, Scott Reed wrote:
 
 
  We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We
 run them in as routers, but do not NAT. Same benefits others mentioned for
 routing, just one fewer NAT. Never have a problem with it this way and
 can't see any good reason to NAT there.
 
 
  On 10/11/2012 3:46 PM, Arthur Stephens wrote:
 
 
  We currently use Ubiquiti radios in bridge mode and assign a ip address
 to the customers router.
  He have heard other wisp are using the Ubiquiti radio as a router.
  Would like feed back why one would do this when it appears customers
 would be double natted when they hook up their routers?
  Or does it not matter from the customer experience?
 
 
  Thanks
 
 
  ___
  Wireless mailing list
  Wireless@wispa.org
  http://lists.wispa.org/mailman/listinfo/wireless
  ___
  Wireless mailing list
  Wireless@wispa.org
  http://lists.wispa.org/mailman/listinfo/wireless

 --
 Simon Westlake
 Powercode.com
 (920) 351-1010




 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Simon Westlake

What builds security?

On 10/19/2012 1:00 PM, Josh Luthman wrote:

It does build a security, though.  Security = 1/convenience*0.72

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


On Fri, Oct 19, 2012 at 1:55 PM, Simon Westlake si...@powercode.com 
mailto:si...@powercode.com wrote:


Mike,

I completely agree and I think it is a goal the WISP industry needs to
work towards - the provisioning of CPE is still a nightmare in
comparison to DOCSIS. PPPoE is not a good solution, IMO - it's
arguably
better than nothing but you shouldn't have to rely on the customer
supplied equipment being configured correctly to just auth to the
network - that's the job of the ISP CPE.

It's not even that hard of a problem to solve in the grand scheme
of things.

On 10/13/2012 8:55 AM, Mike Hammett wrote:
 Well yes it is, but I believe the cable industry has it setup
the best. It's easy for the end user to BYOD and the ISP remains
hand-off. The WISP industry makes it difficult to do so. Currently
everything I do is NATed at the CPE, but I'd like to make that
optional, not a requirement. Obviously for enterprise\wholesale
level connections I do something different, but there's too many
hands involved to do that for residential at this time.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Faisal Imtiaz fai...@snappydsl.net
mailto:fai...@snappydsl.net
 To: WISPA General List wireless@wispa.org
mailto:wireless@wispa.org
 Sent: Saturday, October 13, 2012 8:51:50 AM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 While this is your opinion, others have a different opinion...
 For what is it worth, It would be nice to have Radius attributes for
 provisioning the radio..It currently shows it to be on their
todo list.
 As for your other item, I believe DHCP relay is built into the new
 firmware .

 As far as NAT is concerned, it has it's place.

 Regards.

 Faisal Imtiaz
 Snappy Internet  Telecom
 7266 SW 48 Street
 Miami, Fl 33155
 Tel: 305 663 5518 x 232 tel:305%20663%205518%20x%20232
 Helpdesk: 305 663 5518 tel:305%20663%205518 option 2 Email:
supp...@snappydsl.net

 On 10/12/2012 10:50 PM, Mike Hammett wrote:
 I want to see the removal of doing anything other than DHCP to
the client's device. The CPE radio pulls it's rate-shaping
information from RADIUS and allows any number of DHCP clients on a
per-CPE basis to pull a public IP.

 An ISP doing NAT is just silly.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Scott Reed sr...@nwwnet.net mailto:sr...@nwwnet.net
 To: WISPA General List wireless@wispa.org
mailto:wireless@wispa.org
 Sent: Friday, October 12, 2012 8:16:43 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers


 NAT at the at a couple of towers, but not at the CPE.


 On 10/11/2012 6:52 PM, Sam Tetherow wrote:



 Not sure I under stand the no-NAT, so every device on the other
side of the CPE has it's own public IP?

 On 10/11/2012 4:53 PM, Scott Reed wrote:


 We run MT, not UBNT, CPE, but it doesn't matter what brand it
is. We run them in as routers, but do not NAT. Same benefits
others mentioned for routing, just one fewer NAT. Never have a
problem with it this way and can't see any good reason to NAT there.


 On 10/11/2012 3:46 PM, Arthur Stephens wrote:


 We currently use Ubiquiti radios in bridge mode and assign a ip
address to the customers router.
 He have heard other wisp are using the Ubiquiti radio as a router.
 Would like feed back why one would do this when it appears
customers would be double natted when they hook up their routers?
 Or does it not matter from the customer experience?


 Thanks


 ___
 Wireless mailing list
 Wireless@wispa.org mailto:Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
 ___
 Wireless mailing list
 Wireless@wispa.org mailto:Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless

--
Simon Westlake
Powercode.com
(920) 351-1010 tel:%28920%29%20351-1010




___
Wireless mailing list
Wireless@wispa.org mailto:Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


--
Simon Westlake

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Josh Luthman
The opposite of convenience and standardization.  You do things your way, I
do things my way, another guy does things his way - makes it hard to jump
from network to network from a white hat or black hat perspective.

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


On Fri, Oct 19, 2012 at 2:05 PM, Simon Westlake si...@powercode.com wrote:

  What builds security?


 On 10/19/2012 1:00 PM, Josh Luthman wrote:

 It does build a security, though.  Security = 1/convenience*0.72

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


 On Fri, Oct 19, 2012 at 1:55 PM, Simon Westlake si...@powercode.comwrote:

 Mike,

 I completely agree and I think it is a goal the WISP industry needs to
 work towards - the provisioning of CPE is still a nightmare in
 comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably
 better than nothing but you shouldn't have to rely on the customer
 supplied equipment being configured correctly to just auth to the
 network - that's the job of the ISP CPE.

 It's not even that hard of a problem to solve in the grand scheme of
 things.

 On 10/13/2012 8:55 AM, Mike Hammett wrote:
  Well yes it is, but I believe the cable industry has it setup the best.
 It's easy for the end user to BYOD and the ISP remains hand-off. The WISP
 industry makes it difficult to do so. Currently everything I do is NATed at
 the CPE, but I'd like to make that optional, not a requirement. Obviously
 for enterprise\wholesale level connections I do something different, but
 there's too many hands involved to do that for residential at this time.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: Faisal Imtiaz fai...@snappydsl.net
  To: WISPA General List wireless@wispa.org
  Sent: Saturday, October 13, 2012 8:51:50 AM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
  While this is your opinion, others have a different opinion...
  For what is it worth, It would be nice to have Radius attributes for
  provisioning the radio..It currently shows it to be on their todo list.
  As for your other item, I believe DHCP relay is built into the new
  firmware .
 
  As far as NAT is concerned, it has it's place.
 
  Regards.
 
  Faisal Imtiaz
  Snappy Internet  Telecom
  7266 SW 48 Street
  Miami, Fl 33155
  Tel: 305 663 5518 x 232
  Helpdesk: 305 663 5518 305%20663%205518 option 2 Email:
 supp...@snappydsl.net
 
  On 10/12/2012 10:50 PM, Mike Hammett wrote:
  I want to see the removal of doing anything other than DHCP to the
 client's device. The CPE radio pulls it's rate-shaping information from
 RADIUS and allows any number of DHCP clients on a per-CPE basis to pull a
 public IP.
 
  An ISP doing NAT is just silly.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: Scott Reed sr...@nwwnet.net
  To: WISPA General List wireless@wispa.org
  Sent: Friday, October 12, 2012 8:16:43 PM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
 
  NAT at the at a couple of towers, but not at the CPE.
 
 
  On 10/11/2012 6:52 PM, Sam Tetherow wrote:
 
 
 
  Not sure I under stand the no-NAT, so every device on the other side
 of the CPE has it's own public IP?
 
  On 10/11/2012 4:53 PM, Scott Reed wrote:
 
 
  We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We
 run them in as routers, but do not NAT. Same benefits others mentioned for
 routing, just one fewer NAT. Never have a problem with it this way and
 can't see any good reason to NAT there.
 
 
  On 10/11/2012 3:46 PM, Arthur Stephens wrote:
 
 
  We currently use Ubiquiti radios in bridge mode and assign a ip
 address to the customers router.
  He have heard other wisp are using the Ubiquiti radio as a router.
  Would like feed back why one would do this when it appears customers
 would be double natted when they hook up their routers?
  Or does it not matter from the customer experience?
 
 
  Thanks
 
 
  ___
  Wireless mailing list
  Wireless@wispa.org
  http://lists.wispa.org/mailman/listinfo/wireless
  ___
  Wireless mailing list
  Wireless@wispa.org
  http://lists.wispa.org/mailman/listinfo/wireless

  --
 Simon Westlake
 Powercode.com
 (920) 351-1010 %28920%29%20351-1010




 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless




 ___
 Wireless mailing 
 listWireless@wispa.orghttp://lists.wispa.org/mailman/listinfo/wireless


 --
 Simon Westlake
 Powercode.com(920) 351-1010




 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Butch Evans
On Fri, 2012-10-19 at 12:55 -0500, Simon Westlake wrote:
 I completely agree and I think it is a goal the WISP industry needs to 
 work towards - the provisioning of CPE is still a nightmare in 
 comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably 
 better than nothing but you shouldn't have to rely on the customer 
 supplied equipment being configured correctly to just auth to the 
 network - that's the job of the ISP CPE.

In some regards, I agree with your take on this.  It isn't really fair
to compare ethernet-like protocols that WISPs use to DOCSIS, though.
DOCSIS is it's own transport and one of the things that was built into
the standard is authentication.  That is not so with ethernet-like
protocols.  There IS some level of authentication available for this
purpose, however.  We can use radio/AP authentication based on MAC
addresses of radios, which offers at least a small amount of security.
We have SOME proprietary protocol devices, such as Canopy, AirMAX and
nstreme, that offer various levels of security and authentication
mechanisms (most are still MAC-based).  The problem is that even with
this authentication, it is still not provisioning.  The main issue to
contend with regarding provisioning is the difference between physical
connectivity (Cables) vs RF connectivity that requires SOME
configuration in the CPE to even allow it to connect in the first place.
There are a number of methods to provide CPE provisioning beyond that
first step, which ARE easy to accomplish.

 It's not even that hard of a problem to solve in the grand scheme of things.

This is true.  If there were only some software company that would come
up with a way to make this easier and add some level of security into
the mix  :-)

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Simon Westlake
 This is true.  If there were only some software company that would come
 up with a way to make this easier and add some level of security into
 the mix  :-)

Perhaps I have said too much

;)

-- 
Simon Westlake
Powercode.com
(920) 351-1010




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread LTI - Dennis Burgess
don't know why you would let the customer equipment auth. our network all
auth is done at the CPE that we control.

On Fri, Oct 19, 2012 at 12:55 PM, Simon Westlake si...@powercode.comwrote:

 Mike,

 I completely agree and I think it is a goal the WISP industry needs to
 work towards - the provisioning of CPE is still a nightmare in
 comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably
 better than nothing but you shouldn't have to rely on the customer
 supplied equipment being configured correctly to just auth to the
 network - that's the job of the ISP CPE.

 It's not even that hard of a problem to solve in the grand scheme of
 things.

 On 10/13/2012 8:55 AM, Mike Hammett wrote:
  Well yes it is, but I believe the cable industry has it setup the best.
 It's easy for the end user to BYOD and the ISP remains hand-off. The WISP
 industry makes it difficult to do so. Currently everything I do is NATed at
 the CPE, but I'd like to make that optional, not a requirement. Obviously
 for enterprise\wholesale level connections I do something different, but
 there's too many hands involved to do that for residential at this time.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: Faisal Imtiaz fai...@snappydsl.net
  To: WISPA General List wireless@wispa.org
  Sent: Saturday, October 13, 2012 8:51:50 AM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
  While this is your opinion, others have a different opinion...
  For what is it worth, It would be nice to have Radius attributes for
  provisioning the radio..It currently shows it to be on their todo list.
  As for your other item, I believe DHCP relay is built into the new
  firmware .
 
  As far as NAT is concerned, it has it's place.
 
  Regards.
 
  Faisal Imtiaz
  Snappy Internet  Telecom
  7266 SW 48 Street
  Miami, Fl 33155
  Tel: 305 663 5518 x 232
  Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net
 
  On 10/12/2012 10:50 PM, Mike Hammett wrote:
  I want to see the removal of doing anything other than DHCP to the
 client's device. The CPE radio pulls it's rate-shaping information from
 RADIUS and allows any number of DHCP clients on a per-CPE basis to pull a
 public IP.
 
  An ISP doing NAT is just silly.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: Scott Reed sr...@nwwnet.net
  To: WISPA General List wireless@wispa.org
  Sent: Friday, October 12, 2012 8:16:43 PM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
 
  NAT at the at a couple of towers, but not at the CPE.
 
 
  On 10/11/2012 6:52 PM, Sam Tetherow wrote:
 
 
 
  Not sure I under stand the no-NAT, so every device on the other side of
 the CPE has it's own public IP?
 
  On 10/11/2012 4:53 PM, Scott Reed wrote:
 
 
  We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We
 run them in as routers, but do not NAT. Same benefits others mentioned for
 routing, just one fewer NAT. Never have a problem with it this way and
 can't see any good reason to NAT there.
 
 
  On 10/11/2012 3:46 PM, Arthur Stephens wrote:
 
 
  We currently use Ubiquiti radios in bridge mode and assign a ip address
 to the customers router.
  He have heard other wisp are using the Ubiquiti radio as a router.
  Would like feed back why one would do this when it appears customers
 would be double natted when they hook up their routers?
  Or does it not matter from the customer experience?
 
 
  Thanks
 
 
  ___
  Wireless mailing list
  Wireless@wispa.org
  http://lists.wispa.org/mailman/listinfo/wireless
  ___
  Wireless mailing list
  Wireless@wispa.org
  http://lists.wispa.org/mailman/listinfo/wireless

 --
 Simon Westlake
 Powercode.com
 (920) 351-1010




 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless




-- 

*Dennis Burgess, Mikrotik Certified Trainer** Author of Learn RouterOS-
Second Edition http://www.wlan1.com/product_p/mikrotik%20book-2.htm”

 Link Technologies, Inc -- Mikrotik  WISP Support
Services

 Office*: 314-735-0270 *Website*: http://www.linktechs.net – *Skype*:
linktechs
* **-- Create Wireless Coverage’s with *www.towercoverage.com* **– 900Mhz –
LTE – 3G – 3.65 – TV Whitespace
**

*
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Simon Westlake
I pretty much say 'meh' to that. What it really means is that a smart 
person can probably quickly find a way to exploit your network because 
everyone is reinventing the wheel and making a lot of mistakes doing it.


I get what you're saying but I don't agree that it is a good reason for 
lack of standardization. Imagine how nice it would be if you could just 
hook up an SM and have the following things happen:


Customer plugs in any device and it just works (no calling you to have 
you help configure PPPoE, authorize their new MAC)

Customer loops their network and it doesn't break stuff beyond the SM
Customer can't do stuff beyond the SM even though it's not running NAT 
(e.g. ARP poisoning)

Rate limiting, etc, is standardized in the SM

This is a small subset what you get with a cable modem, and a cable 
modem is not a (at a high level) complicated or expensive device.


On 10/19/2012 1:14 PM, Josh Luthman wrote:
The opposite of convenience and standardization.  You do things your 
way, I do things my way, another guy does things his way - makes it 
hard to jump from network to network from a white hat or black hat 
perspective.


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


On Fri, Oct 19, 2012 at 2:05 PM, Simon Westlake si...@powercode.com 
mailto:si...@powercode.com wrote:


What builds security?


On 10/19/2012 1:00 PM, Josh Luthman wrote:

It does build a security, though.  Security = 1/convenience*0.72

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


On Fri, Oct 19, 2012 at 1:55 PM, Simon Westlake
si...@powercode.com mailto:si...@powercode.com wrote:

Mike,

I completely agree and I think it is a goal the WISP industry
needs to
work towards - the provisioning of CPE is still a nightmare in
comparison to DOCSIS. PPPoE is not a good solution, IMO -
it's arguably
better than nothing but you shouldn't have to rely on the
customer
supplied equipment being configured correctly to just auth to the
network - that's the job of the ISP CPE.

It's not even that hard of a problem to solve in the grand
scheme of things.

On 10/13/2012 8:55 AM, Mike Hammett wrote:
 Well yes it is, but I believe the cable industry has it
setup the best. It's easy for the end user to BYOD and the
ISP remains hand-off. The WISP industry makes it difficult to
do so. Currently everything I do is NATed at the CPE, but I'd
like to make that optional, not a requirement. Obviously for
enterprise\wholesale level connections I do something
different, but there's too many hands involved to do that for
residential at this time.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Faisal Imtiaz fai...@snappydsl.net
mailto:fai...@snappydsl.net
 To: WISPA General List wireless@wispa.org
mailto:wireless@wispa.org
 Sent: Saturday, October 13, 2012 8:51:50 AM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 While this is your opinion, others have a different opinion...
 For what is it worth, It would be nice to have Radius
attributes for
 provisioning the radio..It currently shows it to be on
their todo list.
 As for your other item, I believe DHCP relay is built into
the new
 firmware .

 As far as NAT is concerned, it has it's place.

 Regards.

 Faisal Imtiaz
 Snappy Internet  Telecom
 7266 SW 48 Street
 Miami, Fl 33155
 Tel: 305 663 5518 x 232 tel:305%20663%205518%20x%20232
 Helpdesk: 305 663 5518 tel:305%20663%205518 option 2
Email: supp...@snappydsl.net mailto:supp...@snappydsl.net

 On 10/12/2012 10:50 PM, Mike Hammett wrote:
 I want to see the removal of doing anything other than
DHCP to the client's device. The CPE radio pulls it's
rate-shaping information from RADIUS and allows any number of
DHCP clients on a per-CPE basis to pull a public IP.

 An ISP doing NAT is just silly.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Scott Reed sr...@nwwnet.net
mailto:sr...@nwwnet.net
 To: WISPA General List wireless@wispa.org
mailto:wireless@wispa.org
 Sent: Friday, October 12, 2012 8:16:43 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers


 NAT at the at a couple of towers

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Simon Westlake
On 10/19/2012 1:48 PM, LTI - Dennis Burgess wrote:
 don't know why you would let the customer equipment auth. our network 
 all auth is done at the CPE that we control.

A lot of people are enabling public IPs at the premise by having the 
customer router engage in PPPoE with the ISP concentrator. That's one 
scenario in which it happens.

-- 
Simon Westlake
Powercode.com
(920) 351-1010




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Josh Luthman
I have all of that now.  I NAT the CPE.

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


On Fri, Oct 19, 2012 at 2:49 PM, Simon Westlake si...@powercode.com wrote:

  I pretty much say 'meh' to that. What it really means is that a smart
 person can probably quickly find a way to exploit your network because
 everyone is reinventing the wheel and making a lot of mistakes doing it.

 I get what you're saying but I don't agree that it is a good reason for
 lack of standardization. Imagine how nice it would be if you could just
 hook up an SM and have the following things happen:

 Customer plugs in any device and it just works (no calling you to have you
 help configure PPPoE, authorize their new MAC)
 Customer loops their network and it doesn't break stuff beyond the SM
 Customer can't do stuff beyond the SM even though it's not running NAT
 (e.g. ARP poisoning)
 Rate limiting, etc, is standardized in the SM

 This is a small subset what you get with a cable modem, and a cable modem
 is not a (at a high level) complicated or expensive device.


 On 10/19/2012 1:14 PM, Josh Luthman wrote:

 The opposite of convenience and standardization.  You do things your way,
 I do things my way, another guy does things his way - makes it hard to jump
 from network to network from a white hat or black hat perspective.

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


 On Fri, Oct 19, 2012 at 2:05 PM, Simon Westlake si...@powercode.comwrote:

  What builds security?


 On 10/19/2012 1:00 PM, Josh Luthman wrote:

 It does build a security, though.  Security = 1/convenience*0.72

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


 On Fri, Oct 19, 2012 at 1:55 PM, Simon Westlake si...@powercode.comwrote:

 Mike,

 I completely agree and I think it is a goal the WISP industry needs to
 work towards - the provisioning of CPE is still a nightmare in
 comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably
 better than nothing but you shouldn't have to rely on the customer
 supplied equipment being configured correctly to just auth to the
 network - that's the job of the ISP CPE.

 It's not even that hard of a problem to solve in the grand scheme of
 things.

 On 10/13/2012 8:55 AM, Mike Hammett wrote:
  Well yes it is, but I believe the cable industry has it setup the
 best. It's easy for the end user to BYOD and the ISP remains hand-off. The
 WISP industry makes it difficult to do so. Currently everything I do is
 NATed at the CPE, but I'd like to make that optional, not a requirement.
 Obviously for enterprise\wholesale level connections I do something
 different, but there's too many hands involved to do that for residential
 at this time.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: Faisal Imtiaz fai...@snappydsl.net
  To: WISPA General List wireless@wispa.org
  Sent: Saturday, October 13, 2012 8:51:50 AM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
  While this is your opinion, others have a different opinion...
  For what is it worth, It would be nice to have Radius attributes for
  provisioning the radio..It currently shows it to be on their todo list.
  As for your other item, I believe DHCP relay is built into the new
  firmware .
 
  As far as NAT is concerned, it has it's place.
 
  Regards.
 
  Faisal Imtiaz
  Snappy Internet  Telecom
  7266 SW 48 Street
  Miami, Fl 33155
  Tel: 305 663 5518 x 232 305%20663%205518%20x%20232
  Helpdesk: 305 663 5518 305%20663%205518 option 2 Email:
 supp...@snappydsl.net
 
  On 10/12/2012 10:50 PM, Mike Hammett wrote:
  I want to see the removal of doing anything other than DHCP to the
 client's device. The CPE radio pulls it's rate-shaping information from
 RADIUS and allows any number of DHCP clients on a per-CPE basis to pull a
 public IP.
 
  An ISP doing NAT is just silly.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: Scott Reed sr...@nwwnet.net
  To: WISPA General List wireless@wispa.org
  Sent: Friday, October 12, 2012 8:16:43 PM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
 
  NAT at the at a couple of towers, but not at the CPE.
 
 
  On 10/11/2012 6:52 PM, Sam Tetherow wrote:
 
 
 
  Not sure I under stand the no-NAT, so every device on the other side
 of the CPE has it's own public IP?
 
  On 10/11/2012 4:53 PM, Scott Reed wrote:
 
 
  We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We
 run them in as routers, but do not NAT. Same benefits others mentioned for
 routing, just one fewer NAT. Never have a problem with it this way and
 can't see any good reason to NAT there.
 
 
  On 10/11/2012 3:46 PM, Arthur Stephens wrote:
 
 
  We currently use Ubiquiti radios in bridge mode and assign a ip
 address

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Simon Westlake
Yeah.. that's the solution most WISPs are forced into. Would sure be 
nice to do it without NAT.


On 10/19/2012 1:58 PM, Josh Luthman wrote:

I have all of that now.  I NAT the CPE.

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


On Fri, Oct 19, 2012 at 2:49 PM, Simon Westlake si...@powercode.com 
mailto:si...@powercode.com wrote:


I pretty much say 'meh' to that. What it really means is that a
smart person can probably quickly find a way to exploit your
network because everyone is reinventing the wheel and making a lot
of mistakes doing it.

I get what you're saying but I don't agree that it is a good
reason for lack of standardization. Imagine how nice it would be
if you could just hook up an SM and have the following things happen:

Customer plugs in any device and it just works (no calling you to
have you help configure PPPoE, authorize their new MAC)
Customer loops their network and it doesn't break stuff beyond the SM
Customer can't do stuff beyond the SM even though it's not running
NAT (e.g. ARP poisoning)
Rate limiting, etc, is standardized in the SM

This is a small subset what you get with a cable modem, and a
cable modem is not a (at a high level) complicated or expensive
device.


On 10/19/2012 1:14 PM, Josh Luthman wrote:

The opposite of convenience and standardization.  You do things
your way, I do things my way, another guy does things his way -
makes it hard to jump from network to network from a white hat or
black hat perspective.

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


On Fri, Oct 19, 2012 at 2:05 PM, Simon Westlake
si...@powercode.com mailto:si...@powercode.com wrote:

What builds security?


On 10/19/2012 1:00 PM, Josh Luthman wrote:

It does build a security, though.  Security =
1/convenience*0.72

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


On Fri, Oct 19, 2012 at 1:55 PM, Simon Westlake
si...@powercode.com mailto:si...@powercode.com wrote:

Mike,

I completely agree and I think it is a goal the WISP
industry needs to
work towards - the provisioning of CPE is still a
nightmare in
comparison to DOCSIS. PPPoE is not a good solution, IMO
- it's arguably
better than nothing but you shouldn't have to rely on
the customer
supplied equipment being configured correctly to just
auth to the
network - that's the job of the ISP CPE.

It's not even that hard of a problem to solve in the
grand scheme of things.

On 10/13/2012 8:55 AM, Mike Hammett wrote:
 Well yes it is, but I believe the cable industry has
it setup the best. It's easy for the end user to BYOD
and the ISP remains hand-off. The WISP industry makes it
difficult to do so. Currently everything I do is NATed
at the CPE, but I'd like to make that optional, not a
requirement. Obviously for enterprise\wholesale level
connections I do something different, but there's too
many hands involved to do that for residential at this time.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Faisal Imtiaz fai...@snappydsl.net
mailto:fai...@snappydsl.net
 To: WISPA General List wireless@wispa.org
mailto:wireless@wispa.org
 Sent: Saturday, October 13, 2012 8:51:50 AM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 While this is your opinion, others have a different
opinion...
 For what is it worth, It would be nice to have Radius
attributes for
 provisioning the radio..It currently shows it to be on
their todo list.
 As for your other item, I believe DHCP relay is built
into the new
 firmware .

 As far as NAT is concerned, it has it's place.

 Regards.

 Faisal Imtiaz
 Snappy Internet  Telecom
 7266 SW 48 Street
 Miami, Fl 33155
 Tel: 305 663 5518 x 232 tel:305%20663%205518%20x%20232
 Helpdesk: 305 663 5518 tel:305%20663%205518 option 2
Email: supp...@snappydsl.net mailto:supp...@snappydsl.net

 On 10/12/2012 10:50

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Mike Hammett
What we're (well, I am anyway) saying is that the way the WISP industry does 
it...  is sub-optimal. The customer should be able to supply whatever device 
they want, be handed up to a configured maximum number of public IP addresses 
(specified per account), but the CPE has managed all account authorization. The 
customer should still be permitted to pass 1500 byte packets. The customer 
shouldn't have any configuration on their behalf. You know...  how cable does 
it.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: LTI - Dennis Burgess gmsm...@gmail.com
To: WISPA General List wireless@wispa.org
Sent: Friday, October 19, 2012 1:48:58 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers


don't know why you would let the customer equipment auth. our network all auth 
is done at the CPE that we control. 


On Fri, Oct 19, 2012 at 12:55 PM, Simon Westlake  si...@powercode.com  wrote: 


Mike, 

I completely agree and I think it is a goal the WISP industry needs to 
work towards - the provisioning of CPE is still a nightmare in 
comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably 
better than nothing but you shouldn't have to rely on the customer 
supplied equipment being configured correctly to just auth to the 
network - that's the job of the ISP CPE. 

It's not even that hard of a problem to solve in the grand scheme of things. 



On 10/13/2012 8:55 AM, Mike Hammett wrote: 
 Well yes it is, but I believe the cable industry has it setup the best. It's 
 easy for the end user to BYOD and the ISP remains hand-off. The WISP industry 
 makes it difficult to do so. Currently everything I do is NATed at the CPE, 
 but I'd like to make that optional, not a requirement. Obviously for 
 enterprise\wholesale level connections I do something different, but there's 
 too many hands involved to do that for residential at this time. 
 
 
 
 - 
 Mike Hammett 
 Intelligent Computing Solutions 
 http://www.ics-il.com 
 
 - Original Message - 
 From: Faisal Imtiaz  fai...@snappydsl.net  
 To: WISPA General List  wireless@wispa.org  
 Sent: Saturday, October 13, 2012 8:51:50 AM 
 Subject: Re: [WISPA] Ubiquiti Radios as routers 
 
 While this is your opinion, others have a different opinion... 
 For what is it worth, It would be nice to have Radius attributes for 
 provisioning the radio..It currently shows it to be on their todo list. 
 As for your other item, I believe DHCP relay is built into the new 
 firmware . 
 
 As far as NAT is concerned, it has it's place. 
 
 Regards. 
 
 Faisal Imtiaz 
 Snappy Internet  Telecom 
 7266 SW 48 Street 
 Miami, Fl 33155 
 Tel: 305 663 5518 x 232 
 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net 
 
 On 10/12/2012 10:50 PM, Mike Hammett wrote: 
 I want to see the removal of doing anything other than DHCP to the client's 
 device. The CPE radio pulls it's rate-shaping information from RADIUS and 
 allows any number of DHCP clients on a per-CPE basis to pull a public IP. 
 
 An ISP doing NAT is just silly. 
 
 
 
 - 
 Mike Hammett 
 Intelligent Computing Solutions 
 http://www.ics-il.com 
 
 - Original Message - 
 From: Scott Reed  sr...@nwwnet.net  
 To: WISPA General List  wireless@wispa.org  
 Sent: Friday, October 12, 2012 8:16:43 PM 
 Subject: Re: [WISPA] Ubiquiti Radios as routers 
 
 
 NAT at the at a couple of towers, but not at the CPE. 
 
 
 On 10/11/2012 6:52 PM, Sam Tetherow wrote: 
 
 
 
 Not sure I under stand the no-NAT, so every device on the other side of the 
 CPE has it's own public IP? 
 
 On 10/11/2012 4:53 PM, Scott Reed wrote: 
 
 
 We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We run 
 them in as routers, but do not NAT. Same benefits others mentioned for 
 routing, just one fewer NAT. Never have a problem with it this way and can't 
 see any good reason to NAT there. 
 
 
 On 10/11/2012 3:46 PM, Arthur Stephens wrote: 
 
 
 We currently use Ubiquiti radios in bridge mode and assign a ip address to 
 the customers router. 
 He have heard other wisp are using the Ubiquiti radio as a router. 
 Would like feed back why one would do this when it appears customers would 
 be double natted when they hook up their routers? 
 Or does it not matter from the customer experience? 
 
 
 Thanks 
 
 
 ___ 
 Wireless mailing list 
 Wireless@wispa.org 
 http://lists.wispa.org/mailman/listinfo/wireless 
 ___ 
 Wireless mailing list 
 Wireless@wispa.org 
 http://lists.wispa.org/mailman/listinfo/wireless 

-- 
Simon Westlake 
Powercode.com 
(920) 351-1010 






___ 
Wireless mailing list 
Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 




-- 


Dennis Burgess, Mikrotik Certified Trainer Author of  Learn RouterOS- Second 
Edition ” 
Link Technologies, Inc -- Mikrotik  WISP Support Services

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Mike Hammett
Except that's sub-optimal. I do it that way, but it's not the best way of doing 
it. We shouldn't have to manage that.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Josh Luthman j...@imaginenetworksllc.com
To: WISPA General List wireless@wispa.org
Sent: Friday, October 19, 2012 1:58:13 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers


I have all of that now. I NAT the CPE. 

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



On Fri, Oct 19, 2012 at 2:49 PM, Simon Westlake  si...@powercode.com  wrote: 



I pretty much say 'meh' to that. What it really means is that a smart person 
can probably quickly find a way to exploit your network because everyone is 
reinventing the wheel and making a lot of mistakes doing it. 

I get what you're saying but I don't agree that it is a good reason for lack of 
standardization. Imagine how nice it would be if you could just hook up an SM 
and have the following things happen: 

Customer plugs in any device and it just works (no calling you to have you help 
configure PPPoE, authorize their new MAC) 
Customer loops their network and it doesn't break stuff beyond the SM 
Customer can't do stuff beyond the SM even though it's not running NAT (e.g. 
ARP poisoning) 
Rate limiting, etc, is standardized in the SM 

This is a small subset what you get with a cable modem, and a cable modem is 
not a (at a high level) complicated or expensive device. 




On 10/19/2012 1:14 PM, Josh Luthman wrote: 


The opposite of convenience and standardization. You do things your way, I do 
things my way, another guy does things his way - makes it hard to jump from 
network to network from a white hat or black hat perspective. 

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



On Fri, Oct 19, 2012 at 2:05 PM, Simon Westlake  si...@powercode.com  wrote: 



What builds security? 




On 10/19/2012 1:00 PM, Josh Luthman wrote: 


It does build a security, though. Security = 1/convenience*0.72 

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



On Fri, Oct 19, 2012 at 1:55 PM, Simon Westlake  si...@powercode.com  wrote: 


Mike, 

I completely agree and I think it is a goal the WISP industry needs to 
work towards - the provisioning of CPE is still a nightmare in 
comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably 
better than nothing but you shouldn't have to rely on the customer 
supplied equipment being configured correctly to just auth to the 
network - that's the job of the ISP CPE. 

It's not even that hard of a problem to solve in the grand scheme of things. 



On 10/13/2012 8:55 AM, Mike Hammett wrote: 
 Well yes it is, but I believe the cable industry has it setup the best. It's 
 easy for the end user to BYOD and the ISP remains hand-off. The WISP industry 
 makes it difficult to do so. Currently everything I do is NATed at the CPE, 
 but I'd like to make that optional, not a requirement. Obviously for 
 enterprise\wholesale level connections I do something different, but there's 
 too many hands involved to do that for residential at this time. 
 
 
 
 - 
 Mike Hammett 
 Intelligent Computing Solutions 
 http://www.ics-il.com 
 
 - Original Message - 
 From: Faisal Imtiaz  fai...@snappydsl.net  
 To: WISPA General List  wireless@wispa.org  
 Sent: Saturday, October 13, 2012 8:51:50 AM 
 Subject: Re: [WISPA] Ubiquiti Radios as routers 
 
 While this is your opinion, others have a different opinion... 
 For what is it worth, It would be nice to have Radius attributes for 
 provisioning the radio..It currently shows it to be on their todo list. 
 As for your other item, I believe DHCP relay is built into the new 
 firmware . 
 
 As far as NAT is concerned, it has it's place. 
 
 Regards. 
 
 Faisal Imtiaz 
 Snappy Internet  Telecom 
 7266 SW 48 Street 
 Miami, Fl 33155 
 Tel: 305 663 5518 x 232 
 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net 
 
 On 10/12/2012 10:50 PM, Mike Hammett wrote: 
 I want to see the removal of doing anything other than DHCP to the client's 
 device. The CPE radio pulls it's rate-shaping information from RADIUS and 
 allows any number of DHCP clients on a per-CPE basis to pull a public IP. 
 
 An ISP doing NAT is just silly. 
 
 
 
 - 
 Mike Hammett 
 Intelligent Computing Solutions 
 http://www.ics-il.com 
 
 - Original Message - 
 From: Scott Reed  sr...@nwwnet.net  
 To: WISPA General List  wireless@wispa.org  
 Sent: Friday, October 12, 2012 8:16:43 PM 
 Subject: Re: [WISPA] Ubiquiti Radios as routers 
 
 
 NAT at the at a couple of towers, but not at the CPE. 
 
 
 On 10/11/2012 6:52 PM, Sam Tetherow wrote: 
 
 
 
 Not sure I under stand the no-NAT, so every device on the other side of the 
 CPE has it's own public IP? 
 
 On 10/11/2012 4:53 PM, Scott Reed wrote

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Mike Hammett
It's going to require the radio company to do it first.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Butch Evans but...@butchevans.com
To: WISPA General List wireless@wispa.org
Sent: Friday, October 19, 2012 1:16:07 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers

On Fri, 2012-10-19 at 12:55 -0500, Simon Westlake wrote:
 I completely agree and I think it is a goal the WISP industry needs to 
 work towards - the provisioning of CPE is still a nightmare in 
 comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably 
 better than nothing but you shouldn't have to rely on the customer 
 supplied equipment being configured correctly to just auth to the 
 network - that's the job of the ISP CPE.

In some regards, I agree with your take on this.  It isn't really fair
to compare ethernet-like protocols that WISPs use to DOCSIS, though.
DOCSIS is it's own transport and one of the things that was built into
the standard is authentication.  That is not so with ethernet-like
protocols.  There IS some level of authentication available for this
purpose, however.  We can use radio/AP authentication based on MAC
addresses of radios, which offers at least a small amount of security.
We have SOME proprietary protocol devices, such as Canopy, AirMAX and
nstreme, that offer various levels of security and authentication
mechanisms (most are still MAC-based).  The problem is that even with
this authentication, it is still not provisioning.  The main issue to
contend with regarding provisioning is the difference between physical
connectivity (Cables) vs RF connectivity that requires SOME
configuration in the CPE to even allow it to connect in the first place.
There are a number of methods to provide CPE provisioning beyond that
first step, which ARE easy to accomplish.

 It's not even that hard of a problem to solve in the grand scheme of things.

This is true.  If there were only some software company that would come
up with a way to make this easier and add some level of security into
the mix  :-)

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Butch Evans
On Fri, 2012-10-19 at 15:52 -0500, Mike Hammett wrote:
 Except that's sub-optimal. I do it that way, but it's not the best way of 
 doing it. We shouldn't have to manage that.

What is it that you feel you have to manage behind the natted CPE?
Unless they are a business account, they don't really NEED to do
anything other than private space on their end, which means YOU don't
have to manage anything.  If they ARE a business account, you can hand
them public space.  I don't get what is hard about that...

For example, if you provide static assignments (not pppoe), you can
simply:
1. Configure the public side of the radio
2. Set up NAT
3. Done

If you provide DHCP, you have to:
1. Configure your DHCP server space
2. DONE

If you provide pppoe, you must:
1. Set up user account with their IP address or pool
2. DONE

If you need to provide them a public IP to their gear, behind your CPE
(like your beloved cable companies):
1. Bridge your CPE
2. Do one of the above using THEIR information/router and let them
configure their gear
3. DONE


I don't see the problem you apparently see.


-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Butch Evans
On Fri, 2012-10-19 at 15:52 -0500, Mike Hammett wrote:
 It's going to require the radio company to do it first.

So, you want to see a mechanism in place where you (or your customer)
purchase some random gear, put it on their tower or house and they are
online without you doing anything?  THAT is a bad plan, even if it were
possible.


-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Mike Hammett
I guess not. ;-)

Either they have to configure PPPoE or I have to configure NAT. If they use 
PPPoE, they don't pass 1500 byte packets (I've asked about raising the MTUs 
above 1500 to accommodate, and no one had an answer) and they have to configure 
the router. You use DHCP and now either you can't do the bandwidth shaping or 
you have to mess with knowing their router's MAC address.

Either it doesn't do what it should or there is too much human intervention.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Butch Evans but...@butchevans.com
To: WISPA General List wireless@wispa.org
Sent: Friday, October 19, 2012 4:38:35 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers

On Fri, 2012-10-19 at 15:52 -0500, Mike Hammett wrote:
 Except that's sub-optimal. I do it that way, but it's not the best way of 
 doing it. We shouldn't have to manage that.

What is it that you feel you have to manage behind the natted CPE?
Unless they are a business account, they don't really NEED to do
anything other than private space on their end, which means YOU don't
have to manage anything.  If they ARE a business account, you can hand
them public space.  I don't get what is hard about that...

For example, if you provide static assignments (not pppoe), you can
simply:
1. Configure the public side of the radio
2. Set up NAT
3. Done

If you provide DHCP, you have to:
1. Configure your DHCP server space
2. DONE

If you provide pppoe, you must:
1. Set up user account with their IP address or pool
2. DONE

If you need to provide them a public IP to their gear, behind your CPE
(like your beloved cable companies):
1. Bridge your CPE
2. Do one of the above using THEIR information/router and let them
configure their gear
3. DONE


I don't see the problem you apparently see.


-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Mike Hammett
No.

The cable modem (radio) does the authentication (therefore rate limiting, one 
address per house, etc.) while the customer supplied device is the terminus for 
the public IP and does the NAT. I install the radio, hand them the cat6 out of 
the back of the PoE and they plug it into whatever their heart desires. That 
device receives my public IP address without any configuration, yet the 
customer is still rate limited (automatically, not manual queues). If they 
require two public IPs, I simply configure the back-end to allow two DHCP 
leases from devices behind that CPE.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Butch Evans but...@butchevans.com
To: WISPA General List wireless@wispa.org
Sent: Friday, October 19, 2012 4:40:01 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers

On Fri, 2012-10-19 at 15:52 -0500, Mike Hammett wrote:
 It's going to require the radio company to do it first.

So, you want to see a mechanism in place where you (or your customer)
purchase some random gear, put it on their tower or house and they are
online without you doing anything?  THAT is a bad plan, even if it were
possible.


-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Sam Tetherow
No, I think he wants some piece of equipment that allows the subscriber 
to plug into the ethernet port on his CPE and it is handed a public IP 
address via DHCP (that he can control without knowing the MAC of the 
equipment).

One way to come close would be to assign a /30 to each customer and have 
the CPE in router mode handing out the other end of the /30, but this 
wastes 2 public IPs for each customer which is wasteful, it will also 
require each CPE to be provisioned individually to each customer and 
routing to be done to each CPE.


On 10/19/2012 04:40 PM, Butch Evans wrote:
 On Fri, 2012-10-19 at 15:52 -0500, Mike Hammett wrote:
 It's going to require the radio company to do it first.
 So, you want to see a mechanism in place where you (or your customer)
 purchase some random gear, put it on their tower or house and they are
 online without you doing anything?  THAT is a bad plan, even if it were
 possible.



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Tim Warnock
 Either they have to configure PPPoE or I have to configure NAT. If they use
 PPPoE, they don't pass 1500 byte packets (I've asked about raising the MTUs
 above 1500 to accommodate, and no one had an answer) and they have to
 configure the router. You use DHCP and now either you can't do the
 bandwidth shaping or you have to mess with knowing their router's MAC
 address.

On your trusty cisco:
!
bba-group pppoe global
 tag ppp-max-payload minimum 1508 maximum 1530
!
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Faisal Imtiaz
i will respectfully disagree..WISP Industry is rather a broad 
Term... How one provider (WISP or otherwise) sets up  their Service  
DMARC / Delivery of the Service is totally dependent on the WISP and to 
Whom they are delivering the Service  to.

If you are saying what you are saying in the context of a Residential 
Service Provider, there is plenty of proven options on how to define 
that handoff...
If you are talking about Business service providers then the answer can 
be very different.

While this conversation is very interesting, I am thinking about how 
this applies to us We are not delivering Residential Service, and 
for businesses we do an Ethernet Hand-off, sometimes it is directly off 
the UBNT Radio, other times we install a Mikrotik Router as the Dmarc.

Doing this gives us the the ultimate flexibility to mix and match 
service for the Customer, even in cases where they are wanting to have 
L2 Transport and not internet access.. We use EoIP tunnels to accomplish 
that for them.

While it is nice to have an automated system, but keep in mind that 
automated system and Flexibility are polar opposites.  In my Opinion 
WISP's are specialty providers, and as such have to offer Flexibility...

In case of Residential Service ... There are existing documented ways of 
creating a Walled Garden, and letting the users Register, Cable Industry 
uses this approach for authenticating the Modems and matching them to a 
Subscriber Account..

However, I believe that what Fred is talking about is not something that 
applies fully to Residential Service (Remember all Resi BroadBand is 
classified as best effort, and there is a good reason for it...)

While I can understand Fred asking about CE (Carrier Ethernet) showing 
up in WISP's networks, I am still puzzled as to the need of CE in Radios 
or Routers... Mikrotiks are routers, and very flexible tools There 
is nothing stopping anyone today to deploy these in combination with CE 
switches...

The question of the day then becomes, is the problem the WISP's face, 
have to do with the equipment they are using (not having these 
functionality), or is the problem the WISP, building their network in a 
Layered approach so that the Common Denominators (of functionality) can 
be used as a mass provisioning tool

I personally think that most WISP's want their Radios / devices to do 
everything in the world for them, and do it extremely well, and do it 
for a very in-expensive cost. which of course is not reality.

Customer Provisioning  and Customer management are 'Systems' and not a 
device or protocol ATT / Comcast  / Verizon, have the CPE mfg. 
write special firmware for them to auto provision the devices, WISP's 
can accomplish the same or similar using a Systems approach.


Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/19/2012 4:50 PM, Mike Hammett wrote:
 What we're (well, I am anyway) saying is that the way the WISP industry does 
 it...  is sub-optimal. The customer should be able to supply whatever device 
 they want, be handed up to a configured maximum number of public IP addresses 
 (specified per account), but the CPE has managed all account authorization. 
 The customer should still be permitted to pass 1500 byte packets. The 
 customer shouldn't have any configuration on their behalf. You know...  how 
 cable does it.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: LTI - Dennis Burgess gmsm...@gmail.com
 To: WISPA General List wireless@wispa.org
 Sent: Friday, October 19, 2012 1:48:58 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers


 don't know why you would let the customer equipment auth. our network all 
 auth is done at the CPE that we control.


 On Fri, Oct 19, 2012 at 12:55 PM, Simon Westlake  si...@powercode.com  
 wrote:


 Mike,

 I completely agree and I think it is a goal the WISP industry needs to
 work towards - the provisioning of CPE is still a nightmare in
 comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably
 better than nothing but you shouldn't have to rely on the customer
 supplied equipment being configured correctly to just auth to the
 network - that's the job of the ISP CPE.

 It's not even that hard of a problem to solve in the grand scheme of things.



 On 10/13/2012 8:55 AM, Mike Hammett wrote:
 Well yes it is, but I believe the cable industry has it setup the best. It's 
 easy for the end user to BYOD and the ISP remains hand-off. The WISP 
 industry makes it difficult to do so. Currently everything I do is NATed at 
 the CPE, but I'd like to make that optional, not a requirement. Obviously 
 for enterprise\wholesale level connections I do something different, but 
 there's too many hands involved to do that for residential at this time.



 -
 Mike Hammett
 Intelligent Computing

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Zach Mann
Wish we could unsubscribe from certain, never ending threads.
On Oct 19, 2012 5:52 PM, Faisal Imtiaz fai...@snappydsl.net wrote:

 i will respectfully disagree..WISP Industry is rather a broad
 Term... How one provider (WISP or otherwise) sets up  their Service
 DMARC / Delivery of the Service is totally dependent on the WISP and to
 Whom they are delivering the Service  to.

 If you are saying what you are saying in the context of a Residential
 Service Provider, there is plenty of proven options on how to define
 that handoff...
 If you are talking about Business service providers then the answer can
 be very different.

 While this conversation is very interesting, I am thinking about how
 this applies to us We are not delivering Residential Service, and
 for businesses we do an Ethernet Hand-off, sometimes it is directly off
 the UBNT Radio, other times we install a Mikrotik Router as the Dmarc.

 Doing this gives us the the ultimate flexibility to mix and match
 service for the Customer, even in cases where they are wanting to have
 L2 Transport and not internet access.. We use EoIP tunnels to accomplish
 that for them.

 While it is nice to have an automated system, but keep in mind that
 automated system and Flexibility are polar opposites.  In my Opinion
 WISP's are specialty providers, and as such have to offer Flexibility...

 In case of Residential Service ... There are existing documented ways of
 creating a Walled Garden, and letting the users Register, Cable Industry
 uses this approach for authenticating the Modems and matching them to a
 Subscriber Account..

 However, I believe that what Fred is talking about is not something that
 applies fully to Residential Service (Remember all Resi BroadBand is
 classified as best effort, and there is a good reason for it...)

 While I can understand Fred asking about CE (Carrier Ethernet) showing
 up in WISP's networks, I am still puzzled as to the need of CE in Radios
 or Routers... Mikrotiks are routers, and very flexible tools There
 is nothing stopping anyone today to deploy these in combination with CE
 switches...

 The question of the day then becomes, is the problem the WISP's face,
 have to do with the equipment they are using (not having these
 functionality), or is the problem the WISP, building their network in a
 Layered approach so that the Common Denominators (of functionality) can
 be used as a mass provisioning tool

 I personally think that most WISP's want their Radios / devices to do
 everything in the world for them, and do it extremely well, and do it
 for a very in-expensive cost. which of course is not reality.

 Customer Provisioning  and Customer management are 'Systems' and not a
 device or protocol ATT / Comcast  / Verizon, have the CPE mfg.
 write special firmware for them to auto provision the devices, WISP's
 can accomplish the same or similar using a Systems approach.


 Faisal Imtiaz
 Snappy Internet  Telecom
 7266 SW 48 Street
 Miami, Fl 33155
 Tel: 305 663 5518 x 232
 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

 On 10/19/2012 4:50 PM, Mike Hammett wrote:
  What we're (well, I am anyway) saying is that the way the WISP industry
 does it...  is sub-optimal. The customer should be able to supply whatever
 device they want, be handed up to a configured maximum number of public IP
 addresses (specified per account), but the CPE has managed all account
 authorization. The customer should still be permitted to pass 1500 byte
 packets. The customer shouldn't have any configuration on their behalf. You
 know...  how cable does it.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: LTI - Dennis Burgess gmsm...@gmail.com
  To: WISPA General List wireless@wispa.org
  Sent: Friday, October 19, 2012 1:48:58 PM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
 
  don't know why you would let the customer equipment auth. our network
 all auth is done at the CPE that we control.
 
 
  On Fri, Oct 19, 2012 at 12:55 PM, Simon Westlake  si...@powercode.com 
  wrote:
 
 
  Mike,
 
  I completely agree and I think it is a goal the WISP industry needs to
  work towards - the provisioning of CPE is still a nightmare in
  comparison to DOCSIS. PPPoE is not a good solution, IMO - it's arguably
  better than nothing but you shouldn't have to rely on the customer
  supplied equipment being configured correctly to just auth to the
  network - that's the job of the ISP CPE.
 
  It's not even that hard of a problem to solve in the grand scheme of
 things.
 
 
 
  On 10/13/2012 8:55 AM, Mike Hammett wrote:
  Well yes it is, but I believe the cable industry has it setup the best.
 It's easy for the end user to BYOD and the ISP remains hand-off. The WISP
 industry makes it difficult to do so. Currently everything I do is NATed at
 the CPE, but I'd like to make that optional, not a requirement. Obviously
 for enterprise\wholesale

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Faisal Imtiaz

Sorry bro. hit the delete key.

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/19/2012 6:54 PM, Zach Mann wrote:


Wish we could unsubscribe from certain, never ending threads.

On Oct 19, 2012 5:52 PM, Faisal Imtiaz fai...@snappydsl.net 
mailto:fai...@snappydsl.net wrote:


i will respectfully disagree..WISP Industry is rather a broad
Term... How one provider (WISP or otherwise) sets up  their Service
DMARC / Delivery of the Service is totally dependent on the WISP
and to
Whom they are delivering the Service  to.

If you are saying what you are saying in the context of a Residential
Service Provider, there is plenty of proven options on how to define
that handoff...
If you are talking about Business service providers then the
answer can
be very different.

While this conversation is very interesting, I am thinking about how
this applies to us We are not delivering Residential Service, and
for businesses we do an Ethernet Hand-off, sometimes it is
directly off
the UBNT Radio, other times we install a Mikrotik Router as the Dmarc.

Doing this gives us the the ultimate flexibility to mix and match
service for the Customer, even in cases where they are wanting to have
L2 Transport and not internet access.. We use EoIP tunnels to
accomplish
that for them.

While it is nice to have an automated system, but keep in mind that
automated system and Flexibility are polar opposites.  In my Opinion
WISP's are specialty providers, and as such have to offer
Flexibility...

In case of Residential Service ... There are existing documented
ways of
creating a Walled Garden, and letting the users Register, Cable
Industry
uses this approach for authenticating the Modems and matching them
to a
Subscriber Account..

However, I believe that what Fred is talking about is not
something that
applies fully to Residential Service (Remember all Resi
BroadBand is
classified as best effort, and there is a good reason for it...)

While I can understand Fred asking about CE (Carrier Ethernet) showing
up in WISP's networks, I am still puzzled as to the need of CE in
Radios
or Routers... Mikrotiks are routers, and very flexible tools There
is nothing stopping anyone today to deploy these in combination
with CE
switches...

The question of the day then becomes, is the problem the WISP's face,
have to do with the equipment they are using (not having these
functionality), or is the problem the WISP, building their network
in a
Layered approach so that the Common Denominators (of
functionality) can
be used as a mass provisioning tool

I personally think that most WISP's want their Radios / devices to do
everything in the world for them, and do it extremely well, and do it
for a very in-expensive cost. which of course is not reality.

Customer Provisioning  and Customer management are 'Systems' and not a
device or protocol ATT / Comcast  / Verizon, have the CPE mfg.
write special firmware for them to auto provision the devices, WISP's
can accomplish the same or similar using a Systems approach.


Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232 tel:305%20663%205518%20x%20232
Helpdesk: 305 663 5518 tel:305%20663%205518 option 2 Email:
supp...@snappydsl.net

On 10/19/2012 4:50 PM, Mike Hammett wrote:
 What we're (well, I am anyway) saying is that the way the WISP
industry does it...  is sub-optimal. The customer should be able
to supply whatever device they want, be handed up to a configured
maximum number of public IP addresses (specified per account), but
the CPE has managed all account authorization. The customer should
still be permitted to pass 1500 byte packets. The customer
shouldn't have any configuration on their behalf. You know...  how
cable does it.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: LTI - Dennis Burgess gmsm...@gmail.com
mailto:gmsm...@gmail.com
 To: WISPA General List wireless@wispa.org
mailto:wireless@wispa.org
 Sent: Friday, October 19, 2012 1:48:58 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers


 don't know why you would let the customer equipment auth. our
network all auth is done at the CPE that we control.


 On Fri, Oct 19, 2012 at 12:55 PM, Simon Westlake 
si...@powercode.com mailto:si...@powercode.com  wrote:


 Mike,

 I completely agree and I think it is a goal the WISP industry
needs to
 work towards - the provisioning of CPE is still

Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Butch Evans
On Fri, 2012-10-19 at 16:49 -0500, Mike Hammett wrote:
 No.
 
 The cable modem (radio) does the authentication (therefore rate limiting, one 
 address per house, etc.) while the customer supplied device is the terminus 
 for the public IP and does the NAT. I install the radio, hand them the cat6 
 out of the back of the PoE and they plug it into whatever their heart 
 desires. That device receives my public IP address without any configuration, 
 yet the customer is still rate limited (automatically, not manual queues). If 
 they require two public IPs, I simply configure the back-end to allow two 
 DHCP leases from devices behind that CPE.

This is not that hard to accomplish.  I have a partnership in a WISP in
Texas that does almost exactly what you want.  It just takes a little
creativity, time and expertise.  Further, there is no client to client
communication through the wireless device, so broadcasts, even on a
local network, are eliminated.  This is already built into ubiquiti,
canopy, mikrotik and a number of other devices you could use as CPE
radios.  IF a customer want's a different speed plan, they visit their
portal and select it.  Within seconds, they have been upgraded (or
downgraded) to the new plan.  There is no human intervention required
beyond the effort that made it possible.  FWIW, this system uses all 3
of the manufacturers I mentioned above and the portal works
(automatically) with all 3.  That portal was written in PHP by a
programmer that I hired and he and I spent a total of about 400 hours
getting it together.  You want one?  Just find a programmer and tell him
what you want and how you accomplish it manually and let him do the
rest, OR start programming it yourself.  It isn't that hard, as Simon
said.

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-19 Thread Butch Evans
On Fri, 2012-10-19 at 15:50 -0500, Mike Hammett wrote:
 What we're (well, I am anyway) saying is that the way 
 the WISP industry does it...  is sub-optimal. 

The way YOU are doing it may be sub-optimal.  It is not an industry wide
problem.  There are ways to accomplish what you want.

 The customer should be able to supply whatever device they want, be 
 handed up to a configured maximum number of public IP addresses (specified 
 per account), but the CPE has managed all account authorization. 

You are missing a key component here.  It is NEVER the CPE that manages
anything.  Even in the cable world.  It is the NETWORK that manages the
CPE.

 The customer should still be permitted to pass 1500 byte packets. The 
 customer shouldn't have any configuration on their behalf. You know...  
 how cable does it.

Your presumptions and statements tell me you really don't understand
what happens in a DOCSIS environment.  

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-18 Thread LTI - Dennis Burgess
MPLS does run over a IP backbone, but can use VPLS tunnels to create what
you are doing at layer 2.  Not to mention you would get all of
the benefit of Traffic Engineering, and internal routing giving you the
best of both worlds.  Why its sometimes called Layer 2.5, as it creates
tunnels inside your routed network, giving you fail over and multiple
paths.  With TE you can also reserve bandwidth etc. :)

On Wed, Oct 17, 2012 at 7:16 PM, Fred Goldstein fgoldst...@ionary.comwrote:

 At 10/17/2012 02:26 AM, Jeremy L. Gaddis wrote:
 * Fred Goldstein fgoldst...@ionary.com wrote:
   At 10/12/2012 10:23 AM, Tim Densmore wrote:
   There's a real market gap not quite being filled by our usual WISP
   vendors MT and UBNT.  MT has a new CPE router with SFP support.  This
   would be great for a regional CE fiber network.  Let's say you have a
   building (say, Town Hall) with multiple tenants in it, each with a
   separate IP network (say, Town administration, Police, and School
   Admin).  You'd want to be able to drop off one fiber with separate
   VLANs (virtual circuits) for each network, isolating the traffic from
   each other.  An MEF switch is cheaper than a real Cisco router but a
 
 I can't speak to Ubiquiti but Mikrotik RouterOS certainly supports MPLS
 and VPLS (and LDP and OSPF and BGP).
 
 The design you describe is exactly what the majority of the
 world is using MPLS VPNs for -- utilizing, of course, LDP and BGP (and
 occasionally OSPF between CE and PE).
 
 Unless I'm missing something...

 You're missing something.

 I was specifically asking about Carrier Ethernet.  It's a protocol.
 MPLS is a different protocol which, in the marketplace, largely
 competes with CE.  I know RouterOS supports MPLS.  But CE is different.

 Disregarding that CE is much more multi-protocol in support than
 MultiProtocol Label Switching, whose multi protocols are, in general,
 IP and IP, CE semantics include explicit CIR and EIR support, along
 with CBS and EBS (burst size) specification, on a per-virtual-circuit
 basis.  MPLS does not have CIR semantics; it just assigns relative
 priorities, and is thus fiddly when offered traffic varies.

 At large volumes (once you get past RouterOS into carrier-class
 products), CE is generally cheaper per bit than MPLS, at least if you
 don't buy Cisco, which pretty much owns MPLS (it's their creation).

 Hamburgers are not chicken, even if both are often served for lunch.

   --
   Fred Goldsteink1io   fgoldstein at ionary.com
   ionary Consulting  http://www.ionary.com/
   +1 617 795 2701

 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless




-- 

*Dennis Burgess, Mikrotik Certified Trainer** Author of Learn RouterOS-
Second Edition http://www.wlan1.com/product_p/mikrotik%20book-2.htm”

 Link Technologies, Inc -- Mikrotik  WISP Support
Services

 Office*: 314-735-0270 *Website*: http://www.linktechs.net – *Skype*:
linktechs
* **-- Create Wireless Coverage’s with *www.towercoverage.com* **– 900Mhz –
LTE – 3G – 3.65 – TV Whitespace
**5-Day Advanced RouterOS Workshop -- July 23rd 2012 – St. Louis, MO,
USAhttp://www.wlan1.com/RouterOS_Training_p/5d-stl-training-july2012.htm
5-Day Advanced RouterOS Workshop – Oct 8th 2012 – St. Louis, MO,
USAhttp://www.wlan1.com/RouterOS_Training_p/5d-stl-training-oct2012.htm

*
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-18 Thread Justin Wilson
There are several things you can do to alleviate issues. Greg Osborn is
right. Most customers don't know a difference.  We do several tricks on
various networks.

1.We do 1:MANY nats at every POP.  This way only those customers at that
site are natted out a Public.  This way the entire network does not go
through a single public IP.

2.We do run the UBNT radios in router mode.  However, everyone goes out the
door with the DMZ enabled with a specific IP on the lag side.  If we have a
customer call and request a public for whatever reason it's a simple
process.  We change the IP in billing, they reboot, PPPoE assigns the
public.  All they have to do is statically set their router/PC ip to the IP
which is in the DMZ.  This works for 98% of customers.

Justin

From:  Arthur Stephens arthur.steph...@ptera.net
Reply-To:  WISPA General List wireless@wispa.org
Date:  Thursday, October 11, 2012 3:46 PM
To:  wireless@wispa.org
Subject:  [WISPA] Ubiquiti Radios as routers

 We currently use Ubiquiti radios in bridge mode and assign a ip address to the
 customers router.
 He have heard other wisp are using the Ubiquiti radio as a router.
 Would like feed back why one would do this when it appears customers would be
 double natted when they hook up their routers?
 Or does it not matter from the customer experience?
 
 Thanks
 
 -- 
 Arthur Stephens 
 Senior Sales Technician
 Ptera Wireless Inc.
 PO Box 135
 24001 E Mission Suite 50
 Liberty Lake, WA 99019
 509-927-7837 
 For technical support visit http://www.ptera.net/support
  -
 This message may contain confidential and/or propriety information, and is
 intended for the person/entity to whom it was originally addressed.
 Any use by others is strictly prohibited. Please note that any views or
 opinions presented in this email are solely those of the author and are not
 intended to represent those of the company.
 ___ Wireless mailing list
 Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-18 Thread Fred Goldstein

At 10/18/2012 02:52 PM, Dennis Burgess wrote:
MPLS does run over a IP backbone, but can use VPLS tunnels to create 
what you are doing at layer 2.  Not to mention you would get all of 
the benefit of Traffic Engineering, and internal routing giving you 
the best of both worlds.  Why its sometimes called Layer 2.5, as it 
creates tunnels inside your routed network, giving you fail over and 
multiple paths.  With TE you can also reserve bandwidth etc. :)


With some implementations of MPLS (TE required) and a whole lot of 
fiddling, you can build an MPLS network that does pretty much what 
Carrier Ethernet does, given enough skilled labor to keep it 
running.  But Carrier Ethernet is a big new market, selling like 
crazy, and there are thus a lot of CE networks out there.  (Cable 
companies and ILECs are both competing for it.)


Also, when you leave the ISP world and deal with the big-money IT 
custoemrs, they have their own MPLS networks, and need something to 
run them over.  CE makes a good substrate for MPLS.  Carrier MPLS 
does not carry customer MPLS as naturally.  In fact I think it would 
be fairly hard to configure that.  I know of some real users facing 
that, where a local fiber network went in using MPLS as its basic 
service, thinking that a government with its own MPLS would be able 
to use it, when they're different MPLS domains.  CE would be so much 
cleaner.  Unlike RINA, where there's never a conflict about recursing 
a layer, TCP/IP protocols tend to be written with brittle interfaces 
to others that are expected to be above and below them.


So while you can argue the merits of MPLS vs. CE for a brand-new 
metro network, if you are looking for CPE to go onto an existing 
network, you don't put an MPLS box on a CE network, or 
vice-versa!  I'm looking at a (different) real CE network going up 
now where there's an open question of what CPE to use.  I see a 
market opening for a Routerboard-priced SFP box.  But it doesn't 
matter if it costs $39, runs at 10 Gbps, washes windows and makes 
tea, if it doesn't mate with the network and its services.


On Wed, Oct 17, 2012 at 7:16 PM, Fred Goldstein 
mailto:fgoldst...@ionary.comfgoldst...@ionary.com wrote:

At 10/17/2012 02:26 AM, Jeremy L. Gaddis wrote:
* Fred Goldstein 
mailto:fgoldst...@ionary.comfgoldst...@ionary.com wrote:

  At 10/12/2012 10:23 AM, Tim Densmore wrote:
  There's a real market gap not quite being filled by our usual WISP
  vendors MT and UBNT.  MT has a new CPE router with SFP support.  This
  would be great for a regional CE fiber network.  Let's say you have a
  building (say, Town Hall) with multiple tenants in it, each with a
  separate IP network (say, Town administration, Police, and School
  Admin).  You'd want to be able to drop off one fiber with separate
  VLANs (virtual circuits) for each network, isolating the traffic from
  each other.  An MEF switch is cheaper than a real Cisco router but a

I can't speak to Ubiquiti but Mikrotik RouterOS certainly supports MPLS
and VPLS (and LDP and OSPF and BGP).

The design you describe is exactly what the majority of the
world is using MPLS VPNs for -- utilizing, of course, LDP and BGP (and
occasionally OSPF between CE and PE).

Unless I'm missing something...

You're missing something.

I was specifically asking about Carrier Ethernet.  It's a protocol.
MPLS is a different protocol which, in the marketplace, largely
competes with CE.  I know RouterOS supports MPLS.  But CE is different.

Disregarding that CE is much more multi-protocol in support than
MultiProtocol Label Switching, whose multi protocols are, in general,
IP and IP, CE semantics include explicit CIR and EIR support, along
with CBS and EBS (burst size) specification, on a per-virtual-circuit
basis.  MPLS does not have CIR semantics; it just assigns relative
priorities, and is thus fiddly when offered traffic varies.

At large volumes (once you get past RouterOS into carrier-class
products), CE is generally cheaper per bit than MPLS, at least if you
don't buy Cisco, which pretty much owns MPLS (it's their creation).

Hamburgers are not chicken, even if both are often served for lunch.

  --
  Fred Goldsteink1io   fgoldstein at http://ionary.comionary.com
  ionary 
Consulting  http://www.ionary.com/http://www.ionary.com/

  tel:%2B1%20617%20795%202701+1 617 795 2701

___
Wireless mailing list
mailto:Wireless@wispa.orgWireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless




--

Dennis Burgess, Mikrotik Certified Trainer Author of 
http://www.wlan1.com/product_p/mikrotik%20book-2.htmLearn 
RouterOS- Second Edition
 Link Technologies, Inc -- Mikrotik  WISP Support 
Services 

 Office: 314-735-0270 Website: 
http://www.linktechs.net/http://www.linktechs.net – Skype: 
linktechs
 -- Create Wireless Coverage's with 
http://www.towercoverage.com/www.towercoverage.com – 900Mhz – LTE 
– 3G – 3.65 – TV Whitespace

Re: [WISPA] Ubiquiti Radios as routers

2012-10-18 Thread Mike Hammett
Fred is a very smart guy and generally plays with the big boy versions of 
what we do. I'd be careful disagreeing with him.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: LTI - Dennis Burgess gmsm...@gmail.com
To: WISPA General List wireless@wispa.org
Sent: Thursday, October 18, 2012 1:52:39 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers


MPLS does run over a IP backbone, but can use VPLS tunnels to create what you 
are doing at layer 2. Not to mention you would get all of the benefit of 
Traffic Engineering, and internal routing giving you the best of both worlds. 
Why its sometimes called Layer 2.5, as it creates tunnels inside your routed 
network, giving you fail over and multiple paths. With TE you can also reserve 
bandwidth etc. :) 


On Wed, Oct 17, 2012 at 7:16 PM, Fred Goldstein  fgoldst...@ionary.com  
wrote: 



At 10/17/2012 02:26 AM, Jeremy L. Gaddis wrote: 
* Fred Goldstein  fgoldst...@ionary.com  wrote: 
  At 10/12/2012 10:23 AM, Tim Densmore wrote: 
  There's a real market gap not quite being filled by our usual WISP 
  vendors MT and UBNT. MT has a new CPE router with SFP support. This 
  would be great for a regional CE fiber network. Let's say you have a 
  building (say, Town Hall) with multiple tenants in it, each with a 
  separate IP network (say, Town administration, Police, and School 
  Admin). You'd want to be able to drop off one fiber with separate 
  VLANs (virtual circuits) for each network, isolating the traffic from 
  each other. An MEF switch is cheaper than a real Cisco router but a 
 
I can't speak to Ubiquiti but Mikrotik RouterOS certainly supports MPLS 
and VPLS (and LDP and OSPF and BGP). 
 
The design you describe is exactly what the majority of the 
world is using MPLS VPNs for -- utilizing, of course, LDP and BGP (and 
occasionally OSPF between CE and PE). 
 
Unless I'm missing something... 

You're missing something. 

I was specifically asking about Carrier Ethernet. It's a protocol. 
MPLS is a different protocol which, in the marketplace, largely 
competes with CE. I know RouterOS supports MPLS. But CE is different. 

Disregarding that CE is much more multi-protocol in support than 
MultiProtocol Label Switching, whose multi protocols are, in general, 
IP and IP, CE semantics include explicit CIR and EIR support, along 
with CBS and EBS (burst size) specification, on a per-virtual-circuit 
basis. MPLS does not have CIR semantics; it just assigns relative 
priorities, and is thus fiddly when offered traffic varies. 

At large volumes (once you get past RouterOS into carrier-class 
products), CE is generally cheaper per bit than MPLS, at least if you 
don't buy Cisco, which pretty much owns MPLS (it's their creation). 

Hamburgers are not chicken, even if both are often served for lunch. 


-- 
Fred Goldstein k1io fgoldstein at ionary.com 
ionary Consulting http://www.ionary.com/ 
+1 617 795 2701 



___ 
Wireless mailing list 
Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 




-- 


Dennis Burgess, Mikrotik Certified Trainer Author of  Learn RouterOS- Second 
Edition ” 
Link Technologies, Inc -- Mikrotik  WISP Support Services 
Office : 314-735-0270 Website : http://www.linktechs.net – Skype : linktechs 
-- Create Wireless Coverage’s with www.towercoverage.com – 900Mhz – LTE – 3G – 
3.65 – TV Whitespace 
5-Day Advanced RouterOS Workshop -- July 23 rd 2012 – St. Louis, MO, USA 
5-Day Advanced RouterOS Workshop – Oct 8 th 2012 – St. Louis, MO, USA 



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-18 Thread Faisal Imtiaz
Dennis is also very smart... This is a great discussion...not just about 
agreement or disagreement..it is more about comparison of different 
technologies, both theoretical and practice...

Most WISP networks are rather simple and smaller when compared to the carrier 
world. I believe there are some good operational lessons on both types of 
network.




Faisal

On Oct 18, 2012, at 6:40 PM, Mike Hammett wispawirel...@ics-il.net wrote:

 Fred is a very smart guy and generally plays with the big boy versions of 
 what we do. I'd be careful disagreeing with him.
 
 
 
 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com
 
 - Original Message -
 From: LTI - Dennis Burgess gmsm...@gmail.com
 To: WISPA General List wireless@wispa.org
 Sent: Thursday, October 18, 2012 1:52:39 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers
 
 
 MPLS does run over a IP backbone, but can use VPLS tunnels to create what you 
 are doing at layer 2. Not to mention you would get all of the benefit of 
 Traffic Engineering, and internal routing giving you the best of both worlds. 
 Why its sometimes called Layer 2.5, as it creates tunnels inside your routed 
 network, giving you fail over and multiple paths. With TE you can also 
 reserve bandwidth etc. :) 
 
 
 On Wed, Oct 17, 2012 at 7:16 PM, Fred Goldstein  fgoldst...@ionary.com  
 wrote: 
 
 
 
 At 10/17/2012 02:26 AM, Jeremy L. Gaddis wrote: 
 * Fred Goldstein  fgoldst...@ionary.com  wrote: 
 At 10/12/2012 10:23 AM, Tim Densmore wrote: 
 There's a real market gap not quite being filled by our usual WISP 
 vendors MT and UBNT. MT has a new CPE router with SFP support. This 
 would be great for a regional CE fiber network. Let's say you have a 
 building (say, Town Hall) with multiple tenants in it, each with a 
 separate IP network (say, Town administration, Police, and School 
 Admin). You'd want to be able to drop off one fiber with separate 
 VLANs (virtual circuits) for each network, isolating the traffic from 
 each other. An MEF switch is cheaper than a real Cisco router but a 
 
 I can't speak to Ubiquiti but Mikrotik RouterOS certainly supports MPLS 
 and VPLS (and LDP and OSPF and BGP). 
 
 The design you describe is exactly what the majority of the 
 world is using MPLS VPNs for -- utilizing, of course, LDP and BGP (and 
 occasionally OSPF between CE and PE). 
 
 Unless I'm missing something... 
 
 You're missing something. 
 
 I was specifically asking about Carrier Ethernet. It's a protocol. 
 MPLS is a different protocol which, in the marketplace, largely 
 competes with CE. I know RouterOS supports MPLS. But CE is different. 
 
 Disregarding that CE is much more multi-protocol in support than 
 MultiProtocol Label Switching, whose multi protocols are, in general, 
 IP and IP, CE semantics include explicit CIR and EIR support, along 
 with CBS and EBS (burst size) specification, on a per-virtual-circuit 
 basis. MPLS does not have CIR semantics; it just assigns relative 
 priorities, and is thus fiddly when offered traffic varies. 
 
 At large volumes (once you get past RouterOS into carrier-class 
 products), CE is generally cheaper per bit than MPLS, at least if you 
 don't buy Cisco, which pretty much owns MPLS (it's their creation). 
 
 Hamburgers are not chicken, even if both are often served for lunch. 
 
 
 -- 
 Fred Goldstein k1io fgoldstein at ionary.com 
 ionary Consulting http://www.ionary.com/ 
 +1 617 795 2701 
 
 
 
 ___ 
 Wireless mailing list 
 Wireless@wispa.org 
 http://lists.wispa.org/mailman/listinfo/wireless 
 
 
 
 
 -- 
 
 
 Dennis Burgess, Mikrotik Certified Trainer Author of  Learn RouterOS- Second 
 Edition ” 
 Link Technologies, Inc -- Mikrotik  WISP Support Services 
 Office : 314-735-0270 Website : http://www.linktechs.net – Skype : linktechs 
 -- Create Wireless Coverage’s with www.towercoverage.com – 900Mhz – LTE – 3G 
 – 3.65 – TV Whitespace 
 5-Day Advanced RouterOS Workshop -- July 23 rd 2012 – St. Louis, MO, USA 
 5-Day Advanced RouterOS Workshop – Oct 8 th 2012 – St. Louis, MO, USA 
 
 
 
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-18 Thread LTI - Dennis Burgess
Maybe I should take this off-list but this would be a better question.
 What RFC or industry standard features are you referring ?  Specific
items!  :)

On Thu, Oct 18, 2012 at 7:42 PM, Faisal Imtiaz fai...@snappydsl.net wrote:

 Dennis is also very smart... This is a great discussion...not just about
 agreement or disagreement..it is more about comparison of different
 technologies, both theoretical and practice...

 Most WISP networks are rather simple and smaller when compared to the
 carrier world. I believe there are some good operational lessons on both
 types of network.




 Faisal

 On Oct 18, 2012, at 6:40 PM, Mike Hammett wispawirel...@ics-il.net
 wrote:

  Fred is a very smart guy and generally plays with the big boy versions
 of what we do. I'd be careful disagreeing with him.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: LTI - Dennis Burgess gmsm...@gmail.com
  To: WISPA General List wireless@wispa.org
  Sent: Thursday, October 18, 2012 1:52:39 PM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
 
  MPLS does run over a IP backbone, but can use VPLS tunnels to create
 what you are doing at layer 2. Not to mention you would get all of the
 benefit of Traffic Engineering, and internal routing giving you the best of
 both worlds. Why its sometimes called Layer 2.5, as it creates tunnels
 inside your routed network, giving you fail over and multiple paths. With
 TE you can also reserve bandwidth etc. :)
 
 
  On Wed, Oct 17, 2012 at 7:16 PM, Fred Goldstein  fgoldst...@ionary.com 
  wrote:
 
 
 
  At 10/17/2012 02:26 AM, Jeremy L. Gaddis wrote:
  * Fred Goldstein  fgoldst...@ionary.com  wrote:
  At 10/12/2012 10:23 AM, Tim Densmore wrote:
  There's a real market gap not quite being filled by our usual WISP
  vendors MT and UBNT. MT has a new CPE router with SFP support. This
  would be great for a regional CE fiber network. Let's say you have a
  building (say, Town Hall) with multiple tenants in it, each with a
  separate IP network (say, Town administration, Police, and School
  Admin). You'd want to be able to drop off one fiber with separate
  VLANs (virtual circuits) for each network, isolating the traffic from
  each other. An MEF switch is cheaper than a real Cisco router but a
 
  I can't speak to Ubiquiti but Mikrotik RouterOS certainly supports MPLS
  and VPLS (and LDP and OSPF and BGP).
 
  The design you describe is exactly what the majority of the
  world is using MPLS VPNs for -- utilizing, of course, LDP and BGP (and
  occasionally OSPF between CE and PE).
 
  Unless I'm missing something...
 
  You're missing something.
 
  I was specifically asking about Carrier Ethernet. It's a protocol.
  MPLS is a different protocol which, in the marketplace, largely
  competes with CE. I know RouterOS supports MPLS. But CE is different.
 
  Disregarding that CE is much more multi-protocol in support than
  MultiProtocol Label Switching, whose multi protocols are, in general,
  IP and IP, CE semantics include explicit CIR and EIR support, along
  with CBS and EBS (burst size) specification, on a per-virtual-circuit
  basis. MPLS does not have CIR semantics; it just assigns relative
  priorities, and is thus fiddly when offered traffic varies.
 
  At large volumes (once you get past RouterOS into carrier-class
  products), CE is generally cheaper per bit than MPLS, at least if you
  don't buy Cisco, which pretty much owns MPLS (it's their creation).
 
  Hamburgers are not chicken, even if both are often served for lunch.
 
 
  --
  Fred Goldstein k1io fgoldstein at ionary.com
  ionary Consulting http://www.ionary.com/
  +1 617 795 2701
 
 
 
  ___
  Wireless mailing list
  Wireless@wispa.org
  http://lists.wispa.org/mailman/listinfo/wireless
 
 
 
 
  --
 
 
  Dennis Burgess, Mikrotik Certified Trainer Author of  Learn RouterOS-
 Second Edition ”
  Link Technologies, Inc -- Mikrotik  WISP Support Services
  Office : 314-735-0270 Website : http://www.linktechs.net – Skype :
 linktechs
  -- Create Wireless Coverage’s with www.towercoverage.com – 900Mhz – LTE
 – 3G – 3.65 – TV Whitespace
  5-Day Advanced RouterOS Workshop -- July 23 rd 2012 – St. Louis, MO, USA
  5-Day Advanced RouterOS Workshop – Oct 8 th 2012 – St. Louis, MO, USA
 
 
 
  ___
  Wireless mailing list
  Wireless@wispa.org
  http://lists.wispa.org/mailman/listinfo/wireless
  ___
  Wireless mailing list
  Wireless@wispa.org
  http://lists.wispa.org/mailman/listinfo/wireless
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless




-- 

*Dennis Burgess, Mikrotik Certified Trainer** Author of Learn RouterOS-
Second Edition http://www.wlan1.com/product_p/mikrotik%20book-2.htm”

 Link Technologies, Inc -- Mikrotik  WISP Support
Services

Re: [WISPA] Ubiquiti Radios as routers

2012-10-18 Thread LTI - Dennis Burgess
inline comments

On Thu, Oct 18, 2012 at 3:05 PM, Fred Goldstein fgoldst...@ionary.comwrote:

  At 10/18/2012 02:52 PM, Dennis Burgess wrote:

 MPLS does run over a IP backbone, but can use VPLS tunnels to create what
 you are doing at layer 2.  Not to mention you would get all of the benefit
 of Traffic Engineering, and internal routing giving you the best of both
 worlds.  Why its sometimes called Layer 2.5, as it creates tunnels inside
 your routed network, giving you fail over and multiple paths.  With TE you
 can also reserve bandwidth etc. :)


 With some implementations of MPLS (TE required) and a whole lot of
 fiddling, you can build an MPLS network that does pretty much what Carrier
 Ethernet does, given enough skilled labor to keep it running.  But Carrier
 Ethernet is a big new market, selling like crazy, and there are thus a lot
 of CE networks out there.  (Cable companies and ILECs are both competing
 for it.)


 Also, when you leave the ISP world and deal with the big-money IT
 custoemrs, they have their own MPLS networks, and need something to run
 them over.  CE makes a good substrate for MPLS.  Carrier MPLS does not
 carry customer MPLS as naturally.  In fact I think it would be fairly hard
 to configure that.  I know of some real users facing that, where a local
 fiber network went in using MPLS as its basic service, thinking that a
 government with its own MPLS would be able to use it, when they're
 different MPLS domains.  CE would be so much cleaner.  Unlike RINA, where
 there's never a conflict about recursing a layer, TCP/IP protocols tend to
 be written with brittle interfaces to others that are expected to be above
 and below them.

You can run MPLS tags inside a VPLS circuit.  You would simply build a VPLS
circuit on top of your MPLS network, the MPLS network is really the
transport, the VPLS is your private layer2 network (or if you got VRF or
BGP VPLS, you can run in layer3). Thus giving you the ability to run
another MPLS network over your existing MPLS network.  I am not disagreeing
that CE could be cleaner, but I am not versed in all operations of CE, so
its like comparing apples/oranges.The example that you used though was
VLANs though.


 So while you can argue the merits of MPLS vs. CE for a brand-new metro
 network, if you are looking for CPE to go onto an existing network, you
 don't put an MPLS box on a CE network, or vice-versa!  I'm looking at a
 (different) real CE network going up now where there's an open question of
 what CPE to use.  I see a market opening for a Routerboard-priced SFP box.
 But it doesn't matter if it costs $39, runs at 10 Gbps, washes windows and
 makes tea, if it doesn't mate with the network and its services.


I just posted another question then, what features with CE specifically are
you looking for in this box?



 On Wed, Oct 17, 2012 at 7:16 PM, Fred Goldstein fgoldst...@ionary.com
 wrote:
  At 10/17/2012 02:26 AM, Jeremy L. Gaddis wrote:
 * Fred Goldstein fgoldst...@ionary.com wrote:
   At 10/12/2012 10:23 AM, Tim Densmore wrote:
   There's a real market gap not quite being filled by our usual WISP
   vendors MT and UBNT.  MT has a new CPE router with SFP support.  This
   would be great for a regional CE fiber network.  Let's say you have a
   building (say, Town Hall) with multiple tenants in it, each with a
   separate IP network (say, Town administration, Police, and School
   Admin).  You'd want to be able to drop off one fiber with separate
   VLANs (virtual circuits) for each network, isolating the traffic from
   each other.  An MEF switch is cheaper than a real Cisco router but a
 
 I can't speak to Ubiquiti but Mikrotik RouterOS certainly supports MPLS
 and VPLS (and LDP and OSPF and BGP).
 
 The design you describe is exactly what the majority of the
 world is using MPLS VPNs for -- utilizing, of course, LDP and BGP (and
 occasionally OSPF between CE and PE).
 
 Unless I'm missing something...

 You're missing something.

 I was specifically asking about Carrier Ethernet.  It's a protocol.
 MPLS is a different protocol which, in the marketplace, largely
 competes with CE.  I know RouterOS supports MPLS.  But CE is different.

 Disregarding that CE is much more multi-protocol in support than
 MultiProtocol Label Switching, whose multi protocols are, in general,
 IP and IP, CE semantics include explicit CIR and EIR support, along
 with CBS and EBS (burst size) specification, on a per-virtual-circuit
 basis.  MPLS does not have CIR semantics; it just assigns relative
 priorities, and is thus fiddly when offered traffic varies.

 At large volumes (once you get past RouterOS into carrier-class
 products), CE is generally cheaper per bit than MPLS, at least if you
 don't buy Cisco, which pretty much owns MPLS (it's their creation).

 Hamburgers are not chicken, even if both are often served for lunch.

   --
   Fred Goldsteink1io   fgoldstein at ionary.com
   ionary Consulting  http://www.ionary.com/
   +1 617 

Re: [WISPA] Ubiquiti Radios as routers

2012-10-17 Thread Jeremy L. Gaddis
* Fred Goldstein fgoldst...@ionary.com wrote:
 At 10/12/2012 10:23 AM, Tim Densmore wrote:
 There's a real market gap not quite being filled by our usual WISP 
 vendors MT and UBNT.  MT has a new CPE router with SFP support.  This 
 would be great for a regional CE fiber network.  Let's say you have a 
 building (say, Town Hall) with multiple tenants in it, each with a 
 separate IP network (say, Town administration, Police, and School 
 Admin).  You'd want to be able to drop off one fiber with separate 
 VLANs (virtual circuits) for each network, isolating the traffic from 
 each other.  An MEF switch is cheaper than a real Cisco router but a 

I can't speak to Ubiquiti but Mikrotik RouterOS certainly supports MPLS
and VPLS (and LDP and OSPF and BGP).

The design you describe is exactly what the majority of the
world is using MPLS VPNs for -- utilizing, of course, LDP and BGP (and
occasionally OSPF between CE and PE).

Unless I'm missing something...

-- 
Jeremy L. Gaddis   e: jer...@as54225.net
Network Engineer   m: +1.812.865.0581


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-17 Thread Fred Goldstein
At 10/17/2012 02:26 AM, Jeremy L. Gaddis wrote:
* Fred Goldstein fgoldst...@ionary.com wrote:
  At 10/12/2012 10:23 AM, Tim Densmore wrote:
  There's a real market gap not quite being filled by our usual WISP
  vendors MT and UBNT.  MT has a new CPE router with SFP support.  This
  would be great for a regional CE fiber network.  Let's say you have a
  building (say, Town Hall) with multiple tenants in it, each with a
  separate IP network (say, Town administration, Police, and School
  Admin).  You'd want to be able to drop off one fiber with separate
  VLANs (virtual circuits) for each network, isolating the traffic from
  each other.  An MEF switch is cheaper than a real Cisco router but a

I can't speak to Ubiquiti but Mikrotik RouterOS certainly supports MPLS
and VPLS (and LDP and OSPF and BGP).

The design you describe is exactly what the majority of the
world is using MPLS VPNs for -- utilizing, of course, LDP and BGP (and
occasionally OSPF between CE and PE).

Unless I'm missing something...

You're missing something.

I was specifically asking about Carrier Ethernet.  It's a protocol. 
MPLS is a different protocol which, in the marketplace, largely 
competes with CE.  I know RouterOS supports MPLS.  But CE is different.

Disregarding that CE is much more multi-protocol in support than 
MultiProtocol Label Switching, whose multi protocols are, in general, 
IP and IP, CE semantics include explicit CIR and EIR support, along 
with CBS and EBS (burst size) specification, on a per-virtual-circuit 
basis.  MPLS does not have CIR semantics; it just assigns relative 
priorities, and is thus fiddly when offered traffic varies.

At large volumes (once you get past RouterOS into carrier-class 
products), CE is generally cheaper per bit than MPLS, at least if you 
don't buy Cisco, which pretty much owns MPLS (it's their creation).

Hamburgers are not chicken, even if both are often served for lunch.

  --
  Fred Goldsteink1io   fgoldstein at ionary.com
  ionary Consulting  http://www.ionary.com/
  +1 617 795 2701 

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Faisal Imtiaz
hehe... A switch is a switch is a switch... and then there are switches 
with additional functionality built in...
The question here is what is this 'other functionality' are we talking 
about ?

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/12/2012 10:47 PM, Mike Hammett wrote:
 Fred, I don't think most of the people here understand what YOU'RE talking 
 about. They think a switch is just a switch and they're all the same, but 
 that's far from the truth.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Fred Goldstein fgoldst...@ionary.com
 To: fai...@snappydsl.net, WISPA General List wireless@wispa.org
 Sent: Friday, October 12, 2012 6:19:49 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 At 10/12/2012 07:06 PM, Faisal Imtiaz wrote:
 Being a Technical person, and a visual learner.. I am having trouble
 translating what Fred is trying to do with a Mikrotik, which he thinks
 it cannot do.
 Actually, I said that I don't know how to do it, not that it can or
 cannot be done.  It may be a documentation problem, that they never
 wrote down how to do it.

 We build our Fixed wireless pop's with a Mikrotik Router doing the
 Routing Functions at each pop.
 Each of the Sectors are connected on their own port.
 AP's and CPE's are setup as WDS Bridges.

 This allows us to create a routed network. (clients on each AP are
 bridged) 

 But, if we wanted to, we could also do Vlan's across this type of setup,
 just as easily, especially now since UBNT firmware fully supports vlans...

 What am I missing ?
 If you're doing routing, how do you also do VLANs?

 The VLAN is at a layer below IP, and (this is a key requirement) the
 IP layer must be totally invisible to the box (RouterOS, EdgeOS,
 etc.), and it might not even be an IP packet inside that VLAN.  If it
 is still IP, the address space belongs to the client, not the ISP.

 The Ethernet layer may require some kind of route-determination
 protocol.  Since it's not a real LAN, STP doesn't really hack it;
 perhaps (in RouterOS) HWMP+ can do it.  This protocol varies among CE
 switches.  If it's an edge (CPE) switch, though, it doesn't need to
 participate in route-determination.


 On 10/12/2012 6:07 PM, Fred Goldstein wrote:
 At 10/12/2012 05:48 PM, Butch Evans wrote:
 On Fri, 2012-10-12 at 10:52 -0400, Fred Goldstein wrote:
 There's a real market gap not quite being filled by our usual WISP
 vendors MT and UBNT.  MT has a new CPE router with SFP support.  This
 would be great for a regional CE fiber network.  Let's say you have a
 building (say, Town Hall) with multiple tenants in it, each with a
 separate IP network (say, Town administration, Police, and School
 Admin).  You'd want to be able to drop off one fiber with separate
 VLANs (virtual circuits) for each network, isolating the traffic from
 each other.  An MEF switch is cheaper than a real Cisco router but a
 Routerboard is cheaper yet!  And it can't route since there are
 multiple independent networks there, each with its own routers and
 firewalls.  Nor is bridging appropriate (not isolating).  So a
 Carrier Ethernet (MEF) switching option would fill that bill.  Of
 course the same software would work with a wireless feed to a
 shared-tenant building, not needing the SFP version.

 I suspect the pieces are all there, just not the assembly
 instructions or tools to facilitate it.  It involves setting up VLANs
 and queues.
 So, what you're saying is that you don't understand HOW to make the
 network using MT as a tool?  NOTE: This is not the same as It can't do
 .  It's all in the documentation.  You just have to either
 figure it out from what is there or ask for help from someone who has.
 Yes, that's what I'm thinking.  They never documented how to put
 those pieces together, though they might work.  And Switched
 Ethernet would be a lovely tab on the side of Winbox and
 Webfig.  I'm from the old school, where the definition of bug is
 an undocumented feature, and where software was written to conform
 to the documentation, not the other way around.

 It is there and can be done in a number of different ways (bridged OR
 switched).  Truth be told, I am amazed at what can be done in a small
 box like the mikrotik devices.  It is a swiss army knife.  However, the
 other side of this coin is that often, there is a BETTER tool for some
 network needs.  Much like a swiss army knife, while it is true that it
 has a screwdriver built in, a REAL screwdriver is usually better suited.
 At the same time, often, you only need the functionality provided by the
 built-in screwdriver, but it takes a special knack to make it do the
 job.  The point being, that while it is certainly possible to make
 RouterOS NOT be a router, why would you?  If you want a switch, put in a
 switch.  If you want to save money

Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Faisal Imtiaz
While this is your opinion, others have a different opinion...
For what is it worth, It would be nice to have Radius attributes for 
provisioning the radio..It currently shows it to be on their todo list.
As for your other item, I believe DHCP relay is built into the new 
firmware .

As far as NAT is concerned, it has it's place.

Regards.

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/12/2012 10:50 PM, Mike Hammett wrote:
 I want to see the removal of doing anything other than DHCP to the client's 
 device. The CPE radio pulls it's rate-shaping information from RADIUS and 
 allows any number of DHCP clients on a per-CPE basis to pull a public IP.

 An ISP doing NAT is just silly.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Scott Reed sr...@nwwnet.net
 To: WISPA General List wireless@wispa.org
 Sent: Friday, October 12, 2012 8:16:43 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers


 NAT at the at a couple of towers, but not at the CPE.


 On 10/11/2012 6:52 PM, Sam Tetherow wrote:



 Not sure I under stand the no-NAT, so every device on the other side of the 
 CPE has it's own public IP?

 On 10/11/2012 4:53 PM, Scott Reed wrote:


 We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We run them 
 in as routers, but do not NAT. Same benefits others mentioned for routing, 
 just one fewer NAT. Never have a problem with it this way and can't see any 
 good reason to NAT there.


 On 10/11/2012 3:46 PM, Arthur Stephens wrote:


 We currently use Ubiquiti radios in bridge mode and assign a ip address to 
 the customers router.
 He have heard other wisp are using the Ubiquiti radio as a router.
 Would like feed back why one would do this when it appears customers would be 
 double natted when they hook up their routers?
 Or does it not matter from the customer experience?


 Thanks



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Faisal Imtiaz
MT makes Software and also Hardware (routerboard)

Blanket statements like the one below do not make sense Every Mfg. 
has a range of limits that their products do a very good job for, it you 
try to use them out of that range they fall flat..

Care to put a context to your statement ?

:)

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/12/2012 10:50 PM, Mike Hammett wrote:
 All MT switching is junk.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Scott Reed sr...@nwwnet.net
 To: WISPA General List wireless@wispa.org
 Sent: Friday, October 12, 2012 8:18:25 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers


 MT has several devices with hardware switches on board and fully accessible 
 through the GUI. They also have a switch sort of based on ROS.

 On 10/11/2012 8:35 PM, Fred Goldstein wrote:


 At 10/11/2012 06:52 PM, SamT wrote:


 Not sure I under stand the no-NAT, so every device on the other side of the 
 CPE has it's own public IP?
 There could be one NAT, at the access point.

 My taste, which to be sure I haven't tested at scale in a wireless network 
 (but plan to), is to follow what is becoming standard wireline practice and 
 do switching, not bridging, at layer 2. Routing would then be lumped into 
 one place, making it easier to manage.

 The problem with small Linux-based systems (this includes both UBNT and MT) 
 is that they don't tend to have switching documented or set up in the UI, 
 even if it's possible. Bridging is bad -- it was designed for orange hose 
 Ethernet, and it passes broadcast traffic to everyone. We invented this at 
 DEC in the 1980s and discovered how it doesn't scale too well -- we had a 
 couple of thousand DECnet and IP nodes on a bridged LAN, and the background 
 broadcast traffic level was 400 kbps. This was a lot for systems to handle in 
 1991. I was testing ISDN bridges and discovered how you can't just bridge 
 that type of network across a 56k connection. (I discovered the traffic when 
 I first turned up the bridge. I ended up isolating it behind a router, built 
 from an old VAX. At DEC, we built everything ouf of VAXen.)

 Switching, though, is what Frame Relay and ATM do, and now Carrier Ethernet 
 is the big thing for fiber. It uses the VLAN tag to identify the virtual 
 circuit; the MAC addresses are just passed along. Since it's 
 connection-oriented (via the tag), it can have QoS assigned. I think it's 
 theoretically possible to tag user ports, route on tags and set QoS on 
 RouterOS, but it's not obvious how to do it all. Switching doesn't pass 
 broadcast traffic; it provides more isolation and privacy than plain routing. 
 Mesh routing then works at that layer, transparent to IP. It'll be 
 interesting to set up.




 On 10/11/2012 4:53 PM, Scott Reed wrote:


 We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We run them 
 in as routers, but do not NAT. Same benefits others mentioned for routing, 
 just one fewer NAT. Never have a problem with it this way and can't see any 
 good reason to NAT there.

 On 10/11/2012 3:46 PM, Arthur Stephens wrote:


 We currently use Ubiquiti radios in bridge mode and assign a ip address to 
 the customers router.
 He have heard other wisp are using the Ubiquiti radio as a router.
 Would like feed back why one would do this when it appears customers would be 
 double natted when they hook up their routers?
 Or does it not matter from the customer experience?

 Thanks



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Mike Hammett
Well yes it is, but I believe the cable industry has it setup the best. It's 
easy for the end user to BYOD and the ISP remains hand-off. The WISP industry 
makes it difficult to do so. Currently everything I do is NATed at the CPE, but 
I'd like to make that optional, not a requirement. Obviously for 
enterprise\wholesale level connections I do something different, but there's 
too many hands involved to do that for residential at this time.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Faisal Imtiaz fai...@snappydsl.net
To: WISPA General List wireless@wispa.org
Sent: Saturday, October 13, 2012 8:51:50 AM
Subject: Re: [WISPA] Ubiquiti Radios as routers

While this is your opinion, others have a different opinion...
For what is it worth, It would be nice to have Radius attributes for 
provisioning the radio..It currently shows it to be on their todo list.
As for your other item, I believe DHCP relay is built into the new 
firmware .

As far as NAT is concerned, it has it's place.

Regards.

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/12/2012 10:50 PM, Mike Hammett wrote:
 I want to see the removal of doing anything other than DHCP to the client's 
 device. The CPE radio pulls it's rate-shaping information from RADIUS and 
 allows any number of DHCP clients on a per-CPE basis to pull a public IP.

 An ISP doing NAT is just silly.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Scott Reed sr...@nwwnet.net
 To: WISPA General List wireless@wispa.org
 Sent: Friday, October 12, 2012 8:16:43 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers


 NAT at the at a couple of towers, but not at the CPE.


 On 10/11/2012 6:52 PM, Sam Tetherow wrote:



 Not sure I under stand the no-NAT, so every device on the other side of the 
 CPE has it's own public IP?

 On 10/11/2012 4:53 PM, Scott Reed wrote:


 We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We run them 
 in as routers, but do not NAT. Same benefits others mentioned for routing, 
 just one fewer NAT. Never have a problem with it this way and can't see any 
 good reason to NAT there.


 On 10/11/2012 3:46 PM, Arthur Stephens wrote:


 We currently use Ubiquiti radios in bridge mode and assign a ip address to 
 the customers router.
 He have heard other wisp are using the Ubiquiti radio as a router.
 Would like feed back why one would do this when it appears customers would be 
 double natted when they hook up their routers?
 Or does it not matter from the customer experience?


 Thanks



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Mike Hammett
The RB250GS is possibly the worst incarnation of a managed switch I have ever 
seen. SNMP continually fails. The VLAN configuration is terrible. You can't 
have tagged and untagged VLANs on a single interface.

With RouterOS based switching chips you gain some additional power, but you 
lose per-interface information and control when you enable the switching and 
you still have to use bridging to do anything beyond whatever ports happen to 
be on the switch chip. Therefore, to use any of the RouterOS features, it is 
bridged and only applies to the switch group as a whole.

Some of this lies with the poor choice in chipsets, while some lies in the poor 
implementation.

Cisco, Dell and Extreme Networks (my current favorite) have almost unlimited 
power and granular control. They don't have some of the features of RouterOS, 
but teaming one of them with something running RouterOS is just as effective as 
using what Mikrotik supplies.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Faisal Imtiaz fai...@snappydsl.net
To: wireless@wispa.org
Sent: Saturday, October 13, 2012 8:54:25 AM
Subject: Re: [WISPA] Ubiquiti Radios as routers

MT makes Software and also Hardware (routerboard)

Blanket statements like the one below do not make sense Every Mfg. 
has a range of limits that their products do a very good job for, it you 
try to use them out of that range they fall flat..

Care to put a context to your statement ?

:)

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/12/2012 10:50 PM, Mike Hammett wrote:
 All MT switching is junk.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Scott Reed sr...@nwwnet.net
 To: WISPA General List wireless@wispa.org
 Sent: Friday, October 12, 2012 8:18:25 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers


 MT has several devices with hardware switches on board and fully accessible 
 through the GUI. They also have a switch sort of based on ROS.

 On 10/11/2012 8:35 PM, Fred Goldstein wrote:


 At 10/11/2012 06:52 PM, SamT wrote:


 Not sure I under stand the no-NAT, so every device on the other side of the 
 CPE has it's own public IP?
 There could be one NAT, at the access point.

 My taste, which to be sure I haven't tested at scale in a wireless network 
 (but plan to), is to follow what is becoming standard wireline practice and 
 do switching, not bridging, at layer 2. Routing would then be lumped into 
 one place, making it easier to manage.

 The problem with small Linux-based systems (this includes both UBNT and MT) 
 is that they don't tend to have switching documented or set up in the UI, 
 even if it's possible. Bridging is bad -- it was designed for orange hose 
 Ethernet, and it passes broadcast traffic to everyone. We invented this at 
 DEC in the 1980s and discovered how it doesn't scale too well -- we had a 
 couple of thousand DECnet and IP nodes on a bridged LAN, and the background 
 broadcast traffic level was 400 kbps. This was a lot for systems to handle in 
 1991. I was testing ISDN bridges and discovered how you can't just bridge 
 that type of network across a 56k connection. (I discovered the traffic when 
 I first turned up the bridge. I ended up isolating it behind a router, built 
 from an old VAX. At DEC, we built everything ouf of VAXen.)

 Switching, though, is what Frame Relay and ATM do, and now Carrier Ethernet 
 is the big thing for fiber. It uses the VLAN tag to identify the virtual 
 circuit; the MAC addresses are just passed along. Since it's 
 connection-oriented (via the tag), it can have QoS assigned. I think it's 
 theoretically possible to tag user ports, route on tags and set QoS on 
 RouterOS, but it's not obvious how to do it all. Switching doesn't pass 
 broadcast traffic; it provides more isolation and privacy than plain routing. 
 Mesh routing then works at that layer, transparent to IP. It'll be 
 interesting to set up.




 On 10/11/2012 4:53 PM, Scott Reed wrote:


 We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We run them 
 in as routers, but do not NAT. Same benefits others mentioned for routing, 
 just one fewer NAT. Never have a problem with it this way and can't see any 
 good reason to NAT there.

 On 10/11/2012 3:46 PM, Arthur Stephens wrote:


 We currently use Ubiquiti radios in bridge mode and assign a ip address to 
 the customers router.
 He have heard other wisp are using the Ubiquiti radio as a router.
 Would like feed back why one would do this when it appears customers would be 
 double natted when they hook up their routers?
 Or does it not matter from the customer experience?

 Thanks



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Josh Luthman
How would you have an untagged VLAN?

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


On Sat, Oct 13, 2012 at 10:02 AM, Mike Hammett wispawirel...@ics-il.netwrote:

 The RB250GS is possibly the worst incarnation of a managed switch I have
 ever seen. SNMP continually fails. The VLAN configuration is terrible. You
 can't have tagged and untagged VLANs on a single interface.

 With RouterOS based switching chips you gain some additional power, but
 you lose per-interface information and control when you enable the
 switching and you still have to use bridging to do anything beyond whatever
 ports happen to be on the switch chip. Therefore, to use any of the
 RouterOS features, it is bridged and only applies to the switch group as a
 whole.

 Some of this lies with the poor choice in chipsets, while some lies in the
 poor implementation.

 Cisco, Dell and Extreme Networks (my current favorite) have almost
 unlimited power and granular control. They don't have some of the features
 of RouterOS, but teaming one of them with something running RouterOS is
 just as effective as using what Mikrotik supplies.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Faisal Imtiaz fai...@snappydsl.net
 To: wireless@wispa.org
 Sent: Saturday, October 13, 2012 8:54:25 AM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 MT makes Software and also Hardware (routerboard)

 Blanket statements like the one below do not make sense Every Mfg.
 has a range of limits that their products do a very good job for, it you
 try to use them out of that range they fall flat..

 Care to put a context to your statement ?

 :)

 Faisal Imtiaz
 Snappy Internet  Telecom
 7266 SW 48 Street
 Miami, Fl 33155
 Tel: 305 663 5518 x 232
 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

 On 10/12/2012 10:50 PM, Mike Hammett wrote:
  All MT switching is junk.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: Scott Reed sr...@nwwnet.net
  To: WISPA General List wireless@wispa.org
  Sent: Friday, October 12, 2012 8:18:25 PM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
 
  MT has several devices with hardware switches on board and fully
 accessible through the GUI. They also have a switch sort of based on ROS.
 
  On 10/11/2012 8:35 PM, Fred Goldstein wrote:
 
 
  At 10/11/2012 06:52 PM, SamT wrote:
 
 
  Not sure I under stand the no-NAT, so every device on the other side of
 the CPE has it's own public IP?
  There could be one NAT, at the access point.
 
  My taste, which to be sure I haven't tested at scale in a wireless
 network (but plan to), is to follow what is becoming standard wireline
 practice and do switching, not bridging, at layer 2. Routing would then
 be lumped into one place, making it easier to manage.
 
  The problem with small Linux-based systems (this includes both UBNT and
 MT) is that they don't tend to have switching documented or set up in the
 UI, even if it's possible. Bridging is bad -- it was designed for orange
 hose Ethernet, and it passes broadcast traffic to everyone. We invented
 this at DEC in the 1980s and discovered how it doesn't scale too well -- we
 had a couple of thousand DECnet and IP nodes on a bridged LAN, and the
 background broadcast traffic level was 400 kbps. This was a lot for systems
 to handle in 1991. I was testing ISDN bridges and discovered how you
 can't just bridge that type of network across a 56k connection. (I
 discovered the traffic when I first turned up the bridge. I ended up
 isolating it behind a router, built from an old VAX. At DEC, we built
 everything ouf of VAXen.)
 
  Switching, though, is what Frame Relay and ATM do, and now Carrier
 Ethernet is the big thing for fiber. It uses the VLAN tag to identify the
 virtual circuit; the MAC addresses are just passed along. Since it's
 connection-oriented (via the tag), it can have QoS assigned. I think it's
 theoretically possible to tag user ports, route on tags and set QoS on
 RouterOS, but it's not obvious how to do it all. Switching doesn't pass
 broadcast traffic; it provides more isolation and privacy than plain
 routing. Mesh routing then works at that layer, transparent to IP. It'll be
 interesting to set up.
 
 
 
 
  On 10/11/2012 4:53 PM, Scott Reed wrote:
 
 
  We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We run
 them in as routers, but do not NAT. Same benefits others mentioned for
 routing, just one fewer NAT. Never have a problem with it this way and
 can't see any good reason to NAT there.
 
  On 10/11/2012 3:46 PM, Arthur Stephens wrote:
 
 
  We currently use Ubiquiti radios in bridge mode and assign a ip address
 to the customers router.
  He have heard other wisp are using the Ubiquiti radio as a router.
  Would like feed back why one would do this when it appears customers
 would be double

Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Mike Hammett
What most people are thinking of when they are thinking of a switch is 
something that applies to the enterprise and lower markets. The carrier level 
switches introduce a whole suite of features designed for the provisioning and 
deployment of services to others. Many times some of those features can be 
found in enterprise and lower switches, but they're not as well laid out and 
cohesive as a carrier switch.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Faisal Imtiaz fai...@snappydsl.net
To: wireless@wispa.org
Sent: Saturday, October 13, 2012 8:46:30 AM
Subject: Re: [WISPA] Ubiquiti Radios as routers

hehe... A switch is a switch is a switch... and then there are switches 
with additional functionality built in...
The question here is what is this 'other functionality' are we talking 
about ?

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/12/2012 10:47 PM, Mike Hammett wrote:
 Fred, I don't think most of the people here understand what YOU'RE talking 
 about. They think a switch is just a switch and they're all the same, but 
 that's far from the truth.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Fred Goldstein fgoldst...@ionary.com
 To: fai...@snappydsl.net, WISPA General List wireless@wispa.org
 Sent: Friday, October 12, 2012 6:19:49 PM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 At 10/12/2012 07:06 PM, Faisal Imtiaz wrote:
 Being a Technical person, and a visual learner.. I am having trouble
 translating what Fred is trying to do with a Mikrotik, which he thinks
 it cannot do.
 Actually, I said that I don't know how to do it, not that it can or
 cannot be done.  It may be a documentation problem, that they never
 wrote down how to do it.

 We build our Fixed wireless pop's with a Mikrotik Router doing the
 Routing Functions at each pop.
 Each of the Sectors are connected on their own port.
 AP's and CPE's are setup as WDS Bridges.

 This allows us to create a routed network. (clients on each AP are
 bridged) 

 But, if we wanted to, we could also do Vlan's across this type of setup,
 just as easily, especially now since UBNT firmware fully supports vlans...

 What am I missing ?
 If you're doing routing, how do you also do VLANs?

 The VLAN is at a layer below IP, and (this is a key requirement) the
 IP layer must be totally invisible to the box (RouterOS, EdgeOS,
 etc.), and it might not even be an IP packet inside that VLAN.  If it
 is still IP, the address space belongs to the client, not the ISP.

 The Ethernet layer may require some kind of route-determination
 protocol.  Since it's not a real LAN, STP doesn't really hack it;
 perhaps (in RouterOS) HWMP+ can do it.  This protocol varies among CE
 switches.  If it's an edge (CPE) switch, though, it doesn't need to
 participate in route-determination.


 On 10/12/2012 6:07 PM, Fred Goldstein wrote:
 At 10/12/2012 05:48 PM, Butch Evans wrote:
 On Fri, 2012-10-12 at 10:52 -0400, Fred Goldstein wrote:
 There's a real market gap not quite being filled by our usual WISP
 vendors MT and UBNT.  MT has a new CPE router with SFP support.  This
 would be great for a regional CE fiber network.  Let's say you have a
 building (say, Town Hall) with multiple tenants in it, each with a
 separate IP network (say, Town administration, Police, and School
 Admin).  You'd want to be able to drop off one fiber with separate
 VLANs (virtual circuits) for each network, isolating the traffic from
 each other.  An MEF switch is cheaper than a real Cisco router but a
 Routerboard is cheaper yet!  And it can't route since there are
 multiple independent networks there, each with its own routers and
 firewalls.  Nor is bridging appropriate (not isolating).  So a
 Carrier Ethernet (MEF) switching option would fill that bill.  Of
 course the same software would work with a wireless feed to a
 shared-tenant building, not needing the SFP version.

 I suspect the pieces are all there, just not the assembly
 instructions or tools to facilitate it.  It involves setting up VLANs
 and queues.
 So, what you're saying is that you don't understand HOW to make the
 network using MT as a tool?  NOTE: This is not the same as It can't do
 .  It's all in the documentation.  You just have to either
 figure it out from what is there or ask for help from someone who has.
 Yes, that's what I'm thinking.  They never documented how to put
 those pieces together, though they might work.  And Switched
 Ethernet would be a lovely tab on the side of Winbox and
 Webfig.  I'm from the old school, where the definition of bug is
 an undocumented feature, and where software was written to conform
 to the documentation, not the other way around.

 It is there and can be done in a number of different ways (bridged OR
 switched

Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Mike Hammett
Standard Ethernet without the VLAN tag. One example is to support devices that 
do and do not support VLANs on a given network segment. Let's say in a given 
area, I have a dumb switch that just passes whatever frames it receives. Off of 
that I have a PC which requires the Ethernet to be in untagged form and a UniFi 
where I have local traffic untagged and additional SSIDs running on additional 
VLANs. A real switch has no problem with this, but the 250GS cannot have both 
tagged and untagged VLANs on the same interface (that serves the dumb switch 
referenced above). That is a limitation of the Atheros chips they are using.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Josh Luthman j...@imaginenetworksllc.com
To: WISPA General List wireless@wispa.org
Sent: Saturday, October 13, 2012 9:10:51 AM
Subject: Re: [WISPA] Ubiquiti Radios as routers


How would you have an untagged VLAN? 

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



On Sat, Oct 13, 2012 at 10:02 AM, Mike Hammett  wispawirel...@ics-il.net  
wrote: 


The RB250GS is possibly the worst incarnation of a managed switch I have ever 
seen. SNMP continually fails. The VLAN configuration is terrible. You can't 
have tagged and untagged VLANs on a single interface. 

With RouterOS based switching chips you gain some additional power, but you 
lose per-interface information and control when you enable the switching and 
you still have to use bridging to do anything beyond whatever ports happen to 
be on the switch chip. Therefore, to use any of the RouterOS features, it is 
bridged and only applies to the switch group as a whole. 

Some of this lies with the poor choice in chipsets, while some lies in the poor 
implementation. 

Cisco, Dell and Extreme Networks (my current favorite) have almost unlimited 
power and granular control. They don't have some of the features of RouterOS, 
but teaming one of them with something running RouterOS is just as effective as 
using what Mikrotik supplies. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

- Original Message - 


From: Faisal Imtiaz  fai...@snappydsl.net  
To: wireless@wispa.org 
Sent: Saturday, October 13, 2012 8:54:25 AM 
Subject: Re: [WISPA] Ubiquiti Radios as routers 

MT makes Software and also Hardware (routerboard) 

Blanket statements like the one below do not make sense Every Mfg. 
has a range of limits that their products do a very good job for, it you 
try to use them out of that range they fall flat.. 

Care to put a context to your statement ? 

:) 

Faisal Imtiaz 
Snappy Internet  Telecom 
7266 SW 48 Street 
Miami, Fl 33155 
Tel: 305 663 5518 x 232 
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net 

On 10/12/2012 10:50 PM, Mike Hammett wrote: 
 All MT switching is junk. 
 
 
 
 - 
 Mike Hammett 
 Intelligent Computing Solutions 
 http://www.ics-il.com 
 
 - Original Message - 
 From: Scott Reed  sr...@nwwnet.net  
 To: WISPA General List  wireless@wispa.org  
 Sent: Friday, October 12, 2012 8:18:25 PM 
 Subject: Re: [WISPA] Ubiquiti Radios as routers 
 
 
 MT has several devices with hardware switches on board and fully accessible 
 through the GUI. They also have a switch sort of based on ROS. 
 
 On 10/11/2012 8:35 PM, Fred Goldstein wrote: 
 
 
 At 10/11/2012 06:52 PM, SamT wrote: 
 
 
 Not sure I under stand the no-NAT, so every device on the other side of the 
 CPE has it's own public IP? 
 There could be one NAT, at the access point. 
 
 My taste, which to be sure I haven't tested at scale in a wireless network 
 (but plan to), is to follow what is becoming standard wireline practice and 
 do switching, not bridging, at layer 2. Routing would then be lumped into 
 one place, making it easier to manage. 
 
 The problem with small Linux-based systems (this includes both UBNT and MT) 
 is that they don't tend to have switching documented or set up in the UI, 
 even if it's possible. Bridging is bad -- it was designed for orange hose 
 Ethernet, and it passes broadcast traffic to everyone. We invented this at 
 DEC in the 1980s and discovered how it doesn't scale too well -- we had a 
 couple of thousand DECnet and IP nodes on a bridged LAN, and the background 
 broadcast traffic level was 400 kbps. This was a lot for systems to handle in 
 1991. I was testing ISDN bridges and discovered how you can't just bridge 
 that type of network across a 56k connection. (I discovered the traffic when 
 I first turned up the bridge. I ended up isolating it behind a router, built 
 from an old VAX. At DEC, we built everything ouf of VAXen.) 
 
 Switching, though, is what Frame Relay and ATM do, and now Carrier Ethernet 
 is the big thing for fiber. It uses the VLAN tag to identify the virtual 
 circuit; the MAC addresses are just passed along. Since it's 
 connection-oriented (via the tag), it can have QoS

Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Josh Luthman
That's painfully stupid.  What a worthless device.

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


On Sat, Oct 13, 2012 at 10:09 AM, Mike Hammett wispawirel...@ics-il.netwrote:

 Standard Ethernet without the VLAN tag. One example is to support devices
 that do and do not support VLANs on a given network segment. Let's say in a
 given area, I have a dumb switch that just passes whatever frames it
 receives. Off of that I have a PC which requires the Ethernet to be in
 untagged form and a UniFi where I have local traffic untagged and
 additional SSIDs running on additional VLANs. A real switch has no problem
 with this, but the 250GS cannot have both tagged and untagged VLANs on the
 same interface (that serves the dumb switch referenced above). That is a
 limitation of the Atheros chips they are using.



 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -
 From: Josh Luthman j...@imaginenetworksllc.com
 To: WISPA General List wireless@wispa.org
 Sent: Saturday, October 13, 2012 9:10:51 AM
 Subject: Re: [WISPA] Ubiquiti Radios as routers


 How would you have an untagged VLAN?

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



 On Sat, Oct 13, 2012 at 10:02 AM, Mike Hammett  wispawirel...@ics-il.net 
 wrote:


 The RB250GS is possibly the worst incarnation of a managed switch I have
 ever seen. SNMP continually fails. The VLAN configuration is terrible. You
 can't have tagged and untagged VLANs on a single interface.

 With RouterOS based switching chips you gain some additional power, but
 you lose per-interface information and control when you enable the
 switching and you still have to use bridging to do anything beyond whatever
 ports happen to be on the switch chip. Therefore, to use any of the
 RouterOS features, it is bridged and only applies to the switch group as a
 whole.

 Some of this lies with the poor choice in chipsets, while some lies in the
 poor implementation.

 Cisco, Dell and Extreme Networks (my current favorite) have almost
 unlimited power and granular control. They don't have some of the features
 of RouterOS, but teaming one of them with something running RouterOS is
 just as effective as using what Mikrotik supplies.




 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com

 - Original Message -


 From: Faisal Imtiaz  fai...@snappydsl.net 
 To: wireless@wispa.org
 Sent: Saturday, October 13, 2012 8:54:25 AM
 Subject: Re: [WISPA] Ubiquiti Radios as routers

 MT makes Software and also Hardware (routerboard)

 Blanket statements like the one below do not make sense Every Mfg.
 has a range of limits that their products do a very good job for, it you
 try to use them out of that range they fall flat..

 Care to put a context to your statement ?

 :)

 Faisal Imtiaz
 Snappy Internet  Telecom
 7266 SW 48 Street
 Miami, Fl 33155
 Tel: 305 663 5518 x 232
 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

 On 10/12/2012 10:50 PM, Mike Hammett wrote:
  All MT switching is junk.
 
 
 
  -
  Mike Hammett
  Intelligent Computing Solutions
  http://www.ics-il.com
 
  - Original Message -
  From: Scott Reed  sr...@nwwnet.net 
  To: WISPA General List  wireless@wispa.org 
  Sent: Friday, October 12, 2012 8:18:25 PM
  Subject: Re: [WISPA] Ubiquiti Radios as routers
 
 
  MT has several devices with hardware switches on board and fully
 accessible through the GUI. They also have a switch sort of based on ROS.
 
  On 10/11/2012 8:35 PM, Fred Goldstein wrote:
 
 
  At 10/11/2012 06:52 PM, SamT wrote:
 
 
  Not sure I under stand the no-NAT, so every device on the other side of
 the CPE has it's own public IP?
  There could be one NAT, at the access point.
 
  My taste, which to be sure I haven't tested at scale in a wireless
 network (but plan to), is to follow what is becoming standard wireline
 practice and do switching, not bridging, at layer 2. Routing would then
 be lumped into one place, making it easier to manage.
 
  The problem with small Linux-based systems (this includes both UBNT and
 MT) is that they don't tend to have switching documented or set up in the
 UI, even if it's possible. Bridging is bad -- it was designed for orange
 hose Ethernet, and it passes broadcast traffic to everyone. We invented
 this at DEC in the 1980s and discovered how it doesn't scale too well -- we
 had a couple of thousand DECnet and IP nodes on a bridged LAN, and the
 background broadcast traffic level was 400 kbps. This was a lot for systems
 to handle in 1991. I was testing ISDN bridges and discovered how you
 can't just bridge that type of network across a 56k connection. (I
 discovered the traffic when I first turned up the bridge. I ended up
 isolating it behind a router, built from an old VAX. At DEC, we built
 everything ouf of VAXen.)
 
  Switching, though, is what Frame Relay

Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Mike Hammett
If I have multiple UniFis or PCs, I would need to use multiple ports on the 
250GS going to multiple dumb switches, one that is the untagged VLAN for the 
PCs and the other with the UniFis, only I would have to use an additional VLAN 
to transport the local traffic from the UniFi to the 250GS, where I can drop 
the tag when it leaves.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Josh Luthman j...@imaginenetworksllc.com
To: WISPA General List wireless@wispa.org
Sent: Saturday, October 13, 2012 9:20:07 AM
Subject: Re: [WISPA] Ubiquiti Radios as routers


That's painfully stupid. What a worthless device. 

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



On Sat, Oct 13, 2012 at 10:09 AM, Mike Hammett  wispawirel...@ics-il.net  
wrote: 


Standard Ethernet without the VLAN tag. One example is to support devices that 
do and do not support VLANs on a given network segment. Let's say in a given 
area, I have a dumb switch that just passes whatever frames it receives. Off of 
that I have a PC which requires the Ethernet to be in untagged form and a UniFi 
where I have local traffic untagged and additional SSIDs running on additional 
VLANs. A real switch has no problem with this, but the 250GS cannot have both 
tagged and untagged VLANs on the same interface (that serves the dumb switch 
referenced above). That is a limitation of the Atheros chips they are using. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

- Original Message - 

From: Josh Luthman  j...@imaginenetworksllc.com  
To: WISPA General List  wireless@wispa.org  


Sent: Saturday, October 13, 2012 9:10:51 AM 
Subject: Re: [WISPA] Ubiquiti Radios as routers 


How would you have an untagged VLAN? 

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



On Sat, Oct 13, 2012 at 10:02 AM, Mike Hammett  wispawirel...@ics-il.net  
wrote: 


The RB250GS is possibly the worst incarnation of a managed switch I have ever 
seen. SNMP continually fails. The VLAN configuration is terrible. You can't 
have tagged and untagged VLANs on a single interface. 

With RouterOS based switching chips you gain some additional power, but you 
lose per-interface information and control when you enable the switching and 
you still have to use bridging to do anything beyond whatever ports happen to 
be on the switch chip. Therefore, to use any of the RouterOS features, it is 
bridged and only applies to the switch group as a whole. 

Some of this lies with the poor choice in chipsets, while some lies in the poor 
implementation. 

Cisco, Dell and Extreme Networks (my current favorite) have almost unlimited 
power and granular control. They don't have some of the features of RouterOS, 
but teaming one of them with something running RouterOS is just as effective as 
using what Mikrotik supplies. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

- Original Message - 


From: Faisal Imtiaz  fai...@snappydsl.net  
To: wireless@wispa.org 
Sent: Saturday, October 13, 2012 8:54:25 AM 
Subject: Re: [WISPA] Ubiquiti Radios as routers 

MT makes Software and also Hardware (routerboard) 

Blanket statements like the one below do not make sense Every Mfg. 
has a range of limits that their products do a very good job for, it you 
try to use them out of that range they fall flat.. 

Care to put a context to your statement ? 

:) 

Faisal Imtiaz 
Snappy Internet  Telecom 
7266 SW 48 Street 
Miami, Fl 33155 
Tel: 305 663 5518 x 232 
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net 

On 10/12/2012 10:50 PM, Mike Hammett wrote: 
 All MT switching is junk. 
 
 
 
 - 
 Mike Hammett 
 Intelligent Computing Solutions 
 http://www.ics-il.com 
 
 - Original Message - 
 From: Scott Reed  sr...@nwwnet.net  
 To: WISPA General List  wireless@wispa.org  
 Sent: Friday, October 12, 2012 8:18:25 PM 
 Subject: Re: [WISPA] Ubiquiti Radios as routers 
 
 
 MT has several devices with hardware switches on board and fully accessible 
 through the GUI. They also have a switch sort of based on ROS. 
 
 On 10/11/2012 8:35 PM, Fred Goldstein wrote: 
 
 
 At 10/11/2012 06:52 PM, SamT wrote: 
 
 
 Not sure I under stand the no-NAT, so every device on the other side of the 
 CPE has it's own public IP? 
 There could be one NAT, at the access point. 
 
 My taste, which to be sure I haven't tested at scale in a wireless network 
 (but plan to), is to follow what is becoming standard wireline practice and 
 do switching, not bridging, at layer 2. Routing would then be lumped into 
 one place, making it easier to manage. 
 
 The problem with small Linux-based systems (this includes both UBNT and MT) 
 is that they don't tend to have switching documented or set up in the UI, 
 even if it's possible. Bridging is bad -- it was designed for orange

Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Tim Densmore
Hi Fred,

I think a lot of the confusion here comes from the fact that you're 
using generic terms like switching and VLAN to describe complex 
Metro-E/Carrier-E scenarios.  Standard VLANs break up broadcast domains, 
but they don't create virtual circuits or provide total isolation - this 
is one of the reasons I initially asked what you were describing.  
Metro-e q-in-q with stag/ctag UNIs and EVCs behave much differently than 
standard packet switched ethernet dot1q VLANs in that regard.  I'd 
reference the different metro-e IEEE standards if I were smart enough to 
keep them all in my head or unlazy enough to look them up.

Tons of info available at metroethernetforum.org for folks who are 
trying to figure out what I'm talking about.

I'd be extremely impressed to learn that you could do a decent metro-e 
roll-out with ubnt and mt.  In the WISP world, I'd expect single-tagged 
dot1q VLANs to be enough to differentiate customer traffic, even in 
large-ish MPOP scenarios.  How many POPs generally hang off a single 
network segment before hitting a router?

Thanks for the interesting discussion!

TD

On 10/12/2012 10:14 PM, Fred Goldstein wrote:
 I'm not sure we're talking about the same thing.  It is allowing only 
 the VLAN to go from A to B, while nothing else goes to A or B, and the 
 VLAN is invisible to everyone else.  Which is really virtual circuit 
 behavior; VLAN is the legacy name of the VC ID.

 In CE switching, then, the VLAN receives no broadcasts from anyone 
 else on the switch or network, and sends no broadcasts outside.  What 
 goes onto that mapped port, or onto a VLAN pre-tagged to go to that 
 port, is totally and completely invisible to all other users.  So it's 
 secure enough for public safety use on a shared PMD.  This is 
 different from a bridge, where broadcasts go everywhere.  One type of 
 MEF service (EP-LAN) does actually emulate a LAN with 2 ports and 
 broadcasts among them, but the more common EPL and EVPL would not know 
 a broadcast frame from anything else, since they just pass the MAC 
 addresses transparently.

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Gino Villarini
It can be done with Mk and Canopy, both support qinq

Sent from a Apple Newton


On Oct 13, 2012, at 11:29 AM, Tim Densmore tdensm...@tarpit.cybermesa.com 
wrote:

 Hi Fred,
 
 I think a lot of the confusion here comes from the fact that you're 
 using generic terms like switching and VLAN to describe complex 
 Metro-E/Carrier-E scenarios.  Standard VLANs break up broadcast domains, 
 but they don't create virtual circuits or provide total isolation - this 
 is one of the reasons I initially asked what you were describing.  
 Metro-e q-in-q with stag/ctag UNIs and EVCs behave much differently than 
 standard packet switched ethernet dot1q VLANs in that regard.  I'd 
 reference the different metro-e IEEE standards if I were smart enough to 
 keep them all in my head or unlazy enough to look them up.
 
 Tons of info available at metroethernetforum.org for folks who are 
 trying to figure out what I'm talking about.
 
 I'd be extremely impressed to learn that you could do a decent metro-e 
 roll-out with ubnt and mt.  In the WISP world, I'd expect single-tagged 
 dot1q VLANs to be enough to differentiate customer traffic, even in 
 large-ish MPOP scenarios.  How many POPs generally hang off a single 
 network segment before hitting a router?
 
 Thanks for the interesting discussion!
 
 TD
 
 On 10/12/2012 10:14 PM, Fred Goldstein wrote:
 I'm not sure we're talking about the same thing.  It is allowing only 
 the VLAN to go from A to B, while nothing else goes to A or B, and the 
 VLAN is invisible to everyone else.  Which is really virtual circuit 
 behavior; VLAN is the legacy name of the VC ID.
 
 In CE switching, then, the VLAN receives no broadcasts from anyone 
 else on the switch or network, and sends no broadcasts outside.  What 
 goes onto that mapped port, or onto a VLAN pre-tagged to go to that 
 port, is totally and completely invisible to all other users.  So it's 
 secure enough for public safety use on a shared PMD.  This is 
 different from a bridge, where broadcasts go everywhere.  One type of 
 MEF service (EP-LAN) does actually emulate a LAN with 2 ports and 
 broadcasts among them, but the more common EPL and EVPL would not know 
 a broadcast frame from anything else, since they just pass the MAC 
 addresses transparently.
 
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Rubens Kuhl
 With RouterOS based switching chips you gain some additional power, but you 
 lose per-interface information and control when you enable the switching and 
 you still have to use bridging to do anything beyond whatever ports happen to 
 be on the switch chip. Therefore, to use any of the RouterOS features, it is 
 bridged and only applies to the switch group as a whole.

 Some of this lies with the poor choice in chipsets, while some lies in the 
 poor implementation.

It's a trade off. The switching chips were designed for home gateways,
and that's why they cost X (both volume and price issues), Mikrotik
did a good job of getting that functionality available to do wire-rate
filtering with sub-$100 devices.

What was a good decision for RB4xx/7xx/8xx series might not be the
case for RB1xxx series, which have more ports and usage requirements.


Rubens
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Faisal Imtiaz
  ...now for  a little bit  of a distraction...

Sent from a Apple Newton

Every time I see the above  tag line on Gino's email... I cannot help but crack 
a smile...

now how many folks know what an Apple Newton was ?




Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/13/2012 11:33 AM, Gino Villarini wrote:
 It can be done with Mk and Canopy, both support qinq

 Sent from a Apple Newton


 On Oct 13, 2012, at 11:29 AM, Tim Densmore tdensm...@tarpit.cybermesa.com 
 wrote:

 Hi Fred,

 I think a lot of the confusion here comes from the fact that you're
 using generic terms like switching and VLAN to describe complex
 Metro-E/Carrier-E scenarios.  Standard VLANs break up broadcast domains,
 but they don't create virtual circuits or provide total isolation - this
 is one of the reasons I initially asked what you were describing.
 Metro-e q-in-q with stag/ctag UNIs and EVCs behave much differently than
 standard packet switched ethernet dot1q VLANs in that regard.  I'd
 reference the different metro-e IEEE standards if I were smart enough to
 keep them all in my head or unlazy enough to look them up.

 Tons of info available at metroethernetforum.org for folks who are
 trying to figure out what I'm talking about.

 I'd be extremely impressed to learn that you could do a decent metro-e
 roll-out with ubnt and mt.  In the WISP world, I'd expect single-tagged
 dot1q VLANs to be enough to differentiate customer traffic, even in
 large-ish MPOP scenarios.  How many POPs generally hang off a single
 network segment before hitting a router?

 Thanks for the interesting discussion!

 TD

 On 10/12/2012 10:14 PM, Fred Goldstein wrote:
 I'm not sure we're talking about the same thing.  It is allowing only
 the VLAN to go from A to B, while nothing else goes to A or B, and the
 VLAN is invisible to everyone else.  Which is really virtual circuit
 behavior; VLAN is the legacy name of the VC ID.

 In CE switching, then, the VLAN receives no broadcasts from anyone
 else on the switch or network, and sends no broadcasts outside.  What
 goes onto that mapped port, or onto a VLAN pre-tagged to go to that
 port, is totally and completely invisible to all other users.  So it's
 secure enough for public safety use on a shared PMD.  This is
 different from a bridge, where broadcasts go everywhere.  One type of
 MEF service (EP-LAN) does actually emulate a LAN with 2 ports and
 broadcasts among them, but the more common EPL and EVPL would not know
 a broadcast frame from anything else, since they just pass the MAC
 addresses transparently.
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Jeff Broadwick - Lists
I do...it used to say his Motorola Startac...

Sent from my iPhone

On Oct 13, 2012, at 12:12 PM, Faisal Imtiaz fai...@snappydsl.net wrote:

  ...now for  a little bit  of a distraction...
 
 Sent from a Apple Newton
 
 Every time I see the above  tag line on Gino's email... I cannot help but 
 crack a smile...
 
 now how many folks know what an Apple Newton was ?
 
 
 
 
 Faisal Imtiaz
 Snappy Internet  Telecom
 7266 SW 48 Street
 Miami, Fl 33155
 Tel: 305 663 5518 x 232
 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net
 
 On 10/13/2012 11:33 AM, Gino Villarini wrote:
 It can be done with Mk and Canopy, both support qinq
 
 Sent from a Apple Newton
 
 
 On Oct 13, 2012, at 11:29 AM, Tim Densmore 
 tdensm...@tarpit.cybermesa.com wrote:
 
 Hi Fred,
 
 I think a lot of the confusion here comes from the fact that you're
 using generic terms like switching and VLAN to describe complex
 Metro-E/Carrier-E scenarios.  Standard VLANs break up broadcast domains,
 but they don't create virtual circuits or provide total isolation - this
 is one of the reasons I initially asked what you were describing.
 Metro-e q-in-q with stag/ctag UNIs and EVCs behave much differently than
 standard packet switched ethernet dot1q VLANs in that regard.  I'd
 reference the different metro-e IEEE standards if I were smart enough to
 keep them all in my head or unlazy enough to look them up.
 
 Tons of info available at metroethernetforum.org for folks who are
 trying to figure out what I'm talking about.
 
 I'd be extremely impressed to learn that you could do a decent metro-e
 roll-out with ubnt and mt.  In the WISP world, I'd expect single-tagged
 dot1q VLANs to be enough to differentiate customer traffic, even in
 large-ish MPOP scenarios.  How many POPs generally hang off a single
 network segment before hitting a router?
 
 Thanks for the interesting discussion!
 
 TD
 
 On 10/12/2012 10:14 PM, Fred Goldstein wrote:
 I'm not sure we're talking about the same thing.  It is allowing only
 the VLAN to go from A to B, while nothing else goes to A or B, and the
 VLAN is invisible to everyone else.  Which is really virtual circuit
 behavior; VLAN is the legacy name of the VC ID.
 
 In CE switching, then, the VLAN receives no broadcasts from anyone
 else on the switch or network, and sends no broadcasts outside.  What
 goes onto that mapped port, or onto a VLAN pre-tagged to go to that
 port, is totally and completely invisible to all other users.  So it's
 secure enough for public safety use on a shared PMD.  This is
 different from a bridge, where broadcasts go everywhere.  One type of
 MEF service (EP-LAN) does actually emulate a LAN with 2 ports and
 broadcasts among them, but the more common EPL and EVPL would not know
 a broadcast frame from anything else, since they just pass the MAC
 addresses transparently.
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
 
 
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Fred Goldstein
At 10/13/2012 11:27 AM, Tim Densmore wrote:
Hi Fred,

I think a lot of the confusion here comes from the fact that you're
using generic terms like switching and VLAN to describe complex
Metro-E/Carrier-E scenarios.  Standard VLANs break up broadcast domains,
but they don't create virtual circuits or provide total isolation - this
is one of the reasons I initially asked what you were describing.
Metro-e q-in-q with stag/ctag UNIs and EVCs behave much differently than
standard packet switched ethernet dot1q VLANs in that regard.  I'd
reference the different metro-e IEEE standards if I were smart enough to
keep them all in my head or unlazy enough to look them up.

Yep, the terminology is confusing.  I'm talking about Metro-E (a/k/a 
Carrier Ethernet), which is switching and uses the VLAN tag, but 
sure isn't LAN switching.  The confusion is that the original 1980s 
Orange Hose Ethernet was a broadcast-topology LAN, and the original 
bridges were designed to be transparent.  So by the 1990s orange hose 
was gone, and all Ethernet was switched, but it was switched using 
the bridge construct.  And this still works fine for LANs and the 
home application.  They don't need isolation.

I see a lot of confusion between these two worlds in the wireline/IT 
world too.  Data centers use big managed switches that are still 
LAN-model, or use VLANs with limited isolation.  They rarely deal 
with QoS.  But when you hit the WAN space, the Carrier Ethernet 
construct makes more sense, generally to provide a 2-point pipe 
between routers, or a fan-in. The ILECs are selling these things like 
crazy.  What's frustrating is that there are differences between each 
carriers' offerings; they don't have an easy apples-to-apples 
comparison.  Some of this is policy (do they want to sell CIR and EIR 
separately?) and some of this is hardware limitations (VZ-Core's 
Fujitsu 4500s can't do EVPL, so they map EPLs onto SONET VCGs).

The Metro Ethernet Forum wrote its standards using constructs adapted 
from earlier switches, based of course on what vendors were 
building.  So the VLAN tag is used as the VCI, even though it's too 
small.  And a lot of switches can do both the CE and LAN application, 
depending on how they're configured.  (Extreme comes to mind.)  Throw 
in the term layer 3 switching and you realize that we're a bit 
short of unique nouns in our vocabulary!

Tons of info available at metroethernetforum.org for folks who are
trying to figure out what I'm talking about.

I'd be extremely impressed to learn that you could do a decent metro-e
roll-out with ubnt and mt.  In the WISP world, I'd expect single-tagged
dot1q VLANs to be enough to differentiate customer traffic, even in
large-ish MPOP scenarios.  How many POPs generally hang off a single
network segment before hitting a router?

I would not expect a large-scale Metro-E/Carrier-E network to be 
built using MT or UBNT in the middle.  But a WISP or small ISP might 
want to provide some isolated Ethernet pipes between a customers' 
locations -- think of schools in a district, for instance, or some 
other operation that has internal networking, uses its own private 
address space, and wants to maintain one firewall, hanging other 
sites behind it.  That's one application.  Another is the CPE: The 
RB2011 with the SFP slot looks like a potential CPE for a building 
that has one fiber drop feeding multiple networks.  The application 
that comes to mind is a state office building with offices for motor 
vehicles, social services, and taxation in it -- each has its own 
isolated network, but why not share fiber?  Ciena-class boxes are 
typically used for that, at a much higher price.  (I ran into this 
while doing a procurement cycle for a state network.)

One other way to look at the difference:  The usual ISP view is that 
there is one global public IP address space, and NAT is the exception 
used at the customer location.  The enterprise-IT view is that 
everybody has their own private IP network, and the public Internet 
is that dangerous space on the other side of a firewall.  Where you 
stand on that influences the design of the network and switches.

Thanks for the interesting discussion!

I've enjoyed it.  I still hope somebody at some point figures out 
just how close you can get to an MEF-type switch using RouterOS or 
AirOS.  Or EdgeOS, Real Soon Now.  (They're all Linux under the skin, 
after all.)

TD

On 10/12/2012 10:14 PM, Fred Goldstein wrote:
  I'm not sure we're talking about the same thing.  It is allowing only
  the VLAN to go from A to B, while nothing else goes to A or B, and the
  VLAN is invisible to everyone else.  Which is really virtual circuit
  behavior; VLAN is the legacy name of the VC ID.
 
  In CE switching, then, the VLAN receives no broadcasts from anyone
  else on the switch or network, and sends no broadcasts outside.  What
  goes onto that mapped port, or onto a VLAN pre-tagged to go to that
  port, is totally and completely 

Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Gino Villarini
Lol... startac is my phone, newton is my ipad

Gino A. Villarini
g...@aeronetpr.com
Aeronet Wireless Broadband Corp.
787.273.4143
-Original Message-
From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf 
Of Jeff Broadwick - Lists
Sent: Saturday, October 13, 2012 12:28 PM
To: fai...@snappydsl.net; WISPA General List
Subject: Re: [WISPA] Ubiquiti Radios as routers

I do...it used to say his Motorola Startac...

Sent from my iPhone

On Oct 13, 2012, at 12:12 PM, Faisal Imtiaz fai...@snappydsl.net wrote:

  ...now for  a little bit  of a distraction...
 
 Sent from a Apple Newton
 
 Every time I see the above  tag line on Gino's email... I cannot help but 
 crack a smile...
 
 now how many folks know what an Apple Newton was ?
 
 
 
 
 Faisal Imtiaz
 Snappy Internet  Telecom
 7266 SW 48 Street
 Miami, Fl 33155
 Tel: 305 663 5518 x 232
 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net
 
 On 10/13/2012 11:33 AM, Gino Villarini wrote:
 It can be done with Mk and Canopy, both support qinq
 
 Sent from a Apple Newton
 
 
 On Oct 13, 2012, at 11:29 AM, Tim Densmore 
 tdensm...@tarpit.cybermesa.com wrote:
 
 Hi Fred,
 
 I think a lot of the confusion here comes from the fact that you're 
 using generic terms like switching and VLAN to describe complex 
 Metro-E/Carrier-E scenarios.  Standard VLANs break up broadcast 
 domains, but they don't create virtual circuits or provide total 
 isolation - this is one of the reasons I initially asked what you were 
 describing.
 Metro-e q-in-q with stag/ctag UNIs and EVCs behave much differently 
 than standard packet switched ethernet dot1q VLANs in that regard.  
 I'd reference the different metro-e IEEE standards if I were smart 
 enough to keep them all in my head or unlazy enough to look them up.
 
 Tons of info available at metroethernetforum.org for folks who are 
 trying to figure out what I'm talking about.
 
 I'd be extremely impressed to learn that you could do a decent 
 metro-e roll-out with ubnt and mt.  In the WISP world, I'd expect 
 single-tagged dot1q VLANs to be enough to differentiate customer 
 traffic, even in large-ish MPOP scenarios.  How many POPs generally 
 hang off a single network segment before hitting a router?
 
 Thanks for the interesting discussion!
 
 TD
 
 On 10/12/2012 10:14 PM, Fred Goldstein wrote:
 I'm not sure we're talking about the same thing.  It is allowing 
 only the VLAN to go from A to B, while nothing else goes to A or B, 
 and the VLAN is invisible to everyone else.  Which is really 
 virtual circuit behavior; VLAN is the legacy name of the VC ID.
 
 In CE switching, then, the VLAN receives no broadcasts from anyone 
 else on the switch or network, and sends no broadcasts outside.  
 What goes onto that mapped port, or onto a VLAN pre-tagged to go to 
 that port, is totally and completely invisible to all other users.  
 So it's secure enough for public safety use on a shared PMD.  This 
 is different from a bridge, where broadcasts go everywhere.  One 
 type of MEF service (EP-LAN) does actually emulate a LAN with 2 
 ports and broadcasts among them, but the more common EPL and EVPL 
 would not know a broadcast frame from anything else, since they 
 just pass the MAC addresses transparently.
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
 
 
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Fred Goldstein
You're all a bunch of young whippersnappers with all that newfangled gear.

At 10/13/2012 12:34 PM, you wrote:
Lol... startac is my phone, newton is my ipad

Gino A. Villarini
g...@aeronetpr.com
Aeronet Wireless Broadband Corp.
787.273.4143
-Original Message-
From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] 
On Behalf Of Jeff Broadwick - Lists
Sent: Saturday, October 13, 2012 12:28 PM
To: fai...@snappydsl.net; WISPA General List
Subject: Re: [WISPA] Ubiquiti Radios as routers

I do...it used to say his Motorola Startac...

Sent from my iPhone

On Oct 13, 2012, at 12:12 PM, Faisal Imtiaz fai...@snappydsl.net wrote:

   ...now for  a little bit  of a distraction...
 
  Sent from a Apple Newton
 
  Every time I see the above  tag line on Gino's email... I cannot 
 help but crack a smile...
 
  now how many folks know what an Apple Newton was ?
 
 
 
 
  Faisal Imtiaz
  Snappy Internet  Telecom
  7266 SW 48 Street
  Miami, Fl 33155
  Tel: 305 663 5518 x 232
  Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net
 
  On 10/13/2012 11:33 AM, Gino Villarini wrote:
  It can be done with Mk and Canopy, both support qinq
 
  Sent from a Apple Newton
 
 
  On Oct 13, 2012, at 11:29 AM, Tim Densmore 
 tdensm...@tarpit.cybermesa.com wrote:
 
  Hi Fred,
 
  I think a lot of the confusion here comes from the fact that you're
  using generic terms like switching and VLAN to describe complex
  Metro-E/Carrier-E scenarios.  Standard VLANs break up broadcast
  domains, but they don't create virtual circuits or provide total
  isolation - this is one of the reasons I initially asked what 
 you were describing.
  Metro-e q-in-q with stag/ctag UNIs and EVCs behave much differently
  than standard packet switched ethernet dot1q VLANs in that regard.
  I'd reference the different metro-e IEEE standards if I were smart
  enough to keep them all in my head or unlazy enough to look them up.
 
  Tons of info available at metroethernetforum.org for folks who are
  trying to figure out what I'm talking about.
 
  I'd be extremely impressed to learn that you could do a decent
  metro-e roll-out with ubnt and mt.  In the WISP world, I'd expect
  single-tagged dot1q VLANs to be enough to differentiate customer
  traffic, even in large-ish MPOP scenarios.  How many POPs generally
  hang off a single network segment before hitting a router?
 
  Thanks for the interesting discussion!
 
  TD
 
  On 10/12/2012 10:14 PM, Fred Goldstein wrote:
  I'm not sure we're talking about the same thing.  It is allowing
  only the VLAN to go from A to B, while nothing else goes to A or B,
  and the VLAN is invisible to everyone else.  Which is really
  virtual circuit behavior; VLAN is the legacy name of the VC ID.
 
  In CE switching, then, the VLAN receives no broadcasts from anyone
  else on the switch or network, and sends no broadcasts outside.
  What goes onto that mapped port, or onto a VLAN pre-tagged to go to
  that port, is totally and completely invisible to all other users.
  So it's secure enough for public safety use on a shared PMD.  This
  is different from a bridge, where broadcasts go everywhere.  One
  type of MEF service (EP-LAN) does actually emulate a LAN with 2
  ports and broadcasts among them, but the more common EPL and EVPL
  would not know a broadcast frame from anything else, since they
  just pass the MAC addresses transparently.

Sent from my PDP-11
via DECWRL Mail-11 to TCP/IP gateway

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Butch Evans
On Sat, 2012-10-13 at 09:02 -0500, Mike Hammett wrote:
 Cisco, Dell and Extreme Networks (my current favorite) have 
 almost unlimited power and granular control. They don't have
 some of the features of RouterOS, but teaming one of them with
 something running RouterOS is just as effective as using what 
 Mikrotik supplies.

And you expected that ANYONE could produce the same features and such
for a fraction of the cost?  It isn't fair to compare a $40 switch to
one that sells at $500 or more.  It isn't SUPPOSED to do the same
things.  Statements and comparisons like this really show your age.  The
Mikrotik devices are what they are.  They have limitations which should
be expected.  They work well when they are put in a spot within the
network that fits their capability. 

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Tim Densmore
Hi Gino,

Pardon my ignorance, but what's Mk?

TD

On 10/13/2012 09:33 AM, Gino Villarini wrote:
 It can be done with Mk and Canopy, both support qinq

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Butch Evans
On Sat, 2012-10-13 at 12:30 -0400, Fred Goldstein wrote:
 I've enjoyed it.  I still hope somebody at some point figures out 
 just how close you can get to an MEF-type switch using RouterOS or 
 AirOS.  Or EdgeOS, Real Soon Now.  (They're all Linux under the skin, 
 after all.)

It can be done (sort of) in Linux.  Which, of course, RouterOS has at
it's core.  The problem, though, is that Mikrotik's software is called
RotuerOS for a reason.  These devices are built to be routers.  While
what you are talking about is (at some levels) a hybrid of routing (at
layer 2) and switching.  I realize that is an oversimplification, but
bear with me.  RouterOS is certainly capable of doing much of what you
want, but it is not intended to behave as a switch. It will, however,
have to do it in software, which IS bridging.  You can, for example,
create the following configurations:

Ether1 - trunk port for vlans 10,20,30
Ether2 - Untagged traffic for vlan10
Ether3 - Tagged for vlan20
vlan30 is for managment of the device

The vlans would be configured as:
vlan 10 - created on ether1 only (E1V10)
vlan 20 - created on ether1 (E1V20) and ether3 (E3V20)
vlan 30 - created on ether1 only (E1V30)

Now for the software routing configuration.
You need a bridge device that includes the following:
bvlan10 - includes E1V10 and ether2
bvlan20 - includes E1V20 and E3V20
bvlan30 - (management) includes E1V30 only

This configuration, while it uses bridges to tie the ports together,
would not send broadcast traffic between bridges.  Even on the trunk
port side (ether1).  

IP addressing would be on the bridge devices (if you want them to be
visible at layer 3).  Obviously, bvlan30 would need an address.
Strictly speaking, you could simply eliminate the bridge for vlan30 and
add the layer 3 stuff at E1V30, but personally, I like the consistent
behavior of allowing the bridges to be the communication interface.  

Because RouterOS is designed to be a router and not a switch, the
ability to create a port that handles both tagged and untagged traffic
becomes rather ugly.  It can be done, but it is a horribly ugly
configuration and it uses bridges.  This, of course, depends somewhat on
exactly what you are trying to accomplish.

Because of the limitations of the backend software and the design
purpose of that software, RouterOS would work fine at certain places in
a CE network, but it certainly doesn't fit at the core.  The same is
true of other routers.


-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Fred Goldstein
Butch, thanks for that information!  I've marked that message 
priority high so I don't lose it in my mailing list archive.

I do get your point, that RouterOS was optimized for routing; there's 
just nothing else that fits its price points and form factors 
(especially outdoor Routerboards), so even if it's a little 
inefficient, it may still be cost-effective for some traffic 
levels.  The discussion began with questions about multiple NATs and 
routing within a network; I'd expect the VLAN configurations to get 
at least as much throughput as full-scale routing.  It won't compete 
with Ciena but their boxes don't cost $100 and run on 6 watts.

At 10/13/2012 03:58 PM, Butch Evans wrote:
On Sat, 2012-10-13 at 12:30 -0400, Fred Goldstein wrote:
  I've enjoyed it.  I still hope somebody at some point figures out
  just how close you can get to an MEF-type switch using RouterOS or
  AirOS.  Or EdgeOS, Real Soon Now.  (They're all Linux under the skin,
  after all.)

It can be done (sort of) in Linux.  Which, of course, RouterOS has at
it's core.  The problem, though, is that Mikrotik's software is called
RotuerOS for a reason.  These devices are built to be routers.  While
what you are talking about is (at some levels) a hybrid of routing (at
layer 2) and switching.  I realize that is an oversimplification, but
bear with me.  RouterOS is certainly capable of doing much of what you
want, but it is not intended to behave as a switch. It will, however,
have to do it in software, which IS bridging.  You can, for example,
create the following configurations:

Ether1 - trunk port for vlans 10,20,30
Ether2 - Untagged traffic for vlan10
Ether3 - Tagged for vlan20
vlan30 is for managment of the device

The vlans would be configured as:
vlan 10 - created on ether1 only (E1V10)
vlan 20 - created on ether1 (E1V20) and ether3 (E3V20)
vlan 30 - created on ether1 only (E1V30)

Now for the software routing configuration.
You need a bridge device that includes the following:
bvlan10 - includes E1V10 and ether2
bvlan20 - includes E1V20 and E3V20
bvlan30 - (management) includes E1V30 only

This configuration, while it uses bridges to tie the ports together,
would not send broadcast traffic between bridges.  Even on the trunk
port side (ether1).

IP addressing would be on the bridge devices (if you want them to be
visible at layer 3).  Obviously, bvlan30 would need an address.
Strictly speaking, you could simply eliminate the bridge for vlan30 and
add the layer 3 stuff at E1V30, but personally, I like the consistent
behavior of allowing the bridges to be the communication interface.

Because RouterOS is designed to be a router and not a switch, the
ability to create a port that handles both tagged and untagged traffic
becomes rather ugly.  It can be done, but it is a horribly ugly
configuration and it uses bridges.  This, of course, depends somewhat on
exactly what you are trying to accomplish.

Because of the limitations of the backend software and the design
purpose of that software, RouterOS would work fine at certain places in
a CE network, but it certainly doesn't fit at the core.  The same is
true of other routers.


  --
  Fred Goldsteink1io   fgoldstein at ionary.com
  ionary Consulting  http://www.ionary.com/
  +1 617 795 2701 

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Butch Evans
On Sat, 2012-10-13 at 17:33 -0400, Fred Goldstein wrote:
 I do get your point, that RouterOS was optimized for routing; there's 
 just nothing else that fits its price points and form factors 
 (especially outdoor Routerboards), so even if it's a little 
 inefficient, it may still be cost-effective for some traffic 
 levels.

Specifically, it fits well at the edge (customer edge).  I have some
clients who use RouterOS in a similar way to what you are describing for
that purpose.  For example, one client is running RouterOS as the head
end device in a few buildings he manages.  He is able to combine the
routing capability in RouterOS with it's VLAN capability and deliver
some quality services to tenants in the building.  Throughout the
buildings, he has either switches (mostly Cisco switches) or more
Routerboards (some are X86 systems instead) to manage traffic flows.
The problem with these devices is really centered around management
rather than functionality.  Cisco, for example, has some really nice
tools that can do some routing of vlan traffic at the switch layer,
whereas Mikrotik has to be statically configured for this.  It is not
too hard to build the redundant routes and just use STP or RSTP to
provide the failover in these building networks, but on a large scale,
this can be rather difficult and daunting.  

   The discussion began with questions about multiple NATs and 
 routing within a network; I'd expect the VLAN configurations to get 
 at least as much throughput as full-scale routing.  It won't compete 
 with Ciena but their boxes don't cost $100 and run on 6 watts.

Bear in mind that with RouterOS is actually faster in bridge than in
routing.  Really, that is true of ALL Linux devices.  Because you are
not needing to do a lot of traffic management, you can probably afford
to turn off connection tracking on the Routerboard devices, which can
save an impressive amount of CPU and latency.  

As for multiple NAT, I will just say that I am not a fan of NAT in any
way, other than at the customer edge.  In my networks, I always provided
my customers with one or more public IP addresses.  If they wanted more,
I could deliver more, but it was behind a router.  Customer layer2
traffic belongs to them and I always kept it there.  

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Jon Auer
You can do tag swapping and other fancy VLAN tricks in AirOS by
creating VLAN subints and mapping them to each other using bridge
interfaces.
The Linux bridge interface behaves more like a switch than a bridge
in that you can control mac aging, learning, etc so it doesn't blindly
forward traffic.
If you were feeling ambitious you could roll custom Ubnt firmware that
includes OAM features using dot1ag-utils.

Speaking to the earlier discussion,
While it has overhead I've seen people use EoIP on Mikrotik to
implement pseudo EPL services. L2 over L3 over L2 may offend
sensibilities but it works well enough.
I've also seen carriers using older Cisco gear to connect up customers
to non-MEF switches (Cisco 3550 is still used all over the place) and
do L2PT and QinQ to carry traffic towards the core where you have
devices capable of doing pseudowires.
My point here is that there are ways to achieve the goal of providing
L2 transport services over wireless, fiber, carrier pigeon with
current small carrier equipment. Mikrotik  Ubiquiti aren't
targeting the kinds of customers that demand the formal MEF features
and I wouldn't expect them to change.

On Sat, Oct 13, 2012 at 11:30 AM, Fred Goldstein fgoldst...@ionary.com wrote:
 just how close you can get to an MEF-type switch using RouterOS or
 AirOS.  Or EdgeOS, Real Soon Now.  (They're all Linux under the skin,
 after all.)
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Mike Hammett
Actually, NIB they're $1800 - $5k or more. Used, under $200 shipped with 
warranty.

Of course they fit the networks they're capable of, because they're capable of 
so little. ;-) I'm honestly working to remove all the RB250s from my house's 
network as they've become too annoying. I'll have to home-run some more cable, 
but so is life.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Butch Evans but...@butchevans.com
To: WISPA General List wireless@wispa.org
Sent: Saturday, October 13, 2012 1:44:24 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers

On Sat, 2012-10-13 at 09:02 -0500, Mike Hammett wrote:
 Cisco, Dell and Extreme Networks (my current favorite) have 
 almost unlimited power and granular control. They don't have
 some of the features of RouterOS, but teaming one of them with
 something running RouterOS is just as effective as using what 
 Mikrotik supplies.

And you expected that ANYONE could produce the same features and such
for a fraction of the cost?  It isn't fair to compare a $40 switch to
one that sells at $500 or more.  It isn't SUPPOSED to do the same
things.  Statements and comparisons like this really show your age.  The
Mikrotik devices are what they are.  They have limitations which should
be expected.  They work well when they are put in a spot within the
network that fits their capability. 

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-13 Thread Butch Evans
On Sat, 2012-10-13 at 23:16 -0500, Mike Hammett wrote:
 Of course they fit the networks they're capable of, because 
 they're capable of so little. ;-) I'm honestly working to 
 remove all the RB250s from my house's network as they've 
 become too annoying. I'll have to home-run some more cable, 
 but so is life.

They are plenty capable for a $40 switch.  That is what they are and to
expect something more is not a problem of the product, but the
implementer.  I have 3 of them here in my home network and guess
what...they work perfectly as I expect.  I don't expect them to be more
than a cheap switch, though.

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Dustin Jurman
Hey Fred,  we did exactly that with our Hardee County Network, we use licensed 
links between MEF switches.  Rapid deployment with fiber forward design.

I think we have been through all configurations,  bridging, routing and layer2 
switching.  You could not hit the nail on the head any better here.

The advantages of this type of design include scaleability, performance and 
reduced opex.

DSJ

Dustin Jurman C.E.O
Rapid Systems Corporation
1211 North Westshore BLVD suite 711
Tampa, Fl 33607
Building Better Infrastructure

On Oct 11, 2012, at 8:35 PM, Fred Goldstein 
fgoldst...@ionary.commailto:fgoldst...@ionary.com wrote:

At 10/11/2012 06:52 PM, SamT wrote:
Not sure I under stand the no-NAT, so every device on the other side of the CPE 
has it's own public IP?

There could be one NAT, at the access point.

My taste, which to be sure I haven't tested at scale in a wireless network (but 
plan to), is to follow what is becoming standard wireline practice and do 
switching, not bridging, at layer 2.  Routing would then be lumped into one 
place, making it easier to manage.

The problem with small Linux-based systems (this includes both UBNT and MT) is 
that they don't tend to have switching documented or set up in the UI, even if 
it's possible.  Bridging is bad -- it was designed for orange hose Ethernet, 
and it passes broadcast traffic to everyone.  We invented this at DEC in the 
1980s and discovered how it doesn't scale too well -- we had a couple of 
thousand DECnet and IP nodes on a bridged LAN, and the background broadcast 
traffic level was 400 kbps.  This was a lot for systems to handle in 1991.  I 
was testing ISDN bridges and discovered how you can't just bridge that type 
of network across a 56k connection.  (I discovered the traffic when I first 
turned up the bridge.  I ended up isolating it behind a router, built from an 
old VAX.  At DEC, we built everything ouf of VAXen.)

Switching, though, is what Frame Relay and ATM do, and now Carrier Ethernet is 
the big thing for fiber.  It uses the VLAN tag to identify the virtual circuit; 
the MAC addresses are just passed along.  Since it's connection-oriented (via 
the tag), it can have QoS assigned.  I think it's theoretically possible to tag 
user ports, route on tags and set QoS on RouterOS, but it's not obvious how to 
do it all.  Switching doesn't pass broadcast traffic; it provides more 
isolation and privacy than plain routing.  Mesh routing then works at that 
layer, transparent to IP.  It'll be interesting to set up.


On 10/11/2012 4:53 PM, Scott Reed wrote:
We run MT, not UBNT, CPE, but it doesn't matter what brand it is.  We run them 
in as routers, but do not NAT.  Same benefits others mentioned for routing, 
just one fewer NAT.  Never have a problem with it this way and can't see any 
good reason to NAT there.

On 10/11/2012 3:46 PM, Arthur Stephens wrote:
We currently use Ubiquiti radios in bridge mode and assign a ip address to the 
customers router.
He have heard other wisp are using the Ubiquiti radio as a router.
Would like feed back why one would do this when it appears customers would be 
double natted when they hook up their routers?
Or does it not matter from the customer experience?

Thanks

--
Arthur Stephens
Senior Sales Technician
Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019
509-927-7837
For technical support visit http://www.ptera.net/support
 -
This message may contain confidential and/or propriety information, and is 
intended for the person/entity to whom it was originally addressed.
Any use by others is strictly prohibited. Please note that any views or 
opinions presented in this email are solely those of the author and are not 
intended to represent those of the company.




___
Wireless mailing list
Wireless@wispa.orgmailto:Wireless@wispa.org

http://lists.wispa.org/mailman/listinfo/wireless



No virus found in this message.
Checked by AVG - www.avg.comhttp://www.avg.com
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12
Internal Virus Database is out of date.



--
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration



Mikrotik Advanced Certified

www.nwwnet.nethttp://www.nwwnet.net
(765) 855-1060
(765) 439-4253
(855) 231-6239




___
Wireless mailing list
Wireless@wispa.orgmailto:Wireless@wispa.org

http://lists.wispa.org/mailman/listinfo/wireless


___
Wireless mailing list
Wireless@wispa.orgmailto:Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

 --
 Fred Goldsteink1io   fgoldstein at ionary.comhttp://ionary.com
 ionary Consultinghttp://www.ionary.com/
 +1 617 795 2701

___
Wireless mailing list

Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Steve Barnes
Not to add an advertisement but Level 2 networking is one of the topics that we 
plan to hit on at WISPAPOLOOZA in the Technical Knowledge Exchange at 4:00 on 
Thursday the 25th. That is one of the point Gino wanted to bring up.  I will be 
moderating so if someone has other important Technical questions that might be 
a good session or the Technical Round table Tuesday evening from 7:45 till we 
go to bed.  Hope to see you all there.

Steve Barnes
General Manager
PCS-WIN / RC-WiFihttp://www.rcwifi.com/

From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf 
Of Dustin Jurman
Sent: Thursday, October 11, 2012 8:52 PM
To: WISPA General List
Cc: WISPA General List
Subject: Re: [WISPA] Ubiquiti Radios as routers

Hey Fred,  we did exactly that with our Hardee County Network, we use licensed 
links between MEF switches.  Rapid deployment with fiber forward design.

I think we have been through all configurations,  bridging, routing and layer2 
switching.  You could not hit the nail on the head any better here.

The advantages of this type of design include scaleability, performance and 
reduced opex.

DSJ

Dustin Jurman C.E.O
Rapid Systems Corporation
1211 North Westshore BLVD suite 711
Tampa, Fl 33607
Building Better Infrastructure

On Oct 11, 2012, at 8:35 PM, Fred Goldstein 
fgoldst...@ionary.commailto:fgoldst...@ionary.com wrote:
At 10/11/2012 06:52 PM, SamT wrote:

Not sure I under stand the no-NAT, so every device on the other side of the CPE 
has it's own public IP?

There could be one NAT, at the access point.

My taste, which to be sure I haven't tested at scale in a wireless network (but 
plan to), is to follow what is becoming standard wireline practice and do 
switching, not bridging, at layer 2.  Routing would then be lumped into one 
place, making it easier to manage.

The problem with small Linux-based systems (this includes both UBNT and MT) is 
that they don't tend to have switching documented or set up in the UI, even if 
it's possible.  Bridging is bad -- it was designed for orange hose Ethernet, 
and it passes broadcast traffic to everyone.  We invented this at DEC in the 
1980s and discovered how it doesn't scale too well -- we had a couple of 
thousand DECnet and IP nodes on a bridged LAN, and the background broadcast 
traffic level was 400 kbps.  This was a lot for systems to handle in 1991.  I 
was testing ISDN bridges and discovered how you can't just bridge that type 
of network across a 56k connection.  (I discovered the traffic when I first 
turned up the bridge.  I ended up isolating it behind a router, built from an 
old VAX.  At DEC, we built everything ouf of VAXen.)

Switching, though, is what Frame Relay and ATM do, and now Carrier Ethernet is 
the big thing for fiber.  It uses the VLAN tag to identify the virtual circuit; 
the MAC addresses are just passed along.  Since it's connection-oriented (via 
the tag), it can have QoS assigned.  I think it's theoretically possible to tag 
user ports, route on tags and set QoS on RouterOS, but it's not obvious how to 
do it all.  Switching doesn't pass broadcast traffic; it provides more 
isolation and privacy than plain routing.  Mesh routing then works at that 
layer, transparent to IP.  It'll be interesting to set up.



On 10/11/2012 4:53 PM, Scott Reed wrote:

We run MT, not UBNT, CPE, but it doesn't matter what brand it is.  We run them 
in as routers, but do not NAT.  Same benefits others mentioned for routing, 
just one fewer NAT.  Never have a problem with it this way and can't see any 
good reason to NAT there.

On 10/11/2012 3:46 PM, Arthur Stephens wrote:

We currently use Ubiquiti radios in bridge mode and assign a ip address to the 
customers router.
He have heard other wisp are using the Ubiquiti radio as a router.
Would like feed back why one would do this when it appears customers would be 
double natted when they hook up their routers?
Or does it not matter from the customer experience?

Thanks

--
Arthur Stephens
Senior Sales Technician
Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019
509-927-7837
For technical support visit http://www.ptera.net/support
 -
This message may contain confidential and/or propriety information, and is 
intended for the person/entity to whom it was originally addressed.
Any use by others is strictly prohibited. Please note that any views or 
opinions presented in this email are solely those of the author and are not 
intended to represent those of the company.



___

Wireless mailing list

Wireless@wispa.orgmailto:Wireless@wispa.org

http://lists.wispa.org/mailman/listinfo/wireless

http://lists.wispa.org/mailman/listinfo/wireless


No virus found in this message.
Checked by AVG - www.avg.comhttp://www.avg.com
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12
Internal Virus Database is out

Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Tim Densmore
Hi Fred,

Could you expand a bit on this?  It sounds like you're describing what 
I'd refer to as virtual circuits rather than switching. Are you 
setting up per-customer VLANs or something like that?

TD

On 10/11/2012 06:35 PM, Fred Goldstein wrote:
 Switching, though, is what Frame Relay and ATM do, and now Carrier 
 Ethernet is the big thing for fiber.  It uses the VLAN tag to identify 
 the virtual circuit; the MAC addresses are just passed along.  Since 
 it's connection-oriented (via the tag), it can have QoS assigned.  I 
 think it's theoretically possible to tag user ports, route on tags and 
 set QoS on RouterOS, but it's not obvious how to do it all.  Switching 
 doesn't pass broadcast traffic; it provides more isolation and privacy 
 than plain routing.  Mesh routing then works at that layer, 
 transparent to IP.  It'll be interesting to set up.

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Fred Goldstein
At 10/12/2012 10:23 AM, Tim Densmore wrote:
Hi Fred,

Could you expand a bit on this?  It sounds like you're describing what
I'd refer to as virtual circuits rather than switching. Are you
setting up per-customer VLANs or something like that?

It helps if you think of it as Ethernet-framed Frame Relay, rather 
than as Ethernet that hoary old LAN.  So it's virtual circuit 
switching (the two terms are complementary, not contradictory).  Each 
link between a pair of routers is a VLAN, which is a two-point 
virtual circuit.  The term VLAN is a bit inappropriate nowadays, 
and the 12-bit size of the tag is inadequate for large networks, but 
that's what we get when recycling a mass-produced 
product.  (Apparently ATT ran out of tags on some of their 
switches.)  The tag btw is solved by Q-in-Q nesting of tags, though 
most of the time it's a subscriber tag nested inside a provider tag.

There's a real market gap not quite being filled by our usual WISP 
vendors MT and UBNT.  MT has a new CPE router with SFP support.  This 
would be great for a regional CE fiber network.  Let's say you have a 
building (say, Town Hall) with multiple tenants in it, each with a 
separate IP network (say, Town administration, Police, and School 
Admin).  You'd want to be able to drop off one fiber with separate 
VLANs (virtual circuits) for each network, isolating the traffic from 
each other.  An MEF switch is cheaper than a real Cisco router but a 
Routerboard is cheaper yet!  And it can't route since there are 
multiple independent networks there, each with its own routers and 
firewalls.  Nor is bridging appropriate (not isolating).  So a 
Carrier Ethernet (MEF) switching option would fill that bill.  Of 
course the same software would work with a wireless feed to a 
shared-tenant building, not needing the SFP version.

I suspect the pieces are all there, just not the assembly 
instructions or tools to facilitate it.  It involves setting up VLANs 
and queues.

TD

On 10/11/2012 06:35 PM, Fred Goldstein wrote:
  Switching, though, is what Frame Relay and ATM do, and now Carrier
  Ethernet is the big thing for fiber.  It uses the VLAN tag to identify
  the virtual circuit; the MAC addresses are just passed along.  Since
  it's connection-oriented (via the tag), it can have QoS assigned.  I
  think it's theoretically possible to tag user ports, route on tags and
  set QoS on RouterOS, but it's not obvious how to do it all.  Switching
  doesn't pass broadcast traffic; it provides more isolation and privacy
  than plain routing.  Mesh routing then works at that layer,
  transparent to IP.  It'll be interesting to set up.

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

  --
  Fred Goldsteink1io   fgoldstein at ionary.com
  ionary Consulting  http://www.ionary.com/
  +1 617 795 2701 

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Butch Evans
On Fri, 2012-10-12 at 10:52 -0400, Fred Goldstein wrote:
 There's a real market gap not quite being filled by our usual WISP 
 vendors MT and UBNT.  MT has a new CPE router with SFP support.  This 
 would be great for a regional CE fiber network.  Let's say you have a 
 building (say, Town Hall) with multiple tenants in it, each with a 
 separate IP network (say, Town administration, Police, and School 
 Admin).  You'd want to be able to drop off one fiber with separate 
 VLANs (virtual circuits) for each network, isolating the traffic from 
 each other.  An MEF switch is cheaper than a real Cisco router but a 
 Routerboard is cheaper yet!  And it can't route since there are 
 multiple independent networks there, each with its own routers and 
 firewalls.  Nor is bridging appropriate (not isolating).  So a 
 Carrier Ethernet (MEF) switching option would fill that bill.  Of 
 course the same software would work with a wireless feed to a 
 shared-tenant building, not needing the SFP version.
 
 I suspect the pieces are all there, just not the assembly 
 instructions or tools to facilitate it.  It involves setting up VLANs 
 and queues.

So, what you're saying is that you don't understand HOW to make the
network using MT as a tool?  NOTE: This is not the same as It can't do
.  It's all in the documentation.  You just have to either
figure it out from what is there or ask for help from someone who has.

It is there and can be done in a number of different ways (bridged OR
switched).  Truth be told, I am amazed at what can be done in a small
box like the mikrotik devices.  It is a swiss army knife.  However, the
other side of this coin is that often, there is a BETTER tool for some
network needs.  Much like a swiss army knife, while it is true that it
has a screwdriver built in, a REAL screwdriver is usually better suited.
At the same time, often, you only need the functionality provided by the
built-in screwdriver, but it takes a special knack to make it do the
job.  The point being, that while it is certainly possible to make
RouterOS NOT be a router, why would you?  If you want a switch, put in a
switch.  If you want to save money, just realize that you are trading
something to get it.

There is very little that you can't do with RouterOS in terms of vlan
behaviors, but there certainly ARE a few limitations.  Your needs will
determine which is better.

-- 

* Butch Evans* Professional Network Consultation   *
* http://www.butchevans.com/ * Network Engineering *
* http://store.wispgear.net/ * Wired or Wireless Networks  *
* http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE!*
*  NOTE THE NEW PHONE NUMBER: 702-537-0979 *




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Fred Goldstein
At 10/12/2012 05:48 PM, Butch Evans wrote:
On Fri, 2012-10-12 at 10:52 -0400, Fred Goldstein wrote:
  There's a real market gap not quite being filled by our usual WISP
  vendors MT and UBNT.  MT has a new CPE router with SFP support.  This
  would be great for a regional CE fiber network.  Let's say you have a
  building (say, Town Hall) with multiple tenants in it, each with a
  separate IP network (say, Town administration, Police, and School
  Admin).  You'd want to be able to drop off one fiber with separate
  VLANs (virtual circuits) for each network, isolating the traffic from
  each other.  An MEF switch is cheaper than a real Cisco router but a
  Routerboard is cheaper yet!  And it can't route since there are
  multiple independent networks there, each with its own routers and
  firewalls.  Nor is bridging appropriate (not isolating).  So a
  Carrier Ethernet (MEF) switching option would fill that bill.  Of
  course the same software would work with a wireless feed to a
  shared-tenant building, not needing the SFP version.
 
  I suspect the pieces are all there, just not the assembly
  instructions or tools to facilitate it.  It involves setting up VLANs
  and queues.

So, what you're saying is that you don't understand HOW to make the
network using MT as a tool?  NOTE: This is not the same as It can't do
.  It's all in the documentation.  You just have to either
figure it out from what is there or ask for help from someone who has.

Yes, that's what I'm thinking.  They never documented how to put 
those pieces together, though they might work.  And Switched 
Ethernet would be a lovely tab on the side of Winbox and 
Webfig.  I'm from the old school, where the definition of bug is 
an undocumented feature, and where software was written to conform 
to the documentation, not the other way around.

It is there and can be done in a number of different ways (bridged OR
switched).  Truth be told, I am amazed at what can be done in a small
box like the mikrotik devices.  It is a swiss army knife.  However, the
other side of this coin is that often, there is a BETTER tool for some
network needs.  Much like a swiss army knife, while it is true that it
has a screwdriver built in, a REAL screwdriver is usually better suited.
At the same time, often, you only need the functionality provided by the
built-in screwdriver, but it takes a special knack to make it do the
job.  The point being, that while it is certainly possible to make
RouterOS NOT be a router, why would you?  If you want a switch, put in a
switch.  If you want to save money, just realize that you are trading
something to get it.

Find me an MEF switch for only 200% of the price of an equivalent 
Routerboard! (I suppose the new UBNT EdgeMAX will also fit that 
test.)  Most of the $1000 Ethernet switches are pure LAN bridges, 
not MEF 9/14.  They use the same frame format but utterly different 
semantics.  Plus a RouterOS box might allow a mix of the two, routing 
in one network and switching for everyone.

There is very little that you can't do with RouterOS in terms of vlan
behaviors, but there certainly ARE a few limitations.  Your needs will
determine which is better.

  --
  Fred Goldsteink1io   fgoldstein at ionary.com
  ionary Consulting  http://www.ionary.com/
  +1 617 795 2701 

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Faisal Imtiaz
Being a Technical person, and a visual learner.. I am having trouble 
translating what Fred is trying to do with a Mikrotik, which he thinks 
it cannot do.

We build our Fixed wireless pop's with a Mikrotik Router doing the 
Routing Functions at each pop.
Each of the Sectors are connected on their own port.
   AP's and CPE's are setup as WDS Bridges.

This allows us to create a routed network. (clients on each AP are 
bridged) 

But, if we wanted to, we could also do Vlan's across this type of setup, 
just as easily, especially now since UBNT firmware fully supports vlans...

What am I missing ?

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net

On 10/12/2012 6:07 PM, Fred Goldstein wrote:
 At 10/12/2012 05:48 PM, Butch Evans wrote:
 On Fri, 2012-10-12 at 10:52 -0400, Fred Goldstein wrote:
 There's a real market gap not quite being filled by our usual WISP
 vendors MT and UBNT.  MT has a new CPE router with SFP support.  This
 would be great for a regional CE fiber network.  Let's say you have a
 building (say, Town Hall) with multiple tenants in it, each with a
 separate IP network (say, Town administration, Police, and School
 Admin).  You'd want to be able to drop off one fiber with separate
 VLANs (virtual circuits) for each network, isolating the traffic from
 each other.  An MEF switch is cheaper than a real Cisco router but a
 Routerboard is cheaper yet!  And it can't route since there are
 multiple independent networks there, each with its own routers and
 firewalls.  Nor is bridging appropriate (not isolating).  So a
 Carrier Ethernet (MEF) switching option would fill that bill.  Of
 course the same software would work with a wireless feed to a
 shared-tenant building, not needing the SFP version.

 I suspect the pieces are all there, just not the assembly
 instructions or tools to facilitate it.  It involves setting up VLANs
 and queues.
 So, what you're saying is that you don't understand HOW to make the
 network using MT as a tool?  NOTE: This is not the same as It can't do
 .  It's all in the documentation.  You just have to either
 figure it out from what is there or ask for help from someone who has.
 Yes, that's what I'm thinking.  They never documented how to put
 those pieces together, though they might work.  And Switched
 Ethernet would be a lovely tab on the side of Winbox and
 Webfig.  I'm from the old school, where the definition of bug is
 an undocumented feature, and where software was written to conform
 to the documentation, not the other way around.

 It is there and can be done in a number of different ways (bridged OR
 switched).  Truth be told, I am amazed at what can be done in a small
 box like the mikrotik devices.  It is a swiss army knife.  However, the
 other side of this coin is that often, there is a BETTER tool for some
 network needs.  Much like a swiss army knife, while it is true that it
 has a screwdriver built in, a REAL screwdriver is usually better suited.
 At the same time, often, you only need the functionality provided by the
 built-in screwdriver, but it takes a special knack to make it do the
 job.  The point being, that while it is certainly possible to make
 RouterOS NOT be a router, why would you?  If you want a switch, put in a
 switch.  If you want to save money, just realize that you are trading
 something to get it.
 Find me an MEF switch for only 200% of the price of an equivalent
 Routerboard! (I suppose the new UBNT EdgeMAX will also fit that
 test.)  Most of the $1000 Ethernet switches are pure LAN bridges,
 not MEF 9/14.  They use the same frame format but utterly different
 semantics.  Plus a RouterOS box might allow a mix of the two, routing
 in one network and switching for everyone.

 There is very little that you can't do with RouterOS in terms of vlan
 behaviors, but there certainly ARE a few limitations.  Your needs will
 determine which is better.
--
Fred Goldsteink1io   fgoldstein at ionary.com
ionary Consulting  http://www.ionary.com/
+1 617 795 2701

 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Fred Goldstein
At 10/12/2012 07:06 PM, Faisal Imtiaz wrote:
Being a Technical person, and a visual learner.. I am having trouble
translating what Fred is trying to do with a Mikrotik, which he thinks
it cannot do.

Actually, I said that I don't know how to do it, not that it can or 
cannot be done.  It may be a documentation problem, that they never 
wrote down how to do it.

We build our Fixed wireless pop's with a Mikrotik Router doing the
Routing Functions at each pop.
Each of the Sectors are connected on their own port.
AP's and CPE's are setup as WDS Bridges.

This allows us to create a routed network. (clients on each AP are
bridged) 

But, if we wanted to, we could also do Vlan's across this type of setup,
just as easily, especially now since UBNT firmware fully supports vlans...

What am I missing ?

If you're doing routing, how do you also do VLANs?

The VLAN is at a layer below IP, and (this is a key requirement) the 
IP layer must be totally invisible to the box (RouterOS, EdgeOS, 
etc.), and it might not even be an IP packet inside that VLAN.  If it 
is still IP, the address space belongs to the client, not the ISP.

The Ethernet layer may require some kind of route-determination 
protocol.  Since it's not a real LAN, STP doesn't really hack it; 
perhaps (in RouterOS) HWMP+ can do it.  This protocol varies among CE 
switches.  If it's an edge (CPE) switch, though, it doesn't need to 
participate in route-determination.


On 10/12/2012 6:07 PM, Fred Goldstein wrote:
  At 10/12/2012 05:48 PM, Butch Evans wrote:
  On Fri, 2012-10-12 at 10:52 -0400, Fred Goldstein wrote:
  There's a real market gap not quite being filled by our usual WISP
  vendors MT and UBNT.  MT has a new CPE router with SFP support.  This
  would be great for a regional CE fiber network.  Let's say you have a
  building (say, Town Hall) with multiple tenants in it, each with a
  separate IP network (say, Town administration, Police, and School
  Admin).  You'd want to be able to drop off one fiber with separate
  VLANs (virtual circuits) for each network, isolating the traffic from
  each other.  An MEF switch is cheaper than a real Cisco router but a
  Routerboard is cheaper yet!  And it can't route since there are
  multiple independent networks there, each with its own routers and
  firewalls.  Nor is bridging appropriate (not isolating).  So a
  Carrier Ethernet (MEF) switching option would fill that bill.  Of
  course the same software would work with a wireless feed to a
  shared-tenant building, not needing the SFP version.
 
  I suspect the pieces are all there, just not the assembly
  instructions or tools to facilitate it.  It involves setting up VLANs
  and queues.
  So, what you're saying is that you don't understand HOW to make the
  network using MT as a tool?  NOTE: This is not the same as It can't do
  .  It's all in the documentation.  You just have to either
  figure it out from what is there or ask for help from someone who has.
  Yes, that's what I'm thinking.  They never documented how to put
  those pieces together, though they might work.  And Switched
  Ethernet would be a lovely tab on the side of Winbox and
  Webfig.  I'm from the old school, where the definition of bug is
  an undocumented feature, and where software was written to conform
  to the documentation, not the other way around.
 
  It is there and can be done in a number of different ways (bridged OR
  switched).  Truth be told, I am amazed at what can be done in a small
  box like the mikrotik devices.  It is a swiss army knife.  However, the
  other side of this coin is that often, there is a BETTER tool for some
  network needs.  Much like a swiss army knife, while it is true that it
  has a screwdriver built in, a REAL screwdriver is usually better suited.
  At the same time, often, you only need the functionality provided by the
  built-in screwdriver, but it takes a special knack to make it do the
  job.  The point being, that while it is certainly possible to make
  RouterOS NOT be a router, why would you?  If you want a switch, put in a
  switch.  If you want to save money, just realize that you are trading
  something to get it.
  Find me an MEF switch for only 200% of the price of an equivalent
  Routerboard! (I suppose the new UBNT EdgeMAX will also fit that
  test.)  Most of the $1000 Ethernet switches are pure LAN bridges,
  not MEF 9/14.  They use the same frame format but utterly different
  semantics.  Plus a RouterOS box might allow a mix of the two, routing
  in one network and switching for everyone.
 
  There is very little that you can't do with RouterOS in terms of vlan
  behaviors, but there certainly ARE a few limitations.  Your needs will
  determine which is better.
 --
 Fred Goldsteink1io   fgoldstein at ionary.com
 ionary Consulting  http://www.ionary.com/
 +1 617 795 2701
 
  ___
  Wireless mailing list
  Wireless@wispa.org
  

Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Rubens Kuhl
On Thu, Oct 11, 2012 at 3:46 PM, Arthur Stephens
arthur.steph...@ptera.net wrote:
 We currently use Ubiquiti radios in bridge mode and assign a ip address to
 the customers router.
 He have heard other wisp are using the Ubiquiti radio as a router.
 Would like feed back why one would do this when it appears customers would
 be double natted when they hook up their routers?
 Or does it not matter from the customer experience?

It matters. NAT 44 or NAT 444 or NAT  are detrimental to
applications that are not just browsing the web, as the user usually
loses UPnP features that a single NAT can provide.

What I liked doing was having the benefits of both by filtering at L2
to only packets going to gateway and to required broadcast addresses
All other junk was filtered by the Ubiquiti radio. No double nat, no
routing. Best of both worlds.


Rubens
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Faisal Imtiaz

Faisal Imtiaz


On 10/12/2012 7:19 PM, Fred Goldstein wrote:
 At 10/12/2012 07:06 PM, Faisal Imtiaz wrote:
 Being a Technical person, and a visual learner.. I am having trouble
 translating what Fred is trying to do with a Mikrotik, which he thinks
 it cannot do.
 Actually, I said that I don't know how to do it, not that it can or
 cannot be done.  It may be a documentation problem, that they never
 wrote down how to do it.
Understood, we are discussing this further, because I think both of us 
will come out learning something.
:)
 We build our Fixed wireless pop's with a Mikrotik Router doing the
 Routing Functions at each pop.
 Each of the Sectors are connected on their own port.
 AP's and CPE's are setup as WDS Bridges.

 This allows us to create a routed network. (clients on each AP are
 bridged) 

 But, if we wanted to, we could also do Vlan's across this type of setup,
 just as easily, especially now since UBNT firmware fully supports vlans...

 What am I missing ?
 If you're doing routing, how do you also do VLANs?
Mikrotik's can act like a Layer3 Switch. If you wanted to Route, you can 
assign an IP address to the Vlan or the Ethernet Port and route IP.
If you wanted to pass only Vlan's, then you simple define the Vlan's and 
'bridge them' (kind of like how the Cisco Routers do it).
If you wanted to use the vlan switch function built into the chip set, 
then I believe it is a bit harder to route.

 The VLAN is at a layer below IP, and (this is a key requirement) the
 IP layer must be totally invisible to the box (RouterOS, EdgeOS,
 etc.), and it might not even be an IP packet inside that VLAN.  If it
 is still IP, the address space belongs to the client, not the ISP.
Correct, so today, since the MT's are vlan aware devices... So if you 
put an MT on each side of the Wireless Connection (Ubnt/WDS), then 
effectively they look like they are two MT's connection via Ethernet 
cable (smaller bandwidth of course)...
or
You can pass tagged Vlans over the the Ubnt Radio , and have it deal 
with Vlans...(new firmware is Vlan Aware).
 The Ethernet layer may require some kind of route-determination
 protocol.
You are loosing me here... ?? Pls explain further.
   Since it's not a real LAN, STP doesn't really hack it;
 perhaps (in RouterOS) HWMP+ can do it.  This protocol varies among CE
 switches.  If it's an edge (CPE) switch, though, it doesn't need to
 participate in route-determination.


 On 10/12/2012 6:07 PM, Fred Goldstein wrote:
 At 10/12/2012 05:48 PM, Butch Evans wrote:
 On Fri, 2012-10-12 at 10:52 -0400, Fred Goldstein wrote:
 There's a real market gap not quite being filled by our usual WISP
 vendors MT and UBNT.  MT has a new CPE router with SFP support.  This
 would be great for a regional CE fiber network.  Let's say you have a
 building (say, Town Hall) with multiple tenants in it, each with a
 separate IP network (say, Town administration, Police, and School
 Admin).  You'd want to be able to drop off one fiber with separate
 VLANs (virtual circuits) for each network, isolating the traffic from
 each other.  An MEF switch is cheaper than a real Cisco router but a
 Routerboard is cheaper yet!  And it can't route since there are
 multiple independent networks there, each with its own routers and
 firewalls.  Nor is bridging appropriate (not isolating).  So a
 Carrier Ethernet (MEF) switching option would fill that bill.  Of
 course the same software would work with a wireless feed to a
 shared-tenant building, not needing the SFP version.

 I suspect the pieces are all there, just not the assembly
 instructions or tools to facilitate it.  It involves setting up VLANs
 and queues.
 So, what you're saying is that you don't understand HOW to make the
 network using MT as a tool?  NOTE: This is not the same as It can't do
 .  It's all in the documentation.  You just have to either
 figure it out from what is there or ask for help from someone who has.
 Yes, that's what I'm thinking.  They never documented how to put
 those pieces together, though they might work.  And Switched
 Ethernet would be a lovely tab on the side of Winbox and
 Webfig.  I'm from the old school, where the definition of bug is
 an undocumented feature, and where software was written to conform
 to the documentation, not the other way around.

 It is there and can be done in a number of different ways (bridged OR
 switched).  Truth be told, I am amazed at what can be done in a small
 box like the mikrotik devices.  It is a swiss army knife.  However, the
 other side of this coin is that often, there is a BETTER tool for some
 network needs.  Much like a swiss army knife, while it is true that it
 has a screwdriver built in, a REAL screwdriver is usually better suited.
 At the same time, often, you only need the functionality provided by the
 built-in screwdriver, but it takes a special knack to make it do the
 job.  The point being, that while it is certainly possible to make
 RouterOS NOT be a router, why 

Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Scott Reed

NAT at the at a couple of towers, but not at the CPE.

On 10/11/2012 6:52 PM, Sam Tetherow wrote:
Not sure I under stand the no-NAT, so every device on the other side 
of the CPE has it's own public IP?


On 10/11/2012 4:53 PM, Scott Reed wrote:
We run MT, not UBNT, CPE, but it doesn't matter what brand it is.  We 
run them in as routers, but do not NAT.  Same benefits others 
mentioned for routing, just one fewer NAT.  Never have a problem with 
it this way and can't see any good reason to NAT there.


On 10/11/2012 3:46 PM, Arthur Stephens wrote:
We currently use Ubiquiti radios in bridge mode and assign a ip 
address to the customers router.

He have heard other wisp are using the Ubiquiti radio as a router.
Would like feed back why one would do this when it appears customers 
would be double natted when they hook up their routers?

Or does it not matter from the customer experience?

Thanks

--
Arthur Stephens
Senior Sales Technician
Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019
509-927-7837
For technical support visit http://www.ptera.net/support
 - 

This message may contain confidential and/or propriety information, 
and is intended for the person/entity to whom it was originally 
addressed.
Any use by others is strictly prohibited. Please note that any views 
or opinions presented in this email are solely those of the author 
and are not intended to represent those of the company.



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 
10/01/12

Internal Virus Database is out of date.



--
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration

  


Mikrotik Advanced Certified
  
www.nwwnet.net

(765) 855-1060
(765) 439-4253
(855) 231-6239


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12
Internal Virus Database is out of date.



--
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration

 


Mikrotik Advanced Certified
 
www.nwwnet.net

(765) 855-1060
(765) 439-4253
(855) 231-6239

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Scott Reed
MT has several devices with hardware switches on board and fully 
accessible through the GUI.  They also have a switch sort of based on ROS.

On 10/11/2012 8:35 PM, Fred Goldstein wrote:

At 10/11/2012 06:52 PM, SamT wrote:
Not sure I under stand the no-NAT, so every device on the other side 
of the CPE has it's own public IP?


There could be one NAT, at the access point.

My taste, which to be sure I haven't tested at scale in a wireless 
network (but plan to), is to follow what is becoming standard wireline 
practice and do switching, not bridging, at layer 2. Routing would 
then be lumped into one place, making it easier to manage.


The problem with small Linux-based systems (this includes both UBNT 
and MT) is that they don't tend to have switching documented or set up 
in the UI, even if it's possible.  Bridging is bad -- it was designed 
for orange hose Ethernet, and it passes broadcast traffic to everyone. 
We invented this at DEC in the 1980s and discovered how it doesn't 
scale too well -- we had a couple of thousand DECnet and IP nodes on a 
bridged LAN, and the background broadcast traffic level was 400 kbps. 
This was a lot for systems to handle in 1991.  I was testing ISDN 
bridges and discovered how you can't just bridge that type of 
network across a 56k connection.  (I discovered the traffic when I 
first turned up the bridge.  I ended up isolating it behind a router, 
built from an old VAX.  At DEC, we built everything ouf of VAXen.)


Switching, though, is what Frame Relay and ATM do, and now Carrier 
Ethernet is the big thing for fiber.  It uses the VLAN tag to identify 
the virtual circuit; the MAC addresses are just passed along.  Since 
it's connection-oriented (via the tag), it can have QoS assigned.  I 
think it's theoretically possible to tag user ports, route on tags and 
set QoS on RouterOS, but it's not obvious how to do it all.  Switching 
doesn't pass broadcast traffic; it provides more isolation and privacy 
than plain routing.  Mesh routing then works at that layer, 
transparent to IP.  It'll be interesting to set up.




On 10/11/2012 4:53 PM, Scott Reed wrote:
We run MT, not UBNT, CPE, but it doesn't matter what brand it is.  
We run them in as routers, but do not NAT.  Same benefits others 
mentioned for routing, just one fewer NAT.  Never have a problem 
with it this way and can't see any good reason to NAT there.


On 10/11/2012 3:46 PM, Arthur Stephens wrote:
We currently use Ubiquiti radios in bridge mode and assign a ip 
address to the customers router.

He have heard other wisp are using the Ubiquiti radio as a router.
Would like feed back why one would do this when it appears 
customers would be double natted when they hook up their routers?

Or does it not matter from the customer experience?

Thanks

--
Arthur Stephens
Senior Sales Technician
Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019
509-927-7837
For technical support visit http://www.ptera.net/support
 - 

This message may contain confidential and/or propriety 
information, and is intended for the person/entity to whom it was 
originally addressed.
Any use by others is strictly prohibited. Please note that any 
views or opinions presented in this email are solely those of the 
author and are not intended to represent those of the company.




___
Wireless mailing list
Wireless@wispa.org  mailto:Wireless@wispa.org

http://lists.wispa.org/mailman/listinfo/wireless


No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 
10/01/12

Internal Virus Database is out of date.



--
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration

  


Mikrotik Advanced Certified
  
www.nwwnet.net  http://www.nwwnet.net

(765) 855-1060
(765) 439-4253
(855) 231-6239



___
Wireless mailing list
Wireless@wispa.org  mailto:Wireless@wispa.org

http://lists.wispa.org/mailman/listinfo/wireless


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless 
http://lists.wispa.org/mailman/listinfo/wireless


 --
 Fred Goldsteink1io   fgoldstein at ionary.com
 ionary Consulting http://www.ionary.com/ http://www.ionary.com/
 +1 617 795 2701


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12
Internal Virus Database is out of date.



--
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration

 


Mikrotik Advanced Certified
 

Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread LTI - Dennis Burgess
What is being described is the default behavior of any standard managed
switch.  There is no virtual circuit being built and it still
broadcasts across said VLAN.  They are simply only allowing the VLAN to
go from point A to point B.  This though can be done at wire speed in the
hardware of any switch and MT.   This is not an intelligent method (the
switching system not the people talking about this), as there can only be
STP or other non-standard protocols to handle fail over.  The example is
that if you have 5 switches in-line, you are simply ONLY allowing say
vlan999 to tag ingress on port 22 on switch 1, then only flow though tagged
on the trunk ports between switches, then finally only having one egress
non-tagged port at switch 5 port 22..  Hence a sort of circuit..

This works great on large bandwidth wired applications, but going over
anything wireless for the most part poses an issue.  The trunks are still
seeing all broadcast traffic from all devices, maybe its not going as far
and yes you can control it a bit more, but in the end, a packet storm on
one VLAN will take down the wireless connection and all trunks on a
backhaul radio.  Simply because the UBNT or whatever radio you are using
can't handle 100,000 pps.  The switches, in hardware, can handle millions,
making this situation not a major issue as we have plenty of hardware to
handle those instances and with several mitigation systems built into
these switches, you can further handle said traffic.  Not saying this
method does not work, simply has its own gotchas just like anything else.

The limitations is really in the fail over  it don't care what kind of
packets or even if the packets are needed to traverse the network, hence
more traffic than needed, but its better than one large bridge.  Building
rings that have disabled ports can help, but still don't
intelligently route around issues, as routing would do.But to the
topic, yes, MT can ingress non-vlan tagged traffic and send it out as
tagged traffic, and yes bridging is how that is done (mt is more switching
than bridging in those aspects) and it also can be done with some of there
hardware switch chips.

As for the topic at hand, never let your customer access your layer2
network, it will end up coming back to bite you.  Hence, route your CPE, if
the client wants a public, you route though the CPE as a router, if the
client is a home user and don't want/need inbound access, give them a
public on the CPE, and NAT a private. As far as their router inside, it
should be setup to be a swtich with a AP, makes it simple, else, double-nat
will not affect web/email applications

Dennis



On Fri, Oct 12, 2012 at 8:18 PM, Scott Reed sr...@nwwnet.net wrote:

  MT has several devices with hardware switches on board and fully
 accessible through the GUI.  They also have a switch sort of based on ROS.

 On 10/11/2012 8:35 PM, Fred Goldstein wrote:

 At 10/11/2012 06:52 PM, SamT wrote:

 Not sure I under stand the no-NAT, so every device on the other side of
 the CPE has it's own public IP?


 There could be one NAT, at the access point.

 My taste, which to be sure I haven't tested at scale in a wireless network
 (but plan to), is to follow what is becoming standard wireline practice and
 do switching, not bridging, at layer 2.  Routing would then be lumped
 into one place, making it easier to manage.

 The problem with small Linux-based systems (this includes both UBNT and
 MT) is that they don't tend to have switching documented or set up in the
 UI, even if it's possible.  Bridging is bad -- it was designed for orange
 hose Ethernet, and it passes broadcast traffic to everyone.  We invented
 this at DEC in the 1980s and discovered how it doesn't scale too well -- we
 had a couple of thousand DECnet and IP nodes on a bridged LAN, and the
 background broadcast traffic level was 400 kbps.  This was a lot for
 systems to handle in 1991.  I was testing ISDN bridges and discovered how
 you can't just bridge that type of network across a 56k connection.  (I
 discovered the traffic when I first turned up the bridge.  I ended up
 isolating it behind a router, built from an old VAX.  At DEC, we built
 everything ouf of VAXen.)

 Switching, though, is what Frame Relay and ATM do, and now Carrier
 Ethernet is the big thing for fiber.  It uses the VLAN tag to identify the
 virtual circuit; the MAC addresses are just passed along.  Since it's
 connection-oriented (via the tag), it can have QoS assigned.  I think it's
 theoretically possible to tag user ports, route on tags and set QoS on
 RouterOS, but it's not obvious how to do it all.  Switching doesn't pass
 broadcast traffic; it provides more isolation and privacy than plain
 routing.  Mesh routing then works at that layer, transparent to IP.  It'll
 be interesting to set up.


 On 10/11/2012 4:53 PM, Scott Reed wrote:

 We run MT, not UBNT, CPE, but it doesn't matter what brand it is.  We run
 them in as routers, but do not NAT.  Same benefits 

Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Mike Hammett
Fred, I don't think most of the people here understand what YOU'RE talking 
about. They think a switch is just a switch and they're all the same, but 
that's far from the truth.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Fred Goldstein fgoldst...@ionary.com
To: fai...@snappydsl.net, WISPA General List wireless@wispa.org
Sent: Friday, October 12, 2012 6:19:49 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers

At 10/12/2012 07:06 PM, Faisal Imtiaz wrote:
Being a Technical person, and a visual learner.. I am having trouble
translating what Fred is trying to do with a Mikrotik, which he thinks
it cannot do.

Actually, I said that I don't know how to do it, not that it can or 
cannot be done.  It may be a documentation problem, that they never 
wrote down how to do it.

We build our Fixed wireless pop's with a Mikrotik Router doing the
Routing Functions at each pop.
Each of the Sectors are connected on their own port.
AP's and CPE's are setup as WDS Bridges.

This allows us to create a routed network. (clients on each AP are
bridged) 

But, if we wanted to, we could also do Vlan's across this type of setup,
just as easily, especially now since UBNT firmware fully supports vlans...

What am I missing ?

If you're doing routing, how do you also do VLANs?

The VLAN is at a layer below IP, and (this is a key requirement) the 
IP layer must be totally invisible to the box (RouterOS, EdgeOS, 
etc.), and it might not even be an IP packet inside that VLAN.  If it 
is still IP, the address space belongs to the client, not the ISP.

The Ethernet layer may require some kind of route-determination 
protocol.  Since it's not a real LAN, STP doesn't really hack it; 
perhaps (in RouterOS) HWMP+ can do it.  This protocol varies among CE 
switches.  If it's an edge (CPE) switch, though, it doesn't need to 
participate in route-determination.


On 10/12/2012 6:07 PM, Fred Goldstein wrote:
  At 10/12/2012 05:48 PM, Butch Evans wrote:
  On Fri, 2012-10-12 at 10:52 -0400, Fred Goldstein wrote:
  There's a real market gap not quite being filled by our usual WISP
  vendors MT and UBNT.  MT has a new CPE router with SFP support.  This
  would be great for a regional CE fiber network.  Let's say you have a
  building (say, Town Hall) with multiple tenants in it, each with a
  separate IP network (say, Town administration, Police, and School
  Admin).  You'd want to be able to drop off one fiber with separate
  VLANs (virtual circuits) for each network, isolating the traffic from
  each other.  An MEF switch is cheaper than a real Cisco router but a
  Routerboard is cheaper yet!  And it can't route since there are
  multiple independent networks there, each with its own routers and
  firewalls.  Nor is bridging appropriate (not isolating).  So a
  Carrier Ethernet (MEF) switching option would fill that bill.  Of
  course the same software would work with a wireless feed to a
  shared-tenant building, not needing the SFP version.
 
  I suspect the pieces are all there, just not the assembly
  instructions or tools to facilitate it.  It involves setting up VLANs
  and queues.
  So, what you're saying is that you don't understand HOW to make the
  network using MT as a tool?  NOTE: This is not the same as It can't do
  .  It's all in the documentation.  You just have to either
  figure it out from what is there or ask for help from someone who has.
  Yes, that's what I'm thinking.  They never documented how to put
  those pieces together, though they might work.  And Switched
  Ethernet would be a lovely tab on the side of Winbox and
  Webfig.  I'm from the old school, where the definition of bug is
  an undocumented feature, and where software was written to conform
  to the documentation, not the other way around.
 
  It is there and can be done in a number of different ways (bridged OR
  switched).  Truth be told, I am amazed at what can be done in a small
  box like the mikrotik devices.  It is a swiss army knife.  However, the
  other side of this coin is that often, there is a BETTER tool for some
  network needs.  Much like a swiss army knife, while it is true that it
  has a screwdriver built in, a REAL screwdriver is usually better suited.
  At the same time, often, you only need the functionality provided by the
  built-in screwdriver, but it takes a special knack to make it do the
  job.  The point being, that while it is certainly possible to make
  RouterOS NOT be a router, why would you?  If you want a switch, put in a
  switch.  If you want to save money, just realize that you are trading
  something to get it.
  Find me an MEF switch for only 200% of the price of an equivalent
  Routerboard! (I suppose the new UBNT EdgeMAX will also fit that
  test.)  Most of the $1000 Ethernet switches are pure LAN bridges,
  not MEF 9/14.  They use the same frame format but utterly different
  semantics.  Plus a RouterOS box might allow a mix

Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Mike Hammett
I want to see the removal of doing anything other than DHCP to the client's 
device. The CPE radio pulls it's rate-shaping information from RADIUS and 
allows any number of DHCP clients on a per-CPE basis to pull a public IP.

An ISP doing NAT is just silly.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Scott Reed sr...@nwwnet.net
To: WISPA General List wireless@wispa.org
Sent: Friday, October 12, 2012 8:16:43 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers


NAT at the at a couple of towers, but not at the CPE. 


On 10/11/2012 6:52 PM, Sam Tetherow wrote: 



Not sure I under stand the no-NAT, so every device on the other side of the CPE 
has it's own public IP? 

On 10/11/2012 4:53 PM, Scott Reed wrote: 


We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We run them 
in as routers, but do not NAT. Same benefits others mentioned for routing, just 
one fewer NAT. Never have a problem with it this way and can't see any good 
reason to NAT there. 


On 10/11/2012 3:46 PM, Arthur Stephens wrote: 


We currently use Ubiquiti radios in bridge mode and assign a ip address to the 
customers router. 
He have heard other wisp are using the Ubiquiti radio as a router. 
Would like feed back why one would do this when it appears customers would be 
double natted when they hook up their routers? 
Or does it not matter from the customer experience? 


Thanks 

-- 
Arthur Stephens 
Senior Sales Technician 
Ptera Wireless Inc. 
PO Box 135 
24001 E Mission Suite 50 
Liberty Lake, WA 99019 
509-927-7837 
For technical support visit http://www.ptera.net/support 
- 
This message may contain confidential and/or propriety information, and is 
intended for the person/entity to whom it was originally addressed. 
Any use by others is strictly prohibited. Please note that any views or 
opinions presented in this email are solely those of the author and are not 
intended to represent those of the company. 


___
Wireless mailing list Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 



No virus found in this message. 
Checked by AVG - www.avg.com 
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12 
Internal Virus Database is out of date. 
-- 
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration

 

Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060
(765) 439-4253
(855) 231-6239 

___
Wireless mailing list Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 


___
Wireless mailing list Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 



No virus found in this message. 
Checked by AVG - www.avg.com 
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12 
Internal Virus Database is out of date. 
-- 
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration

 

Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060
(765) 439-4253
(855) 231-6239 
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Mike Hammett
All MT switching is junk.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Scott Reed sr...@nwwnet.net
To: WISPA General List wireless@wispa.org
Sent: Friday, October 12, 2012 8:18:25 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers


MT has several devices with hardware switches on board and fully accessible 
through the GUI. They also have a switch sort of based on ROS. 

On 10/11/2012 8:35 PM, Fred Goldstein wrote: 


At 10/11/2012 06:52 PM, SamT wrote: 


Not sure I under stand the no-NAT, so every device on the other side of the CPE 
has it's own public IP? 
There could be one NAT, at the access point. 

My taste, which to be sure I haven't tested at scale in a wireless network (but 
plan to), is to follow what is becoming standard wireline practice and do 
switching, not bridging, at layer 2. Routing would then be lumped into one 
place, making it easier to manage. 

The problem with small Linux-based systems (this includes both UBNT and MT) is 
that they don't tend to have switching documented or set up in the UI, even if 
it's possible. Bridging is bad -- it was designed for orange hose Ethernet, and 
it passes broadcast traffic to everyone. We invented this at DEC in the 1980s 
and discovered how it doesn't scale too well -- we had a couple of thousand 
DECnet and IP nodes on a bridged LAN, and the background broadcast traffic 
level was 400 kbps. This was a lot for systems to handle in 1991. I was testing 
ISDN bridges and discovered how you can't just bridge that type of network 
across a 56k connection. (I discovered the traffic when I first turned up the 
bridge. I ended up isolating it behind a router, built from an old VAX. At DEC, 
we built everything ouf of VAXen.) 

Switching, though, is what Frame Relay and ATM do, and now Carrier Ethernet is 
the big thing for fiber. It uses the VLAN tag to identify the virtual circuit; 
the MAC addresses are just passed along. Since it's connection-oriented (via 
the tag), it can have QoS assigned. I think it's theoretically possible to tag 
user ports, route on tags and set QoS on RouterOS, but it's not obvious how to 
do it all. Switching doesn't pass broadcast traffic; it provides more isolation 
and privacy than plain routing. Mesh routing then works at that layer, 
transparent to IP. It'll be interesting to set up. 




On 10/11/2012 4:53 PM, Scott Reed wrote: 


We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We run them 
in as routers, but do not NAT. Same benefits others mentioned for routing, just 
one fewer NAT. Never have a problem with it this way and can't see any good 
reason to NAT there. 

On 10/11/2012 3:46 PM, Arthur Stephens wrote: 


We currently use Ubiquiti radios in bridge mode and assign a ip address to the 
customers router. 
He have heard other wisp are using the Ubiquiti radio as a router. 
Would like feed back why one would do this when it appears customers would be 
double natted when they hook up their routers? 
Or does it not matter from the customer experience? 

Thanks 

-- 
Arthur Stephens 
Senior Sales Technician 
Ptera Wireless Inc. 
PO Box 135 
24001 E Mission Suite 50 
Liberty Lake, WA 99019 
509-927-7837 
For technical support visit http://www.ptera.net/support 
- 
This message may contain confidential and/or propriety information, and is 
intended for the person/entity to whom it was originally addressed. 
Any use by others is strictly prohibited. Please note that any views or 
opinions presented in this email are solely those of the author and are not 
intended to represent those of the company. 



___
Wireless mailing list Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 

No virus found in this message. 
Checked by AVG - www.avg.com 
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12 
Internal Virus Database is out of date. 

-- 
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration

 

Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060
(765) 439-4253
(855) 231-6239 


___
Wireless mailing list Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 
___ 
Wireless mailing list 
Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 

-- 
Fred Goldstein k1io fgoldstein at ionary.com 
ionary Consulting http://www.ionary.com/ 
+1 617 795 2701 

___
Wireless mailing list Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 



No virus found in this message. 
Checked by AVG - www.avg.com 
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12 
Internal Virus Database is out of date. 
-- 
Scott Reed
Owner
NewWays

Re: [WISPA] Ubiquiti Radios as routers

2012-10-12 Thread Fred Goldstein

Mike Hammett duly noted,

Fred, I don't think most of the people here understand what YOU'RE 
talking about. They think a switch is just a switch and they're all 
the same, but that's far from the truth.



Probably true, which is why I'd like to clarify it.  Vendors who sell 
primarily to ISPs or one-company IP networks don't realize how big 
the enterprise network market is, now largely moving to Carrier 
Ethernet as a cheaper substitute for leased lines, which are 
grotesquely overpriced in much of the US (if you're not in a major 
data center).  And there is opportunity for wireless here too, though 
nowadays it's mostly done via dedicated point-to-point radios, not 
shared networks.


At 10/12/2012 10:10 PM, Dennis Burgess wrote:
What is being described is the default behavior of any standard 
managed switch.  There is no virtual circuit being built and it 
still broadcasts across said VLAN.  They are simply only allowing 
the VLAN to go from point A to point B.  This though can be done at 
wire speed in the hardware of any switch and MT.


I'm not sure we're talking about the same thing.  It is allowing only 
the VLAN to go from A to B, while nothing else goes to A or B, and 
the VLAN is invisible to everyone else.  Which is really virtual 
circuit behavior; VLAN is the legacy name of the VC ID.


In CE switching, then, the VLAN receives no broadcasts from anyone 
else on the switch or network, and sends no broadcasts outside.  What 
goes onto that mapped port, or onto a VLAN pre-tagged to go to that 
port, is totally and completely invisible to all other users.  So 
it's secure enough for public safety use on a shared PMD.  This is 
different from a bridge, where broadcasts go everywhere.  One type of 
MEF service (EP-LAN) does actually emulate a LAN with 2 ports and 
broadcasts among them, but the more common EPL and EVPL would not 
know a broadcast frame from anything else, since they just pass the 
MAC addresses transparently.


This is not an intelligent method (the switching system not the 
people talking about this), as there can only be STP or other 
non-standard protocols to handle fail over.  The example is that if 
you have 5 switches in-line, you are simply ONLY allowing say 
vlan999 to tag ingress on port 22 on switch 1, then only flow though 
tagged on the trunk ports between switches, then finally only having 
one egress non-tagged port at switch 5 port 22..  Hence a sort of circuit..


Almost everything, including the RB951-2n, supports RSTP as well as 
STP, but yes beyond that the intelligence is non-standard.  Cisco, 
for instance, has a fairly elaborate routing (in the literal sense, 
not IP) protocol for optimizing every path.  Of course you don't see 
many multi-vendor CE networks... the edges can be different though.


This works great on large bandwidth wired applications, but going 
over anything wireless for the most part poses an issue.  The 
trunks are still seeing all broadcast traffic from all devices, 
maybe its not going as far and yes you can control it a bit more, 
but in the end, a packet storm on one VLAN will take down the 
wireless connection and all trunks on a backhaul radio.


The idea is that there are no broadcast packets.  You configure 
devices that use the network to think of it as point-to-point 
circuits.  Broadcasts only go to the opposite end of that EPL 
(2-point) or EVPL (point-to-multipoint).  I'm ignoring the EP-LAN 
case since that's not relevant here.


Also, traffic levels on each EPL (VLAN) are limited by the 
three-color traffic classifier (CIR+EIR).  So you cap each user at 
the ingress, and optionally assign a CIR to a smaller amount, for 
applications like VoIP.  However, typical unlicensed radio links 
aren't as predictable as fiber so the commitment isn't the same.


 Simply because the UBNT or whatever radio you are using can't 
handle 100,000 pps.  The switches, in hardware, can handle 
millions, making this situation not a major issue as we have plenty 
of hardware to handle those instances and with several mitigation 
systems built into these switches, you can further handle said 
traffic.  Not saying this method does not work, simply has its own 
gotchas just like anything else.


I wonder if that hardware handles the VLANs with the QoS (CIR/CBS, 
EIR/EBS) features.  Otherwise it could still be done in software, but 
not at the same speed.  I'd still expect, for example, an LTI box to 
be able to do it fast enough to keep up with a Ubiquiti 5GHz 
radio.  (AirFiber might be a bit trickier.)


The limitations is really in the fail over  it don't care what kind 
of packets or even if the packets are needed to traverse the 
network, hence more traffic than needed, but its better than one 
large bridge.  Building rings that have disabled ports can help, 
but still don't intelligently route around issues, as routing 
would do.But to the topic, yes, MT can ingress non-vlan tagged 
traffic and send it out as tagged traffic, and yes 

[WISPA] Ubiquiti Radios as routers

2012-10-11 Thread Arthur Stephens
We currently use Ubiquiti radios in bridge mode and assign a ip address to
the customers router.
He have heard other wisp are using the Ubiquiti radio as a router.
Would like feed back why one would do this when it appears customers would
be double natted when they hook up their routers?
Or does it not matter from the customer experience?

Thanks

-- 
Arthur Stephens
Senior Sales Technician
Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019
509-927-7837
For technical support visit http://www.ptera.net/support
 -

This message may contain confidential and/or propriety information, and is
intended for the person/entity to whom it was originally addressed.
Any use by others is strictly prohibited. Please note that any views or
opinions presented in this email are solely those of the author and are not
intended to represent those of the company.
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-11 Thread Greg Osborn

  
  
Very few customers know any difference.
  
  On 10/11/2012 3:46 PM, Arthur Stephens wrote:

We currently use Ubiquitiradios in bridge mode and
  assign a ip address to the customers router.
  He have heard other wisp are using theUbiquitiradio as a
router.
  Would like feed back why one would do this when it appears
customers would be double natted when they hook up their
routers?
  Or does it not matter from the customer experience?
  
Thanks


-- 
Arthur Stephens

Senior Sales Technician

Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019

509-927-7837

For technical support visit http://www.ptera.net/support
-

"This message may contain confidential and/or propriety
information,
and is intended for the person/entity to whom it was originally
addressed. 
Any use by others is strictly prohibited.
Please note that any views or opinions presented in this email
are solely those of the author and are not intended to represent
those of the company."
  
  
  
  
  ___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless



  

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-11 Thread Josh Luthman
Almost all of my customers have NAT'ed Ubnt CPE radios.  The handful that
need a static get charged for it (or free if business) and then I do the
port forwrading for them.

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


On Thu, Oct 11, 2012 at 3:49 PM, Greg Osborn gregwosb...@gmail.com wrote:

  Very few customers know any difference.


 On 10/11/2012 3:46 PM, Arthur Stephens wrote:

 We currently use Ubiquiti radios in bridge mode and assign a ip address to
 the customers router.
 He have heard other wisp are using the Ubiquiti radio as a router.
 Would like feed back why one would do this when it appears customers would
 be double natted when they hook up their routers?
 Or does it not matter from the customer experience?

 Thanks

  --
 Arthur Stephens
 Senior Sales Technician
 Ptera Wireless Inc.
 PO Box 135
 24001 E Mission Suite 50
 Liberty Lake, WA 99019
 509-927-7837
 For technical support visit http://www.ptera.net/support
  -

 This message may contain confidential and/or propriety information, and
 is intended for the person/entity to whom it was originally addressed.
 Any use by others is strictly prohibited. Please note that any views or
 opinions presented in this email are solely those of the author and are not
 intended to represent those of the company.


 ___
 Wireless mailing 
 listWireless@wispa.orghttp://lists.wispa.org/mailman/listinfo/wireless



 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-11 Thread Chris Fabien
We run Ubiquiti CPE in router mode and it acts as the NAT router for
the customer. We install a wifi router inside as part of standard
install package, but just run it as a switch+AP. This gives us more
visibility into customer network for troubleshooting and abuse
detection (why does this house have 27 computers), protects the
wireless side from broadcast traffic and rouge DHCP (yes you can also
just filter for that). We have port forwards in our default config for
access to the router, voip ATA, etc. Overall it has worked very well,
especially now that ubnt has uPnP available which is required for XBox
to work properly.

On Thu, Oct 11, 2012 at 3:46 PM, Arthur Stephens
arthur.steph...@ptera.net wrote:
 We currently use Ubiquiti radios in bridge mode and assign a ip address to
 the customers router.
 He have heard other wisp are using the Ubiquiti radio as a router.
 Would like feed back why one would do this when it appears customers would
 be double natted when they hook up their routers?
 Or does it not matter from the customer experience?

 Thanks

 --
 Arthur Stephens
 Senior Sales Technician
 Ptera Wireless Inc.
 PO Box 135
 24001 E Mission Suite 50
 Liberty Lake, WA 99019
 509-927-7837
 For technical support visit http://www.ptera.net/support

 -
 This message may contain confidential and/or propriety information, and is
 intended for the person/entity to whom it was originally addressed.
 Any use by others is strictly prohibited. Please note that any views or
 opinions presented in this email are solely those of the author and are not
 intended to represent those of the company.

 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-11 Thread Steve Barnes
All my customers are natted at the CPE unless they have Static IP. Actually we 
Nat at the AP as well. So they are triple Natted and I have lots of customers 
doing VPN's and every form of video and music and have never had one problem.

Pro's:
Customer can plug PC right into POE or switch and don't need a Router.
No worry if customer plugs router in backward of getting their DHCP on our AP
Customer has another level of security (yes its poor)

Con's:
Some items such as XBOX don't like it.
I can't remote login to their Router to see what they have done wrong.

Steve Barnes
General Manager
PCS-WIN / RC-WiFihttp://www.rcwifi.com/

From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf 
Of Arthur Stephens
Sent: Thursday, October 11, 2012 3:47 PM
To: wireless@wispa.org
Subject: [WISPA] Ubiquiti Radios as routers

We currently use Ubiquiti radios in bridge mode and assign a ip address to the 
customers router.
He have heard other wisp are using the Ubiquiti radio as a router.
Would like feed back why one would do this when it appears customers would be 
double natted when they hook up their routers?
Or does it not matter from the customer experience?

Thanks

--
Arthur Stephens
Senior Sales Technician
Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019
509-927-7837
For technical support visit http://www.ptera.net/support
 -
This message may contain confidential and/or propriety information, and is 
intended for the person/entity to whom it was originally addressed.
Any use by others is strictly prohibited. Please note that any views or 
opinions presented in this email are solely those of the author and are not 
intended to represent those of the company.
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-11 Thread Sam Tetherow
We do it because it makes customer maintenance a lot easier.  They can 
replace/remove their router without having to call the office or 
changing settings in their computer or router, everything comes with 
DHCP enabled default.  There are very few places where the customer will 
ever know.  If there is a problem, we will set the radio in bridge mode 
and give them a static IP, but the only place we ever do that is if they 
have a higher end router and need to be able to run VPNs.


If they want to manage their own port forwarding and such, we just DMZ 
the radio (be sure you uncheck the DMZ management ports) and forward all 
the traffic to a static 192.168.100.x which is what they statically set 
their router to.


We use to be all bridged with CB3s back in the day, and I have no desire 
what so ever to go back.



On 10/11/2012 02:46 PM, Arthur Stephens wrote:
We currently use Ubiquiti radios in bridge mode and assign a ip 
address to the customers router.

He have heard other wisp are using the Ubiquiti radio as a router.
Would like feed back why one would do this when it appears customers 
would be double natted when they hook up their routers?

Or does it not matter from the customer experience?

Thanks

--
Arthur Stephens
Senior Sales Technician
Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019
509-927-7837
For technical support visit http://www.ptera.net/support
 - 

This message may contain confidential and/or propriety information, 
and is intended for the person/entity to whom it was originally 
addressed.
Any use by others is strictly prohibited. Please note that any views 
or opinions presented in this email are solely those of the author and 
are not intended to represent those of the company.



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-11 Thread Scott Reed
We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We run 
them in as routers, but do not NAT.  Same benefits others mentioned for 
routing, just one fewer NAT.  Never have a problem with it this way and 
can't see any good reason to NAT there.


On 10/11/2012 3:46 PM, Arthur Stephens wrote:
We currently use Ubiquiti radios in bridge mode and assign a ip 
address to the customers router.

He have heard other wisp are using the Ubiquiti radio as a router.
Would like feed back why one would do this when it appears customers 
would be double natted when they hook up their routers?

Or does it not matter from the customer experience?

Thanks

--
Arthur Stephens
Senior Sales Technician
Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019
509-927-7837
For technical support visit http://www.ptera.net/support
 - 

This message may contain confidential and/or propriety information, 
and is intended for the person/entity to whom it was originally 
addressed.
Any use by others is strictly prohibited. Please note that any views 
or opinions presented in this email are solely those of the author and 
are not intended to represent those of the company.



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12
Internal Virus Database is out of date.



--
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration

 


Mikrotik Advanced Certified
 
www.nwwnet.net

(765) 855-1060
(765) 439-4253
(855) 231-6239

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-11 Thread Matt Jenkins

  
  
I did this for the first time last week. It seems to work fine.


On 10/11/2012 12:46 PM, Arthur Stephens
  wrote:

We currently use Ubiquitiradios in bridge mode and
  assign a ip address to the customers router.
  He have heard other wisp are using theUbiquitiradio as a
router.
  Would like feed back why one would do this when it appears
customers would be double natted when they hook up their
routers?
  Or does it not matter from the customer experience?
  
Thanks


-- 
Arthur Stephens

Senior Sales Technician

Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019

509-927-7837

For technical support visit http://www.ptera.net/support
-

"This message may contain confidential and/or propriety
information,
and is intended for the person/entity to whom it was originally
addressed. 
Any use by others is strictly prohibited.
Please note that any views or opinions presented in this email
are solely those of the author and are not intended to represent
those of the company."
  
  
  
  
  ___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless



  

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-11 Thread Sam Tetherow
Not sure I under stand the no-NAT, so every device on the other side of 
the CPE has it's own public IP?


On 10/11/2012 4:53 PM, Scott Reed wrote:
We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We 
run them in as routers, but do not NAT.  Same benefits others 
mentioned for routing, just one fewer NAT.  Never have a problem with 
it this way and can't see any good reason to NAT there.


On 10/11/2012 3:46 PM, Arthur Stephens wrote:
We currently use Ubiquiti radios in bridge mode and assign a ip 
address to the customers router.

He have heard other wisp are using the Ubiquiti radio as a router.
Would like feed back why one would do this when it appears customers 
would be double natted when they hook up their routers?

Or does it not matter from the customer experience?

Thanks

--
Arthur Stephens
Senior Sales Technician
Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019
509-927-7837
For technical support visit http://www.ptera.net/support
 - 

This message may contain confidential and/or propriety information, 
and is intended for the person/entity to whom it was originally 
addressed.
Any use by others is strictly prohibited. Please note that any views 
or opinions presented in this email are solely those of the author 
and are not intended to represent those of the company.



___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12
Internal Virus Database is out of date.



--
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration

  


Mikrotik Advanced Certified
  
www.nwwnet.net

(765) 855-1060
(765) 439-4253
(855) 231-6239


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-11 Thread Fred Goldstein

At 10/11/2012 06:52 PM, SamT wrote:
Not sure I under stand the no-NAT, so every device on the other side 
of the CPE has it's own public IP?


There could be one NAT, at the access point.

My taste, which to be sure I haven't tested at scale in a wireless 
network (but plan to), is to follow what is becoming standard 
wireline practice and do switching, not bridging, at layer 
2.  Routing would then be lumped into one place, making it easier to manage.


The problem with small Linux-based systems (this includes both UBNT 
and MT) is that they don't tend to have switching documented or set 
up in the UI, even if it's possible.  Bridging is bad -- it was 
designed for orange hose Ethernet, and it passes broadcast traffic to 
everyone.  We invented this at DEC in the 1980s and discovered how it 
doesn't scale too well -- we had a couple of thousand DECnet and IP 
nodes on a bridged LAN, and the background broadcast traffic level 
was 400 kbps.  This was a lot for systems to handle in 1991.  I was 
testing ISDN bridges and discovered how you can't just bridge that 
type of network across a 56k connection.  (I discovered the traffic 
when I first turned up the bridge.  I ended up isolating it behind a 
router, built from an old VAX.  At DEC, we built everything ouf of VAXen.)


Switching, though, is what Frame Relay and ATM do, and now Carrier 
Ethernet is the big thing for fiber.  It uses the VLAN tag to 
identify the virtual circuit; the MAC addresses are just passed 
along.  Since it's connection-oriented (via the tag), it can have QoS 
assigned.  I think it's theoretically possible to tag user ports, 
route on tags and set QoS on RouterOS, but it's not obvious how to do 
it all.  Switching doesn't pass broadcast traffic; it provides more 
isolation and privacy than plain routing.  Mesh routing then works at 
that layer, transparent to IP.  It'll be interesting to set up.




On 10/11/2012 4:53 PM, Scott Reed wrote:
We run MT, not UBNT, CPE, but it doesn't matter what brand it 
is.  We run them in as routers, but do not NAT.  Same benefits 
others mentioned for routing, just one fewer NAT.  Never have a 
problem with it this way and can't see any good reason to NAT there.


On 10/11/2012 3:46 PM, Arthur Stephens wrote:
We currently use Ubiquiti radios in bridge mode and assign a ip 
address to the customers router.

He have heard other wisp are using the Ubiquiti radio as a router.
Would like feed back why one would do this when it appears 
customers would be double natted when they hook up their routers?

Or does it not matter from the customer experience?

Thanks

--
Arthur Stephens
Senior Sales Technician
Ptera Wireless Inc.
PO Box 135
24001 E Mission Suite 50
Liberty Lake, WA 99019
509-927-7837
For technical support visit 
http://www.ptera.net/supporthttp://www.ptera.net/support


-
This message may contain confidential and/or propriety 
information, and is intended for the person/entity to whom it was 
originally addressed.
Any use by others is strictly prohibited. Please note that any 
views or opinions presented in this email are solely those of the 
author and are not intended to represent those of the company.




___
Wireless mailing list
mailto:Wireless@wispa.orgWireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


No virus found in this message.
Checked by AVG - http://www.avg.comwww.avg.com
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12
Internal Virus Database is out of date.



--
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration



Mikrotik Advanced Certified

http://www.nwwnet.netwww.nwwnet.net
(765) 855-1060
(765) 439-4253
(855) 231-6239


___
Wireless mailing list
mailto:Wireless@wispa.orgWireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


 --
 Fred Goldsteink1io   fgoldstein at ionary.com
 ionary Consulting  http://www.ionary.com/
 +1 617 795 2701 ___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless


Re: [WISPA] Ubiquiti Radios as routers

2012-10-11 Thread Mike Hammett
I do wish they made it a bit more carrier in that regard. I use PPPoE because 
I can control everything that way, but it sure would be nice to use something 
to control all of that business, then let their device manage IPs...  just like 
cable.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -
From: Fred Goldstein fgoldst...@ionary.com
To: WISPA General List wireless@wispa.org
Sent: Thursday, October 11, 2012 7:35:53 PM
Subject: Re: [WISPA] Ubiquiti Radios as routers


At 10/11/2012 06:52 PM, SamT wrote: 


Not sure I under stand the no-NAT, so every device on the other side of the CPE 
has it's own public IP? 
There could be one NAT, at the access point. 

My taste, which to be sure I haven't tested at scale in a wireless network (but 
plan to), is to follow what is becoming standard wireline practice and do 
switching, not bridging, at layer 2. Routing would then be lumped into one 
place, making it easier to manage. 

The problem with small Linux-based systems (this includes both UBNT and MT) is 
that they don't tend to have switching documented or set up in the UI, even if 
it's possible. Bridging is bad -- it was designed for orange hose Ethernet, and 
it passes broadcast traffic to everyone. We invented this at DEC in the 1980s 
and discovered how it doesn't scale too well -- we had a couple of thousand 
DECnet and IP nodes on a bridged LAN, and the background broadcast traffic 
level was 400 kbps. This was a lot for systems to handle in 1991. I was testing 
ISDN bridges and discovered how you can't just bridge that type of network 
across a 56k connection. (I discovered the traffic when I first turned up the 
bridge. I ended up isolating it behind a router, built from an old VAX. At DEC, 
we built everything ouf of VAXen.) 

Switching, though, is what Frame Relay and ATM do, and now Carrier Ethernet is 
the big thing for fiber. It uses the VLAN tag to identify the virtual circuit; 
the MAC addresses are just passed along. Since it's connection-oriented (via 
the tag), it can have QoS assigned. I think it's theoretically possible to tag 
user ports, route on tags and set QoS on RouterOS, but it's not obvious how to 
do it all. Switching doesn't pass broadcast traffic; it provides more isolation 
and privacy than plain routing. Mesh routing then works at that layer, 
transparent to IP. It'll be interesting to set up. 




On 10/11/2012 4:53 PM, Scott Reed wrote: 


We run MT, not UBNT, CPE, but it doesn't matter what brand it is. We run them 
in as routers, but do not NAT. Same benefits others mentioned for routing, just 
one fewer NAT. Never have a problem with it this way and can't see any good 
reason to NAT there. 

On 10/11/2012 3:46 PM, Arthur Stephens wrote: 


We currently use Ubiquiti radios in bridge mode and assign a ip address to the 
customers router. 
He have heard other wisp are using the Ubiquiti radio as a router. 
Would like feed back why one would do this when it appears customers would be 
double natted when they hook up their routers? 
Or does it not matter from the customer experience? 

Thanks 

-- 
Arthur Stephens 
Senior Sales Technician 
Ptera Wireless Inc. 
PO Box 135 
24001 E Mission Suite 50 
Liberty Lake, WA 99019 
509-927-7837 
For technical support visit http://www.ptera.net/support 
- 
This message may contain confidential and/or propriety information, and is 
intended for the person/entity to whom it was originally addressed. 
Any use by others is strictly prohibited. Please note that any views or 
opinions presented in this email are solely those of the author and are not 
intended to represent those of the company. 



___
Wireless mailing list Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 

No virus found in this message. 
Checked by AVG - www.avg.com 
Version: 2013.0.2677 / Virus Database: 2591/5802 - Release Date: 10/01/12 
Internal Virus Database is out of date. 

-- 
Scott Reed
Owner
NewWays Networking, LLC
Wireless Networking
Network Design, Installation and Administration

 

Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060
(765) 439-4253
(855) 231-6239 


___
Wireless mailing list Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 
___ 
Wireless mailing list 
Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless 

-- 
Fred Goldstein k1io fgoldstein at ionary.com 
ionary Consulting http://www.ionary.com/ 
+1 617 795 2701 
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless