Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

LMS 3.2 on solaris IP multi path

A customer has installed LMS 3.2 on a solaris 10 server.

The server as an IPPM address 10.2.5.210 and 2 phyiscal addresses  10.2.5.212 and 10.2.5.213.

No complains about this setup during the install

He observes that RME sets the tftpserver address to 10.2.5..213 where he had expected to see the 10.2.5..210

Address or name of remote host []? 10.2.5.213 Destination filename [vlan.dat]? 20091231093259857-172.20.0.20.cfg .....

%Error opening tftp://10.2.5.213/20091231093259857-172.20.0.20.cfg (Timed out)

I recall about a gateway.cfg file but the customer says he has no such file.

My questions are:

  • Is this IPPM configuration supported?

  • How does RME decide about it's TFTP IP address?

  • If the tftp daemon listen on both addresses and is mapped to the directory where ciscoworks creates its file to receive the config, why would if fail?

Cheers,

Michel

6 REPLIES
Cisco Employee

Re: LMS 3.2 on solaris IP multi path

Technically, IPMP is not supported.  We never tested it.  In order to determine the IP address to use for TFTP, RME will first check if the device has an RME ID (i.e. NAT IP) associated with the device.  If so, it will use that address.  Else, it will establish a TCP connection to the device on either tcp/23 or tcp/22, and use the local IP address from that socket as the TFTP address.  This uses the server's routing table, so it should be accurate.

As for why that's failing, you'd have to look at both the IPMP configuration, and any network filters.  Yes, the TFTP daemon should bind to *:69, but that may have been changed on the server.  Additionally, there may be access-lists or firewalls in place which are only allowing TFTP to the IPMP address.  As a workaround, you could manually specify the IPMP address as the RME ID for all devices in their RME device attributes.

Blue

Re: LMS 3.2 on solaris IP multi path

Since there was a bug (CSCsr20682) filed for IPMP, it bodes well for it being "supported". In any case, my LMS deployments are working fine on IPMP-enabled Sol 10 hosts.

The Cisco-supplied tftp daemon (/opt/CSCOpx/bin/in.tftpd) is listening on all interfaces:

      *.69                                Idle

The "gateway.cfg" you referrred to was actually $NMSROOT/lib/vbroker/gatekeeper.cfg, but no longer exists in LMS 3.2 (or 3.1 for that matter).

Was the tftp transfer done referring to the hostname of the floating IP (10.2.5.210) though? The following files/output will help shed more light:

"ifconfig -a" output

/etc/hosts

/etc/hostname.* files

/etc/default/mpathd

Cisco Employee

Re: LMS 3.2 on solaris IP multi path

This was my bug, and while it was filed for an IPMP configuration, official testing was never done for IPMP.  This bug actually bites users not running on IPMP as well, so we were able to verifiy it without moving to an IPMP config.

Blue

Re: LMS 3.2 on solaris IP multi path

I only just now noticed your second point in the old thread that /opt/CSCOpx/lib/classpath/ss.properties should have SS_CHECKIP=false, along with the CSCsr20682 patch. I haven't actually done that. I wonder what implication it has.

Cisco Employee

Re: LMS 3.2 on solaris IP multi path

Setting SS_CHECKIP to false is only required if you are getting 403 errors trying to log in.  It has no bearing on the CSTM functionality.

Re: LMS 3.2 on solaris IP multi path

Gentlemen,

Thank you very much for your comments.

The RME ID is what I was looking for here. This will make the TFTP go to the IPMP address.

I'm not aware if TFTP  sessions are limited to the IPMP address but this may be the issue here.

My customer says he tried manually to do a TFTP  to this address and it failed where a TFTP  to another TFTP  server worked.

I assume the default TFTP "security" (shouldn't call it that), where a world write-able file must exist on the TFTP  server applies to the ciscoworks TFTP  daemon.

I wonder if my customer created such a file. (I did mention it)

If he can't fix the TFTP  issue himself then I'm for hire 

Cheers,

Michel

553
Views
21
Helpful
6
Replies