Force 425 firmware 5.3 causing VPLS tunnel flapping

Products ePMP
21

Hi adrii this problem, is on all firmare version after 5.1.3 , in a network , where epmp force 400 is linked to switch mikrotik or router mikrotik sfp, every vpls packet that surf by 400 , drop, work only with 5.1.3

22

hi,

try this

telnet to your device

F425_pe2>config set cambiumAccelerationEngine 3
F425_pe2>config commit
F425_pe2>reboot

it solves a similar problem for me.

4 Likes
23

Yes, this work for me too
Thanks a lot

1 Like
24

we are experiencing the same. No problem on 5.1.3 (maybe not even 5.1.4). Above that vpls/mpls does not work properly

25

try what was suggested by @maigao12 it seems to have helped on one of my links that is having this issue but I’m not sure it has completely solved the problem yet.

1 Like
26

Hello, good morning everyone, I am presenting the same problem with the VPLS tunnels with some PTP Force 4625, it worked with the brand with force 300 and without any problem with the MPLS network, it works great, the problem came when I bought 10 pairs of Force 4625 for my MPLS network, they do not raise the VPLS tunnels, the MPLS looks very unstable, it is as if it were an MTU problem, checking with SSH on the devices I increased the MTU on the radio link and also that of the ports ethernet and the problem was not resolved, I am already seriously thinking about returning these 20 devices to my supplier in Mexico (Syscom).

And that’s why I came here looking for information if it is a configuration problem for the device itself.

Has anyone already managed to solve the problem?

27

With this patch it only raises the VPLS tunnel but it does not see anything at layer 2 from end to end, as mentioned above, it is as if it were an MTU problem within the Wireless link, not the Ethernet ports.

28

Hello @amingar,

the issue initially reported by Jacub is not exactly about MPLS. I can reproduce it on 80MHz channel. The root cause is OSPF session flapping. It goes down when the link reaches its maximum capacity. We are working on improvement.
We have re-tested MPLS forwarding in 5.7.0 and it works as expected.

May I ask you to Raise Ticket in the top right of this page?
Attach techsupport files from AP and SM when it does not work and PM me the ticket number.
I will try to sort it!

1 Like
29

Hello.
Any news on this problem???
Still exists on 5.8.0 firmware.

30

Hello @KONSTANTINOS_TSOUMAN,

could you raise a ticket, attach your techsupport files and PM me its number?
I would like to have a remote session to debug it.
In my tests the root cause is OSPF session flapping when traffic load reaches it’s maximum.
I analyzed OSPF Hello packet flow. They all get delivered. Unforunatly Hello packet has no sequence number so we can not track if they come out of order. Routing protocols are prioritized in our driver and should not be lost.
If your situation is different I want to see it.

31

Hello
I swaped the links with the 4625s
and the problem still exists with these too!!!
I also tried with the 5.9 firmware but it did not work either.
I am desperade!!!

32

Hello @KONSTANTINOS_TSOUMAN,

please read my previous comment!

33

For what it is worth - none of the VPLS problems I’ve had with these radios were on busy links. In fact, most of them were idle or very low utilization backup links. What has stabilized them for me is the following:

config set cambiumAccelerationEngine 3
config commit
reboot

It would be very helpful to know what the various cambiumAccelerationEngine flags do from a settings standpoint.

34

Hello @Jacob_Turner,

"Acceleration engine mode:
		 1 - Automatic selection. In this mode, ECM will detect board type
			to see if NSS acceleration engine is supported. If yes,
			NSS front end will be selected to run. Otherwise SFE front end
			will be selected to run,
		 2 - NSS front end (HW acceleration),
		 3 - SFE front end (SW acceleration)"

The NSS (Network Soft Switch) is a dedicated chip on the PCB designed to offload network processing from the main OS, improving performance and reducing system load. It operates as follows:

  1. When a packet arrives at the radio’s interface, it is passed to the OS, where the forwarding decision is initially made.
  2. A hash is generated based on the source and destination MAC addresses, as well as the IP addresses.
  3. This forwarding decision is then handed off to the NSS.
  4. For subsequent packets with the same hash, the NSS handles them directly, bypassing the OS entirely for faster processing.
4 Likes
35

Thank you @aka !

extra characters here to make the post go through.

36

Which device support NSS?

37

@aka which devices support NSS?

1 Like
38

Thank you, Jacob, This trick solves continued issues we’ve been experiencing.

Even TCP seems broken when the hardware accelerated engine is enabled (default behavior) on 400C links with MTU > 1500. Setting cambiumAccelerationEngine to 3 solves it immediately and allows VPLS, VXLAN, and other traffic with MTU > 1500 to pass correctly for us.

@aka It would be appreciated if cambium could warn users about this, or to just default these units to ```SFE front end (SW acceleration)" until cambium can resolve this outstanding problem. Troubleshooting this is very tedious. If ISP operators have to SSH into these radios to toggle a setting just to be able to use MTU above 1500, that should be disclosed. Thanks.

4 Likes
39

Hello!

It is time to update this thread! We have a bunch of improvements related to such symptoms in upcoming release 5.10. A beta should be published in the nearest future.
I will really appreciate if you can try ePMP R5.10-RC29 and let me know your feedback. This build should be used with caution in production environment.

40

@aka are there any release notes or similar yet for this trial firmware? Thanks!