RE: Network "Change Management"

From: Bill Nash (
Date: 09/20/04

  • Next message: Evan Pierce: "RE: Network "Change Management""
    Date: Mon, 20 Sep 2004 12:48:45 -0700 (MST)
    To: Jorge Reyes <>

    The passive trap option is definitely better than an active poll.
    Cisco's IOS-on-Catalyst handling of per vlan forwarding tables, with
    regard to the SNMP engine, really makes polling for existing MAC entries,
    in your bridge/forwarding tables, a super pain in the ass.

    Alternatively, if handling snmp traps is too much admin overhead,
    redirecting these traps to syslog output (where possible) would integrate
    into existing syslog analysis engines (ala netcool, etc) with ease. While
    I haven't tested it, it's likely possible to handle assigned MAC<->port
    membership violations in the same manner. This is definitely behavior that
    may change significantly between CatOS and IOS, or any of the hybrid
    versions on various Catalyst platforms. Your mileage may vary, or be
    recorded in kilometers.

    - billn

    On Sat, 18 Sep 2004, Jorge Reyes wrote:

    > FastEthernet and Ethernet interfaces on a Cisco switch support the generic link up and down traps defined in SNMP MIB II. This sample output was captured on an ATM inverse multiplexing over an ATM (IMA) network module. It used the debug snmp packet command to view the contents of the traps.
    > 3640-1.1(config)# interface ATM 2/0
    > 3640-1.1(config-if)# no shutdown
    > 3640-1.1(config-if)#
    > *Mar 1 20:17:24.222: SNMP: Queuing packet to
    > *Mar 1 20:17:24.222: SNMP: V1 Trap, ent products.110,
    > addr, gentrap 3, spectrap 0
    > !--- The gentrap value "3" identifies the LinkUp generic trap.
    > ifEntry.1.1 = 1
    > ifEntry.2.1 = ATM2/0
    > ifEntry.3.1 = 18
    > lifEntry.20.1 = up
    > *Mar 1 20:17:24.290: SNMP: Queuing packet to
    > *Mar 1 20:17:24.290: SNMP: V1 Trap, ent ciscoSyslogMIB.2,
    > addr, gentrap 6, spectrap 1
    > clogHistoryEntry.2.49 = LINK
    > clogHistoryEntry.3.49 = 4
    > clogHistoryEntry.4.49 = UPDOWN
    > clogHistoryEntry.5.49 = Interface ATM2/0, changed state to up
    > clogHistoryEntry.6.49 = 7304420
    > Issue the show snmp command to confirm that the router sent a trap PDU.
    > 3640-1.1# show snmp
    > Chassis: 10526647
    > 55 SNMP packets input
    > 0 Bad SNMP version errors
    > 16 Unknown community name
    > 0 Illegal operation for community name supplied
    > 0 Encoding errors
    > 37 Number of requested variables
    > 0 Number of altered variables
    > 2 Get-request PDUs
    > 37 Get-next PDUs
    > 0 Set-request PDUs
    > 55 SNMP packets output
    > 0 Too big errors (Maximum packet size 1500)
    > 2 No such name errors
    > 0 Bad values errors
    > 0 General errors
    > 39 Response PDUs
    > 16 Trap PDUs
    > So you can configure your Linux Server to accept SNMP traps from the Cisco switch and page alert base on the trap value.
    > UP/DOWN that is
    > Jorge
    > -----Original Message-----
    > From: Zow" Terry Brugger []
    > Sent: Thu 9/16/2004 12:24 PM
    > To: Dave Torre
    > Cc:
    > Subject: Re: Network "Change Management"
    > Dave,
    > > Does anyone know of a Linux utility that can watch the MAC address
    > > tables in Cisco switches and alert admins as to when a new device has
    > > been plugged in?
    > I don't work with Cisco switches too much, however you may be able to
    > configure it to send an snmp alert to your Linux box when a new device is
    > plugged in. You'd then use snmp-util (or whatever it's called these days) to
    > handle the message on the Linux side.
    > Alternatively you can set up arpwatch on your Linux box and periodically ping
    > your whole range of IPs. Arpwatch will alert you when it sees new or changed
    > MAC addresses for those IPs.
    > > Basically, we have your standard client network with DHCP. Internet
    > > access is restricted to authenticated users, and so are the file shares.
    > > However, we've had a few instances where people just plug in their
    > > personal laptops which makes me very worried...
    > Okay, then a couple other things you might want to consider:
    > 1. If it is a managed switch, you should be able to configure it to only
    > allow MACs on a given list, hence preventing new boxes from even getting a
    > layer 2 connection.
    > 2. Set up the dhcp server to only allocate IPs to certain MAC addresses.
    > 3. You should be able to get dhcpd to report to you when it allocates to a
    > previously unseen MAC address (probably by throwing together some scripts to
    > parse the log messages and comparing the MACs in them to a list).
    > Of course, all of the above are assuming that someone isn't spoofing their
    > MAC address to one that you allow on your network. Typically someone has to
    > be deliberately malicious to do that though, so the above strategies
    > (especially blocking based on MAC) are good for stopping people from
    > connecting up their personal laptop and infecting the network with the worm
    > du jure. The best prevention against MAC spoofing is to trust your users.
    > Hope this helps,
    > Terry

  • Next message: Evan Pierce: "RE: Network "Change Management""

    Relevant Pages

    • Re: sending snmp traps from z/OS
      ... Pat is stating that the SNMP command may also be used for ... My experience with the SNMP command - from ... This is the SNMP support for NetView ... And it supports trap generation. ...
    • sending snmp traps from z/OS
      ... I have been trying to send a simple snmp trap from z/OS to another host for ... got some notion about SNMP agents and the needed configuration. ... snmp agent task only gives me the opportunity to RECEIVE TRAPS and not to ...
    • Re: sending snmp traps from z/OS
      ... I was beginning to warm to the idea that the traditional, V1, SNMP ... notifications to the SNMP agent just doesn't fit!!! ... correctly understanding the intended use of a trap or notify, ... An SNMP agent often include a definition of a target for SNMP traps. ...
    • Re: what program to send snmp traps?
      ... Generate a notification (trap) to report an event to the SNMP manager with ... If the -a flag is not specified, the default host is the local host. ... Message specifies the information the trap will hold. ...
    • Sun cluster 3.2 SNMP traps
      ... I'm using Sun Cluster 3.2_2.08 on sparc and am trying to get the snmp ... The default trap destination is port 11162, ... The cluster node is using the sma snmp daemon, ...