I'm looking for an answer for the following:
Is it possible to use wireless bridges to pass ipx traffic? I'm looking for an answer that consider this:
- I'm using Novell 4.1 which uses 802.2 at the data-link layer. Documentation says nothing about wireless bridges supporting 802.2, only 802.3
Most, if not all, wireless devices are acting as either a hub or a bridge ....
They don't care what layer 3 protocol is in use, they don't even look at it. Some have features that can act on layer three, if invoked, but out-of-the-box, they should pass all Ethernet.
I see you don't get the point: I'm saying that Novell 4.1 does not use 802.3 (that is layer 2!). It uses 802.2. I can't find any docs saying wireless bridges support this "layer 2" protocol (ethernet variant).
A switch, in a normal configuration (i.e., no "features" enabled), will pass all traffic:
IP, IPX, DECNET, SNA ...
Everything. It is the nature of the beast. It does not care what layer three protocol, it also doesn't care about what layer two protocol (other than it's got to some flavor of Ethernet-over-UTP... ANY flavor of Ethernet-over-UTP).
It is essentially the same as using a hub, except with the possible bonus of limiting the collision domain.
An AP, by default, operates as a wireless hub. With no features enabled, it should pass the same Ethernet as wired devices (you still need to manage it using TCP/IP or via the console).
You're not finding anything because there is nothing like that to find.
I see your point about the AP working as a hub, but I'm talking about "wireless bridges".
As you may know, an IP bridge or switch creates an association table, with at least two columns:
MAC ADDRESS -- IP ADDRESS
That it learns as it works. I saw no screenshot sowing a table like:
MAC ADDRESS -- IP/IPX ADDRESS
I can't say: Yes! Lets buy U$D 15000 in equipment because: "it should pass the same Ethernet as wired devices"
See it? I need respaldatory documentation.
You're still a little too high on the OSI stack.
Bridges build a table that is MAC ---> port
The MAC is learned by looking at the source address of frames received on all ports. The source MAC is noted, as well as the port it was "heard" on.
When a frame is received, the MAC is looked up in the table. If the bridge has the MAC in the table, it send the frame out the associated port.
If the MAC isn't found in the table, the bridge will flood the received frame out all active ports.
Good Luck ...
You're right, the table is MAC -- PORT. Anyway, to lear the MAC addresses the wireless bridge should be able to interpret the 802.2 frame, don't it?
Could you utilize routers to perform IP encapsulation of the IPX traffic?
Each router would be located between the LAN segment ant the wireless bridge serving that LAN segment:
LAN --- ROUTER --- WIRELESSBRIDGE . . . RF . . . WIRELESSBRIDGE --- ROUTER --- LAN
I know about this possibility, but the first router supporting IPX is a 1710 router, and 7 more routers to the project adds a lot of money.
However, if I must use them, I've two choices:
- I can use a VPN using GRE encapsultion, but it's too bandwith consuming and I've a better choice:
- I can use IPX 802.2 encapsulation on the LAN side of the routers, and IPX 802.3 encapsulation on the wireless bridge side.
This is an alternative, maybe the one with best performance, but with 7 more routers.
I'm still trying to find some documentation....
There are RFCs addressing the Encapsulation Transform from wireless to wired -- RFC1042 and 802.1H.
Ethernet Encapsulation Transform
Choose 802.1H or RFC1042 to set Ethernet encapsulation type. Data packets that are not 802.2 packets must be reformatted to 802.2 via 802.1H or RFC1042.
802.1H -- This default setting provides optimum performance for Cisco Aironet wireless products.
RFC1042 -- Use this setting to ensure interoperability with non-Cisco Aironet wireless equipment. RFC1042 does not provide the interoperability advantages of 802.1H but is often used by other manufacturers of wireless equipment.