This was so easy to configure in StarOS. Why is it impossible in StarVX?

[VerilanES]

Have a 2-dual CM9 WAR boards with the newest firmware and I'm using apConfig 1.5 to set them up. Here's what I would like to do (and what I was able to accomplish using a WRAP setup. my only issue with WRAP was throughput)

Server WAR:
Eth0 bridged to WPCI0
Eth1 bridged to WPCI1

Client WAR:
Eth0 bridged to WPCI0
Eth1 bridged to WPCI1

Server WPCI0 connected to Client WPCI0
Server WPCI0 connected to Client WPCI0

VDS established between Server WPCI0 and Client WPCI0
VDS established between Server WPCI1 and Client WPCI1

PC connected to Server Eth0 talks to PC connected to Client Eth0
PC connected to Server Eth1 talks to PC connected to Client Eth1

With WPCI1 cards removed from both sides of the link, I was able to get this type of PC2PC communication working no problem. I ran my bandwidth tests (there's another post about the speeds) and pass traffic without a hitch. As soon as I added the WPCI1 cards to either side, the whole thing fell apart and I wasn't able to pass any traffic on any interface or subnet. Here's the config that worked original with only one WPCI0 pair.

Server
SSID: unique1
setup as access point
Eth0:192.168.0.1
WPCI0: 192.168.1.1
All connections bridged

Client
SSID: unique2
setup as Wireless Client Bridge
Eth0:192.168.0.2
WPCI0: 192.168.1.2
All connections bridged

*PERFECT*

So I added the addiontal cards and configured like so

Server
SSID: unique2
setup as Access Point
Eth1: 192.168.2.1
WPCI1: 192.168.3.1
All connections bridged

Client
SSID: unique2
setup as Wireless Client Bridge
Eth1: 192.168.2.2
WPCI1: 192.168.3.2
All connections bridged

*NOPE*

In StarOS I was able to setup seperate bridge numbers for each interface pair which would isolate the pairs from each other. Can I not do that with StarVX? Is that causing my problem? I was also able to specify completely separate VDS numbers. Am I to assume since I cannot set a VDS number (that I can tell) that my pairs are trying to connect using the same VDS? I would imagine that this would in effect create a bridge between all interfaces and cause all sorts of issues.

So, what do I do? how can I set this up so that it works? If I need to setup static routes, I don't even know where to start to accomplish what I'm trying to do and turning on RIP doesn't seem to solve anything.

help!!!

[VerilanES]

mistyped the initial setup

Server WPCI0 connected to Client WPCI0
Server WPCI1 connected to Client WPCI1

[lonnie]

Where do I start on this. First of all there is no VDS, so no, you cannot specify a VDS device.

The bridging for this first release was strictly a simple bridge with all devices. We changed systems before we got the software enhanced to have separate bridge groups.

You are bridging. What are those IP addresses for? The ONLY IP you should have is on ONE device for the purpose of doing configuration. A bridge is NOT a destination. It passes traffic between physical segments. If you have those separate subnets on the devices you are routing. Why on earth would you then mess it up by setting bridge mode?

You cannot have bridge loops, which you currently have by having multiple connections between Server and Client. If you could see the traffic you would see a major amount of traffic being echoed in a loop.

Bridging works on MAC level. It is layer 2. A physical segment should have a single mask or subnet size.

I don't want to come on too defensive here, but you really have a wrong design and you cannot blame the software. It is doing what it is supposed to do.

The new Linux software that will be released shortly (check the thread on v3 for WAR) will have the old familiar bridge groups. We will also have STP so that you can use your plug and play approach and it terminates bridge loops. With any luck on development time frame we will even have VDS. CBQ, Beacon, firewall, RIP and OSPF will also be there.

Once we get the first release out the door we will work towards Multiple ESSID, WPA, PPPoE server and client, HotSpot, and other finishing touches.

[VerilanES]

my ignorance is only surpassed by your expertise. thank you

[VerilanES]

You must get so tired of people that don't understand network architecture complaining about network arhitecture not working! We just want it to work the same way it does in our heads!

:)

Just be patient with us. we'll come along.

[lonnie]

I try to be patient. Sometimes, late at night I get too harsh. Sorry.

The system you have laid out would be perfect for a routed backbone. It would also somewhat accomplish your attempt to do full duplex using static routes and default routes imaginatively.

You have the default route on one radio and you have static routes to get the return traffic back to the user on the other radio. This is not true FDX but is very close in principle.

Sorry about the bridging. We chose a new method since this was all new. It gave us a chance to break with the past but the all bridged did not cut it for most people.

We have had more trouble with bridging than any other "feature". That does not mean our bridging was bad, but rather people just throw things together and expect it to work, and if it doesn't, it must be the fault of the software. I guess when you get right down to it those people would have a hard time doing routed as well.

It is time for a network concepts and design thread. I'll get some drawings going and start a page on our website. I'll work on this over Christmas so don't expect anything right away. We are still very focused on the first release of the v3 for WAR.

[VerilanES]

static routing worked great. Still not seeing 40mb/s, but there's definitly more enviromental factors to clear up.

[VerilanES]

....i've started a new thread with a description of the setup. Using a VDS would have been simpler, but if it was anything like the WRAP boards, it would create a lot of processor overhead that would impact throughput.

[MrSmith]

