We are pleased to announce that Router Firmware 8.6.0 RC 2 is now available.
Whoop whoop!!! @James_Webster3945 Look!
Is there any way to see if a fix from a ticket made it in? #26050265 I was told they would try to add it to the next RC but I don’t see anything related in the notes. Thanks.
We have checked and confirmed that the fix has been included in 8.6.0 RC2 (Reference ID: 36812).
We also reviewed the release notes and found that the reference to this issue was inadvertently omitted. I have communicated this to the team, and they will add the record back to the release notes.
Thank you for bringing this to our attention.
Just curious: how does this one differ from the functionality already included in previous GA firmware versions?
These two features serve different purposes.
One feature is used to stop advertising the route , meaning the route will not be announced to other peers or devices. However, it does not actively block traffic if an alternative route is available.
The other feature is used to block the traffic itself , preventing traffic from passing through regardless of whether a route exists.
You can refer to the descriptions in the screenshot below for more details on the behavior of each feature. :
SpeedFusion VPN Route Isolation (SpeedFusion VPN routes will not be forwarded to other SpeedFusion VPN peers)
Layer 3 Isolation (Block layer 3 network traffic between SpeedFusion VPN peers)
Exciting release
. Can someone clarify this item? I can imagine a few things it could mean but to be sure, what does it do exactly and what kind of scenarios is it meant to cover. Maybe a use case could help understand better? Thank you.
This is a sneaky little NAT you can place in between a specific VLAN and (now) other VLANs, so that devices outside can talk to a virtual address than maps into the actual address of devices in that subnet. Often systems like PLCs, IP Cameras, IP Phones or other devices are either set to a static IP or have the same subnet in every location. You can now integrate those without having to re-address the LAN devices. Previous firmware could advertise these virtual networks through SpeedFusion, but not to other local VLANs.
Thank you @Travis. So that is getting interesting. There is a scenario I was hoping to address someday, and I am wondering if that feature could solve this.
I have a set of printers living in a dedicated VLAN. Today I have to turn on interVLAN routing and add many internal firewall rules to restrict traffic in and out of other VLANS to only allow a device on another VLAN to talk to a specific printer in that printer VLAN (each VLAN for devices can talk to a single printer).
With the Virtual Network Mapping feature you mention, could I now map a proxy IP for a given printer (e.g.: 192.168.400.24) in the corresponding VLAN for that printer (e.g: 192.168.400.24 ↔ 192.168.502.24)? That way devices in 192.168.502.0/24 could talk to 192.168.400.24 through 192.168.502.24 without enabling intervlan routing and firewall rules? If so that would be really awesome. Did I understand well?
Exactly! @MartinLangmaid has a great video that covers it when it was originally launched for use on SpeedFusion, but the concepts are the same with the newly added added VLAN support.
Thanks @Travis. Exciting! We will have to experiment with that. From the video and the 8.5.4 current interface, this might not be exactly what we needed but I have to see with 8.6.0.
If 8.6.0 has the same interface than 8.5.4 (just missing the advertisement to other local VLANs), then it seems I could map the whole Printer VLAN subnet into one single device VLAN, allowing the devices in that VLAN to see all the printers (instead of just one). And the other device VLANs could not get the same mapping (since you can only map a subnet once). So that would not work.
Alternatively I could use Many To One mappings to map the device VLANS to single IPs inside the Printer VLAN, allowing the devices to talk through that IP to the printers, but then the devices could talk to all the printers, not just the one that is assigned to their VLAN. So that would not work either.
Really what we need is the mapping of single IPs from the printer VLAN into particular device VLANs. But keeping my finger crossed for when I look at 8.6.0, we might get a good surprise
.
In any cases, I think this added feature will be very useful and simplify many scenarios albeit may be not ours!




