CCNP Equal Cost Multi Path (ECMP)

From Datateknik
Revision as of 14:01, 2 December 2016 by Imra (Talk | contribs)

Jump to: navigation, search

Intro

Contents

Routing - Verifying CEF's 15 hash-buckets

Verification of Configuration

Leaf-1#show ip route
Gateway of last resort is not set


      10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C        10.1.1.0/24 is directly connected, gig0/1
L        10.1.1.1/32 is directly connected, gig0/1
C        10.2.2.0/24 is directly connected, gig0/2
L        10.2.2.1/32 is directly connected, gig0/2
C        10.3.3.0/24 is directly connected, gig0/3
L        10.3.3.1/32 is directly connected, gig0/3

Note above that we have one subnet for each spine switch


O        10.2.0.0/16  [110/2] via 10.1.1.3, 1d19h, gig0/1   ← Assuming we add summary
                      [110/2] via 10.2.2.3, 1d19h, gig0/2
                      [110/2] via 10.3.3.3, 1d19h, gig0/3
O        10.3.0.0/16  [110/2] via 10.1.1.3, 1d19h, gig0/1   ← Assuming we add summary
                      [110/2] via 10.2.2.3, 1d19h, gig0/2
                      [110/2] via 10.3.3.3, 1d19h, gig0/3
O        10.4.0.0/16  [110/2] via 10.1.1.3, 1d19h, gig0/1   ← Assuming we add summary
                      [110/2] via 10.2.2.3, 1d19h, gig0/2
                      [110/2] via 10.3.3.3, 1d19h, gig0/3

Note above that we have three equal cost paths to servers on other leafs, the same amount of parallel paths as we have spines.


C        10.1.10.0/30 is directly connected, gig0/10
L        10.1.10.1/32 is directly connected, gig0/10
C        10.1.11.0/30 is directly connected, gig0/11
L        10.1.11.1/32 is directly connected, gig0/11
C        10.1.12.0/30 is directly connected, gig0/12
L        10.1.12.1/32 is directly connected, gig0/12

Note above that every server is in its own LAN, with 10.$leaf.$down_port.1 as default-gateway. ($y ??)


Now we check the hash-buckets for load balancing over spines/between leafs.

Leaf-4#show ip cef 10.5.0.0 internal
10.5.0.0/16, epoch 3, RIB[I], refcount 6, per-destination sharing
  sources: RIB
  feature space:
   Broker: linked, distributed at 4th priority
  ifnums:
   FastEthernet0/1(469): 10.1.1.5
   FastEthernet0/2(470): 10.2.2.5
   FastEthernet0/2(470): 10.3.3.5
  path 0625780C, path list 053A00B0, share 1/1, type attached nexthop, for IPv4
  nexthop 10.1.1.5 gig0/1, adjacency IP adj out of gig0/1, addr 10.1.1.5 058EF420
  path 0625787C, path list 053A00B0, share 1/1, type attached nexthop, for IPv4
  nexthop 10.2.2.5 gig0/2, adjacency IP adj out of gig0/2, addr 10.2.2.5 058EF280
  path 0625787C, path list 053A00B0, share 1/1, type attached nexthop, for IPv4
  nexthop 10.3.3.5 gig0/2, adjacency IP adj out of gig0/2, addr 10.2.2.5 05EFAKE0
 

  output chain:
    loadinfo 0588EE68, per-session, 2 choices, flags 0003, 6 locks
    flags: Per-session, for-rx-IPv4
    16 hash buckets
     < 0 > IP adj out of FastEthernet0/1, addr 10.1.1.3 058EF420
     < 1 > IP adj out of FastEthernet0/2, addr 10.2.2.3 058EF280
     < 2 > IP adj out of FastEthernet0/3, addr 10.1.1.3 058FAKE0
     < 3 > IP adj out of FastEthernet0/1, addr 10.2.2.3 058EF420
     < 4 > IP adj out of FastEthernet0/2, addr 10.1.1.3 058EF280
     < 5 > IP adj out of FastEthernet0/3, addr 10.2.2.3 058FAKE0
     < 6 > IP adj out of FastEthernet0/1, addr 10.1.1.3 058EF420
     < 7 > IP adj out of FastEthernet0/2, addr 10.2.2.3 058EF280
     < 8 > IP adj out of FastEthernet0/3, addr 10.1.1.3 058FAKE0
     < 9 > IP adj out of FastEthernet0/1, addr 10.2.2.3 058EF420
     <10 > IP adj out of FastEthernet0/2, addr 10.1.1.3 058EF280
     <11 > IP adj out of FastEthernet0/3, addr 10.2.2.3 058FAKE0
     <12 > IP adj out of FastEthernet0/1, addr 10.1.1.3 058EF420
     <13 > IP adj out of FastEthernet0/2, addr 10.2.2.3 058EF280
     <14 > IP adj out of FastEthernet0/3, addr 10.1.1.3 058FAKE0
     <15 >  -- not used /Robert
   Subblocks:
    None