Will v3 bridging be "true" bridging, or will it still be proxy-ARP (like in v2)?

[lonnie]

It will be true bridging, which means you cannot have a standard client bridged. It will have to be to one of our units that handles the AP/Client linkage, using a modified WDS mechanism.

[titan_wireless]

It will be true bridging, which means you cannot have a standard client bridged. It will have to be to one of our units that handles the AP/Client linkage, using a modified WDS mechanism.

Lonnie,

Can you explain this a little more? When you say "cannot have a standard client bridge", what does that mean?

If we used a WAR board for an AP, would we have to use a V3 or Vx client device only? Please clerify, as thats the way I read it.

Thanks

[tog]

That's nice that you've got a modified WDS thing going on so we can do a true bridge and DHCP will work and everything for any router/PC behind a v3 client to a StarOS v3 AP. Slick! Although your v2 proxy-ARP client isn't bad, it's a great functional workaround for the 802.11 limitation.

Now, at the same time that the StarOS v3 AP is taking on these "WDS" StarOS v3 clients, I assume it will also be able to handle all the normal standard non-WDS 802.11g clients such as StarOS v2 "proxy-ARP'ing" clients and the like?

The way normal standard WDS has always worked, the AP was able to take on normal clients and at the same time associate to other WDS-speaking devices, so I'm hoping that a v3 AP ended up with that ability. If it didn't, then I will not be able to run my v3 APs in the "modified WDS capable" mode and I will end up needing the "proxy-ARP" for v3 bridged station mode.

Heck, I hope the client/station mode in v3 is still capable of doing the "proxy-ARP" thing just to maintain the capability of being a station/client bridge with standard 802.11a/b/g access points.

[lonnie]

Anything but our client will not be a true transparent bridge. You can use them but you will still have all the issues of pseudo bridges.

Lonnie,

Can you explain this a little more? When you say "cannot have a standard client bridge", what does that mean?

If we used a WAR board for an AP, would we have to use a V3 or Vx client device only? Please clerify, as thats the way I read it.

Thanks

[lonnie]

There will be AP and Client mode for a standard routed network. If you feel the need for bridging, then we add client bridge which is a true bridge.

Client and Client Bridge can be used at the same time.

We are not going to offer proxy arp pseudo bridging. All it does is create trouble. It was only ever meant for one one level but in true fashion people pushed it and tried to use it for everything. I have not been able to get guys to stop using it wrongly so we'll simply do away with it. With a true bridge we have no need for a pseudo bridge.

That's nice that you've got a modified WDS thing going on so we can do a true bridge and DHCP will work and everything for any router/PC behind a v3 client to a StarOS v3 AP. Slick! Although your v2 proxy-ARP client isn't bad, it's a great functional workaround for the 802.11 limitation.

Now, at the same time that the StarOS v3 AP is taking on these "WDS" StarOS v3 clients, I assume it will also be able to handle all the normal standard non-WDS 802.11g clients such as StarOS v2 "proxy-ARP'ing" clients and the like?

The way normal standard WDS has always worked, the AP was able to take on normal clients and at the same time associate to other WDS-speaking devices, so I'm hoping that a v3 AP ended up with that ability. If it didn't, then I will not be able to run my v3 APs in the "modified WDS capable" mode and I will end up needing the "proxy-ARP" for v3 bridged station mode.

Heck, I hope the client/station mode in v3 is still capable of doing the "proxy-ARP" thing just to maintain the capability of being a station/client bridge with standard 802.11a/b/g access points.

[tog]

I just use the v2 proxy-ARP bridge for my end-user StarOS v2 clients connected to an AP, one layer, as intended. We assign all WRAP/StarOS v2 users a static IP (or multiple if needed) and it works absolutely perfectly, but the ability to use DHCP will be fantastic.

If a StarOS v3 access point can support both the v3 WDS-type clients at the same time as standard non-WDS-type clients, then I personally don't have any immediate practical use for the proxy-ARP bridge anymore so I don't care if it's gone.

It DOES disable your ability to use StarOS v3 as an 802.11 client bridge with anything that isn't a StarOS v3 AP, though. But, again, that doesn't concern me personally because I intend to upgrade all my APs to v3 as quickly as possible. I wont have any v3 clients until v3/x86 is released anyway

Does providing a true bridge somehow keep people from doing things incorrectly? What keeps you from using the new WDS-type bridge more than one layer deep all ugly-like?

[lonnie]

With a transparent bridge it does not matter about depth or complexity behind the bridge. Proxy ARP is mashing the packets and remembering the details so it can unmash the return, so as the LAN behind the proxy gets big it falls apart. A true transparent bridge is just like a long cat5 patch cord between two switches.

I hope guys do not take this as an A-OK to use poor design. You should be routing in all but certain situations.

When you want file servers and print servers shared the easy way is to bridge the two segments. When you bridge to avoid having to learn to route and subnet you are in trouble from the very beginning.

It all comes down to what you want exposed to the client, and you never let a client share your backbone. Sure his traffic will be on the backbone but he has a different MAC broadcast segment. He should never hear your equipment doing ARP broadcasts and should never be able to spoof a MAC of one of your backbone devices.

As I said, it is simple, really. You decide what you want to expose to your customer. You can withdraw and deposit money at the bank but you don't just wander around and have unrestricted access to the vault.