Host x in vlan y is flapping between port...

[carlsbad05]

Good morning/afternooon CSF,

I am having some issues with my network. I will start off by saying I am not a very "experienced" net admin, and most of my work revolves around Information Security Management. The net admin here quit, and I got tasked with running the network during a big project. That being said, I am CCNA and so I am trying to do my best to maintain a network that is well above my expertise level.

We had a 6506E in place, that we replaced with a 3750X. The person that bought the new switch didn't check to see if it had the required interfaces, and it didn't. As you probably know, the 3750X has only fiber, and we needed about 12 ports for our copper "backbone". The solution presented to me was to use a 3750G we had laying around and trunk it to the 3750X. I configured the 3750X and 3750G and put them in place. Everything worked great for the 3750X and the hosts on the 3750G that were being used for internal items, but the trunks on ports 25-32 of the 3750G are flapping all over the place. Ports 25-32 are all trunking to another HP switch in a different stack that we can't even so much as look at because someone else manages it. The 3750G then trunks to the core 3750X via fiber. Everything was working fine on the 6506E and I made sure to setup the interfaces the same way as they were on the old switch.

I shut all the interfaces one by one to see if the flapping and it still did regardless of which interface was shut at the time. I just really feel like it's something to do with the copper trunks having to go throug that additional switch in the scheme of things (3750X), and maybe STP isn't set up right? I could be way off. One thing I did just notice is that my 3750G is the root bridge for all the VLANS in use by the CAT6 trunks plugged into it. Since it has to go through my 3750X, shouldn't the 3750X be the root bridge for all of these VLANS? Just blasting away at stuff now, not sure if I'm close or not.

I've attached the flapping messages, some interface info, and some of the STP configs for the VLANs in question. All configs are from the 3750G. Any assistance is greatly appreciated.

[Gregory Snipes]

OK, couple of things here.

First off, you have created a loop in the network. In a switched layer 2 environment you cannot have multiple links between switches. It creates some fairly serious problems. This is why spanning tree was created, it finds and blocks all but one path between any given pair of switches. However you can configure multiple physical links to act as one link, this is called ether-channeling. To configure it between an HP and a Cisco switch you will likely need to use LACP to handle the ether-channel negotiation.

Second, the 3750X can be stacked with the 3750G and made into a single device. In this way you would not need to have extra links between the 3750X and the 3750G, all data moving between them would flow over the stackwise bus.

[carlsbad05]

Thank you so much for your reply.

1.) Unfortunately, we can't do the stacking. Our higher ups don't so much approve of that.

2.) I'm not sure we were using LACP before. I am looking at the entire config of the old switch and I don't see it anywhere. Also, if it has to be configured on both ends, I can't do it. I don't have any access to the HP switch.

I also want to make sure it has nothing to do with STP. When I look at the config on the "core" switch, it doesn't have an STP entry for any of the 3 VLANs in question. Is that how it's supposed to be? I am guessing the only way that would be the "right" thing, is because the bottom switch is acting as the "core" switch, but only for those VLANs. That being said, it is still passing all of its traffic up through the fiber trunk to the core. That seems to be too much of an issue to not be part of the problem. But maybe it's not.

[paul driver]

hello
at present i cannot access your attached file you have shared

however it does sound that your current physical setup isnt optimal though having multiple interconnects can cause issues these CAN be managed with correct configuration.

You say the hp switch isnt managed by you ,But do you know if this 3rd party has any other connection back into your network?

I would make sure that all access ports are protected and not able to trunk or become root/designated ports for your lan segments from other unknown switches. this can be done with stp port protection

bpduguard/ rootguard/loopguard

As for your etherchannels -I would personally have the switch create the port-channel automatically and not manually create it

And as stated by Gregory- lacp applied for the etherchannel between to the hp switch is required

res
paul


Sent from Cisco Technical Support Android App

[carlsbad05]

Hey there,

Sorry to come back with these new conditions, but we are actually able to do a physical stack, and it is now in place. The issue is that the connectivity to the Virtual Servers is still a no go. The flapping came back after the new interface configs were put into the switch, and we still can't RDP into the VM servers. We can ping them now, however.

Also, should we have wiped the "slave" (3750G) switch before stacking them? Do I need to merge any other configs other than the interface configs? I can't think of anything else that would have changed. STP is for 3 or more switches and we are only using two for these links now so that's not an issue, at least it shouldn't be. There are no STP instances for the VLANs these ports are on. We didn't reload the core (3750X) switch either. I can probably do that tonight when I come back in if need be.

Thank you all so much for your assistance. It is very much appreciated.

EDIT =====

I wanted to also say that we looked into the whole ether-channel deal, and it will probably be something we will try, but unfortunately we can't get into that other rack with the HP switch in it. We're hoping to have access to it tomorrow or Friday.

[Gregory Snipes]

Glad to here you persuaded the powers that be to let you stack these devices. It is really a perfect fit for what you needed there. Wiping the slave would have been preferable but not required, if every thing is working now I would not worry. The interface configs are the only thing that needs to be redone, the rest will just carry over from the 3750X.

You still need to do something about the loop. One option you can look at is setting up flex links. This will allow you to designate one port as the primary and another port as secondary. The primary port will be used and the secondary will not, unless the primary goes down, then the secondary will activate itself.

Flex links would provide you with link redundancy without needing to configure anything on the HP switch. Here is some guidance on how to configure flex links. If possible, the ether channel is still the preferable option as it will allow both links to be  active and forwarding traffic at the same time.

[carlsbad05]

Thanks for the advice. Yes, it is a plus that we were able to convince certain people to allow the physical stack. It really makes it a lot easier to manage.

So, I have discussed all of our options with our "higher ups" and they are confused as to the actual "group" that manages this HP stack. They have been scrambling around since I posted this to figure out who it is that actually set it up and manages it. Sad, really. At any rate, when they figure it out, I will be here to configure and/or re-configure our side of the trunk. Good times for sure. Thank you all so much for your support.

I really wish there was a way to leave this open without it being closed or something...so I can list what we did as a resolution. I hate putting something like this up here and not listing it as resolved with a solid description on what we did to fix it. It's only helpful to others if they see a resolution. I'll just keep coming back and editing it until we get it resolved. Thanks again.

[carlsbad05]

Ok everyone, I know it's been a few days, but we just found the techs who installed the HP suite in our comm room. (sad, I know)

That being said, we figured out a couple of things.

1.) We fixed the connectivity issue using two ether-channels. We had 8 copper trunks and they were going to two HP switches, 4 on each. That being said, we isolated the 4 for each to their own ether-channel since it was configured on the HP and we were good on connectivity.

2.) We found out the MACFLAP was not causing the connectivity issue and we think it may have even been happening on the previous core, but since personnel probably didn't have "terminal monitor" on, and were using SSH to monitor the switch, they may not have noticed the flapping.

We're still working the flapping issue, but we think we have isolated it to their virtual switch on their end. We'll see. I'll update when I know more.