Network Gateway Devices Vyatta

The Network Gateway device provide performance, ease of configuration, and the maintenance advantages of running on normal server hardware. The hardware is sized to handle the routing load for multiple VLANs and can be ordered with RAID arrays to provide redundancy to the disk subsystem. For an overview of the benefits and functionality of Network Gateway devices please see the article at

As the administrator of your Network Gateway, you are able to configure the gateway to enable the kind of connectivity you want for the VLANs which you elect to route through the Network Gateway. Some of the more prominent options include:

  • Firewall a VLAN.
  • Remove firewall protection from a VLAN.
  • Use NAT on a VLAN.
  • Configure IPSec tunnels and routing between them.
  • Shape traffic on a VLAN.


  • Configuration mode: Invoked with the use of the "configure" command, configuration mode is where configuration of the vRouter system is performed.
  • Operational mode: The initial mode upon logging into a vRouter system where "show" commands can be run to query information on the running state of the system. The system can also be restarted from here.


The vRouter system is configured using either the web GUI or a remote console session through SSH or telnet. Telnet is not an encrypted protocol and is not secure so this guide will focus on the remote console option SSH. Configuring the vRouter outside of the vRouter shell and interface may produce unexpected results.

Accessing the device

To initially access the Brocade vRtouer an SSH client will be necessary. Most Unix-based operating systems such as Linux, BSD, and Mac OSX will generally have OpenSSH clients included with their default installations. Windows users will need to download an SSH client such as PuTTy for use with the system.

Within the customer portal, you will find the IP addresses, login username, and password for the device. You will need to use the Vyatta account to login via SSH, as root access is disabled for SSH logins by default:
ssh vyatta@[IP address]

Once you've logged in, the SSH client will be connected to the system via the vRouter shell. Please note that connections to private IPs will generally require connecting either from another machine you have with us or by connecting to our backend management VPN. Rather than editing the SSH configuration file, vRouter installations can use the following command to enable root access via SSH:
set service ssh allow-root

Command exploration

The vRouter command shell includes tab completion capabilities. If you are curious about what commands are available, press the tab key for a list showing the possible commands and a short explanation of them. This works at the shell prompt and within the middle of typing a command. For instance:
$show log dns [Press tab]
Possible completions:
dynamic Show log for Dynamic DNS
forwarding Show log for DNS Forwarding

Operational mode/Configuration mode

The vRouter's shell is a modal interface, with several modes of operation. The primary/default mode is "Operational", and this will be the mode presented upon login. In operational mode you can view information and issue commands which impact the current run of the system such as setting the date/time and rebooting the device.

The command "configure" will place the user into configuration mode where edits to the configuration can be performed. It is important to understand that configuration changes do not take place immediately; they must be committed and saved. As commands are entered they go into a configuration buffer. Once all the necessary commands are entered the user has to run the "commit" command to make those changes live.

To save commands permanently in the configuration file it is necessary to do "save" after "commit".

Operational mode commands can be run from configuration mode by starting the command with the word run. An example:
# run show configuration commands | grep name-server
set system name-server ''
set system name-server ''

