Showing posts with label 6509E. Show all posts
Showing posts with label 6509E. Show all posts

Monday, January 28, 2013

Reverse Engineering - DHCP & NetFlow


Most often than not, you will be required to reverse engineer different environments that are undocumented. I have been tasked with swapping out another 6509 for a 6509E and adding a secondary 6509E for redundancy.
One of the items I discovered that was unique to this environment was the DHCP configurations someone put in but never documented them and some NetFlow that was running but never being exported. It also was against policy for this environment.
 You will learn a lot while reverse engineering. Take for example this DHCP configuration; I have always implemented what was shown to me in Cisco books and never to the extent of what I found.  Another important lesson is to know what dependencies one configuration has to another, this is how things break if you don't over analyze. I obviously masqueraded some of the items due to security concerns and these two configurations have no dependency on each other.


DHCP CONFIG:

ip dhcp pool AP
   host 10.200.10.58 255.255.255.0
   client-identifier 0100.c0b7.2d38.07
   bootfile config.ini
   default-router 10.200.10.254
   domain-name joel.com
   option 150 ip 10.200.10.102
   lease 7

ip dhcp pool AP
   host 10.200.10.59 255.255.255.0
   client-identifier 0100.c0b7.2d37.c3
   bootfile config.ini
   default-router 10.200.10.254
   domain-name joel.com
   option 150 ip 10.200.10.102
   lease 7

Document I used to figure out what was going with this configuration:
http://www.cisco.com/en/US/docs/ios/12_1/iproute/command/reference/1rddhcp.html#wp1018363

Verfication:

6509E#show ip dhcp binding
IP address Client-ID/ Lease expiration Type
Hardware address
10.200.10.58 0100.c0b7.2d38.07 Infinite Manual
10.200.10.59 0100.c0b7.2d37.c3 Infinite Manual

NetFlow Config:

6509E#show running-config | include netflow
mls netflow interface
6509E#show run int vlan 30
Building configuration...
Current configuration : 174 bytes
!
interface Vlan30
 description AP
 ip address 10.200.10.254 255.255.255.0
 ip flow ingress
end

Document I used to figure out what was going with this configuration:
http://www.cisco.com/en/US/docs/ios/netflow/command/reference/nf_02.html#wp1012875

Verification:

6509E#show ip cache flow
-------------------------------------------------------------------------------
Displaying software-switched flow entries on the MSFC in Module 6:
IP packet size distribution (98171M total packets):
   1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480
   .000 .174 .019 .012 .007 .013 .054 .007 .002 .003 .004 .001 .016 .000 .000
    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
   .000 .000 .080 .073 .523 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 278544 bytes
  534 active, 3562 inactive, 2284418974 added
  2945144932 ager polls, 0 flow alloc failures
  Active flows timeout in 30 minutes
  Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 33992 bytes
  0 active, 1024 inactive, 0 added, 0 added to flow
  0 alloc failures, 0 force free
  1 chunk, 1 chunk added
  last clearing of statistics never
Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)
--------         Flows     /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow
TCP-Telnet     1685390      0.3         1    47      0.7       0.8      14.3
TCP-FTP        1258810      0.2         1    51      0.5       0.5      12.0
TCP-FTPD        282755      0.0         1    48      0.0       0.0      14.4

Thursday, January 17, 2013

Cisco 6509E Redundant Mode VS Combined Mode


Today while setting up a spare chassis to be used for burning in cards only, I noticed something that I never ran into.  Two out of the 8 modules that I had loaded into the chassis were showing a status of PwrDeny (See Example 1.1). We can correct this by installing higher wattage power supplies or changing the power mode from redundant to combined mode. I personally would prefer to install the higher wattage power supplies, but due to circumstances out of my control, I ended up changing the power mode to combined. Pros and Cons are below as well.

Redundant Mode:
When running in Redundant Mode, each power supply provides approximately 50% of its capacity to the chassis. In the event of a failure, the unaffected power supply will then provide 100% of its capacity and an alert will be generated. As there was enough to power the chassis ahead of time, there is no interruption to service in this configuration. This is also the default and recommended way to configure power supplies

Combined Mode:
In combined mode, each power supply provides approximately 83% of its capacity to the chassis. This allows for greater utilization of the power supplies and potentially increased PoE densities

Source: http://en.wikipedia.org/wiki/Catalyst_6500

Example 1.1

6509E_BURN_IN#show mod
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  1   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     XXXXXXXXXXXX
  2    8  CEF720 8 port 10GE with DFC            WS-X6708-10GE      XXXXXXXXXXXX
  3   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     XXXXXXXXXXXX
  4   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX    XXXXXXXXXXXX
  5    5  Supervisor Engine 720 10GE (Active)    VS-S720-10G      XXXXXXXXXXXX
  6    5  Supervisor Engine 720 10GE (Hot)       VS-S720-10G        XXXXXXXXXXXX
  7   16  CEF720 16 port 10GE                    WS-X6716-10GE      XXXXXXXXXXXX
  8   16  CEF720 16 port 10GE                    WS-X6716-10GE      XXXXXXXXXXXX

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
  1  0023.5e7f.4ac0 to 0023.5e7f.4aef   3.0   12.2(18r)S1  12.2(33)SXI6 Ok
  2  001e.f7f8.21e8 to 001e.f7f8.21ef   1.4   12.2(18r)S1  12.2(33)SXI6 Ok
  3  0012.4376.c1d0 to 0012.4376.c1ff   2.1   Unknown      Unknown      PwrDeny
  4  0021.55df.1ed0 to 0021.55df.1eff   2.8   12.2(18r)S1  12.2(33)SXI6 Ok
  5  0025.84bf.7b08 to 0025.84bf.7b0f   3.1   8.5(3)       12.2(33)SXI6 Ok
  6  001e.4a7e.e468 to 001e.4a7e.e46f   3.1   8.5(3)       12.2(33)SXI6 Ok
  7  e05f.b974.a680 to e05f.b974.a68f   1.0   12.2(18r)S1  12.2(33)SXI6 Ok
  8  e05f.b974.a860 to e05f.b974.a86f   1.0   Unknown      Unknown      PwrDeny

