Add Route Table (Standalone)

What Is Add Route Table?

Add Route Table is the fundamental configuration unit used in order to create isolated network zones on TR7. Every route table defines an independent network zone that has its own interfaces, IP addresses, routing rules and network configuration. This structure works similarly to the VRF (Virtual Routing and Forwarding) concept; at the system level every route table is created as a separate zone that works with its own network stack.

TR7 comes with the DEFAULT route table by default; this table (internal id 1, table number 1) is always present and cannot be deleted. By creating additional route tables, different traffic types, security requirements or customer environments can be isolated from one another. The smallest free table number starting from 2 is assigned to every new table; in the Route table column of the interface list the table is shown in the form number name (e.g. 2 RT_DMZ); in the form selectors only the name is seen.

The fundamental isolation features between the route tables:

Feature	Behavior
Interfaces	Every route table has its own interfaces
IP Addresses	The IP addresses belong to a specific route table; the IP collision check is done inside the table
Routing Rules	Every table takes its own routing decisions independently
Static Routes	Static routes and default gateway definitions specific to the table can be made
DNS	Every table can have its own DNS servers; when they are not defined, the DNS settings of the DEFAULT table are inherited
Dynamic Routing	Every table can run an independent dynamic routing protocol (FRR)

Isolated Zone

VRF-like

An independent network zone that has its own interface, IP and routing rules

Multi-Tenant

Without IP collision

Different tables can use the same IP ranges

Dynamic Routing

BGP · OSPF · …

Every table runs an independent dynamic routing protocol

Segmentation

Security zones

The DMZ, the internal network and the management traffic are separated

For general information about route tables and for the listing screen see the Route Tables page.

Why Is Add Route Table Important?

In modern network architectures traffic isolation, security segmentation and multi-tenant support are critical requirements. Route tables are the fundamental way of meeting these requirements on TR7.

• Traffic Isolation: The traffic in different route tables works completely isolated from one another; the routing decisions in one table do not affect the other tables. In this way the traffic at different security levels is managed safely on the same physical device.
• Multi-Tenant Environments: In the environments that serve more than one customer, by creating a separate route table for every customer, the risk of an IP collision disappears. Different customers can use the same IP ranges, because every route table defines its own network zone.
• Security Segmentation: By using separate route tables for different security zones such as the DMZ, the internal network and the management traffic, the security policies are applied more effectively.
• Dynamic Routing Support: Every route table can run dynamic routing protocols such as BGP and OSPF independently; this provides a flexible routing configuration in complex network topologies.

Best Practices

• Name the route tables according to their purpose of use. Use descriptive names that reflect the purpose of use (e.g. RT_DMZ, RT_INTERNAL, RT_CUSTOMER_A); this makes management easier in large environments.
• Use the DEFAULT table for the management traffic. Keep the DEFAULT route table for device management and for basic connectivity; create separate route tables for the service traffic. In this way management access is always preserved.
• Move the interfaces after creating the table. A new route table is created empty; the interfaces are moved to the table from the Route table field in the Edit Interface form and their IP addresses and routes come together with the interface.
• Provide the communication between the route tables with V-ETH(Peer). When controlled communication between different route tables is required, use V-ETH(Peer) interfaces; these interfaces create a safe connection point between isolated tables.
• Configure dynamic routing carefully. Before enabling the dynamic routing protocols, analyze the network topology and the neighboring devices; a misconfigured dynamic routing may cause network instability. Turning the Dynamic route table option off afterwards deletes the defined daemon settings.
• Keep documentation per route table. Since there is no description field in the form, document the purpose of use, the interfaces it contains and the routing rules separately for every route table; this is of critical importance in troubleshooting and in change management.

How to Add?

The following steps are followed in order to add a new route table on the TR7 device:

1. The Configuration Menu is opened by clicking the TR7 logo at the bottom left.
2. The Network → Interfaces → Actions → Add route table steps are followed; the form opens as a closable tab inside the interface list screen. The same form is also opened with the Add button on the Route Tables listing screen.
3. A unique and descriptive name is entered for the route table.
4. If dynamic routing is required, Dynamic route table is checked and the related daemons are enabled.
5. The route table is created by clicking the Add button.

The adding does not ask for confirmation; the record returns immediately, the table is created in the system in the background and the form tab closes. The route table created is empty and becomes selectable in the interface editing, IP assignment and routing forms.

The operations that are not done in this form

The route table form contains only the name of the table and the dynamic routing settings. The other configurations related to the table are done from separate screens:

• Interface assignment: the Route table field in the Edit Interface form. While an interface is being moved, the IP addresses and the routes on it are moved to the table as well (the "... IP and ... route entries will move to route table '...' together with the interface" warning is listed in the confirmation window). Since the Bond/LACP and bridge members follow the table of their master interfaces, they cannot be moved from the table they are in in any direction; the protected interfaces (the ones that carry a management access IP, that is HTTP/HTTPS/SSH/SNMP, and the cluster synchronization interface) cannot be moved outside DEFAULT.
• The default gateway: the Default gateway option in the Add Static Routing form or the editing icon in the Route Tables list.
• DNS servers: on the Device DNS screen by selecting the related route table; the tables that are not defined inherit the DNS settings of DEFAULT.

The Add Route Table Form

By following the steps above, the route table adding form is opened. There is no Details section in the form; as long as Dynamic route table is not checked, the form consists of two fields.

The Add Route Table Form

INFO

Route Table Name

A unique name is entered for the route table (1–15 characters; required). When it is left empty, the "Required field" warning, for a long name the "Route table name must have 1-15 characters" warning, and for a name that is in use the "Name is used" warning is given. A format that reflects the purpose of use is recommended in the naming (e.g. RT_DMZ, RT_CUSTOMER_A, RT_INTERNAL). The name can be edited after it is created; the internal identity (id) of the table and the table number are independent of the name.

INFO

Dynamic Route Table

Whether the dynamic routing protocols will be run on the route table is determined (a check box, unchecked by default). In TR7 dynamic routing is provided over the FRRouting (FRR) infrastructure; when the option is checked, the FRR mode and the daemon switches become visible in the form; after the record a separate FRR instance is run for the table.

FRR Mode

It determines the FRR configuration profile for all the dynamic routing daemons in the route table; TR7 passes the selected profile directly to FRR (frr_profile). The timer and behavior differences are applied not by TR7 but by the profile semantics of FRR itself. Two options are offered in the list in lower case (the default is traditional):

• traditional: the classic/conservative default profile of FRR; it is a general purpose profile compatible with traditional and enterprise network environments. Default.
• datacenter: the profile of FRR tuned for data center / CLOS fabric environments; it enables the default behavior and timers suitable for these environments.

The Daemons

When dynamic routing is enabled, one or several of the daemons below can be turned on. Every daemon is an Enabled / Disabled switch (the default is Disabled); when it is turned on, the related FRR start options are entered in the box next to it. The default option is -A 127.0.0.1; for the IPv6 daemons OSPF6D and RIPNGD it is -A ::1. The option text is not validated and is passed to FRR as it is.

Daemon	Area of Use
BGPD	Border Gateway Protocol; ISP connections, routing between large networks
OSPFD	Open Shortest Path First; enterprise internal network routing (IPv4)
OSPF6D	OSPFv3; OSPF for IPv6 environments
RIPD	Routing Information Protocol; simple routing in small networks (IPv4)
RIPNGD	RIP Next Generation; RIP for IPv6
ISISD	Intermediate System to Intermediate System; link-state routing, large-scale SP networks
PIMD	Protocol Independent Multicast; multicast routing
LDPD	Label Distribution Protocol; MPLS label distribution
NHRPD	Next Hop Resolution Protocol; DMVPN/NBMA address resolution
EIGRPD	Enhanced Interior Gateway Routing Protocol; compatibility with Cisco environments
BABELD	Babel; distance-vector routing for wireless/mesh networks
SHARPD	Super Happy Advanced Routing Process; a helper daemon for route injection/testing
PBRD	Policy-Based Routing; policy-based routing
BFDD	Bidirectional Forwarding Detection; fast link failure detection
FABRICD	OpenFabric; data center fabric routing
VRRPD	Virtual Router Redundancy Protocol; gateway redundancy
PATHD	Segment Routing Traffic Engineering (PCEP); path computation

TIP

The selection of the dynamic routing protocol depends on the network topology and on the existing infrastructure. In enterprise internal networks usually OSPFD, and in ISP connections BGPD is preferred. The protocol configuration of the selected daemons is done, after the table is created, over the VTYSH console opened from the preview panel on the Route Tables screen.

INFO

Add

The route table is created by clicking the Add button; while there is an erroneous field in the form, the button is passive. The record is applied without confirmation being asked and the form tab closes; if the server rejects the record, an error window opens and the form stays open. The route table created:

• can be selected as the Route table in the Edit Interface form and the interfaces can be moved to the table,
• new virtual interfaces can be created directly in this table in the Add Interface form,
• is seen as the route table filter in the Add IP Address and Add Static Routing forms,
• can be selected in the Route table fields in the Backend Service and vService forms.

Editing a Route Table (Edit)

An existing route table is edited by right-clicking the cell in the Route table column on the Interfaces List screen (Edit), with the Edit button in the Route Tables list or from the preview panel of the table. The editing form is the same as the adding form; in addition, the internal identity of the table is displayed as an information row and the button of the form becomes Edit.

• No field is locked; all the tables including the DEFAULT table can be renamed. A name change does not affect the network zone created in the system.
• The change is saved without confirmation being asked.
• When the Dynamic route table option is turned off and saved, the FRR mode and daemon settings are deleted; when it is turned on again, it is started with an empty FRR configuration.

WARNING

After the editing the number of the table may be reassigned: the table takes the smallest free number. Since the number determines the number name label on the screens and the console/VTYSH ports bound to the table, after the editing it must be checked whether these values have changed.

Deleting a Route Table

A route table is deleted with Delete in the right-click menu of the Route table cell in the interface list or with the Delete button in the Route Tables list. The DEFAULT table cannot be deleted; when it is tried, the "Cannot delete default namespace" error is returned.

The deletion always asks for confirmation: "Are you sure that you want to delete route tables object?" (in a multiple selection "Are you sure you want to delete N route tables objects?"). In the confirmation window the side effects of the deletion are listed with their levels; if there is an item at the 🔴 level, a second "This action has destructive consequences. Are you REALLY sure?" confirmation is asked.

The deletion cascade

• The virtual interfaces (VLAN, VXLAN, V-ETH, V-ETH(Peer), Bond, LACP, Bridge) in the table are deleted; 🔴 "... interface(s) in the route table will be deleted".
• The physical (ETH) interfaces in the table are moved to the DEFAULT table; ℹ️ "... physical interface(s) will move to the default route table".
• All the IP addresses and routes in the table are deleted (including those of the physical interfaces that are moved); 🔴 "... IP address(es) will be deleted", 🟠 "... route(s) will be deleted".
• The FRR instance and the files running for the table are removed; the DNS definition of the table falls out of the configuration.