IP Address being advertised on 2 VLANs

r_durant

ilcram19-2 wrote: »

have you tried to allow only the vlans that need to pass by each trunk port?

No, I haven't tried this...

Forsaken_GA

r_durant wrote: »

I really have no idea why Fa0/16 is setup as an access port in Vlan21 and Fa0/34 setup as an access port in Vlan202. I believe the two switches were meant to be one solely for Vlan21 only and the other solely for Vlan202 only, with each either having an uplink or trunk to the core. How the direct link between the two happened, I don't know.

If you inherited this, and your 2950's only have a single uplink to the 3750, someone probably put the link between the two switches in case the uplink to the 3750 went down so traffic could still flow. That or someone just screwed up.

If each switch is only supposed to have one vlan on it, then remove the link between them, setup trunks from the 3750 to the 2950's, and specify that only the vlan that's supposed to be on that switch (and your management vlan, of course) are allowed to traverse the trunk. This will probably clear up your problem entirely, and make your network much simpler to deal with to boot.

APA

r_durant wrote: »

I will make the change that you suggested and let you know how it goes, one thing I'd like to know id if making the change will bring down the link??

Thanks for all the assistance from everyone so far....

Nope, only changing the access vlan.... physical link won't go down.

ilcram19-2 wrote: »

have you tried to allow only the vlans that need to pass by each trunk port?

This is more a cleanup\best practice task once the initial problem is sorted....remember the end host is in it's correct access vlan so the traffic passing out of the trunk will be the correct vlan that needs to pass the trunk. The issue is coming about due to the L2 link between the two 2950s causing traffic to appear as if it is from a different vlan.

r_durant

Forsaken_GA wrote: »

If you inherited this, and your 2950's only have a single uplink to the 3750, someone probably put the link between the two switches in case the uplink to the 3750 went down so traffic could still flow. That or someone just screwed up.

If each switch is only supposed to have one vlan on it, then remove the link between them, setup trunks from the 3750 to the 2950's, and specify that only the vlan that's supposed to be on that switch (and your management vlan, of course) are allowed to traverse the trunk. This will probably clear up your problem entirely, and make your network much simpler to deal with to boot.

Yea, I'm thinking someone patched a cable somewhere, or maybe put in one of those small switches and bridged the link.

r_durant

APA wrote: »

Nope, only changing the access vlan.... physical link won't go down.



This is more a cleanup\best practice task once the initial problem is sorted....remember the end host is in it's correct access vlan so the traffic passing out of the trunk will be the correct vlan that needs to pass the trunk. The issue is coming about due to the L2 link between the two 2950s causing traffic to appear as if it is from a different vlan.

Well, I have 2 possible solutions...just putting fa0/34 in vlan21 or breaking the link and creating trunks back to the core. I'll go in the office tomorrow and try to clean it up before monday.

Forsaken_GA

r_durant wrote: »

Yea, I'm thinking someone patched a cable somewhere, or maybe put in one of those small switches and bridged the link.

Track it down and explain to the offender this is a bad thing!

This is also why I tend to put access ports into admin down until they're needed. It's a little bit more of a pain in the rear for me when someone needs a port turned up, but prevents links from showing up mysteriously.

If you don't have one, it sounds like it might be time to pick up some overtime and map out your links

r_durant

Forsaken_GA wrote: »

Track it down and explain to the offender this is a bad thing!

This is also why I tend to put access ports into admin down until they're needed. It's a little bit more of a pain in the rear for me when someone needs a port turned up, but prevents links from showing up mysteriously.

If you don't have one, it sounds like it might be time to pick up some overtime and map out your links

I had actually planned to clean up the whole thing, but a major project for the last year and a half didn't leave much time to do anything else. The good thing is that we're moving from this building pretty soon, well every dept except us in IT, therefore i won't have all those other floors and so many vlans to deal with at this building. But i do plan to track it down and also have better documentation of the network, I only have high-level diagrams, but nothing that maps out the links

r_durant

APA wrote: »

So CDP is telling us that there is indeed a direct link between the two switches... over fa0/16 and fa0/34 respectively.... regardless of whether it's over the one patch lead.. or via a patch-panel and multiple patch leads is irrelevant - it is still considered a direct link.

Why is Fa0/16 setup as an access port in Vlan21 and Fa0/34 setup as an access port in Vlan202?

This would explain why you are getting addresses assigned from multiple vlans, but one is only ever active... When ever a flap occurs I'll guarantee that which ever DHCP offer the hosts responds to first is the IP address that gets assigned...

I'm thinking that the VLAN202 address is coming about due to the fact that VLAN21 broadcasts would be sent out Fa0/16, but as they cross into Fa0/34 they are then tagged as VLAN202 and presented to your core which then presents this to the DHCP server, as it thinks the host broadcasting is in VLAN202therefore it assigns an address accordingly.

I'm going back to my original explanation - You said that the network use to work absolutely fine right? Only recently did this issue come about, but no network changes have been made?

I have a funny feeling someone in your team hasn't realised their patching has caused this issue so has negated to mention this change... If you are worried about unplugging\shutting down the link...I'd suggest changing Fa0/34 to 'switchport access vlan 21' , then clear the sole arp entry on Vlan202 for the mac-address previously mentioned.

This should see your issues disappear as VLAN21 traffic will not be tagged as VLAN202 as it crosses fa0/34 anymore...... and of course the issues will hopefully not re-appear elsewhere unless there are some other funky patching issues between the same switches\other switches in the topology.

I can't see any reason for having one side as Vlan21 and the other as Vlan202 for your topology........ Where I work we have some inter-connects setup with different VLANS on each side due to wholesale inter-connect links crossing between separate administrative domains, and each company wants the traffic traversing that link to be apart of a specific VLAN in their topology, however this doesn't seem to be the case for you.

Make the changes and let us know how you go

Just to let you all know i used APA's solution of changing Fa0/34 to 'switchport access vlan 21' and this solved the problem.

The building should be cleared in a month or so, so i think i'll wait a bit and just clean up this floor that will be left. I probably won't have enough time to do the building now anyways...

Thanks again...

APA

That is fantastic news r_durant Glad the issue has been resolved! Hope you sent a memo to your team explaining the dangers of looping unknown switchports together.....