Tag: packet

  • Static ARP Ubiquiti EdgeOS

    There are times when one needs to reach a certain device on the network and cannot as multiple devices have the same IP address. This should in theory not happen but it does in networks where people can freely connect devices themselves. If the device has a static IP address which another device already has, it is nearly impossible to reach it to reconfigure it remotely as packets would end up on the wrong device. This where a static ARP entry can smooth out things forcing the router to only send packets to that single device of one’s choice

    sudo arp -s 192.168.0.1 e4:ea:b4:08:a8:32 -i eth1

    This tells the router that “192.168.0.1” is at MAC “e4:ea:b4:08:a8:32” and will stop it broadcasting ARP requests; it just sends packets directly to that MAC.

    When done simply delete it again:

    sudo arp -d 192.168.0.1 -i eth1


    After that, the router will go back to the normal ARP behaviour of broadcasting ARP requests instead of using the fixed MAC.

    If you run show arp eth1 after deletion, you should see the static entry removed.

  • AF60-LR Ethernet Carrier Drop option missing

    Dealing with rain on a 60 GHz radio link can be tricky. It works flawlessly with high capacity in the Gbit range when the weather is nice. Once raindrops start pouring down the link will degrade to a point where it may drop the connection completely, all depending on precipitation level and radio frequency/channel selection.

    When running OSPF over such a wireless bridge there is no indication that the link has failed until the next “Hello” receives no answer from the neighbouring router and the “Dead Interval” is reached. At this point the link would be brought down by OSPF and assuming there are redundant paths, traffic would be routed through another part of the network to its final destination.

    The problem here is the long time the link is reported as being up by OSPF when it is really down. This means traffic is being sent through this dysfunctional path and getting nowhere for as long as the duration of the OSPF “Hello” plus “Dead Interval” timer. Of course one could decrease this timer to a bare minimum, however in a wireless network there could be some brief interference at times which usually would not last long enough for the user to notice. It also increases load on the routers and albeit minimally, the network itself due to the extra packets.

    What we really need is the same experience for the router as if the network cable was to be pulled out of its port socket. The OSPF process would immediately bring the interface down and the path would no longer exist in the OSPF topology database. Traffic would be routed without delay and any downtime via the redundant path. Here is where Ethernet Carrier Drop comes into the picture. As described by Ubiquiti itself in the info label:

    Carrier drop monitors your link and disables Ethernet interface in case downlink capacity drops below configured threshold.
    Port is disabled, if capacity remains below threshold for Carrier Down delay.
    Once capacity exceeds specified threshold for Carrier Up delay, port will be enabled.

    I needed a link consisting of a pair of Ubiquiti 60 GHz airFiber (AF60-LR) to use Ethernet Carrier Drop when rain faded the signal strength killing the connection. The pair runs in a Master & Station mode so wireless configuration is done in the Master and propagates to the Station. However I could not find the Ethernet Carrier Drop selector anywhere. Looking through all the setting pages revealed nothing, however I knew it was present in the firmware.

    Digging around I found a reference to the feature in the old 2021 2.5.0 firmware change-log:

    - Ethernet Carrier Drop is configured on the Station side of the link. When Station DL capacity drops below configured threshold, Ethernet port will be disabled. Management will be available only via wireless link.

    So there you go, the Ethernet Carrier Drop feature is actually in the Station and not the Master wireless settings page.

    I guess the logic behind it is that usually the Master peer is more centrally located in the network topology and the Station in the remote branch. One cannot access the device while the Ethernet port is disabled, so if done on the Master one could be locked out from doing any further configuration changes. Still, it is a bit curious the feature is not explained anywhere apart from in a four year old firmware change-log.