cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1125
Views
0
Helpful
6
Replies

is it a bug? msfc and fwsm on 7609 who drop echo reply packet?

rbc01524101
Level 1
Level 1

Device:

7609#show module
Mod Ports Card Type Model Serial No.
--- ----- -------------------------------------- ------------------ -----------
1 48 CEF720 48 port 1000mb SFP WS-X6748-SFP SAL10425EVS
2 16 16 port 1000mb GBIC ethernet WS-X6416-GBIC SAL093069EP
3 6 Firewall Module WS-SVC-FWM-1 SAD11040045
4 8 Network Analysis Module WS-SVC-NAM-2 SAD105000NK
5 2 Supervisor Engine 720 (Active) WS-SUP720-BASE SAD083408HL
9 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX SAL1013H2RL

Mod MAC addresses Hw Fw Sw Status
--- ---------------------------------- ------ ------------ ------------ -------
1 001a.a2a2.e988 to 001a.a2a2.e9b7 1.10 12.2(14r)S5 12.2(18)SXD1 Ok
2 000c.8515.d810 to 000c.8515.d81f 2.5 5.4(2) 8.3(0.156)RO Ok
3 001a.6d66.1bdc to 001a.6d66.1be3 4.1 7.2(1) 3.2(11) Ok
4 001b.2a65.4dcc to 001b.2a65.4dd3 4.2 7.2(1) 3.5(1b) Ok
5 0011.92e7.0148 to 0011.92e7.014b 3.1 7.7(1) 12.2(18)SXD1 Ok
9 0017.5954.1be0 to 0017.5954.1c0f 2.3 12.2(14r)S5 12.2(18)SXD1 Ok

Mod Sub-Module Model Serial Hw Status
--- --------------------------- ------------------ ------------ ------- -------
1 Centralized Forwarding Card WS-F6700-CFC SAL1050AHXE 4.0 Ok
5 Policy Feature Card 3 WS-F6K-PFC3A SAD08260420 2.3 Ok
5 MSFC3 Daughterboard WS-SUP720 SAD08300FAP 2.2 Ok
9 Centralized Forwarding Card WS-F6700-CFC SAL1004BEJA 2.0 Ok

Mod Online Diag Status
--- -------------------
1 Pass
2 Pass
3 Pass
4 Pass
5 Pass
9 Pass

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Topology:

host(172.16.44.154/16 gw 172.16.1.10)--(interface vlan1 172.16.1.10/16)msfc(interface vlan249 192.168.249.2/24)--(inside 192.168.249.1/24)fwsm

at msfc ,take 172.16.1.10 as sourse ping 192.168.249.1, pass~

at fwsm, ping 192.168.249.2 and 172.16.1.10,               pass~

at host, ping 172.16.1.10 and 192.168.249.2,                pass~

at host, ping 192.168.249.1         time out....

at fwsm, debug icmp trace, as show

    ICMP echo request (len 32 id 2 seq 52238) 172.16.44.154 > 192.168.249.1

    ICMP echo reply (len 32 id 2 seq 52238) 192.168.249.1 > 172.16.44.154

    ICMP echo request (len 32 id 2 seq 52494) 172.16.44.154 > 192.168.249.1

    ICMP echo reply (len 32 id 2 seq 52494) 192.168.249.1 > 172.16.44.154

    ICMP echo request (len 32 id 2 seq 52750) 172.16.44.154 > 192.168.249.1

    ICMP echo reply (len 32 id 2 seq 52750) 192.168.249.1 > 172.16.44.154

    there has echo reply packet  sending back to msfc ,so ping on msfc is ok

    but this host is directly connect on (7609 WS-X6748-GE-TX) ,gateway is also on  this msfc .

why this host has not receive the echo reply packet? who drop the packet? 

on 7609's config ,there has no acl deny the icmp or deny the packet  from 192.168.249.1.

This failure occurred after a 7609 restart,cold start ~

i'm sorry for my poor english~

1 Accepted Solution

Accepted Solutions

The FWSM seems to be sending the reply out.

You need to open a TAC case so, we can gather ELAM capture and see where the reply packet is getting lost.

-KS

View solution in original post

6 Replies 6

Deepak Sharma
Cisco Employee
Cisco Employee

Hi Zhijie.


I am not aware of any such bug on version 3.2(11).  However, since ICMP trace is showing us the reply coming back.  We need to have a quick check on the MAC address to which the reply is send across.  One of easy way to find this out is capture on FWSM vlan nameif as Inside.  


show run access-list cap

! If there is no ACL then add

access-list cap per icmp ho 172.16.44.154 ho 192.168.249.1

access-list cap per icmp  ho 192.168.249.1 ho 172.16.44.154

!

!RUN a capture

cap in in in ac cap pa 1522 bu 2048000

!

show cap in


Along with show cap in, can you please share show route, show arp from FWSM and show arp, show interface from MSFC.


Regards,

-Deepak

I see the SUP is running 12.2(18)SXD1 Ok.

Do you have DEC (Distributed ether channel) configured?

Could be CSCee10005

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCee10005

Upgrade the switch past 12.2(18)SXF7 or above and see if the problem persist.

Pls. open a TAC case where we can gather an ELAM capture on the SUP and see if this is this defect for sure.

-KS

i'm sorry ,i have not the access level for login in the Bug Toolkit~

and there has not anything about dec config on 7609, there are 6G autoconfig by system~

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------  
272    Po272(SU)        -        Gi3/1(P)   Gi3/2(P)   Gi3/3(P)   Gi3/4(P)  
                                 Gi3/5(P)   Gi3/6(P)

thank you for answer my problem~

as follow yours step~

