Sunday, October 16, 2011

Understand Nexus 7000 Module Forwarding Capacity

Nexus 7000’s line card forwarding (FIB) capacity may be a limiting factor. This is particularly true in a virtualized data center, where multiple VDCs and VRFs are used. This note explains the importance of understanding and managing module capacity.

Nexus 7000 has forwarding engine on line cards. The larger the size of the routing table, the bigger the FIB required for hardware forwarding. When designing with multiple VDCs and VRFs, multiple routing processes and routing tables consume more resources on the module.

Below shows a module using 64k of 65k allocated capacity:

#show hardware capacity forwarding
Module 1 usage:
Route Type              Used      %Used      Free      %Free      Total    
                     (Log/Phys)            (Log/Phys)           (Log/Phys)   
IPv4 Unicast:       64161/64161     97     1375/1375       2    65536/65536 
L2VPN Peer:             0/0          0        0/0          0        0/0     
MPLS:                   0/0          0        0/0          0        0/0     
IPv4 Multicast:         4/8          0    14332/28664     99    14336/28672 
L2VPN IPv4 Mcast:       0/0          0        0/0          0        0/0     
IPv6 Unicast:         195/390        1    14141/28282     98    14336/28672 
L2VPN IPv6 Mcast:       0/0          0        0/0          0        0/0     
IPv6 Multicast:         5/20         0     2043/8172      99     2048/8192  

Saturday, October 15, 2011

Building a private cloud using MPLS and selective tag switching

To support virtualization requirements, it may be necessary to create a private cloud within the enterprise. MPLS is a proven technology to extend virtualization across WAN networks. Most existing network equipment can be enabled for MPLS, thus allowing an enterprise to gain significant new capabilities without the expense of equipment and facility cost.

To transition an existing production network into one that is MPLS enabled, a detailed design is required to select and place key infrastructure elements such as P, PE, and CE routers. Given that existing production traffic may already be routed by these devices, it is often desirable to leave that untouched.

Selective tag switching allows certain VPN traffic to be label switched by the MPLS network, while the other traffic continues to be routed.

 IP address planning is a critical prerequisite to enable selective tag switching. It is highly desirable to place MPLS infrastructure and the new private cloud extensions in a new and distinctive IP address block.

On the P router, private cloud traffic can be identified by PE router loopback addresses, here using as an example
access-list 88 permit

By default, label switching is applied to all traffic. Therefore it is important to reverse that behavior, and turn on label switching for the target traffic identified by access list.
no mpls ldp advertise-labels
mpls ldp advertise-labels for 88

As a result, only MPLS VPN traffic will be tag switched, while existing traffic shows “untagged”
P-router#sh mpls forward
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Untagged   0          Fa0/0
17     Untagged  0          Fa0/0
18     Untagged  0          Fa0/0
19     Untagged  0          Fa1/0
20     Untagged   0          Fa1/0
21     Pop tag   0          Fa0/0
22     Pop tag   0          Fa1/0
23     Pop tag     544932     Et3/0
24     21     399694     Fa0/0
25     21     416019     Fa1/0
26     Pop tag   0          Et3/0
27     Pop tag   0          Et3/0
28     22   0          Fa0/0
29     Pop tag   0          Fa0/0

 “traceroute” also provides an excellent tool to demonstrate if a packet is routed or tag switched throughout a network.