IP Address being advertised on 2 VLANs

What's your switch topology look like?

SysAdmin4066

Only thing I can think of is port changes. Either physically or configured. Someone either changed the ports those were plugged into to be a different VLAN or they plugged them into different switch ports.

mikearama

If you believe the printer is physically plugged into G1/0/24, what's physically plugged into G1/0/12? Anything? Is it a printer?

is port Gi1/0/12 a trunk port?

Can you paste the config of the printer's switchport?

mikearama wrote: »

If you believe the printer is physically plugged into G1/0/24, what's physically plugged into G1/0/12? Anything? Is it a printer?

These are likely both trunks.

Maybe STP has the different vlans routing over different trunks. Doesn't explain how one NIC got in two VLANs though. Maybe someone added a Voice VLAN to the wrong port.

Sorry guys, I left work early yesterday not feeling well...

Now to catchup and provide some info...

Switch topology...
2 clustered 3750G-24 at the core
Each floor has an 'uplink' to the 3750's and not trunked...
Each floor has at minimum 2 x 2950 switches, some trunked, some just linked together...

what's physically plugged into G1/0/12? Anything? Is it a printer?
Plugged into this port is 2950 switch.

Is port Gi1/0/12 a trunk port?
No, it's not a trunk port, just the 2950 uplinked on that port...
interface GigabitEthernet1/0/12
switchport access vlan 21
switchport mode dynamic desirable
spanning-tree portfast

Port Gi1/0/24 is also uplinked to another 2950 switch...
interface GigabitEthernet1/0/24
switchport mode dynamic desirable

Can you paste the config of the printer's switchport?
It's difficult finding the switch port unless i have a toner, since each time i search the switches i get the mac-address listed on those 2 ports.

Hope this helps some...

Just to add...
We have persons (and printers) who were assigned with 192.168.202.x addresses, these are now being assigned 21.x addresses, even though the switchports are assigned to the 202 VLAN.

Similarly, I have this morning a printer on the ground floor, which had a 200.x address and assigned to the 200 VLAN, now being assigned a 202.x address.

I'm not sure where to start troubleshooting...

I thought of reloading the core switches, but that is the heart of the operation, so to do that i would have to possibly wait until weekend.

networker050184

I'm guessing those have formed trunks because you have dynamic desirable on and that is also the default on the 2950. A show interface trunk will tell you for sure. If you want it to be an access port only use the switchport mode access command on it.

Yeah it could still be a trunk with that config, depending what the other side looks like.

That 2950 hanging off of gi1/12, does that have a connection to any other switch? If so, I would remove portfast. Whats hanging off of 1/24? I assume another 2950? Do these 2950s have a connection to each other?

If you do a sh mac-add add *printer MAC* on the 2950 off of gi1/12, does it have 1 or two listings? Either way, track them both down and see where they go, I doubt the go to switchports and rather go in a loop (or the same place).

GT-Rob wrote: »

Yeah it could still be a trunk with that config, depending what the other side looks like.

That 2950 hanging off of gi1/12, does that have a connection to any other switch? If so, I would remove portfast. Whats hanging off of 1/24? I assume another 2950? Do these 2950s have a connection to each other?

If you do a sh mac-add add *printer MAC* on the 2950 off of gi1/12, does it have 1 or two listings? Either way, track them both down and see where they go, I doubt the go to switchports and rather go in a loop (or the same place).

I agree, I think you have a trunk port on there causing a loop somewhere in your network. Fix the loop and you should be good.

Yes, both are trunking...

Port Mode Encapsulation Status Native vlan
Gi1/0/12 desirable n-802.1q trunking 1
Gi1/0/24 desirable n-802.1q trunking 1

Look like you have 2 options. You can either remove the trunk where you don't want there to be a trunk, or you can try and fix STP.

Fixing STP will most certainly cause a down time of at least a minute or so, so be careful. I've been burned in the past by that damn protocol.

So is it best to take trunking off both interfaces? Or just one?

billscott92787

I agree as well that the dynamic desirable is causing a trunk and a switching loop to form. I would disable the trunk port on both ends "IF" you never plan for there to be any device on either end that will make trunking be required. This way if someone comes along and unplugs the cable from one of the switches, they can't cause it to trunk with another device if they plug one of the ends into another port that is trunking, which in effect would cause probably the same issue you are having now. Definitely interesting to see this in the work place. I can't wait to find a job that I get to deal with this stuff on a daily basis! I know crazy right? LOL

billscott92787 wrote: »

I agree as well that the dynamic desirable is causing a trunk and a switching loop to form. I would disable the trunk port on both ends "IF" you never plan for there to be any device on either end that will make trunking be required. This way if someone comes along and unplugs the cable from one of the switches, they can't cause it to trunk with another device if they plug one of the ends into another port that is trunking, which in effect would cause probably the same issue you are having now. Definitely interesting to see this in the work place. I can't wait to find a job that I get to deal with this stuff on a daily basis! I know crazy right? LOL

