Mushroom Networks Documentation

What were the changes in firmware version 1.17 (Interface Groups, Manual Network Routes, VoIP Armor)?

The following features have been upgraded for 1.17 and are discussed in this FAQ:

Interface Groups

  • Components of Interface Groups
  • How to Enable “Capture All”
  • How to Enable “Include HTTP”
  • Load Balancing Weights
  • Random Group
  • Interface Options

 Changes in Manual Network Routes

  • Interface Binding
  • Bridge Alias

 VoIP Armor

 

Interface Groups

An interface group is like a bundled virtual interface which the user controls. The user can define what interfaces (WAN, Cellular, VLL) are to be associated with this virtual interface, what percentage of each interface is to be used. The user can also define what type of traffic would traverse this bundled virtual interface.

Components of Interface Groups 

1. Interface Groups: This block will give the user the functionality to create a group which could then have the filters and the outgoing interfaces associated with it.

2. Interface Group Interfaces: The interface group interfaces consists of all the interfaces the user wants to be associated with the concerned group. For instance the user can add WAN 1 and Cellular WAN 2 to a particular group.

 In the above example only WAN1 and Cellular WAN2 would be used for this group. 

3. Interface Group Filter: The interface group filter will define the traffic which the user needs to pass on the group.

This filter would put all the traffic from 192.168.253.115 on Interface Group 2.

The default settings are as follows. It is best practice to not change this group and add new groups for any customization.

The blank device index indicates all device indexes of device type being selected. A weight of 0.0 for all Interfaces selected indicates an equally distributing system. This would match all the traffic incoming on LAN, and can be used to load balance by changing the weight. 

How to Enable “Capture All” with the Group Interfaces

As we can see here that the weight of 1 for the VLL tunnel would ensure all the traffic goes over the VLL. The other interfaces have a weight of 0, which will act as a failover in case of the VLL going down.

How to Enable “Include HTTP” in 1.17

Upgrading from 1.16.3 with the include HTTP enabled, would create an HTTP aggregation exclusion rule, which is equivalent to all the HTTP traffic going through the VLL.

The fields will be wild carded, to include all the HTTP traffic.

Load Balancing Weights using the Interface Groups

Load balancing weights can be defined as shown above for each interfaces involved in the interface groups interfaces. In this case the weights are 0.7 for WAN1 and 0.3 for WAN2.

Random Group

In this case the Traffic matching the filter is randomly distributed across all interfaces included in the interface group interfaces for that group. This would better be described by a round robin distribution.

NOTE: “Connection” routes have a higher precedence than the Interface Groups, so rules in the “Connection” route will be followed with a higher priority. This can be used to define exceptions to the interface group rules.

Interface Options

The Interface Options tab consists of the flow pinning control. The flow pinning has to be set to false on the server side for the VLL and VoIP armor interfaces. This ensures that the traffic incoming through the VLL on the server side and destined for the web would properly exit the box.

NOTE: This need to be set only on the server side if you have your own mushroom server. In case of subscription to the BBS, this will be handled by Mushroom Networks.

 

Changes in Manual Network Routes

The manual network routes have a re-defined interface, splitting the routes into either “Simple”, “Connection”, or “Advanced” routes. The features give the user added flexibility in identifying the traffic that needs to follow this route.

To add a manual network route, click “Add” next to Manual Network Routes on the “Advanced” tab of the BBNA web interface:

This will bring up the following input screen, which defaults to a “Simple” route:

The simple route as shown above can be specified with Device Type (WAN, LAN, VLL, Bridge, Cellular, Wireless), Device Index, desired Gateway, Destination IP, MTU, and Metric, which defines the priority of this route. The priority is in ascending order, so routes with a higher Metric are given priority over other routes.

For more flexibility in defining the route, switch the Type field from “Simple” to “Connection” and the following input screen will be presented:

The “Connection” route as shown above can be specified with Device Type and Index, Gateway, Source/Destination IP and port, MTU, DSCP, Protocol, Failover Mode, and Priority, with the priority in ascending order (higher value has higher priority).

The Failover Mode is used to configure the failover action in case of primary interface failure. It has 2 modes: “sticky mode” and “available mode”. In case of a primary interface failure, the sticky mode will transfer the traffic onto the secondary interface, and when the primary line comes back up, will transfer the traffic back to the primary interface. With the “available mode”, after the primary interface recovers, the traffic that failed-over earlier will continue to use the failover interface. The newer sessions will be routed over the primary interface as usual.

Interface Binding

Interface binding in 1.17 will be done through Manual network routes. Interface binding to a source IP can be done with a “Connection” manual network route, whereas for a destination a “Simple” manual network route should suffice.

