CLI command to see IP addresses assigned to the IFM (when using IMM)?

[RedNectar]

Hi folks,

I hope you can solve this one for me.

In the Intersight GUI, I can see (Infrastructure Services > Configure > Chassis> MyChassis >| [Inventory] tab) that the IP addresses 172.16.26.161 and 172.16.26.162 have been assigned to the IFMs

What I'd like to know is how I see these IP addresses from the CLI of the FIs

This is so frustrating - I actually found a command the other day that showed me this - it was long, curiously had the word "software" in the chain somewhere, and a word something like "ifcfg" - and I'm pretty sure it was after I'd issued the connect nxos command. Kicking myself now for not recording it somewhere.

But I can't re-discover it. Or perhaps it disappeared when I upgraded the FI and server firmware to 42.(1m) and 5.0(2b) respectively, although the 9508-UCSX Chassis reports version 4.2(1j)

You would expect the show mgmt-ip-debug command to show this, but alas it doesn't.

It may well be a software version thing.  My (fading) memory was before the upgrade, when I issued a connect iom 1 command, I'd connect to the 172.16.26.161 IP address - although you would see that until you exited the shell.  Now when I exit the IOM shell, I see that a session to 127.1.1.1 has been closed normally.

I guess at the end of this what I'd really like to know is 

Why do IFMs need IP addresses?

So if you can answer that question as a bonus, that would be good.

[Brian Morrissey · Accepted solution]

You can monitor the IFM's via SNMP if you have an IP address + SNMP enabled in the chassis profile (https://www.cisco.com/c/en/us/td/docs/unified_computing/Intersight/IMM_SNMP_Monitoring/b_imm_snmp_monitoring_guide/m_enabling_snmp_imm.html).

To get the external IP from the CLI you can do "connect iom X with X being the chassis # " and then "show platform software cmcctrl ifconfig".  If it's got an external IP on it you should see it on one of the sub-interfaces in that output eg eth1.vlan100 is inet addr:192.168.1.20

The 127.1.1.x address is just the internal communication between the FI and IOM, with x being the chassis #.

[RedNectar]

@brian 

THAT'S IT. I promise to buy you a beverage when we meet!

Took me 5 mins to figure this out last week, and tried in vein for ages (too embarrassed to admit just how long) to rediscover it yesterday! Well, I DIDN'T rediscover, it hence why I called on the community!

UCSX-A# connect iom 1
Attaching to FEX 1 ...
To exit type 'exit', to abort type '$.'
Last login: Sat Jan  7 20:16:01 GMT 2023 from 127.1.1.250 on pts/0
Bad terminal type: "xterm". Will assume vt100.
fex-1# show platform software cmcctrl ifconfig
eth1      Link encap:Ethernet  HWaddr CC:ED:4D:5A:CF:81
          inet6 addr: fe80::ceed:4dff:fe5a:cf81/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5394199 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6301107 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3481059473 (3.2 GiB)  TX bytes:1070494421 (1020.9 MiB)

eth1.1    Link encap:Ethernet  HWaddr CC:ED:4D:5A:CF:81
          inet addr:127.3.0.254  Bcast:127.3.0.255  Mask:255.255.255.0
          inet6 addr: fe80::ceed:4dff:fe5a:cf81/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3705552 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5972728 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3309737792 (3.0 GiB)  TX bytes:1007831241 (961.1 MiB)

eth1.126  Link encap:Ethernet  HWaddr CC:ED:4D:5A:CF:81
          inet addr:172.16.26.161  Bcast:172.16.26.255  Mask:255.255.255.0
          inet6 addr: fe80::ceed:4dff:fe5a:cf81/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:347 errors:0 dropped:0 overruns:0 frame:0
          TX packets:220 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:16046 (15.6 KiB)  TX bytes:9744 (9.5 KiB)

<snip>

Now all I have to do is figure out WHY the IOM (now occasionally renamed IFM) needs to consume an IP address from the IP Pool - AFAIK - at least as far as I remember,  I don't believe the old UCS IOMs needed an IP address!

And IF you allocate the chassis and IMC Access policy that has only OOB IP addresses, no IPs are consumed, and I'm not able to decern any difference in functionallity - which just makes me wonder moreso:

WHY the IOM (now occasionally renamed IFM) needs to consume an IP address from the IP Pool?

[Brian Morrissey]

Thanks glad that command was able to help out.

The only need that I am aware of currently for the external IP address on the IFM is for SNMP monitoring.  In the older UCSM mode everything was done by the FI for SNMP, whereas in IMM mode SNMP is enabled on the individual components (FI, IFM, Blades/Racks) if the subcomponents have inband addresses assigned.

[RedNectar]

@Brian Morrissey ,

Thanks for that.  Although your explanation is totally at odds with the Intersight Help Center which says:

The following list describes the chassis policies that you can configure in Cisco Intersight.

• IMC Access Policy—Enables you to configure and manage your network by mapping the IP pools to the chassis profile. This policy allows you to configure a VLAN and associate it with an IP address using the IP pool.

  ---

  Note: In-Band configuration is not supported for Chassis IMC Access Policy.

  ---

• SNMP Policy—Configures the SNMP settings for sending fault and alert information by SNMP traps from the managed devices. SNMP Users or SNMP Traps configured previously on the managed devices are removed and replaced with users or traps that you configure in this policy. If you have not added any users or traps in the policy, the existing users or traps on the input/output module (IOM) are removed.

I've hit the Feedback button, so hopefully this will be fixed.