What's this new ePMP FCC ID?
@dkeltgen wrote:
Easy one this time: How do I enable/disable user accounts (installer, home, readonly) via CNS, SNMP, or CLI?
Hi,
We don't provide this option through CLI, SNMP or CNS at this time. We can look into adding this.
Thanks,
Sriram
@Mike Hammett wrote:
What's this new ePMP FCC ID?
I don't know what you're talking about Mike :)
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.
Thanks,
Sriram
1 Like
@dkeltgen wrote:
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.
Hi dkeltgen,
Our AP and SM in bridge mode function like a regular bridge and populate the bridging table as you indicated. There is not a way to alter this.
Dan
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.
2 Likes
What is the current distance limit - assuming infinite-gain antennas - on ePMP, for the different channel widths?
@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.
For ePTP mode the ranges are as follows:
20 MHz: 32 miles (52 km)
40 MHz: 15 miles (24 km)
Thanks,
Sriram
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?
Hi Ninedd,
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.
Dan
Ok, thank you. So this is just straight/simple Maximum Rate then... no quota, no fall back, no temporary bursts, or anything like that?
Dan,
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.
Thanks,
Dan
The ePMP developers will join us in a few minutes. You can post your questions here now.
Sriram,
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.
Thanks,
Dan
@ninedd wrote:
Ok, thank you. So this is just straight/simple Maximum Rate then... no quota, no fall back, no temporary bursts, or anything like that?
That's correct.
@Cambium_RayS wrote:The ePMP developers will join us in a few minutes. You can post your questions here now.
Holy smokes, long day for the dev team!
Oh, I've got a question. Is there a direct link/url that will show the ealign screen (which is awesome by the way) without authentication? Something like http://[ip_address_of_radio]/ealign
Thanks,
Dan
@dkeltgen wrote:
Sriram,
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.
Thanks,
Dan
I see. As Dan Sullivan said earlier, the ePMP link performs as a simple bridge and there is no way to alter this. Your suggestion of having a short Aging time out the L3 router or cron job may be the way to go.
@dkeltgen wrote:
@Cambium_RayS wrote:
The ePMP developers will join us in a few minutes. You can post your questions here now.
Holy smokes, long day for the dev team!
Oh, I've got a question. Is there a direct link/url that will show the ealign screen (which is awesome by the way) without authentication? Something like http://[ip_address_of_radio]/ealign
Thanks,
Dan
Not at this time.
When will ePTP be supported in unii-2/dfs bands? :p
@dkeltgen wrote:
When will ePTP be supported in unii-2/dfs bands? :p
This is something we're actively working on. The hope is to have it ready in Release 2.4.3.