Hi Paul, Regardless of whether you run routed or switched, the speed is about the same. Unlike a hardware switch that has special processors to handle traffic at "wire speeds", a "10GB/s backplane, etc, Mikrotik runs on off-the-shelf PC hardware. The processing power needed to get a packet from port A to port B is about the same regardless of whether you route or switch.
We haven't seen much of a performance difference between the two. A link that was 3 ms before seems to be 3 ms now. A multi-hop link that was 6 ms before seems to be about 6 ms now. For us, the advantages were: 1. Centralized customer management. All DHCP and PPPoE handled at a single point. To make changes, we have only one place to visit. 2. Ability to roam. We run the same SSID on all towers and sectors. Now when people roam from one tower to another, their session will follow them seamlessly. 3. Reduced CPU and memory consumption on the Mikrotiks on towers. NAT (connection tracking) and PPPoE are especially CPU and memory intensive. With each AP doing these functions, some of our busy towers were getting pegged at 100% CPU -- not a good thing. Those same towers are now averaging 25% CPU and never seem to go above 60% CPU. 4. Get rid of Mikrotik's buggy OSPF. We love OSPF and use it extensively on our network. But Mikrotik's OSPF implementation has been buggy since day 1 of RouterOS 2.9. We found that OSPF worked reliably under RouterOS 2.8, but under 2.9, we've seen boxes that have all neighbors and no routes, one neighbor (itself) and no routes, no neighbors at all, reset continuously (exstart/init sequence), etc. Everyone's situation is different, but for us, it was definitely the right decision to make. Regards, Dave 989-837-3790 x 151 989-837-3780 fax [EMAIL PROTECTED] www.mercury.net 129 Ashman St, Midland, MI 48640 ----- Original Message ----- From: "Paul Hendry" <[EMAIL PROTECTED]> To: "'WISPA General List'" <wireless@wispa.org> Sent: Tuesday, June 13, 2006 8:03 AM Subject: RE: [WISPA] looking for a device > We too have been looking at moving from routed to a switched Mikrotik for > the core network but the unknown quantity seems to be if there are any > latency or speed issues related to the move. A "true" switched network is > faster than a routed network as the switching is done at a hardware level > but in Mikrotik I believe both switching and routed is done in software. > What have you seen? > > P. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of David Sovereen > Sent: 13 June 2006 04:12 > To: WISPA General List > Subject: Re: [WISPA] looking for a device > > We just completed converting our network from routed to bridged. Where each > > AP (we run Mikrotik) used to do its own DHCP and PPPoE to customers and > speak OSPF to the network, the APs (still Mikrotik) now bridge traffic to a > regional Mikrotik that handles PPPoE and DHCP for that region. We are using > > RSTP. In this way, people can roam from one tower to another and their DHCP > > lease is still good at the next tower. A region for us to 3 to 4 counties. > > We converted our first region about a month ago and finished the last one > last weekend. We're very pleased with the results so far. > > Dave > > ----- Original Message ----- > From: "Charles Wu" <[EMAIL PROTECTED]> > To: "'WISPA General List'" <wireless@wispa.org> > Sent: Monday, June 12, 2006 9:22 PM > Subject: RE: [WISPA] looking for a device > > > It is worth noting that you lose the benefits of routing protocols when you > bridge your network > > Sure, there's always RSTP... (heh) > > Many larger wireless / Wifi based architecture these days seem to be > favoring a layer 3 tunneling / handoff method over a bridged layer 2 network > > -Charles > > ------------------------------------------- > CWLab > Technology Architects > http://www.cwlab.com > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Tom DeReggi > Sent: Monday, June 12, 2006 5:30 PM > To: WISPA General List > Subject: Re: [WISPA] looking for a device > > > To clarify.... > > The term I referred to as "Double VLAN" is not the technically correct name > (thats just what I call it), it is actually called "Q in Q" as stated by > several in this thread. > > One of the reasons this is valuable is for a wholesale network. It basically > > allows you to create a single VLAN end to end across your network for a > subscriber or reseller, and still use VLAN for your local needs to operate > your network. > > I'll give an example of where I might use VLAN for my network need. I have a > > single fiber connection from the basement to the roof. On the roof I have a > > VLAN switch and 6 sector radios. I have a router in the basement. I could > then seperate data between the different radio traffic by giving a unique > VLAN to the Ethernet port that each sector radio connects to, and route > between them in my basement router. > > I'll give an example of where I'd use a VLAN end to end for a reseller. > Reseller has a connection between me and them at one point on my network. > The reseller might provide the backbone and IPs. The client routes the > customers traffic to a specific VLAN when entering my network. I then have > that VLAN configured across my network until reaches the end user's building > > router that terminates the VLAN. > > Now what happens when the resellers customer (example 2) resides in the > building (example 1)? Normally two VLANs can't exist simultaneously as teh > switch wouldn;t know which ID to tag data with. Q in Q VLAN would allow one > > VLAN ID to reside in side of another VLAN. Its the same concept as > tunnelling, except for its not. > > Now how does this apply to radios that support Q in Q? Depends. Use your > imagination. The first problem is can the radio pass Q in Q VLAN data? > Second can it tag it? Being able to tag VLAN data at the radio level can be > extremely useful. First off it avoids having to configure a second device > (VLAN switch) that complicates the automation of configurations. Part of > the Idea is that CLECs and Governement, are all high on Security, and they > do not want to have to coordinate complex IP models between their systems > and the wholesalers, instead they want to be able to send traffic LAyer2 and > > seperate traffic so one client does not have the abilty to see the other > client's traffic. Its sort of an Ethernet way of doing a Private Virtual > Circuit. > > The only problem with VLAN is you need to have every component of you > network that passes VLANs to be able to pass large packets so Full MTU can > be delivered to clients. This is one of the limits to Wifi and regular > switches, is many Wifi devices and all non managed switches do not pass > large packets. > > Radio like Trango and Alvarion (with Q in Q support) have the abilty to pass > > large packets. > > The other advantage of VLAN is that when used across a PtMP design and VLAN > support at CPE, it allows doing remote banwdith management based on the > customers circuit ID, and having a way to distinguish and differentiate the > data. > > Q in Q, gives the provider flexibilty on how and when they would like to use > > VLAN and in multiple ways simultaneously. > > Its uncertain how Q in Q will be used for sure, as VLAN does add much > complexity over say a basic bridged design. Part of the benefit, is that > redundancy is not always supported in an ideal way when VLAN is used. By > allowing a VLAN end to end encapsulated in the other packets, it potentially > > could allow avoiding the pitfalls that limit redundancy by having the end > locations (the reseller and the client) the one tagging the VLAN and > knowing that that VLAN info survives any other VLAN tagging that may happen > on the network, or for that matter abilty for that data to route across > paths that are not technically that VLAN assignment on the other layer. I'm > > not explaining this clearly, but that is the gist of it. > > The end result is, if a provider's whole network supports Q in Q, it allows > them to compete with other fiber Metro-E services. > > Many believe that the design of the future for Metro deployments is to run > MPLS at the edge devices, and then Q in Q VLAN inside the Metro Ethernet > rings. The key ideas here is abilty to creaetequivelent of virtual circuits > > of Ethernet. > > Tom DeReggi > RapidDSL & Wireless, Inc > IntAirNet- Fixed Wireless Broadband > > > ----- Original Message ----- > From: "Charles Wu" <[EMAIL PROTECTED]> > To: "'WISPA General List'" <wireless@wispa.org> > Sent: Friday, June 09, 2006 11:33 AM > Subject: RE: [WISPA] looking for a device > > > I think Jon is asking about the "double VLAN" -- or a "q in q" > implementation It's extremely useful for creating virtual bridged customer > networks > > -Charles > > ------------------------------------------- > CWLab > Technology Architects > http://www.cwlab.com > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Rick Harnish > Sent: Friday, June 09, 2006 9:10 AM > To: 'WISPA General List' > Subject: RE: [WISPA] looking for a device > > > Virtual LAN. Imagine segregating segments of your network across a backhaul > pipe so that they flow together but don't actually see each other. Managed > switches have the ability to create VLANs per port. Think of it as a merger > between routing and switching. Its a pipe or several inside a pipe. Tried > to be simple here, I'm sure someone else can give you a more technical > description. > > Rick Harnish > President > OnlyInternet Broadband & Wireless, Inc. > 260-827-2482 Office > 260-307-4000 Cell > 260-918-4340 VoIP > www.oibw.net > [EMAIL PROTECTED] > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of John Scrivner > Sent: Friday, June 09, 2006 9:39 AM > To: WISPA General List > Subject: Re: [WISPA] looking for a device > > Can you or someone explain what double VLAN is? I have never heard of such a > thing. How can it be used to help us? Thanks, Scriv > > > > > Yo may want to look at Alvarion. Alvarion does support VLAN. new > > Firmware4 supports double VLAN also. Alvarion used to have one model > > that was designed to have a second integrated radio into it. > > I can't remember if it was a 900/2.4 combo, or a 5.8/2.4 combo. > > > -- > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > -- > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > -- > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > -- > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > -- > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > -- > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 12/06/2006 > > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 12/06/2006 > > > -- > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
