We have many new customers around the world connecting ePMP networks to perform more than residential access. We have deployments for video surveillance, shipyard connectivity, remote monitoring, and more. The next Ask the Experts session will provide time for you to ask about how to optimize a network for a specific application and share field experiences with other users.
Participating is easy. Just login and join this thread at any or all of the following times on Wednesday, April 29th:
8 – 9 AM CDT
1 – 2 PM CDT
9 – 10 PM CDT
Pass this information to your colleagues. If you are not yet a member of the Cambium Community, join at http://community.cambiumnetworks.com/ by using the link in the top right corner.
We look forward to the discussion and meeting with you. Add the sessions to your outlook calendar by clicking on the attachments below:
From what I gather the ePMP will not forward unknown unicast packets (DLF), at least not in the downstream direction. Because of this, if the MAC address of a device behind a SM (i.e. a camera) expires or is cleared do to a STP TC, it will be inaccessible until that device generates a packet (thus re-populating the SM's MAC address table) or until the ARP table is cleared on the upstream router, thus forcing an ARP broadcast, to which the client device will respond.
Under most circumstances not forwarding unknown unicast is going to be a good thing to help keep chatter down on the wireless network. However, in these cases where we have some kind of device/server/camera connected to a SM it can render the device inaccessible. Is there a way to prevent this from happening or do I have to either; set an artificially low ARP timeout on my L3 device, or setup some kind of job on my cameras/devices that periodically send traffic out (ex a cron job that pings the default gateway every minute)?
On a serious note, its one of several new radios we're working on. I'm sure you'll hear more about it in the coming months or the next time you stop by our office.
From what I gather the ePMP will not forward unknown unicast packets (DLF), at least not in the downstream direction. Because of this, if the MAC address of a device behind a SM (i.e. a camera) expires or is cleared do to a STP TC, it will be inaccessible until that device generates a packet (thus re-populating the SM's MAC address table) or until the ARP table is cleared on the upstream router, thus forcing an ARP broadcast, to which the client device will respond.
Under most circumstances not forwarding unknown unicast is going to be a good thing to help keep chatter down on the wireless network. However, in these cases where we have some kind of device/server/camera connected to a SM it can render the device inaccessible. Is there a way to prevent this from happening or do I have to either; set an artificially low ARP timeout on my L3 device, or setup some kind of job on my cameras/devices that periodically send traffic out (ex a cron job that pings the default gateway every minute)?
Thanks!
If the camera is connected to the SM, it will be upstream data, won't it? In this case, the camera is constantly sending data (video), the ARP cache should not get expire.
I think the issue is that the ePMP crew are doing too good a job, there’s nothing to complain about (other than waiting for .AC). Thank you ladies and gentlemen.
@CStanners wrote: What is the current distance limit - assuming infinite-gain antennas - on ePMP, for the different channel widths?
Hi,
In TDD mode, whether its PMP or PTP deployment, the max distance of the farthest SM is 40 miles (64 km). Although, we have had customers deploy links at 136 km! It works and they are happy but we cannot guarantee performance, at this time, beyond 64 km.
Hi. This is probably something I can learn by reading a manual... BUT since it's ''ask'' day, I'll ask. :)
What is the Bandwidth Control methods in the ePMP? With our current radios, they have CBQ in them, so we can set a maximum throughput on the Ethernet port, and the client is capped at that rate. Or, we can set a client to be able to get 5 Mbit throughput, and to fall-back to 2.5 Mbit after a certain time.
So what method of bandwidth control is in the ePMP?
ePMP provides MIR (Maximum Information Rate) functionality. This limits both DL and UL throughput.
MIR can be configured with either the local GUI or using RADIUS. If GUI provisioing is used, then generic MIR profiles are set up at the AP and individual SMs can select the profile to be used. If RADIUS provisioning is used, then the AP is told by the RADIUS server the exact MIR DL and UL rates to use. Actual MIR rates in use for all SMs are shown at the AP under Monitor -> Wireless.
Got it. However, most switches/bridges, by default, do forward unknown unicast packets to all ports (besides, of course, the port it was received on). In situations where applications/servers are being hosted in the wireless network this may be the desired/required behavior. It's not critical for us because we've lowered the ARP timeouts on our camera and management networks to 30 seconds. So, worst case we're unable to access downstream devices for only a short period of time. The downside of this is of course a lot more ARP table churn and activity.
Most switches allow you to enable/disable DLF (destination lookup failure) and/or have options for unicast storm control, something you already have for broadcast traffic.
The camera in this siuation (from a TCP standpoint) is the server. The data is being pulled from it. If the TCP session is closed (for any number of reasons) and the situation which I presented expresses itself (bridge table entry is cleared or expired), the camera will be inaccessible until the ARP entry on the router is expired.
