Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

ping drops from server on same vlan but different contexts

I have a pair of ace 20 modules in HA mode running A2(3.6a)

I have a vlan "10" shared by two contexts, the only layer 3 interfaces for the vlan are these two contexts. there is no firewall involved.

If I ping a server that resides on vlan 10 from context "A" I see a small number of drops.

If I ping the same server from context "B" there are no packet drops.

The server has a def g/w of the vlan 10 alias address in context "A"

So I get no drops from the context that is not the def g/w for the server, but do see drops for the context that is the def g/w.

Does anyone have an explanation for this behavior

2 REPLIES
Cisco Employee

Hi Clark,So normally if you

Hi Clark,

So normally if you have server and context interface IP's in the same subnet, the response should be direct. I am not sure why you see drops. The packet should be directed back at the ACE interface if the subnet is same. Can you take a pcap and see from which interface you receive the ICMP request and to which MAC server replies when drops happen?

Regards,

Kanwal

New Member

Thought i would post the

Thought i would post the resolution of this issue for other users experiencing a similar problem.

To recap, the issue was that I was experiencing ping drops from servers within one context but not from another.

The rate of drops was approx 0.1% and this was constant irrespective of load or time of day.

As I reported the setup is a pair of ace 20 modules in HA mode running A2(3.6a)

All of the contexts were live on the active module and in hot-standby on the standby device.

The standby module reset itself and reported the following

"last boot reason:  NP 1 Failed : SRAM Parity Error Chan 0"

the host switch reported

Jun 11 23:13:28: SP: The PC in slot 3 is shutting down. Please wait ...
Jun 11 23:13:38: SP: PC shutdown completed for module 3
Jun 11 23:13:38: %C6KPWR-SP-4-DISABLED: power to module in slot 3 set off (Reset)
Jun 11 23:18:41: %DIAG-SP-6-RUN_MINIMUM: Module 3: Running Minimal Diagnostics...
Jun 11 23:18:42: SP: ******************************************************************
Jun 11 23:18:42: SP: * WARNING:
Jun 11 23:18:42: SP: * EOBC Stress Ping test on module 3 may take up to 3min.
Jun 11 23:18:42: SP: * During this time, please DO NOT perform packet switching on the module.
Jun 11 23:18:42: SP: ******************************************************************

Jun 11 23:18:50: %DIAG-SP-6-DIAG_OK: Module 3: Passed Online Diagnostics
Jun 11 23:18:50: %OIR-SP-6-INSCARD: Card inserted in slot 3, interfaces are now online
Jun 11 23:18:57: %SVCLC-5-FWTRUNK: Firewalled VLANs configured on trunks

 

After the standby module rebooted the issue disappeared and no further ping drops were recorded.

So it seems that the standby module was in some fashion affecting the ability of a single context on the  active module to recieve ping responses from servers that were configured with the alias address of that context as their default gateway.

Hope this is of use to someone out there.

151
Views
0
Helpful
2
Replies