The hash mark (#) indicates configuration mode. Beginning a command with the word "run" indicates to the vRouter shell that an operational command is being presented. This example also shows the feature of being able to "grep" against the output of commands.

Sample Configuration

The configuration is laid out in a hierarchical pattern of nodes. Consider this static route block:

protocols {
     static {
         route {
             next-hop {
         route {
             next-hop {

This would be generated by the commands:
set protocols static route next-hop
set protocols static route next-hop

This example illustrates that it is possible for a node (static) to have multiple child nodes. To remove the route for the command delete protocols static route would be used. If was left off the command then both of the route nodes would be marked for deletion. Remember, the configuration is not actually changed until the "commit" command is issued. To compare the current running configuration to any changes that are present in the configuration butter, the "compare" command may be used. To flush the configuration buffer use the "discard" command.


User accounts can be configured with two levels of access: admin and operator. Operator level users are able to run show commands to view the running status of the system and issue reset commands to restart services on the device. Operator level permissions do not imply read-only access. Admin level users have full access to all configurations and operations for the device. Admin users can view running configurations, change configuration settings for the device, reboot the device, and shutdown on the device.

The users can be configured for password, public key or both authentication styles. Public key authentication is used with SSH and allows the user to login using a key file on their system. To create an operator user with a password:
set system login user [account] authentication plaintext-password [password]
set system login user [account] level operator
Note: Without the level specified a user is considered admin. The password (though entered in the clear) will display as encrypted in the configuration file.


The vRouter device is able to route multiple VLANs over the same network interface (bond1 or eth1). This is accomplished by setting the switch port into trunk mode and configuring virtual interfaces (VIFs) on the device. For example:
set interfaces bonding bond0 vif 1432 address
set interfaces bonding bond0 vif 1693 address

The two commands above create two virtual interfaces on the bond0 interface. The interface bond0.1432 would process traffic for VLAN 1432 while the interface bond0.1693 would process traffic for VLAN 1693.


The Network Gateway has the ability to process firewall rules on the device to protect the VLANs routed through the device. The firewall in vRouter is broken into: defining one or more sets of rules and applying a set of rules to an interface or zone.

It is important to test firewall rules after creation to ensure the rules work as intend. It is also important verify that new rules do not restrict administrative access to the device. While manipulating rules on the eth1 interface it is advisable to connect to the device via eth0. Connecting to the console via the IPMI KVM is also an option.

Firewall groups

Firewall groups are collections of IPs, networks (subnets) or ports which can be referenced in multiple firewall rules. An example of a network group is:
set firewall group network-group RFC1918 description 'Not publically routable networks'
set firewall group network-group RFC1918 network ''
set firewall group network-group RFC1918 network ''
set firewall group network-group RFC1918 network ''

This group defines 3 subnets (,, and can be referenced in later rules by the name "RFC1918". For a list of useful network-group definitions for datacenter services networks please visit SoftLayer Network Addresses.

Firewall rule sets

Firewall rules are grouped together into named sets of rules to make applying the same rules to multiple interfaces easier. Each rule set has a default action associated with it. Consider the default action as a rule at the end of the set which will accept or drop any traffic which was not otherwise resolved by the prior rules in the set. Consider the following example:
set firewall name ALLOW_LEGACY default-action accept
set firewall name ALLOW_LEGACY rule 1 action drop
set firewall name ALLOW_LEGACY rule 1 source group network-group RFC1918
set firewall name ALLOW_LEGACY rule 2 action drop
set firewall name ALLOW_LEGACY rule 2 destination port telnet
set firewall name ALLOW_LEGACY rule 2 log enable
set firewall name ALLOW_LEGACY rule 2 protocol tcp
set firewall name ALLOW_LEGACY rule 2 source group network-group !LEGACYNETS

In the ruleset, ALLOW_LEGACY, there are two rules defined. The first rule drops any traffic sourced from a network-group named RFC1918. The second rule drops (discards) and logs any traffic destined for the telnet port (tcp/23) expect for traffic from the network-group LEGACYNETS (the escalation mark before LEGACYNETS indicates negation). The default-action indicates that anything else is accepted.

Allowing datacenter access

We have several IP subnets which are used to provide services and support to systems running within the datacenter. For example, DNS resolver services are running on and Other subnets are used during the provisioning and support. You can find the IP ranges used in the datacenters at the following location: SoftLayer Network Addresses

Allowing access is accomplished by placing the proper network-group statements at the beginning of the firewall rule sets with an action of accept. Where precisely the rule set has to be applied will depend on the routing and firewall design being implementing.

It is a recommended practice to place the firewall rules in the location which causes the least duplication of work. For example, allowing backend subnets inbound on bond0 would be less work than allowing backend subnets outbound toward each VLAN virtual interface.

Firewall logging

If you enable logging on firewall rules you can view that log using the command:
show log firewall name [RULESET NAME]

More general information can be found using the command:
show firewall name [RULESET NAME]

The second command above will show the zones and interfaces to which the rule set is bound and the packet/byte counters for the rules in the ruleset.

Per-interface firewall rules

One method for configuration the firewall on a vRouter is to apply firewall rule sets to each interface. In this case an interface can be a physical interface (eth0) or a virtual interface (eth0.303). Each interface has three possible firewall assignments:

IN The firewall is checked against packets which, as they pass through the system, are entering via the interface.
OUT The firewall is checked against packets which, as they pass through the system, are leaving via the interface.
LOCAL The firewall is checked against packets which are destined directly for the vRouter.

An interface can have only one rule set applied to an assignment possibility. Each assignment can have a different rule set applied to it. Note that it is not possible to firewall traffic sourcing from the vRouter device itself using per-interface firewalls.

To assign the ALLOW_LEGACY rule set to the LOCAL option for the eth1 interface you would use the configuration command:
set interfaces ethernet eth1 firewall local name 'ALLOW_LEGACY'

To view the runs and counters associated with them, use the operational mode command:
show firewall name ALLOW_LEGACY

The output is:

Rulesets Information
IPv4 Firewall "ALLOW_LEGACY":

Active on (eth1,LOCAL)
rule  action   proto     packets  bytes
----  ------   -----     -------  -----
1     drop     all       0        0
  condition - saddr daddr match-set RFC1918 src
2     drop     tcp       16       840
  condition - saddr daddr ! match-SRC-NTWRK-GROUP LEGACYNETS tcp dpt:23LOG enabled
10000 accept   all       1014     270607
  condition - saddr daddr

The highlight shows the interface and type of the firewall rule set assignment. The same rule set could be active on multiple interfaces.

Zone firewalling

Another firewall concept in the Brocade vRotuer is zone based firewalls. In zone-based firewall operation an interface is assigned to a zone (only one zone per interface) and firewall rule sets are assigned to the boundaries between zones with the idea that all interfaces within a zone have the same security level and are allowed to route freely. Traffic is only scrutinized when it is passing from one zone into another. Zones drop any traffic coming into them which is not explicitly allowed.

An interface can either belong to a zone or have a per-interface firewall configuration; an interface cannot do both. Imagine the following office scenario with 3 departments, each department with it's own VLAN:
Department A - VLANs 10 and 20 (interface eth1.10 and eth1.20)
Department B - VLANs 30 and 40 (interface eth1.30 and eth1.40)
Department C - VLAN 50 (interface eth1.50)

A zone can be created for each department and the interfaces for that department can be added to the zone.

set zone-policy zone DEPARTMENTA interface 'eth1.10'
set zone-policy zone DEPARTMENTA interface 'eth1.20'
set zone-policy zone DEPARTMENTB interface 'eth1.30'
set zone-policy zone DEPARTMENTB interface 'eth1.40'
set zone-policy zone DEPARTMENTC interface 'eth1.50'

The "commit" command will populate each zones an interface and the default drop rules will discard any traffic trying to enter the zone from the outside the zone. In the example, VLAN 10 and 20 can pass traffic since they are in the same zone (DEPARTMENTA) but VLAN 10 and VLAN 30 cannot pass traffic because VLAN 30 is in a different zone (DEPARTMENTB).

The interfaces within each zone are able to pass traffic freely and rules can be defined for interaction between the zones. A rule set is configured from the point of view of entering the zone from another zone. An example of the command to configure a rule is:
set zone-policy zone DEPARTMENTB from DEPARTMENTC firewall name ALLOW_PING

The command above associates the transition DEPARTMENTC -> DEPARTMENTB with the rule set named ALLOW_PING. Traffic entering the DEPARTMENTB zone from the DEPARTMENTC zone would be checked against this rule set. It is important to understand that this assignment from zone DEPARTMENTC going into zone DEPARTMENTB does not make any statement about the inverse. If there are no rules allowing traffic from zone DEPARTMENTB into zone DEPARTMENTC then traffic (ICMP replies) will not get back to the hosts in DEPARTMENTC.

Local Zone

The vRouter device can be configured into a local zone. When this is done traffic directly to the vRouter device can be limited (as the traffic would be entering the local zone). For example:
set zone-policy zone VYATTALOCAL local-zone

The command above creates a zone called VYATTALOCAL and marks it as a local-zone. Rule sets can be applied to the zone boundary like any other zone in order to lock down access to the device. Be mindful of connectivity to the device when working with a local zone. The local zone entry will lock out access to the device. A mistake in this configuration will generally require work with the KVM console or possibly rebooting the device.


The configuration commands need to be backed up when there is a change to the system. This can be accomplished by running the operational mode command show configuration commands and then saving the output (for example by copying/pasting from the SSH session). This would be considered a minimum backup for the configuration.

A more complete backup would be to generate a tech support archive for the system:
$ generate tech-support archive
Saving the archivals...
Saved tech-support archival at /opt/vyatta/etc/config/support/

The generated archive file can then be copied from the vRouter device to storage of your choice. The archive contains backups of the configuration information, home directories and logging information. It is a much more complete backup of a system.

-rw-r--r--  1 michael  michael    7863 Aug 22 12:46 config.tgz
-rw-r--r--  1 michael  michael     112 Aug 22 12:46 core-dump.tgz
-rw-r--r--  1 michael  michael  716033 Aug 22 12:46 etc.tgz
-rw-r--r--  1 michael  michael    3698 Aug 22 12:46 home.tgz
-rw-r--r--  1 michael  michael    1092 Aug 22 12:46 root.tgz
-rw-r--r--  1 michael  michael    4204 Aug 22 12:46 tmp.tgz
-rw-r--r--  1 michael  michael   82976 Aug 22 12:46 var-log.tgz

Any notes that you create while configuring the device would also be good information to backup in a central location accessible to all of your administration staff.

Solutions to Common Questions

Lost password

If there is access to the system, set a new password:
set system login user [account] authentication plaintext-password [password]
If there is not access to the system, reboot the device and there is a password recovery option on the GRUB menu for resetting the root user password.

Firewall lock out

The "reboot at [time]" construct can be useful when testing potentially dangerous firewall rules. If the rule works then use the command "reboot cancel" to cancel the reboot; if the rule locks out access simply wait for the scheduled reboot to occur.

If there is no access to the system, then a reboot may be used to recover access. Upon rebooting, the system will read the configuration file which would be unchanged by previous entries that were discarded by the reboot.

If there is access via KVM the following action maybe performed to recover access:

  1. Disable the offending rule by
    1. set firewall name [firewall name] rule [rule number] disable
    2. commit
  2. Unhook the entire named rule set from the necessary interface. Be VERY CAREFUL with this command; incorrect use will wipe out your interface configuration.
    1. delete interfaces ethernet [interface] firewall [type] name [firewall name]
    2. commit