IP Address Conflict - possibly from 6509 Core Switch?

[markferrara]

Hi,

We have had a server on 10.102.4.250 for some time, and yesterday we had connectivity issues to it.

It appears we have DHCP on our server VLAN (for some reason) and that the IP Address to another device with MAC address 0024.515d.9c00 (A cisco vendor ID)

I have performed a show arp on the distribution switch on that subnet and confirmed the mac address:

Dist_Sw-3750#

show arp | i 10.102.4.250

Internet     10.102.4.250     0024.515d.9c00     ARPA      VLAN 100

Core_SW-6509#

show mac address-table | i 9c00

*     100     0024.515d.9c00     static     no               - Router

*      50     0024.515d.9c00     static     no               - Router

*      48     0024.515d.9c00     static     no               - Router

*      54    0024.515d.9c00     static     no               - Router

*      52     0024.515d.9c00     static     no               - Router

*      34     0024.515d.9c00     static     no               - Router

Does this mean the Core Switch is somehow assigned this address?

I have performed a show ip int br and show run | i 10.102.4.250 but it does not appear anywhere.

Any help would be most appreciated!

Thanks in advance.

[Giuseppe Larosa · Accepted solution]

Hello Mark,

yes that MAC address 0024.515d.9c00 is in use on the core switch and used by all SVIs defined on it.

The difficult part is to understand why the distribution switch has built that ARP entry and the DHCP server sees it as a DHCP client to which it provided the conflicting IP address

Start by checking

core switch:

show run int vlan 100

show ip int vlan 100

as the ARP entry is learned on SVI vlan 100 on the distribution switch

There is a chance  that there is an SVI on the core switch configured with ip address dhcp (to act as a DHCP client )  that is not part of the global routing table, but it is associated to a VRF. (ip vrf forwarding )

In this case the SVI is not listed in the output of show ip int brief, because it is part of the VRF.

The SVI may have been configured for testing purposes.

What is the vlan-id of the server vlan? if on the core switch there is an SVI associated to it that may be the one that you are looking for.

This is because the SVI must be connected at layer2 to the server Vlan to be considered a DHCP client of that Vlan.

This may happen using an access port or because the server vlan is  allowed on the trunk between distribution and core switch (if one is present).

If an access port has been used it may be member of a Vlan that is different from the server Vlan (tricky but possible) and so the SVI may be unrelated to Server Vlan in this case. (this would lead to CDP error on vlan mismatch if CDP is enabled)

Edit:

the MAC address might have been spoofed and used by a PC with some form of malicious software, in this case you need to follow the MAC address in the CAM table of the distribution switch for the server Vlan to see where it is learned.

This is indeed the next troubleshooting step that you should perform. IF it points really to the core switch there is an SVI on it as explained above otherwise you will find another device using the same MAC address.

Hope to help

Giuseppe

[markferrara]

Thanks for your input Giuseppe,

I think I was looking in the wrong place...

The VLAN (VLAN 4) for the 10.102.4.0 /23 subnet is on the Firewall side of the 6509 on the FSWM module and there was no SVI on the Core Switch for VLAN 4.

I performed a show arp on this side of the FWSM and obtained the mac address of the host and traced it to a port on VLAN 4 on the Core Switch.

It appears that a new server had obtained the IP Address of an existing server on 10.102.4.250...

Once this new server was disconnected from the network, the correct server reobtained the correct IP address.

We have DHCP on our Server VLAN, which seems dangerous to me, but the scopes needs to be looked at since there are exclusions, reservations and inconsistant pools everywhere!

Thanks again!

[Giuseppe Larosa]

Hello Mark,

nice to know that you have solved.

And yes the DHCP server pools configuration has to be reviewed the reservations need to be updated

I agree that DHCP in the server vlans is uncommon. You should at least divide the subnets in two subparts one to be used for DHCP and one for devices with manual IP setup  OR you should use DHCP on all devices with a lot of reservations to fix the IP address of each server over time.

We did so for the printers for example: letting them get an IP address from DHCP and then creating a reservation to make it stable over time.

Hope to help

Giuseppe