Disable vEthernet snmp trap link-status on 1000v

[cbuzzard]

Hello -

Are there any options to disable the snmp link-status trap on Veth interfaces on the 1000v?  The normal "no snmp trap link-status" command is not available on a Vethernet interface, nor on the port-profile.  You can do it on the physical uplink ports, but that doesn't buy me anything.  The example in this doc shows you can but that doesn't not appear correct to me, http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_1_4/command/reference/n1000v_cmds_s.html#wp1309091

I'd prefer not to disable all snmp link status traps, but that might be the only option.

Thanks in advance

[mipetrin]

Hi,

What version of Nexus 1000v are you using?

Can you please provide the output of what you see when you attempt to run the commands?

Thanks,

Michael

[cbuzzard]

Hi Michael and all -

We are on version 4.2(1)SV1(4a).

Below is screen capture for your question.  You'll see that when trying to do 'no snmp trap link-status' for a vEth it errors for invalid command.  If you do the help context you'll see that the only option for SNMP is the global SNMP-SERVER change.

VSM-01(config)# int vethernet 79

VSM-01(config-if)# no snmp trap link-status

                                           ^

% Invalid command at '^' marker.

VSM-01(config-if)# no snmp-server ?

  aaa-user           Set duration for which aaa-cached snmp user exists

  community          Set community string and access privs

  contact            Modify sysContact

  context            SNMP context to be mapped

  counter            Set duration for which cached snmp counter cleared

  enable             Enable SNMP Traps

  globalEnforcePriv  Globally enforce privacy for all the users

  host               Specify hosts to receive SNMP notifications

  location           Modify sysLocation

  mib                Mib access parameters

  protocol           Snmp protocol operations

  source-interface   Source interface to be used for sending out SNMP notifications

  tcp-session        Enable one time authentication for snmp over tcp session.

  user               Define a user who can access the SNMP engine

VSM-01(config-if)# port-profile CustomerTemplate-SD

VSM-01(config-port-prof)# no snmp trap ?

                                        ^

% Invalid command at '^' marker.

Here you can see that when you do the command for a type Ethernet interface it is an option. 

VSM-01(config-port-prof)# int ethernet 10/1

VSM-01(config-if)# no snmp trap link-status ?

Thanks

Chad

[mipetrin]

Hey Chad,

Thanks for the details. I have tested in my lab with 1.4a and 1.4. Both of these do not have the command "snmp trap link-status" for the vethernet interface. I tried an old setup running 1.3b and it did have the command "snmp trap link-status" under the vethernet interface. So it looks like there was a change somewhere in between the releases.

Let me get in touch with people internally to see what I can find out for you.

I'll let you know.

Thanks,

Michael

[cbuzzard]

Thanks, Michael.  Related to the issue, if a request can be made this would be helpful at implementation to be able to apply it to a port-profile as well.  In our case as a Service Provider we'll have hundreds/thousands of veths and can't go modify each one after it was created at provisioning.  If we can apply it at the profile level then it will get picked up as VMs are provisioned not requiring follow-up actions.

Thanks for listening.

Chad

[mipetrin · Accepted solution]

Hey Chad,

I have created the following Bug to track this issue in 1.4 and 1.4a releases:

CSCtx41516 - Disable "snmp trap link-status" on a vethernet interface

Essentially it is a summary of the discussion from this thread and the testing I performed as a result. You should hopefully be able to see the details soon.

In terms of the request to apply the configuration at the port-profile level, I've gone back and tested if this feature was ever available in SV1(3b), SV1(3d), SV1(4) and SV1(4a). The answer to this is unfortunately not.

If you need this feature, as it would be beneficial within your environment where you are creating 1000+ vethernet interfaces, I recommend that you reach out to your account/sales team and put together a business case for the feature request. They can help put it together and attempt to get the feature request approved by the Developers and Business Unit.

Let me know if there is anything else.

Thanks,

Michael

[cbuzzard]

Thanks, Michael.  I already engaged our team yesterday on it so I'll follow-up with the bug ID and ask them to look at a feature request for the other piece.

Thanks for your assistance with it, much appreciated.

Chad