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 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
In the application I'm thinking of, the CPE can't route IP, as it's
not a public IP network (ISP) application. It's the (more lucrative)
enterprise network case, where the IP networks are private payload,
so you're literally only providing a pipe for their networks. Now
opening a bridge to customers would be a disaster, as the model of a
bridge is to pass everything unless blocked. But a switch is the
opposite, only pass what's explicitly allowed, nothing else. I used
to avoid "Ethernet" stuff like the plague because it was all bridging
until a few years ago, when MEF took off.
Dennis
On Fri, Oct 12, 2012 at 8:18 PM, Scott Reed
<<mailto:sr...@nwwnet.net>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?
--
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