Leaf-4#

Sometimes you need to tweak the load balancing scheme with the command

 ip cef load-sharing algorithm include-ports source destination

Done!

Congratulations.

Routing - Verifying path in CEF

This has not been verified for L3 Etherchannels

show ip cef exact-route source-ip-address destination-ip-address

Example from http://packetlife.net/blog/2011/may/27/show-ip-cef/

Router# show ip cef exact-route 10.0.9.5 192.168.0.1
10.0.9.5        -> 192.168.0.1    : FastEthernet0/1 (next hop 10.0.9.18)
Router# show ip cef exact-route 10.0.9.6 192.168.0.1
10.0.9.6        -> 192.168.0.1    : FastEthernet0/0 (next hop 10.0.9.14)

Source: http://www.netcraftsmen.com/load-balancing-and-cisco-express-forwarding-cef-with-parallel-paths/

CEF with EtherChannel

From: Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches paragraph Catalyst 3560

You can find out which interface is used in the EtherChannel to forward traffic based on
the load balancing method. The command for this determination is

test etherchannel load-balance interface port-channel number {ip | mac} [source_ip_add | source_mac_add] [dest_ip_add | dest_mac_add]

Example:



switch#show ip cef exact-route 172.16.79.186 192.168.42.183
172.16.79.186 -> 192.168.42.183 => IP adj out of Vlan100, addr 10.10.1.245 

switch#show vlan id 100
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
100 uplink1 active Po4


switch#test etherchannel load-balance interface po4 ip 172.16.79.186 192.168.42.183
Would select Gi0/51 of Po4
switch#show controller util | inc (^Port|Gi0/51)
Port Receive Utilization Transmit Utilization
Gi0/51 1 0 

Example 2:

switch#show control util
Port Receive Utilization Transmit Utilization
Gi0/49 1 55
Gi0/50 6 0
Gi0/51 1 0
Gi0/52 12 57 

Debugging according to Cisco

Regular Interface (No Subinterfaces)

Step 1
View the Address Resolution Protocol (ARP).
RP/0/RSP0/CPU0:router# show arp 

Step 2
Verify that the lag table is programmed properly in the hardware.
RP/0/RSP0/CPU0:router# show interface bundle-ether bundle-id 

Step 3
View the running configuration information.
RP/0/RSP0/CPU0:router# show running-config 

Step 4
View information about packets forwarded by CEF.
RP/0/RSP0/CPU0:router# show cef 

Step 5
RP/0/RSP0/CPU0:router# show cef hardware ingress location node-id

Step 6
RP/0/RSP0/CPU0:router# show cef hardware egress location node-id 

'''Subinterface''' 

Step 1
Troubleshoot Layer 3 IPv4 traffic.
Step 2
Ensure that VLAN traffic coming in matches that on the incoming interface.

Ping Failed over Bundle
Step 1
View the ARP.
RP/0/RSP0/CPU0:router# show arp 
Step 2
View the ARP information on the particular LC or RSP.
RP/0/RSP0/CPU0:router# show arp location node-id
Step 3
RP/0/RSP0/CPU0:router# show cef hardware detail location node-id ingress 
Step 4
RP/0/RSP0/CPU0:router# show interface 
Step 5
Use the hash calculator to determine which bundle member (interface) to test.
Step 6
Remove the interface from the bundle.
Step 7
Assign an IP address to the interface.
Step 8
Ping the interface.
Step 9
Ensure that the ARP is resolved between the router and the node being pinged.
### END ###

dCEF

Brandon, Just as a side note, "show ip cef exact-route" will show you the software CEF hash. It's not useful on hardware platforms to determine path selection as hardware will not necessarily make the same decision. "show mls cef exact-route" is what you want to use on these platforms. For distributed forwarding(DFC) platforms it may need to be checked by attaching to the ingress LC.

-Ben http://www.gossamer-threads.com/lists/cisco/nsp/140211

NEXT2

bbb

NEXT3

hej.

Personal tools
Namespaces

Variants
Actions
Navigation
Tools