Yes its fun, until you bring down the whole network by accident with a loop!

To the OP: If these ports are going to switches, why not make them trunks? Is there only one vlan on your 2950s? Also, if you are going to make them 'access ports', and turn on portfast, you need to ensure that these 2950s are not connected to any other switches. If there are redundant connections, then make them trunks, and let spanning tree do its job. To be honest portfast isn't really doing anything for you when its connected to a switch, its more intended for end hosts that need a connection right away when they boot up.

I inherited these configs, and they seemed to have been working up until now. I've never had this problem before and really had no reason to look at the configs.

There should not be any other switches connected to these ones, only the connections back to the 3750 core switch.

Forsaken_GA

Every single time I've seen this problem, it's been a ****ed up trunk, and usually one that wasn't necessary in the first place. You want real fun? Get yourself into a situation where some of your nodes arp for a gateway ip, and the device that responds comes across a trunk from a device which doesn't have that IP.

If you have switch to switch connections, make them trunks, and manually define which vlans are allowed on the trunks. Make sure your native vlan is consistent across the switches. Eliminate any unnecessary links. And if your design is such that you have the option to convert everything to layer 3 and can eliminate STP entirely, *do it*

These are the kinds of problems that I get paid $100+/hr to fix hehe

APA

I agree you probably have a loop somewhere in your network.... don't use 'dynamic desirable'

Statically set your trunk ports & access ports.....

But.....

This doesn't explain why hosts are getting addresses from different vlans.... a loop would be causing mac-addresses to flap between different ports but on the same vlan\same vlan carried over a trunk...

Are you sure someone isn't plugging\unplugging hosts in an attempt to fix the issue, but really they are just confusing you even more by causing new CAM table entries in the different VLANs?

The 2950's hanging off the core..... do they solely home one vlan? If not then you want to keep Gi1/0/12 and Gi1/0/24 as trunk ports, but via the 'switchport mode trunk & switchport trunk encapsulation dot1q' commands.

Have a look at the arp table.... 'sh ip arp | inc (mac-address of host above)'

Ping the addresses that come up... is one dead?? If so that's more than likely a stale entry and would link to someone actually swapping switchports on you.

On the 2950's as GT-Rob said - Execute 'show mac-address-table dynamic address xxxx.xxxx.xxxx'

Is it directing you to an end host? another switch?

If I ping the address it's alive...

I have taken off the dynamic desired, and when I created a trunk on one of the 2950's to the core, i was only able to access one vlan...

If I run the command on both 2950's, here's what I get....

#show mac-address-table dynamic address 0000.4817.fec9
Mac Address Table

Vlan Mac Address Type Ports
----

202 0000.4817.fec9 DYNAMIC Gi0/1
21 0000.4817.fec9 DYNAMIC Gi0/1
Total Mac Addresses for this criterion: 2

#show mac-address-table dynamic address 0000.4817.fec9
Mac Address Table

Vlan Mac Address Type Ports
----

----

21 0000.4817.fec9 DYNAMIC Fa0/16
202 0000.4817.fec9 DYNAMIC Fa0/1
Total Mac Addresses for this criterion: 2

What has me puzzled, is why are they indicating 2 different VLANs...

There's not much I can do during the day, as it will affect users on the floor...

To elaborate on the trunk i had created...

On the 2950:

interface FastEthernet0/3
description Trunk to 3750CORE-1 port Gi1/0/12
switchport mode trunk
no ip address

On the 3750 core switch:

interface GigabitEthernet1/0/12
switchport trunk encapsulation dot1q
switchport mode trunk

I didn't specify any particular vlans to traverse the trunk.

If you don't specify then all VLANs are able to traverse the trunk. Specify which one(s) you want. Also ensure that the native VLAN is set properly on both ends of the trunk.

APA

r_durant wrote: »

If I ping the address it's alive...

Wait.... so when you ping both the 202 & 21 Vlan addresses they both respond???

Can you show us the configurations of Fa0/16, Fa0/1 & Gi0/1 from the relevant 2950s
please?

Also output from the relevant 2950s for

- show cdp neighbors
- show int desc

This is sounding more an more like your edge\access switches(2950s) have a link between them perhaps??? You may not even know about it... possibly someone has accidently patched an ethernet link between the two unknowingly (I´ve had this happen before!)

4E6564

I think APA is exactly right.

So you have the Core connected to both the 22 VLAN switch and the 202 VLAN switch?

What could have happened is someone plugged a cable between the switches, and it was defined as an access port (e.g. VLAN 22). Thus the 22 VLAN switch sends frames to the 202, but the 202 assumes they are 202 VLAN and thus sends them tagged as 202 to the core. I don't have any switiches near me to test, but it seems like that could happen. Or it could be a weird trunk issue.

APA..

