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/