For example: Suppose we want to bind all traffic from system 192.168.254.113 to go over WAN1. This can be done by adding an advanced manual route for the source IP.

To interface bind a destination IP, use a “Simple” route as shown below.

Bridge Alias

The bridge alias would add an additional subnet on the LAN side. This gives the user the flexibility to configure multiple subnets on the LAN side. So any system in the range 192.168.2.0-255 can now be routed to or routed from.

 

VOIP Armor

VOIP Armor tunnel is a specialized bonding tunnel that is designed to optimize VOIP traffic. VOIP Armor requires two sides, the VLL Server side and the VOIP Armor client side. The VLL Server side functionality can be achieved either via the “VOIP Armor Cloud Relay Service” that is provided by Mushroom Networks as a subscription service, or you can install your own VOIP Armor Relay device in your own data center.

The client side functionality of VOIP Armor is available either as an add-on module to Truffle, or is also available as the VOIP Armor Unit. Configuring VOIP Armor consists of 2 steps:

Step 1: Setting up the VOIP Armor tunnel between your client unit and the VOIP Armor Relay side.

If you have subscribed to the VOIP Armor Cloud Relay Service, then your server side of the VOIP Armor tunnel is already setup for you. If you have your own VOIP Armor Relay Unit (or Truffle with VOIP Armor Relay), then you will need to configure the VOIP Armor instance for the server side by clicking “add” button for the “VLL + VOIP Armor instances” section under the “VLL” tab.

Click the “Add” button and then choose “VLL Server” from the drop-down menu for the “Type”. Create a login and password (you will need to use the same login and password on the client side). All other parameters should be left as the default values. Click “Apply” to finalize the Server side configuration.

Similarly, to configure your VOIP Armor client side, on your VOIP Armor Unit (or Truffle with VOIP Armor module), go to the user interface of the unit and click on the “VLL” tab. Click on the “add” button for the “VLL + VOIP Armor instances” section. Choose “VLL Client: VOIP Armor” from the dropdown menu for the “Type”. Create a login and password (you will need to use the same login and password that you created previously). Enter the IP address of the VLL Server that you configured earlier. Click “Apply” to finalize the Client side configuration.

The tunnel should now establish by creating the VOIP Armor tunnel between the client and server side. The graph status will be populated under the “VLL + VOIP Armor instances” showing the “up (x of x)” status of the tunnel.

Step 2: Now that you have established the VOIP Armor tunnel, we can create the firewall rules and the manual route rules to allow VOIP/SIP traffic into the tunnel from outside as well as direct VOIP/SIP traffic generated on the LAN side to the VOIP Armor tunnel. To direct your VOIP/SIP traffic on your LAN to the VOIP Armor tunnel, go to the “ADVANCED” tab and click on to “Add” for “Manual Network Routes”. Choose “Simple Route” as type, “vll” for “Devce Type” and enter the name of the tunnel you created earlier for the “Device Index”.

If you know the destination IP addresses of your VOIP / SIP traffic (usually your SIP trunk provider’s or your hosted IP-PBX provider’s IP address) then you can use those IP addresses as the value for the “Destination” section of the configuration. This will route all traffic with that destination IP through the VOIP Armor tunnel.

If you don’t know the “Destination” IP of the VOIP/SIP traffic, then you can identify your VOIP/SIP traffic via the Source IP address. To create a “Manual Network Route” for this, choose the “Advanced Route” as the type (as seen below).

Similarly, choose “vll” as the “Device Type” and enter the name of your tunnel (same name that you created earlier) into the “Device Index”. Enter the source IP address of the VOIP/SIP traffic (e.g. the IP address of your local PBX or voice gateway in your local LAN) into the “Source” section and click “Apply”.

As a final step, you will need to make sure the VOIP/SIP traffic coming inbound to the server side will go through the VOIP Armor tunnel. To do this, you will need to add a “Manual Network Route” at the Server side. Please note that if you have subscribed to the VOIP Armor Cloud Relay service, a Mushroom Networks team member will set this for you for the Cloud instance. If you do have the VOIP Armor Relay unit at the server side location, then click “add” for a “Manual Network Route”:

Choose “Simple Route” as the “Type”, “vll” as the “Device Type” and enter the tunnel name (the same name you created earlier) into the “Device Index” field. Finally, enter the local LAN IP of your phone/PBX/Voice-Gateway that the inbound VOIP/SIP traffic will go to, and click “Apply”.

Your VOIP Armor tunnel setup and the related Manual Routing rules are now all set.

 

© 2004 – 2024 Mushroom Networks Inc. All rights reserved.

Let’s chat. Call us at +1 (858) 452-1031 or fill the form: