cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3362
Views
0
Helpful
5
Replies
alistair.cowan
Beginner

2960S - no connectivity to mgmgt fa0 interface?

Hi Folks,

I'll try to make this brief!

I have a pair of stacked 2960S (LAN Base WS-C2960S-48TS-L to be exact) switches running 12.2(58)SE2 configured with multiple VLANs.  None of the VLANs have any L3 interfaces enabled and the switch can therefore only be managed by the management port fa0 (via https/ssh) and the console.

The problem I'm having is connectivity to fa0 fails, depending on where I'm pinging from. For example:

2960 MGMGT port (fa0) --> Upstream Switch <-- 2960's VLAN 100 (gi1/0/26) <-- Client desktops

                                                            |

                                                            |

                                                  Rest of LAN

Pings to fa0 from LAN or Upstream Switch - PASS

Pings to fa0 from VLAN100 clients - FAIL

Pings to rest of LAN from VLAN 100 clients - PASS

Lets say we expand the above as follows:

2960 MGMGT port (fa0) --> Upstream Switch <-- 2960_VLAN_100 (gi1/0/26) | 2960_VLAN_100 (gi1/0/28) <-- Downstream Switch <--  Dsktp clnts

                                                            |

                                                            |

                                                  Rest of LAN

Same results as the initial setup, but in addition:

Pings to fa0 from downstream switch/clients - FAIL

Pings to rest of LAN from downstream switch/clients - PASS

So, I think what's happening is the 2960 is detecting that fa0 MAC resolves to one of its own interface addresses, and therefore doesn't pass the traffic onto the upstream switch.  The end result is the traffic never reaches fa0.  Could someone please confirm if my thinking is correct here?  And is there any way around this setup issue?

I've attached my configs in a zip if it helps.

Many thanks,

Alistair

EDIT:  I should also add that ARP entries for fa0 are present and correct in the downstream clients ARP tables....

EDIT2: Added "loopback" command to fa0 with no luck, and uploaded Windows EOL RC

1 ACCEPTED SOLUTION

Accepted Solutions
MikeyDunn1
Beginner

Hey Alistair,

I believe the best route for efficient management would be to assign a reachable IP to an available VLAN interface, configure your vty settings and disable Fa0. If security is an issue, you can always further define specific security parameters.

Hope this suggestion helped!

Thanks,

Mikey

View solution in original post

5 REPLIES 5
MikeyDunn1
Beginner

Hey Alistair,

The configs you provided are helpful, however, the formatting of your running-config is unreadable. Can you re-post your current running configuration of your stack?

Thanks!

Hi Michael,

Apologies - think it was a Linux EOL issue, I've converted with Notepad++ and seems to look better now.

Thanks,

Alistair

Leo Laohoo
VIP Community Legend

I'm getting confused with your configuration of Fast0.  This port, labeled as "Management", but in reality acts as an Out-of-Bound-Management (OoBM) port.  Most of the time OoBM ports have a separate IP Address subnet on it's own.

Here's one way to test:

1.  Change the IP address of the Management port, say 1.1.1.1/24.

2.  Configure a laptop client to 1.1.1.221/24.

3.  Plug the laptop client to the management port directly and see if you can reach the switch stack.

MikeyDunn1
Beginner

Hey Alistair,

I believe the best route for efficient management would be to assign a reachable IP to an available VLAN interface, configure your vty settings and disable Fa0. If security is an issue, you can always further define specific security parameters.

Hope this suggestion helped!

Thanks,

Mikey

Hi,

Thank you both for your responses - I did just revert to removing the fa0 configuration and configured a managment VLAN instead.

The behaviour I was seeing would be acceptable in situations whereby the lack of fa0 connectivity to downstream clients is not an issue.  I hoped the switch would de-couple the fa0 mac address from it's own 'local' switching table and forward it on to the upstream switch like any other packet destined for non-local interfaces, but I can understand the behaviour.

This will do our job, it's just the mgmt VLAN configuration feels like a waste of an access port

Thanks again,

Alistair