Mod  Sub-Module                  Model              Serial       Hw     Status
---- --------------------------- ------------------ ----------- ------- -------
  1  Distributed Forwarding Card WS-F6700-DFC3B     SAL12437YGQ  4.7    Ok
  2  Distributed Forwarding Card WS-F6700-DFC3C     SAL1223SNM7  1.0    Ok
  3  Centralized Forwarding Card WS-F6700-CFC       SAD0843019H  2.0    PwrDeny
  4  Distributed Forwarding Card WS-F6700-DFC3B     SAL1219Q4TH  4.6    Ok
  5  Policy Feature Card 3       VS-F6K-PFC3C       SAL1407B9EV  1.1    Ok
  5  MSFC3 Daughterboard         VS-F6K-MSFC3       SAL1407BJ77  2.1    Ok
  6  Policy Feature Card 3       VS-F6K-PFC3C       SAL1408BN6M  1.1    Ok
  6  MSFC3 Daughterboard         VS-F6K-MSFC3       SAL1407BFWL  2.1    Ok
  7  Distributed Forwarding Card WS-F6700-DFC3C     SAL15139YZ9  1.4    Ok
  8  Distributed Forwarding Card WS-F6700-DFC3C     SAL1513A3BP  1.4    PwrDeny

Mod  Online Diag Status
---- -------------------
  1  Pass
  2  Pass
  3  Not Applicable
  4  Pass
  5  Pass
  6  Pass
  7  Pass
  8  Not Applicable

Confirming The Current Mode:
6509E_BURN_IN#show power redundancy-mode
system power redundancy mode = redundant


Changing The Power Mode:
6509E_BURN_IN(config)#power redundancy-mode combined
6509E_BURN_IN(config)#
6509E_BURN_IN(config)#end
!
6509E_BURN_IN#show power redundancy-mode
system power redundancy mode = combined



 

 

Sunday, March 4, 2012

Multicast - Input queue drops/flushes

Below I will describe the steps I took to troubleshoot input queue drops/flushes on a Cisco 6509E device.

1: I tried increasing the input-queue from the default 75 to 1000, 2000 and then 4096 but that still did not stop the drops/flushes. This does work from occasion but it depends on the input rate of the data.

hold−queue <
is 75).


 
value> command for each interface (the queue length value can be 0 − 4096. The default value
Each interface owns an input queue onto which incoming packets are placed to await processing by the Routing Processor (RP). Frequently, the rate of incoming packets placed on the input queue exceeds the rate at which the RP can process the packets.
http://www.cisco.com/en/US/products/hw/modules/ps2643/products_tech_note09186a0080094a8c.shtml



6509E#show int gi 4/7
GigabitEthernet4/7 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is 0017.0f9b.0800 (bia 0017.0f9b.0800)
  Description: multicast-unicast
  Internet address is 192.168.7.94/31
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseT
  input flow-control is off, output flow-control is off
  Clock mode is auto
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:20:24
  Input queue: 0/2000/5/5 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 6004000 bits/sec, 3614 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
  L2 Switched: ucast: 480 pkt, 33840 bytes - mcast: 145 pkt, 13669 bytes
  L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 7135671 pkt, 1481502786 bytes mcast
  L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
     7064317 packets input, 1466661500 bytes, 0 no buffer
     Received 7063839 broadcasts (6970308 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     0 input packets with dribble condition detected
     1296 packets output, 93739 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out
6509E#


6509E#show int gi 4/7 switching
GigabitEthernet4/7 multicast-unicast
          Throttle count          0
        Drops         RP          5         SP          0
  SPD Flushes       Fast          5        SSE          0
  SPD Aggress       Fast          0
SPD Priority     Inputs         84      Drops          0
     Protocol       Path    Pkts In   Chars In   Pkts Out  Chars Out
        Other    Process       2682     210124          0          0
            Cache misses          0
                    Fast          0          0          0          0
               Auton/SSE          0          0          0          0
           IP    Process     716508   63616061     713076   92495576
            Cache misses          0
                    Fast   32778336 5720227032          0          0
               Auton/SSE  564492684 102883224482          5        390
6509E#


Selective Packet Discard (SPD) is a mechanism to manage the process level input queues on the Route Processor (RP). The goal of SPD is to provide priority to routing protocol packets and other important traffic control Layer 2 keepalives during periods of process level queue congestion.
http://www.cisco.com/en/US/products/hw/routers/ps167/products_tech_note09186a008012fb87.shtml

In order to stop the interface from being oversubscribed by the multicast traffic, I need a way to filter all the traffic coming into the interface.

3: Implementing a multicast boundary list, you need to set this up on both sides of the interface. If you only set this up one side, the receiving end the transmitting end will still push unnecessary data onto the receiving device.  In order to setup a multicast boundary, issue the below commands.

Creating a multicast boundary and applying it:

ip access-list standard name_acl
permit x.x.x.x
or
permit x.x.x.x 0.0.0.255
exit
!
interface gi 4/7
ip multicast boundary name_acl
end
!
WR
!

Now you are filtering multicast coming in and out of this port. This resolved my issue. I also recommend you read http://www.frameip.com/dos-cisco/queue_drops.pdf

Input queue drops are counted by the system if the number of packet buffers allocated to the interface is
exhausted or reaches its maximum threshold. The maximum queue value can be increased by using the