Hi Peter,

 

Yes, the maximum number of MAC address supported by airBridge is about 64 only.

How many PCs are connected behind the <remote-aib>?

 

If you have the following setup with the firmware (0.01.07 & 0.01.04) loaded on the <local-aib>, the client PCs will not be able to pass the traffic to the internet. This is because of the <local-aib> does the MAC translation which causing this design unsuitable for the routing. It can only work between site to site connectivity.

 

<internet>---<isp network/router>---<switch>---<local-aib>---<remote-aib>---<PC>

 

To workaround this issue, you can downgrade the <local-aib> to the older firmware 0.09.10 and this will become transparent bridge with single MAC support. The <local-aib> directly connected directly to the router so it can see only the ROUTER as a single client.

 

In between <local-aib> and ISP router, is there any clients connected? If any device connected in between means, the old firmware will not support and does support only single MAC.

 

To downgrade to 0.09.10, install the simpleMonitor 1.43 and automatically it will prompt for the firmware upgrade.

http://www.smartbridges.com/new/support/ab.php

 

Alternatively, you can change it to the aPPO-CB combination and this will provide you with transparent bridging and multi MAC support.

 

Seeni

sB Tech Support

[EMAIL PROTECTED]

 

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Sanchez
Sent: Wednesday, October 08, 2003 5:56 AM
To: [EMAIL PROTECTED]
Subject: [smartBridges] 64 Client limitation

 

We are having strange issues.. Here is a rundown of the layout:

 

<internet>---<isp network/router>---<switch>---<local-aib>---<remote-aib>---<PC>

 

The network being used for the wireless link is as follows:

 

64.42.139.48/29

 

ISP Wireless Router - .49

Local AIB - .50

Remote AIB - .51

Remote PC - .52

 

ISP Router is just a gateway router for multiple 802.11b links we have.

Its on a much larger network local to the ISP (us). The link above is

our first and only link using AIB's. We are having issues where

machines/devices on the ISP Network side are having trouble pinging the

Remote PC while other machines/devices on the SAME SUBNET (local ISP

Network) as the machines/devices having trouble are not.

 

For instance,

 

Plato (our shell server), is 64.42.128.47/27

NS (our name server), is 64.42.128.50/27

 

They are in the same subnet, off the same router interface and switch.

Plato can ping Remote PC but NS can NOT.

 

If we reboot the Local AIB the issue goes away, but the next morning (or

a few hours later), the issue is back. My first guess is the routing. I

triple checked everything I can think of. I am very confident the

routing is correct because no other wireless customers (fed off the same

ISP Wireless Router) don't have trouble reaching the same destinations

that the AIB link is having trouble with. Also, traceroutes are showing

the correct path, only from the machines having trouble (ie, NS) the

traceroute stops AFTER leaving the ISP Wireless Router, and traceroute

FROM Remote PC never even make it to the ISP Wireless Router. Almost

like the packets are dying between the Local AIB and Remote AIB, yet

from Plato its absolutely fine.

 

My next guess is the 64 client limitation. My question is this... Would

the AIB's hold a "client table" of IP addresses requesting data through

it, say to Remote PC, and use this table as its 64 allowed clients? Keep

in mind most of the "Source IP's" are NOT in the AIB's local subnet (I

doubt that this matters). If so, would this by the cause of the issue I

am experiencing?

 

Thanks for any and all help you may provide.

 

Peter

----------ANNOUNCEMENT----------

Don't forget to register for WISPCON IV

http://www.wispcon.info/us/wispcon-iv/wispcon-iv.htm

 

The PART-15.ORG smartBridges Discussion List

To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname>

To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges)

Archives: http://archives.part-15.org 

Reply via email to