I have seen Pseudobridge on the Mikrotik side give OSPF issues. For the customer side no issues. But with OSPF and pseudobridge you have duplicate Mac addresses due to the nature of how it works. This can cause issues when running OSPF, at least in our experience. Had a network of 90 some backhauls all in pseudobridge. After converting to WDS many issues disappeared.
-- Justin Wilson <j...@mtin.net> http://www.mtin.net/blog Wisp Consulting Tower Climbing Network Support From: Tom DeReggi <wirelessn...@rapiddsl.net> Reply-To: WISPA General List <wireless@wispa.org> Date: Wed, 28 Apr 2010 19:33:35 -0400 To: WISPA General List <wireless@wispa.org> Subject: Re: [WISPA] Ever wonder how bad RB333/444 stacked cards interfere? Pseudobridge has tested to perform almost exactly the same as Station mode. It does NOT have the same slowness side effects as WDS. For us, it looks like pseduobridge might work for us for the client side, because we dont use layer2 protocols across the wireless link to the customer... That might not be the case for other WISPs that have more dynamic provisioning. Tom DeReggi RapidDSL & Wireless, Inc IntAirNet- Fixed Wireless Broadband ----- Original Message ----- From: "Paul Hendry" <paul.hen...@skyline-networks.com> To: "wireless" <wireless@wispa.org> Sent: Wednesday, April 28, 2010 4:58 AM Subject: Re: [WISPA] Ever wonder how bad RB333/444 stacked cards interfere? > Have you tested pseudobridge to achieve a similar affect without WDS? > > -----Original Message----- > From: Tom DeReggi [mailto:wirelessn...@rapiddsl.net] > Sent: 28 April 2010 01:41 > To: WISPA General List > Subject: Re: [WISPA] Ever wonder how bad RB333/444 stacked cards > interfere? > > Yes, WDS adds significant overhead. But.. its not a real problem because > there is a hardware solution to fix it. Thats why I've been an advocate > for > faster processor CPE SBCs for like ever. And its why we dont use low cost > $50 slow processor CPEs. When using 533Mhz and 680mMhz processors it > really > shouldn't matter anymore, there is plenty of CPU horsepower. When we were > doing MT throughoput testing last week on 433AH, we were getting much > slower > throughput with WDS than Station mode and routing, BUT the bottle neck was > not CPU usage. We never exceeded 20% CPU usage, even with WDS. WDS on MT > is > slower, but for different reasons than CPU that I have not yet learned. > > With StarOS and 533 boards, we had almost 40% higher CPU usage with WDS, > BUT > WDS passed traffic just as fast as any of its routing or station modes, > with > plenty of CPU to spare. > > One of the tests we are going to run this week, is repeating the WDS tests > using RB600 or RB800s which use netwqork processor for IO, to verify > whether > there was a different type of hardware bottle neck on the RB433AH other > than > CPU. But I'm predicting its a software issue contributing the the > slowness. > > If you are selling a sub a 10mb service, ther is plenty of CPU respources > even with low cost CPEs. And if need to passfull capacity, (using > 20-30mpbs > plus) > There should be plenty of revenue comming in to justify paying an extra > $50 > one time for faster CPUs. > > My arguement is that all commercial grade stuff bridges well... Canopy, > Trango, Alvarion, what ever. These devices do NOT have fast processors > compared to the MT type SBCs available on the street today. The MTs > should > be capable of bridging (WDS) just the same, from a hardware perspective, > and > I'd say the same for UBQT. > > I want to make you I'm clear... we run bridged radio links. But we do not > run a bridged network. We use routers at customer's Demarc before they > connect to us, and we run a router at the cell site behind every AP. But > we > want Radio Links to look like a long patch cable for management reasons, > and > flexibility reasons. > > Also note that using WDS Slave has different issues of consideration. In > that case the client (slave) operates like an AP. All sort of RF > efficienties could arise. > But the goal was to use StationWDS, which was meant as a solution to > operate > like a station, except to add the second MAC Address to the header. > Its something that should be efficent to do, without much RF trade off, in > theory. But because MT is someone secrative on exactly what they are doing > to achieve Station WDS, its impossible for me to conclude accurately, and > I > can only guess, and measure the results.. > > Tom DeReggi > RapidDSL & Wireless, Inc > IntAirNet- Fixed Wireless Broadband > > > ----- Original Message ----- > From: "Paul Hendry" <paul.hen...@skyline-networks.com> > To: "wireless" <wireless@wispa.org> > Sent: Tuesday, April 27, 2010 6:41 AM > Subject: Re: [WISPA] Ever wonder how bad RB333/444 stacked cards > interfere? > > >> Hey Tom, >> >> Do you have any issues/limitations running 100% WDS instead of a standard >> routed network? Would have thought WDS + NStreme would cause CPU related >> issues and extra overhead might limit the amount of bandwidth available >> per AP? >> >> Many thanks, >> >> Paul. >> >> -----Original Message----- >> From: Tom DeReggi [mailto:wirelessn...@rapiddsl.net] >> Sent: 27 April 2010 05:34 >> To: wa4...@arrl.net; WISPA General List >> Subject: Re: [WISPA] Ever wonder how bad RB333/444 stacked cards >> interfere? >> >> Yes. We let and encourage all our customers to pick their own routers (so >> they are liable for their decission, not us), which is why we like to >> bridge >> at customer CPE end. >> >> The reason we need 5-9 eth ports is for when we serve shopping centers or >> industrial park warehouse type clients. >> We run one CPE to the building, but there is not anywhere inside the >> building for us to put indoor equipment. >> There is also rarely reliable AC power on the roof, without eating the >> cost >> of electrician and painful permitting. >> So we put a 5-9 eth port device on the roof, fed by POE. Then we run a >> CAT5 >> for each customer accross the roof, and enter each customer's suite/bay >> through/underneith their AIRConditioning Unit entry, usually located on >> the >> roof. Landlords hate seeing cable dropped over edge of building, so they >> like it when we do it that way. We then power the roof equipment (POE) >> from >> one of the customer's suites. If they cancel, we just move the POE to >> another suite, and change their port to teh POE port at the outdoor >> equipment. This model has worked wonderfully for us. We can go install a >> new >> building for about $300 with one client, and easilly accommodate the rest >> of >> the tenants as we follow back with sales, without having to replicate any >> work or disrupt any pre-existing customers there. With the MT being an >> integrated Radio and Switch, provisioning and remote troubleshooting is >> really easy. The only flaw is AC Power might not be harded for power >> outages. So after we earn some revenue for a while, we'll sometimes go >> back, >> and buildout our own power source. I was pretty excited about the Tycon >> Outdoor battery backup case, because I think they'd work well for this >> application. >> >> Tom DeReggi >> RapidDSL & Wireless, Inc >> IntAirNet- Fixed Wireless Broadband >> >> >> ----- Original Message ----- >> From: "Leon D. Zetekoff" <wa4...@backwoodswireless.net> >> To: <wireless@wispa.org> >> Sent: Monday, April 26, 2010 8:49 PM >> Subject: Re: [WISPA] Ever wonder how bad RB333/444 stacked cards >> interfere? >> >> >>> On 04/26/2010 08:12 PM, Tom DeReggi wrote: >>>> Are you bridging at the AP and CPE, and does it work? >>>> >>>> Something something that was brought to my attention is that UBQT has >>>> Iperf >>>> built in at teh command line. So technically, if we used UBQT at the >>>> CPE >>>> and >>>> MT as AP, we could still do speed tests easilly, since all our MT APs >>>> plug >>>> into our proprietary cell site routers which have Iperf. >>>> >>>> But does it bridge OK? We dont really need the MT AP. What we do need >>>> is >>>> 5-9 >>>> port CPEs everyonce in a while, which locks us into the MT solutions in >>>> some >>>> locations, or we ahve to add one more component of failure. Truthfully, >>>> that >>>> is probably what we are going to start doing, where we decide to use >>>> UBQT. >>>> Run UBQT radios, then put a MT router at the end where we need 5-9 >>>> ports. >>>> They are pretty inexpensive now, its not that big a deal anymore to >>>> duplicate expense. >>>> >>> Hey Tom...didya ever think of letting the customer supply there own >>> "router" behind the RF CPE? >>> >>> Leon >>> >>> >>> -------------------------------------------------------------------------------- >>> WISPA Wants You! Join today! >>> http://signup.wispa.org/ >>> -------------------------------------------------------------------------------- >>> >>> WISPA Wireless List: wireless@wispa.org >>> >>> Subscribe/Unsubscribe: >>> http://lists.wispa.org/mailman/listinfo/wireless >>> >>> Archives: http://lists.wispa.org/pipermail/wireless/ >> >> >> >> -------------------------------------------------------------------------------- >> WISPA Wants You! Join today! >> http://signup.wispa.org/ >> -------------------------------------------------------------------------------- >> >> WISPA Wireless List: wireless@wispa.org >> >> Subscribe/Unsubscribe: >> http://lists.wispa.org/mailman/listinfo/wireless >> >> Archives: http://lists.wispa.org/pipermail/wireless/ >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> >> >> >> >> -------------------------------------------------------------------------------- >> WISPA Wants You! Join today! >> http://signup.wispa.org/ >> -------------------------------------------------------------------------------- >> >> WISPA Wireless List: wireless@wispa.org >> >> Subscribe/Unsubscribe: >> http://lists.wispa.org/mailman/listinfo/wireless >> >> Archives: http://lists.wispa.org/pipermail/wireless/ > > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ ---------------------------------------------------------------------------- ---- WISPA Wants You! Join today! http://signup.wispa.org/ ---------------------------------------------------------------------------- ---- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
