cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2715
Views
5
Helpful
12
Replies

CIMC hijacks IP address!

Roman Rodichev
Level 7
Level 7

UCS C200M2 CIMC firmware 1.4(1a). CIMC is configured with 192.168.1.48/24 proof

Screen Shot 2011-11-16 at 5.49.22 PM.png

Let me ping it from core:

ARC-3750-Core#ping 192.168.1.48

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.48, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

ARC-3750-Core#show ip arp 192.168.1.48

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  192.168.1.48            0   7081.05ff.2d2c  ARPA   Vlan1

Looks good. Now watch this:

ARC-3750-Core#ping 192.168.1.10

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.10, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

ARC-3750-Core#show ip arp 192.168.1.10

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  192.168.1.10           20   7081.05ff.2d2c  ARPA   Vlan1

192.168.1.10 is also voice gateway, so I've been chasing this for a few days until I finally decided to change voice gateway's IP and then discovered that 192.168.1.10 was still responding.

Probably a bug.

2 Accepted Solutions

Accepted Solutions

We've logged a new bug spefically to track this issue - CSCtw47679.

(Please allow 24hrs for this bug to be publicly visible)

Symptom:

Default CIMC IP addressing on eth0 mgmt interface is not clearing
after static IP configuration.
When user statically assigns the CIMC with an IP address in the subnet
of 192.168.1.X, IP address 192.168.1.10 is not
cleared from UCS system and user is able to ping both IP's to reach the CIMC. 
This will cause layer 3 addressing confusion if another device is configured
with the 192.168.1.10 address as well.
Conditions:


Bug is experienced on C200 M2 running firmware version 1.4(1a). 
This condition exists when customer is statically
assigning an IP address to the CIMC and affects the network when the
subnet 192.168.1.X is in use. Workaround:
1. Boot into the CIMC Configuration Utility. 2. Reset configurations to factory default settings. 3. Reconfigure configurations through local KVM.

Anyone else having this issue I implore you to open a quick TAC case and request to attach this bug so we can prioritize a fix.

Regards,

Robert

View solution in original post

NP.  As soon as I have the patch version this will be addressed it I will update this post.

Regards,

Robert

View solution in original post

12 Replies 12

Robert Burns
Cisco Employee
Cisco Employee

Was the .10 address ever configured on this CIMC?

I dont believe the CIMC would "hijack" a random IP address like that.

Robert

mipetrin
Cisco Employee
Cisco Employee

Hi Roman,

The 192.168.1.10 is a burnt in address that is assigned to the server during manufacturing. A particular script needs to be run in order to remove this address from the interface. Looks like this may have been missed on your device.

To alleviate the issue, break into the CIMC utility and reset the settings to factory default. This will run a script that wipes the address. Then you can reconfigure the CIMC address and should find that 192.168.1.10 is no longer reachable.

Thanks,

Michael

Michael,

this appears to be a common bug. I just got two more servers and they have the same issue. Yes, factory default reset gets rid of 192.168.1.10. This can be a nasty defect for some who use 192.168.1.x and happen to have an existing 192.168.1.10 on their network. I'm asking TAC engineer to file a bug.

As far as my existing production servers go, I now have to go onsite, factory reset CIMC, reboot the server, and set the CIMC IP again.

Roman

Thanks Roman - Please update this thread with the Bug ID.

Regards,

Robert

There is this internal bug CSCtl86779 that reports a situation where CIMC will continue to respond to addresses it is no longer configured for if the networking mode is changed when a session is active.   To say that this is left over from the factory seems to be a little off base in my opinion.  This appears to be the default IP address assigned to en0 when the system is in its factory default state, too bad it isn't documented as such though.

We've logged a new bug spefically to track this issue - CSCtw47679.

(Please allow 24hrs for this bug to be publicly visible)

Symptom:

Default CIMC IP addressing on eth0 mgmt interface is not clearing
after static IP configuration.
When user statically assigns the CIMC with an IP address in the subnet
of 192.168.1.X, IP address 192.168.1.10 is not
cleared from UCS system and user is able to ping both IP's to reach the CIMC. 
This will cause layer 3 addressing confusion if another device is configured
with the 192.168.1.10 address as well.
Conditions:


Bug is experienced on C200 M2 running firmware version 1.4(1a). 
This condition exists when customer is statically
assigning an IP address to the CIMC and affects the network when the
subnet 192.168.1.X is in use. Workaround:
1. Boot into the CIMC Configuration Utility. 2. Reset configurations to factory default settings. 3. Reconfigure configurations through local KVM.

Anyone else having this issue I implore you to open a quick TAC case and request to attach this bug so we can prioritize a fix.

Regards,

Robert

Thanks Robert, I'm glad this issue will be addressed in a future CIMC update.

NP.  As soon as I have the patch version this will be addressed it I will update this post.

Regards,

Robert

Great, thank you!

Roman,

Didn't want to leave you hanging.  The fix for the CIMC address bug above is scheduled for 1.4(3) which is currently tracking for a Feb. release.  This is a tenative date as always.  I'll continue to update as things change/confirm/release.

Regards,

Robert

s.winiarz
Level 1
Level 1

Hello,

We have the same issue with 3 ucs C210M2 servers.

Is there any news about solving this issue ?

I've looked in 1.4.3k firmware release note but it seems that it isn't still resolved...

Regrdas

This was was indeed fixed as of 1.4(3).  The latest 1.4(3k) would also be included here.   Not all bugs resolved are documented in the release notes.

Robert

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: