Category Archives: misc

Router Virtualization Concepts; IOS XR Virtualization

Hardware-Isolated Virtual Router (HVR)

Dedicates both control plane and data plane resources on a per-module boundary to individual virtual entities.

HVR implementation multiplies the available resources (add modules, processors, etc.).
Software-Isolated Virtual Router (SVR)
Share hardware ressources in the data plane.
Multiple guest operating systems to overlay on a host operating system – detrimental impact on scale because it introduces significant contention of resources.
Approach to overprovision ressources on all SVRs – wastes ressources decreasing overall scale.

Integrate virtualization into kernel. Same contention of resources. Complexity and instability in the kernel.

Virtualization in the individual applications. Better scale. Complicates design, testing and management.

SVR implementation divides the available resources.

Chassis resources (power supplies, blowers, fabric) are shared for both HVR and SVR.

Secure Domain Routers
HVR technology.
Distributed Route Processors (DRPs; hardware modules)  = full isolation between instances.
SDR defined on per-slot boundary with entire RP and Modular Service Card dedicated to an SDR.

The only parts of the chassis that are shared are the fabric, the fans, and the power supplies.
Owner SDR -system-wide functions including creation of non-owner SDRs. Admin config mode access.

In each SDR, administration and control capabilities are provided by the designated secure  domain router system controller (DSDRSC). Each SDR must include a DSDRSC to operate, and you must assign an RP or DRP to act as the DSDRSC.

The DSDRSC of the owner SDR is also the DSC of the entire system.
CPU and memory of an SDR are not shared with other SDRs

URPF with ACL configured order of operations

Step 1 Input ACLs configured on the inbound interface are checked.

Step 2 Unicast RPF checks to see if the packet has arrived on the best return path to the source, which it does by doing a reverse lookup in the FIB table.

Step 3 CEF table (FIB) lookup is carried out for packet forwarding.

Step 4 Output ACLs are checked on the outbound interface.

Step 5 The packet is forwarded.

CEF

ip cef and ipv6 cef

ip cef load-sharing algorithm and ipv6 cef load-sharing algorithm :

  • Original algorithm: As the name suggests, this is the original unseeded implementation prone to CEF polarization.
  • Universal algorithm: An improved algorithm using the Universal ID to avoid the CEF polarization.
  • Tunnel algorithm: A further improvement on the Universal algorithm especially suitable to environments where tunnels are extensively deployed, possibly resulting in arelatively small number of outer source/destination pairs. Avoids the CEF polarization. Might not be available for IPv6 CEF.
  • L4 port algorithm: Based on the Universal algorithm while also taking the L4 source and/or destination ports into account. Avoids the CEF polarization.

mls ip cef load-sharing (6500/7600):

Default ( default mls ip cef load-sharing ): Uses source and destination IP, plus the
Universal ID if supported by the hardware. Avoids CEF polarization.
Full ( mls ip cef load-sharing full ): Uses source IP, destination IP, source L4 port, and
destination L4 port. Does not use Universal ID. Prone to CEF polarization. However,
to alleviate its impact, this load-balancing algorithm causes the traffic to split equally
among multiple paths only if the number of paths is odd. With an even number of
parallel paths, the ratio of traffic split will not be uniform.
Simple ( mls ip cef load-sharing simple ): Uses source and destination IP only. Does
not use Universal ID. Prone to CEF polarization.
Full Simple ( mls ip cef load-sharing full simple ): Uses source IP, destination IP,
source L4 port, and destination L4 port. Does not use Universal ID. Prone to CEF
polarization. The difference from Full mode is that all parallel paths receive an equal
weight, and fewer adjacency entries in hardware are used. This mode avoids unequal
traffic split seen with Full mode.

unique-ID/universal-ID – adds a 32-bit router-specific value to the hash function (called the universal ID – this is a randomly generated value at the time of the switch boot up that can can be manually controlled).  This unique -ID concept does not work for an even number of equal-cost paths due to a hardware limitation, but it works perfectly for an odd number of equal-cost paths. In order to overcome this problem, Cisco IOS adds one link to the hardware adjacency table when there is an even number of equal-cost paths in order to make the system believe that there is an odd number of equal-cost links.

CEF Polarization: http://www.cisco.com/c/en/us/support/docs/ip/express-forwarding-cef/116376-technote-cef-00.html
CEF description: http://xgu.ru/wiki/Cisco_Express_Forwarding

IOS XE

This separation is achieved through the Forwarding and Feature Manager (FFM) and the
Forwarding Engine Driver (FED).
The FFM provides a set of APIs used to manage the control plane processes. The resulting
outcome is that the FFM programs the data plane through the FED and maintains all
forwarding states for the system. It is the FED that allows the drivers to affect the data
plane, and it is provided by the platform.