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 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 listwirel...@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 listwirel...@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 > listWireless@wispa.orghttp://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 > > -- *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, USA<http://www.wlan1.com/RouterOS_Training_p/5d-stl-training-july2012.htm> 5-Day Advanced RouterOS Workshop – Oct 8th 2012 – St. Louis, MO, USA<http://www.wlan1.com/RouterOS_Training_p/5d-stl-training-oct2012.htm> *
_______________________________________________ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless
