NE routing and forwarding
NE routing and forwarding objects
You can configure and manage the following routing and forwarding objects on managed NEs using the NFM-P navigation tree routing view:
You can also configure the routing protocols assigned to routing and forwarding objects such as BGP, L2TP, MPLS, and LDP. The supported protocols are device-dependent and are displayed in the navigation tree routing view as child objects of the routing instance. See Chapter 28, Routing protocol configuration for more information about configuring routing protocols.
The following figure shows an example of the various routing objects that can be displayed in the routing view of the navigation tree.
Figure 27-1: Routing and forwarding objects
Routing instances
Routing instances are virtual routers. A routing instance in routing navigation tree is a representation of all of the characteristics/objects assigned to the router such as the interfaces, protocols, static routes, network domains, and other instance types (IS-IS, OSPF) being managed by the NFM-P. The supported objects are displayed in the navigation tree as child objects of the routing instance.
Routing instances contain their own dedicated interfaces and routing tables that are used to deploy multiple logical devices in one physical chassis.
DHCP relay and snooping on OmniSwitch routing instances
A DHCP relay agent is a BOOTP relay agent that relays DHCP messages between DHCP clients and DHCP servers on different IP networks. The Omniswitch supports global or per-VLAN BOOTP/DHCP relay service and per-VLAN UDP port relay services.
DHCP Option 82 and DHCP snooping provide security for a DHCP relay service. The DHCP Option 82 switch-level feature allows the relay agent to insert identifying information into client-originated DHCP packets before the packets are forwarded to the DHCP server. DHCP Snooping, at the switch or VLAN level, improves network security by filtering DHCP messages received from devices outside the network and building and maintaining a binding table to track access information for each device. DHCP relay Option 82 and snooping cannot be run on the switch at the same time.
DHCP relay and snooping is configured at the default routing instance level, see To configure UDP relay, DHCP snooping, and DHCP Option 82 on OmniSwitch routing instances . In addition, per-VLAN DHCP snooping can be enabled on a VLAN site. See To create a standard VLAN service on OmniSwitch devices , To create an OmniSwitch L2 VPN TLS VLAN service , and To create an OmniSwitch BTV VLAN service for more information.
It is necessary to configure ports connected to DHCP servers within the network and/or firewall as trusted ports so that necessary DHCP traffic to/from the server is not blocked. Configuring the port mode as trusted also identifies the device connected to that port as a trusted device within the network. See To configure OmniSwitch Ethernet ports for more information.
Web portal routing instances
You can use a web port routing instance to configure the WPP protocol running between a BRAS/BNG and a Web portal server. WPP is used for web portal authentication of WLAN users (DHCP Host). A web portal routing instances can be configured on a base routing instance or a VPRN routing instance. See WPP in Chapter 28, Routing protocol configuration for more information.
VRF instances
Virtual routing and forwarding (VRF) allows multiple instances of a routing table to co-exist within the same router at the same time. This increases functionality by allowing network paths to be segmented without using multiple devices. Because traffic is automatically segregated, VRF also increases network security and can eliminate the need for encryption and authentication. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflicting with each other.
IS-IS and OSPF instances
You can use IS-IS and OSPF non-forwarding instances to separate a very large network into smaller administrative entities. Instead of configuring a large number of filters, non-forwarding instances can be used to filter routes, thereby instantiating policies. Non-forwarding instances can be used to reduce the amount of routing information advertised throughout all components of a network. Routing information associated with a particular instance can be announced where required, instead of being advertised to the whole network.
Static routes
Static routing uses a manually-configured routing entry, rather than information from a dynamic routing protocol to forward traffic and never change unless you explicitly update them. Additionally, all traffic destined for a static address is routed through the same router and are automatically imported into the routing table when a router comes online.
Static routing is useful for networks with customers whose traffic must always flow through the same routers. Static routing avoids the bandwidth cost and route import latency of dynamic routing.
L3 network interfaces
An L3 network interface is a logical IP object that is defined on a physical port, such as an Ethernet port. An L3 interface:
The physical connection of one device to another device is through a port or channel. However, the L3 network interface determines its IP connectivity. The L3 network interface passes both routing information and IP traffic.
You can configure the following L3 network interface types on routing instances with the NFM-P:
DoS protection on L3 network interfaces
In a subscriber aggregation network, an NE typically receives few control-plane packets from a specific subscriber. If one or more subscribers generate excessive control-plane traffic, DoS protection policies can help to ensure that NEs do not become overburdened by these unwanted packets. Global DoS protection controls the arrival rate for unprovisioned link-layer protocol packets from CE devices.
You can use the NFM-P to create DoS protection policies and apply them to L3 network interfaces. A DoS protection policy limits the number of control-plane protocol packets that are received each second from a subscriber host, and optionally logs a violation notification if a policy limit is exceeded. The interface drops the excessive packets before they are queued or processed by the NE. You can use the NE System Security form to view the violations for a specific NE.
You can apply DoS protection policies to control the following on L3 network interfaces:
-
the overall control-plane packet arrival rate for the interface
-
whether an NE sends a notification trap if a policy limit is exceeded
An NE that supports DoS protection automatically assigns a default DoS protection policy to each L3 network interface. The default policy limits only the overall packet arrival rate for the interface, and cannot be deleted or modified.
You can also apply DoS protection policies to certain L2 and L3 access interfaces. See the appropriate service chapter for information about applying DoS protection policies to access interfaces.
You can configure a global NE DoS protection policy and distribute it to NEs by choosing Administration→Security→NE DoS Protection from the NFM-P main menu. See the procedure to configure an NE DoS protection policy in the NSP System Administrator Guide for more information about configuring and applying NE DoS protection policies.
DDoS protection on network and access interfaces
You can configure a global NE DDoS protection policy and distribute it to NEs by choosing Administration→Security→NE DDoS Protection from the NFM-P main menu. You can configure a DDoS protection policy on an L2 and L3 network interface. See the procedure to configure an NE DDoS protection policy in the NSP System Administrator Guide for information about configuring a DDoS protection policy.
You can also apply DDoS protection policies to certain L2 and L3 access interfaces and SAPs. See the appropriate service chapter for information about applying DDoS protection policies to access interfaces.
System interfaces
The system interface is associated with a network entity, such as a specific device, not a specific interface.The system interface is also referred to as the loopback interface.
The system interface is used to preserve connectivity when an interface fails or is removed. A system interface must have an IP address and a 32-bit subnet mask. The system interface is used as the device identifier by higher-level protocols such as OSPF and BGP. The system interface is associated during the configuration of the following entities:
NE routing policies
Policy-based routing (PBR) gives you a flexible means of routing packets over devices using the NFM-P by allowing you to configure a defined policy that override default routing protocol decisions on the router for traffic flows, and lessening reliance on routes derived from routing protocols. PBR gives you more control over routing by extending and complementing the existing mechanisms provided by routing protocols. PBR allows you to set the IP precedence. It also allows you to specify a path for certain traffic, such as priority traffic over a high-cost link.
You can set up PBR as a way to route packets based on configured policies. For example, you can implement routing policies to allow or deny paths based on the identity of a particular end system, an application protocol, or the size of packets.
There are no default routing policies on the NFM-P. Each policy must be created and applied to a routing object, a routing protocol, or the forwarding table. Each set of rules that is associated with controlling routes are called routing policy statement entries on the client GUI. See Chapter 54, Routing policies for more information on routing policies.
Self-generated traffic and QoS
The NFM-P supports QoS configuration for self-generated traffic (SGT) on routing instances and VPRN sites. NEs produce SGT for various applications, such as Telnet, SNMP, SSH, and others. For each application, you can configure the DSCP or dot1p value for the traffic generated by that application. You can also map DSCP values to forwarding classes. See To configure QoS for self-generated traffic on a routing instance and To configure QoS for self-generated traffic on a VPRN site.
Network domains
You can use the navigation tree Routing view to configure and manage network domains and to associate network interfaces or service tunnels with the network domain. For supported devices, there is a default Network Domain that is assigned to the associate Routing Instance. The default network domain cannot be deleted but the properties associated with it can be changed.
By default, all network interfaces in a routing instance belong to the default network domain. You can associate an interface to any user defined network domain. The loopback and system interfaces cannot be associated with user defined network domains.
Network domains help determine which network ports are eligible to transport traffic of individual SDPs. This information is used for the SAP-ingress queue allocation which is applied to VPLS SAPs. No SAP-ingress queues are allocated if a given port does not belong to the network domain used in a VPLS.
Note: A maximum of four network domains are supported in any VPLS.
If an SDP is used for E-PIPE, I-PIPE or A-PIPE bindings, the network domain configuration is not considered.
Network domains are not applicable to loopback and system interfaces.
An SDP can be assigned to only one network domain. If no user defined network domain is created, an SDP will be assigned to the default network domain. All SAPs in VPLS will have a queue reaching all fwd complexes serving interfaces belonging to the same network domains as the SDPs. You can assign or remove a network domain association of the interface or SDP without deleting the respective object.
TCP MSS adjustment for PPPoE sessions
The NFM-P supports ISA-based TCP MSS adjustment for PPPoE sessions. The functionality allows a BNG to adjust TCP MSS values, preventing PPP clients from sending large packets which could be dropped in an access network.
In the NFM-P, TCP SYN-flagged packets are matched by an IP filter policy configured with a filter action of TCP MSS Adjust, and forwarded through an internal LAG SAP to an ISA-BB provisioned on the routing instance. Base and VPRN routing instances are associated with an ISA-BB through an ISA NAT group containing multiple ISA-BBs. The ISA-BB adjusts the TCP MSS value if:
-
the MSS option is not present, in which case MSS field is inserted into the packet with the MSS value configured on the routing instance.
-
the MSS value is larger than the value configured on the routing instance, in which case the packet MSS value is changed to the configured value.
Workflow to configure TCP MSS adjustment
1 |
Configure an ISA NAT group to be used for MSS adjustment; see To configure an ISA-NAT group. |
2 |
Associate the ISA-NAT group with a base routing instance or VPRN routing instance and configure the MSS value on the routing instance; see To configure a routing instance or a VRF instance or To configure TCP MSS adjustment on a VPRN site. |
3 |
Create an IPv4 or IPv6 filter policy with a filter action of TCP MSS Adjust to match TCP packets requiring MSS adjustment; see To configure an ACL IP filter policy or To configure an ACL IPv6 filter policy. |
4 |
Apply the IPv4 or IPv6 filter policy to an SLA profile or L3 network interface; see To configure an SLA profile or To configure L3 network interfaces. |
Workflow to configure NE routing and forwarding
1 |
Configure a base routing instance or VRF instance on a device; see To configure a routing instance or a VRF instance . | ||
2 |
Enable the routing protocols to be supported on the device or routing instance. The supported protocols are device dependent. See the Routing protocol configuration workflow and procedures in Chapter 28, Routing protocol configuration for more information about configuring routing protocols. | ||
3 | Perform the following actions on the base routing instances as required:
| ||
4 |
Configure L3 network interfaces as required:
| ||
5 | Configure CPM virtual routing instances as required:
| ||
6 |
Cable the network ports on the devices to the network ports on other devices. | ||
7 |
Configure the appropriate routing policies as required; see Chapter 54, Routing policies . | ||
8 |
Create a network domain as required; see To create a network domain .
| ||
9 | View or list the following NE routing and forwarding related objects, as required:
|