FWSM# show running-config access-list cap
access-list cap extended permit icmp host 172.16.44.154 host 192.168.249.1
access-list cap extended permit icmp host 192.168.249.1 host 172.16.44.154

i  capture icmp on fwsm inside ,as  show  ,there are echo reply packets sending back on inside ~

FWSM# show capture in
14 packets seen, 14 packets captured
   1: 06:24:16.326613650 802.1Q vlan#249 P0 172.16.44.154 > 192.168.249.1: icmp: echo request
   2: 06:24:16.326613650 802.1Q vlan#249 P0 192.168.249.1 > 172.16.44.154: icmp: echo reply
   3: 06:24:21.326618900 802.1Q vlan#249 P0 172.16.44.154 > 192.168.249.1: icmp: echo request
   4: 06:24:21.326618900 802.1Q vlan#249 P0 192.168.249.1 > 172.16.44.154: icmp: echo reply
   5: 06:24:27.326624400 802.1Q vlan#249 P0 172.16.44.154 > 192.168.249.1: icmp: echo request
   6: 06:24:27.326624400 802.1Q vlan#249 P0 192.168.249.1 > 172.16.44.154: icmp: echo reply
   7: 06:24:32.326629900 802.1Q vlan#249 P0 172.16.44.154 > 192.168.249.1: icmp: echo request
   8: 06:24:32.326629900 802.1Q vlan#249 P0 192.168.249.1 > 172.16.44.154: icmp: echo reply
   9: 06:24:38.326635400 802.1Q vlan#249 P0 172.16.44.154 > 192.168.249.1: icmp: echo request
  10: 06:24:38.326635400 802.1Q vlan#249 P0 192.168.249.1 > 172.16.44.154: icmp: echo reply
  11: 06:24:43.326640900 802.1Q vlan#249 P0 172.16.44.154 > 192.168.249.1: icmp: echo request
  12: 06:24:43.326640900 802.1Q vlan#249 P0 192.168.249.1 > 172.16.44.154: icmp: echo reply
  13: 06:24:49.326646400 802.1Q vlan#249 P0 172.16.44.154 > 192.168.249.1: icmp: echo request
  14: 06:24:49.326646400 802.1Q vlan#249 P0 192.168.249.1 > 172.16.44.154: icmp: echo reply

--------------------------------------------------------------------------------------------------------

FWSM# show arp
        inside 192.168.249.2 001c.0f5f.9f80
        eobc 127.0.0.51 0000.1500.0000
FWSM# show route

S    172.16.0.0 255.255.0.0 [1/0] via 192.168.249.2, inside
C    192.168.249.0 255.255.255.0 is directly connected, inside

-----------------------------------------------------------------------------------------

7609#show arp | include Vlan249
Internet  192.168.249.1         190   001a.a1e8.f880  ARPA   Vlan249
Internet  192.168.249.2           -   001c.0f5f.9f80  ARPA   Vlan249

route table on 7609


C    172.16.0.0/16 is directly connected, Vlan1

C    192.168.249.0/24 is directly connected, Vlan249

show interface on msfc vlan 1 & vlan 249

7609#show interfaces vlan 1
Vlan1 is up, line protocol is up
  Hardware is EtherSVI, address is 001c.0f5f.9f80 (bia 001c.0f5f.9f80)
  Internet address is 172.16.1.10/16
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 8/255, rxload 5/255
  Encapsulation ARPA, loopback not set
  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 never
  Input queue: 0/75/459251/5008 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 20227000 bits/sec, 5876 packets/sec
  5 minute output rate 33828000 bits/sec, 5841 packets/sec
  L2 Switched: ucast: 1636079710 pkt, 1357522746776 bytes - mcast: 12149250 pkt, 1273235343 bytes
  L3 in Switched: ucast: 2282459590 pkt, 1127987063561 bytes - mcast: 0 pkt, 0 bytes mcast
  L3 out Switched: ucast: 1924966687 pkt, 1097019117087 bytes mcast: 0 pkt, 0 bytes
     2294761071 packets input, 1129321570674 bytes, 0 no buffer
     Received 11749391 broadcasts (374947 IP multicast)
     0 runts, 0 giants, 2100 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     1926528109 packets output, 1097512924676 bytes, 0 underruns
     0 output errors, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
7609#show interfaces vlan 249
Vlan249 is up, line protocol is up
  Hardware is EtherSVI, address is 001c.0f5f.9f80 (bia 001c.0f5f.9f80)
  Internet address is 192.168.249.2/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 03:15:11, output 03:15:11, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  L2 Switched: ucast: 44441 pkt, 5192054 bytes - mcast: 11 pkt, 704 bytes
  L3 in Switched: ucast: 99338 pkt, 8534297 bytes - mcast: 0 pkt, 0 bytes mcast
  L3 out Switched: ucast: 97625 pkt, 6779924 bytes mcast: 0 pkt, 0 bytes
     143784 packets input, 13726267 bytes, 0 no buffer
     Received 11 broadcasts (0 IP multicast)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     141858 packets output, 11912555 bytes, 0 underruns
     0 output errors, 3 interface resets
     0 output buffer failures, 0 output buffers swapped out
7609#

-------------------------------------------------------------------------------------------------

7609#show etherchannel summary
Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
272    Po272(SU)        -        Gi3/1(P)   Gi3/2(P)   Gi3/3(P)   Gi3/4(P)  
                                 Gi3/5(P)   Gi3/6(P)

The FWSM seems to be sending the reply out.

You need to open a TAC case so, we can gather ELAM capture and see where the reply packet is getting lost.

-KS

thank you , i will upgrade the  ios to test it.~

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card