Arista discovery -- losing the management IP address

Greg Hubbard1 · ‎01-22-2020

I am trying to find a way to work around a problem with discovery of Arista switches. It appears that the Arista design includes a special management interface (Management1) but if this interface is added to a separate VRF it becomes invisible to normal SNMP queries. According to Arista, the interface can be polled if the query uses a special community string format (i.e. "public@VRF"). I tested this, and it works, but it only provides a small amount of information.

No matter -- the problem I am having is that some switches contain no IP addresses for interfaces, and these are added to the CMDB "properly" with the IP address of the management interface in the right place. Other switches are configured for redundancy, so they have an IP address on an interface to support the failover (such as 1.0.0.1 on primary and maybe 1.0.0.2 on the partner). Discovery is finding these addresses the normal way.

When the discovery pattern finishes, it appears to have the IP address set correctly, but the device ends up in the CMDB with one of the failover addresses instead. I *think* that this is happening in the identification/reconciliation phase -- the algorithm seems to be favoring IP addresses in the IP address list over the IP attribute set for the CI.

Does anyone else have any experience with Arista devices? Have you seen this problem? If so, what did you do about it?

GLH

Greg Hubbard1 · ‎02-27-2020

No one offered anything about this, so I will reply to my own question with information that I have gathered.

First, Arista takes "security" seriously. They recommend putting the management interface into a special VRF. This causes the IP address to be hidden from normal SNMP queries -- even if they run against the management interface!

Their solution is to use a special credential: <community_string>@<vrf> when polling sensitive information. I have tested this and there is not much that comes from this type of polling other than the IP address of the management interface.

Discovery, of course, does not seem to be able to use multiple credentials for the same device, especially during one discovery pattern. Perhaps there is an enhancement idea in this.

Apparently there is some logic in the reconciliation engine that causes the IP address for a CI to be updated if the IP address in the payload does not appear in the IP address list elsewhere in the payload. On the surface this makes sense, but (in network) there are times when devices are managed with IP addresses that they do not contain, such as in environments that use Network Address Translation (NAT). I will not chase that rabbit here.

My choices seemed to be these:

1. Create a pattern that removes ALL IP addresses from the device

2. Create a pattern that injects the missing management IP address. This can work because of these assumptions:

1. The management interface is always called Management1

2. The address of the management interface is very likely to be the IP address that was used to find the device.

I took the second route because there was value in retaining the IP addressing in the device.

The implementation turned out not to be all that hard after some study of table support in the pattern language. I probably did not do it right, but here is what I did:

a. I cloned the Network Switch pattern to create my own

b. I cloned the SNMP Identify pattern library to create my own. (This is much harder than it should be)

c. I altered my copy of the Network Switch pattern so it would use my copy of SNMP Identify instead of the standard one.

d. I altered my copy of the SNMP Identify pattern by adding new steps between the existing steps that processed the IP address table. After the addresses are collected, my new steps make a copy of the table, transform it by changing everything to my desired value, and then remove any duplicate records. This new table is then added to the standard table and the "normal" logic continues. To keep the madness to a minimum, I put an "OID matching" precondition on all of my new steps so they will only run against an Arista device.

e. I created a classifier for these devices that launches my own pattern, and I linked this to my collection of Arista OIDs.

The good news is that this seems to work. The bad news is that I have a new pattern to support from now on, and there are portions of it that are difficult to manage in a DEV-UAT-PROD environment. For instance, there is NO support right now for library patterns in update sets. You cannot even export them to XML. The only way I know how to copy them from system to system is to start a new one on the target system and save it (so it gets put into the pattern table and started NDL is attached) and then open it up and copy/paste the NDL that I want.

This approach seems to work, but it did not "correct" any incorrect addressing on existing CIs. I had to manually fix them. Afterwards, my pattern worked -- it added the management address to the list, and the reconciliation stopped clobbering the IP address in each CI.

Long post, but someone might be interested some day...

GLH

Andrew Pywell · ‎06-05-2020

Hi Greg,

Looks like we will have to do the same work as you and probably dig a bit deeper. We have a requirement to create a "container" for each element listed in the EntPhysicalTable similar to what is available in HPE IMC, i.e.

Device- switch01.sub.dom.com JPE12345678

Container-Xcvr for Ethernet1 CAB-S-S-25G-2M
Container-Xcvr for Ethernet2 CAB-S-S-25G-2M
Container-Xcvr for Ethernet3 CAB-S-S-25G-2M
Container-Xcvr for Ethernet4 CAB-S-S-25G-3M
Container-Xcvr for Ethernet5 CAB-S-S-25G-3M
Container-Xcvr for Ethernet6 CAB-S-S-25G-3M
Container-Xcvr for Ethernet7 CAB-S-S-25G-3M
Container-Xcvr for Ethernet8 CAB-S-S-25G-2M
Container-Xcvr for Ethernet9 CAB-S-S-25G-2M
Container-Xcvr for Ethernet10 CAB-S-S-25G-2M
Container-Xcvr for Ethernet11 CAB-S-S-25G-2M
Container-Xcvr for Ethernet12 CAB-S-S-25G-3M
Container-Xcvr for Ethernet13 CAB-S-S-25G-3M
Container-Xcvr for Ethernet14 CAB-S-S-25G-3M
Container-Xcvr for Ethernet15 CAB-S-S-25G-3M
Container-Xcvr for Ethernet16 CAB-S-S-25G-3M
Container-Xcvr for Ethernet17 CAB-S-S-25G-3M
Container-Xcvr for Ethernet18 CAB-S-S-25G-2M
Container-Xcvr for Ethernet19 CAB-S-S-25G-3M
Container-Xcvr for Ethernet38 CAB-SFP-SFP-3M
Container-Xcvr for Ethernet39 CAB-SFP-SFP-3M
Container-Xcvr for Ethernet40 CAB-SFP-SFP-3M
Container-Xcvr for Ethernet45 SFP-1G-T
Container-Xcvr for Ethernet46 SFP-1G-T
Container-Xcvr for Ethernet47 SFP-1G-T
Container-Xcvr for Ethernet48 SFP-1G-T
Container-Xcvr for Ethernet49 CAB-Q-Q-100G-2M
Container-Xcvr for Ethernet50 CAB-Q-Q-100G-5M
Container-Xcvr for Ethernet53 CAB-Q-Q-100G-1M
Container-Xcvr for Ethernet54 CAB-Q-Q-100G-1M
Container-Fan Tray 1 FAN-7000H-R
Container-Fan Tray 2 FAN-7000H-R
Container-Fan Tray 3 FAN-7000H-R
Container-Fan Tray 4 FAN-7000H-R
Power-PowerSupply1 PWR-747AC-R
Power-PowerSupply2 PWR-747AC-R

Device Label

switch01.sub.dom.com

Interface List

Net Asset Information

Asset Name	Xcvr for Ethernet45	Asset Class	Container
Asset Description	Xcvr for Ethernet45	Manufacturer	Arista Networks
Model	SFP-1G-T	Serial Number	AHN12345678E
FRU	Yes	Asset Number
Asset OID	0.0	Physical Asset	Yes

Alias	Ethernet45	Manufacture Date
Build Version		Service Time	2019-03-28 12:40:01
Hardware Version	20	Maintenance Expiration Date	2019-11-04
Firmware Version/Boot ROM		Remaining Maintenance	0 day
Software Version		Card Serial Number	AHN12345678E
BOM Code		CLEI Code
Last Poll Time	2020-06-03 16:21:34	Location
Department		Remarks
Maintainer Info		Maintainer Contact Number
Product number

Would you be willing to share your new pattern should we commit to sharing our enhancements with you?

Thanks

Andrew

pywell@dxc.com

Greg Hubbard1 · ‎06-05-2020

Hi Andrew,

I do not mind sharing my kludge -- it is not elegant.

The biggest problem with it is that I created a private version of the SNMP Identify library, and altered this version. At this point, library patterns are hard to work with, and I am curious if ServiceNow plans to do anything about this.

I am not sure about the best way to post a pattern like this. Got any hints?

Greg Hubbard