Wait.... so when you ping both the 202 & 21 Vlan addresses they both respond???

The IP of the printer in question is 21.183, it doesn't respond to 202.183.

...as you said earlier, and from looking at the below outputs, it would seem as though there's a link between the two 2950's over ports fa0/16 and fa0/34. But both of those patch into a patch panel from the 2950's, there's no direct link between the 2. Unless there's a non-cisco switch somewhere in between them.

comp-room-nortel switch

interface FastEthernet0/1
switchport access vlan 21
no ip address

interface FastEthernet0/16
switchport access vlan 21
no ip address

Device ID Local Intrfce Holdtme Capability Platform Port ID
CARDCENTER-1 Fas 0/16 160 S I WS-C2950T-Fas 0/34
3750CORE-1 Fas 0/1 123 R S I WS-C3750G-Gig 1/0/12
2950-Main-FLR-2 Fas 0/21 155 S I WS-C2950T-Fas 0/16

Interface Status Protocol Description
Vl1 admin down down
Vl21 up up
Fa0/1 up up
Fa0/2 down down
Fa0/3 down down Uplink to 3750CORE-1 port Gi1/0/12
Fa0/4 down down
Fa0/5 down down
Fa0/6 down down
Fa0/7 down down
Fa0/8 up up
Fa0/9 up up
Fa0/10 up up
Fa0/11 down down
Fa0/12 down down
Fa0/13 up up
Fa0/14 down down
Fa0/15 up up
Fa0/16 up up
Fa0/17 down down
Fa0/18 down down
Fa0/19 up up
Fa0/20 up up
Fa0/21 up up
Fa0/22 down down
Fa0/23 up up
Fa0/24 down down

CARDCENTER-1 switch

interface GigabitEthernet0/1
channel-group 1 mode auto

interface FastEthernet0/34
switchport access vlan 202
switchport mode access
spanning-tree portfast

Device ID Local Intrfce Holdtme Capability Platform Port ID
comp-room-nortel Fas 0/34 129 S I WS-C2950-2Fas 0/16
3750CORE-1 Gig 0/1 124 R S I WS-C3750G-Gig 1/0/24

Interface Status Protocol Description
Vl1 admin down down
Vl21 admin down down
Vl202 up up
Fa0/1 up up
Fa0/2 down down
Fa0/3 up up
Fa0/4 up up
Fa0/5 up up
Fa0/6 down down
Fa0/7 down down
Fa0/8 up up
Fa0/9 up up
Fa0/10 up up
Fa0/11 up up
Fa0/12 down down
Fa0/13 down down
Fa0/14 down down
Fa0/15 down down
Fa0/16 up up
Fa0/17 down down
Fa0/18 down down
Fa0/19 up up
Fa0/20 up up
Fa0/21 up up
Fa0/22 up up
Fa0/23 up up
Fa0/24 up up
Fa0/25 down down
Fa0/26 down down
Fa0/27 up up
Fa0/28 up up
Fa0/29 up up
Fa0/30 up up
Fa0/31 up up
Fa0/32 up up
Fa0/33 down down
Fa0/34 up up
Fa0/35 down down
Fa0/36 down down
Fa0/37 down down
Fa0/38 down down
Fa0/39 down down
Fa0/40 down down
Fa0/41 up up
Fa0/42 up up
Fa0/43 up up
Fa0/44 up up
Fa0/45 up up
Fa0/46 down down
Fa0/47 down down
Fa0/48 down down
Gi0/1 up up
Gi0/2 down down
Po1 down down
Po2 down down

So a show cdp neigh on the 2950s only shows the one 3740core? (not counting any phones or APs you might have).

Why not try investigating the other direction. Take a mac off your core and trace it out from the 2950s. Is there two paths to get to it? A connection between those switches is the only reasonable explanation I can think of, and the trunks being treated as access ports is whats giving you the 2 vlans (and the port fast causing the loop). Even though the printer's access port is defined as vlan X, if the uplink on its switch as an access port in vlan Y, then the printer is going to show up as vlan Y on the core.

We don't have any IP phones in this building, so I don't think that is a possibility...but from the show cdp, it shows other switches as well, other than the core.

I pulled a mac off the core and it only gives one path back:

CARDCENTER-1#sh mac-address-table | inc 0016.e60e.a4ed
201 0016.e60e.a4ed DYNAMIC Gi0/1

comp-room-nortel#sh mac-address-table | inc 0016.e60e.a4ed
201 0016.e60e.a4ed DYNAMIC Fa0/1

Only one path, and through those interfaces (Gi0/1 & Fa0/1) is the path it should be taking.

APA

r_durant wrote: »

...as you said earlier, and from looking at the below outputs, it would seem as though there's a link between the two 2950's over ports fa0/16 and fa0/34. But both of those patch into a patch panel from the 2950's, there's no direct link between the 2. Unless there's a non-cisco switch somewhere in between them.

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

ilcram19-2

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