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

S170 Appliance - M1 Port goes offline

svorhees1
Level 1
Level 1

I have a random issue with a brand new S170 where the M1 (mgmt) port goes offline after about 3-4 hours of uptime.  Rebooting (soft reboot) brings the M1 port on-line.  P1 stays connected.  P2 is not being used.

This unit is a newer unit that was replaced because the older unit was doing the same thing.  

The code has been upgraded to 8.8.0-085.  The unit is not being used in production.  It's just sitting there connected to the network.

It is connected to a 6509-E.  I have switched the port and cable that M1 was plugged into.  The same problem occurred on the new port/cable.

My guess is that the problem lies within the S170 because when the S170 is in this down M1 state, a reboot fixes it... moving the port/cable when it's in the down M1 state DOES NOT fix it... 

Could there be a setting in the 6509 that tells the S170 to drop it's M1 port?  (I've personally never heard of a switch doing something like this, especially 3-4 hours after connecting).

Has anyone seen this behavior before?

 

1 Accepted Solution

Accepted Solutions

Atazazuddin Shaikh
Cisco Employee
Cisco Employee

Hello

Thanks for reaching out,  This "state" can occur if two MAC addresses responding to the ARP broadcast, for <IP_Address> of default gateway for the M1 interface.  by default ARP table ger "refresh" every 4 hours.

What is a next step:

if possible take a packet capture that will show the MAC addresses responding to the ARP broadcast and one of entry will be valid (belonging to D/G of M1 interface)

or

Open a TAC case and an engineer can assist,

 

Regards,

Zack

 

 

 

View solution in original post

6 Replies 6

Atazazuddin Shaikh
Cisco Employee
Cisco Employee

Hello

Thanks for reaching out,  This "state" can occur if two MAC addresses responding to the ARP broadcast, for <IP_Address> of default gateway for the M1 interface.  by default ARP table ger "refresh" every 4 hours.

What is a next step:

if possible take a packet capture that will show the MAC addresses responding to the ARP broadcast and one of entry will be valid (belonging to D/G of M1 interface)

or

Open a TAC case and an engineer can assist,

 

Regards,

Zack

 

 

 

As a generic troubleshooting method, I changed the IP address of the M1 interface in order to see if there was a conflict.  I am a bit of a network novice so this may be way off base.

I do believe you are onto something with your response and I will be pursuing that.

Additional behavior to note:  If I unplug the P1 port from the switch, the M1 port stops pinging (goes offline).

If I unplug the M1 port, the P1 port stays on-line.  No effect.

Could this be a related to the overall issue?

Thanks for your quick response, Agreed this is not a "expected behavior". with the capture it will show it more details,  one more thing by creating "static ARP" entry on the switch can provide some inside as well.  Unlike dynamic ARP  "static ARP" will stick..

 

Thanks

Zack

 

We have cleared the ARP table on our switch but to no avail.  

Could you offer some basic suggestions as to troubleshooting this?  I don't believe we have any static ARP entries when I look at the ARP table (show arp).  There don't seem to be any duplicate IP addresses or MAC addresses that seem to be competing for the IP address in question.

I even changed the IP address of M1 and P1 on the S170 to see if that would help, it didn't.

I'm not sure what else to do... We are in a bit of a pickle here because we don't have support on our 6509E.  

Thanks for your response, Packet capture will help to isolate this issue.   Please open a TAC case on the WSA and engineer can run *rolling capture on WSA to further isolate and determine what other MAC address are responding to M1 etc.

 

Thanks

Zack

 

Found the fix.  Our interfaces were overlapping with their subnet masks.

M1 = 10.2.254.251/24
P1 = 10.2.1.251/16

I changed it to this:

M1 = 10.2.254.251/24
P1 = 10.2.1.251/20

All good now.  I am 100% sure this was the problem.  Thanks for the guidance Ataz... You got me in the area I needed to be to think about this and finally solve it.