From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

NMC DOiT Vol.2 Scenario 22 – SNMPv3 + Multicast Redundant RPs with MSDP + rcmd + rsh + memory free low-watermark + memory reserve critical

1,345 Words. Plan about 9 minute(s) to read this.

I frittered away the morning upgrading the blog site. Ah, well. It had to be done. I’ve been needing to upgrade from WordPress 2.2.2 to 2.3.2 for a while now, but when I did the upgrade, the old theme that I was using broke. So I’m using a new theme. But the new theme needed some tweaking to make it look like I wanted it to look. I think the look is mostly there now, after lots of poking at the CSS and HTML files that make up the theme. But with that behind me, I can finish up blogging NMC scenario 22.

  • There was a security task combined with a network management task that were both dealing with SNMPv3. SNMPv3, you may recall, is a more secure version of SNMP, with the option of encrypted authentication among other features.  In this lab, I was asked to create specific SNMP “views” (where you assign what part of the MIB tree is accessible), and then assign certain rights to users and groups who could access the views. Note that although I created a user called “administrator”, that user will not be seen in a “show run” because of the type of privileges he had.  In summary, you create SNMPv3 views, you assign groups access to the views, and then you assign users to the groups.  (Wow, I just had an MCSE flashback from almost 10 years ago…create users, users go into groups, groups get the permissions.  Remember that mantra, you old Microsofties?)  Read more about configuring SNMPv3.

    R1#show run | i snmp
    snmp-server user operator operatorgrp v3 access  51
    snmp-server group operatorgrp v3 noauth read doit
    snmp-server group administratorgrp v3 priv read doit write doit
    snmp-server view doit system included
    snmp-server view doit cisco included
    snmp-server view doit system.7 excluded

    R1#show snmp user

    User name: operator
    Engine ID: 800000090300000E83081270
    storage-type: nonvolatile        active access-list: 51
    Authentication Protocol: None
    Privacy Protocol: None
    Group-name: operatorgrp

    User name: administrator
    Engine ID: 800000090300000E83081270
    storage-type: nonvolatile        active access-list: 52
    Authentication Protocol: MD5
    Privacy Protocol: None
    Group-name: administratorgrp

    R1#show snmp group
    groupname: ILMI                             security model:v1
    readview : *ilmi                            writeview: *ilmi
    notifyview: <no notifyview specified>
    row status: active

    groupname: ILMI                             security model:v2c
    readview : *ilmi                            writeview: *ilmi
    notifyview: <no notifyview specified>
    row status: active

    groupname: operatorgrp                      security model:v3 noauth
    readview : doit                             writeview: <no writeview specified>
    notifyview: <no notifyview specified>
    row status: active

    groupname: administratorgrp                 security model:v3 priv
    readview : doit                             writeview: doit
    notifyview: <no notifyview specified>
    row status: active

    R1#

  • The multicast task was to deploy triple-redundant rendezvous points in a pure sparse-mode environment configuring redundant RPs via static assignment.  Configuring redundant RPs serves the obvious purpose of redundancy, but also serves a purpose of rudimentary load balancing.  When you build redundant RPs, you do it by assigning the same host address to loopback interfaces on multiple routers.  In other words, you’ll have more than one router with the same IP assigned to a loopback.  You advertise this loopback address via your routing protocol.  When multicast sources put traffic on the wire, the closest RP as determined by the unicast routing protocol metric will receive the traffic from the PIM DR on the source’s segment via encapsulated register messages, decapsulate the traffic, then forward traffic copies out all the sparse-mode interfaces that have expressed an interest in receiving the traffic.

    When you have redundant RPs on the network, it’s important that they keep track of one another.  MSDP is the protocol used for this, and MSDP is further used to let all the RPs in a multicast domain know about a new source that’s talking.  All RPs on the wire have the ability to relay that source traffic, assuming there are interested receivers.  Read more about configuring MSDP here.  In this example, the task instructs that routers R1, R3, and R4 were to have interfaces of 111.1.1.1 configured as redundant RPs on the sparse mode multicast domain.

    R1#show run
    ip multicast-routing
    !
    interface Loopback10
    ip address 111.1.1.1 255.255.255.255
    ip pim sparse-mode
    !
    interface Loopback101
    ip address 135.15.101.1 255.255.255.0
    ip pim sparse-mode
    !
    ip pim rp-address 111.1.1.1
    no ip pim dm-fallback
    !
    ip msdp peer 135.15.103.1 connect-source Loopback101
    ip msdp peer 135.15.104.1 connect-source Loopback101
    ip msdp originator-id Loopback101
    ip msdp mesh-group MYMESH 135.15.103.1
    ip msdp mesh-group MYMESH 135.15.104.1
    !

    R1#

    R3#show r
    ip multicast-routing
    !
    interface Loopback10
    ip address 111.1.1.1 255.255.255.255
    ip pim sparse-mode
    !
    interface Loopback103
    ip address 135.15.103.1 255.255.255.0
    ip pim sparse-mode
    !
    ip pim rp-address 111.1.1.1
    ip msdp peer 135.15.101.1 connect-source Loopback103
    ip msdp peer 135.15.104.1 connect-source Loopback103
    ip msdp originator-id Loopback103
    ip msdp mesh-group MYMESH 135.15.101.1
    ip msdp mesh-group MYMESH 135.15.104.1
    !

    R3#

    R4#show r
    ip multicast-routing
    !
    interface Loopback10
    ip address 111.1.1.1 255.255.255.255
    ip pim sparse-mode
    !
    interface Loopback104
    ip address 135.15.104.1 255.255.255.0
    ip pim sparse-mode
    !
    ip pim rp-address 111.1.1.1
    ip msdp peer 135.15.101.1 connect-source Loopback104
    ip msdp peer 135.15.103.1 connect-source Loopback104
    ip msdp originator-id Loopback104
    ip msdp mesh-group MYMESH 135.15.101.1
    ip msdp mesh-group MYMESH 135.15.103.1
    !

    R4#show ip msdp summary
    MSDP Peer Status Summary
    Peer Address     AS    State    Uptime/  Reset SA    Peer Name
    Downtime Count Count
    135.15.101.1     ?     Up       2d20h    0     0     ?
    135.15.103.1     ?     Up       2d20h    0     0     ?

    R4#

  • When we’re on a router and we want to see information on another router, we usually SSH or telnet over to the other router, login, do what we need to do, then logout, right?  What if all you wanted to do was execute one simple command?  There’s another way to do so, using rcmd and rsh commands.  In this example, user NMCADMIN on the R4 console should be able to get “show ver” and “show run” from R5.  User NMCOPERATOR should be able to get “show ver” only.  Note that the commands are in the “Configuration Fundamentals” section of the Doc CD.

    R5#show run | i rcmd
    ip rcmd rsh-enable
    ip rcmd remote-host
    NMCADMIN 135.15.20.4 R4 enable
    ip rcmd remote-host NMCOPERATOR 135.15.20.4 R4

    R5#

    R4#rsh 135.15.20.5 /user NMCOPERATOR show ver
    Cisco IOS Software, 3700 Software (C3745-ADVENTERPRISEK9-M), Version 12.4(16), RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2007 by Cisco Systems, Inc.
    Compiled Wed 20-Jun-07 13:52 by prod_rel_team

    ROM: System Bootstrap, Version 12.2(8r)T2, RELEASE SOFTWARE (fc1)

    R5 uptime is 5 days, 23 hours, 0 minutes
    System returned to ROM by reload
    System image file is “slot0:c3745-adventerprisek9-mz.124-16.bin”

    This product contains cryptographic features and is subject to United
    States and local country laws governing import, export, transfer and
    use. Delivery of Cisco cryptographic products does not imply
    third-party authority to import, export, distribute or use encryption.
    Importers, exporters, distributors and users are responsible for
    compliance with U.S. and local country laws. By using this product you
    agree to comply with applicable laws and regulations. If you are unable
    to comply with U.S. and local laws, return this product immediately.

    A summary of U.S. laws governing Cisco cryptographic products may be found at:
    http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

    If you require further assistance please contact us by sending email to
    export@cisco.com.

    Cisco 3745 (R7000) processor (revision 2.0) with 243712K/18432K bytes of memory.
    Processor board ID JMX0746L15U
    R7000 CPU at 350MHz, Implementation 39, Rev 3.3, 256KB L2, 2048KB L3 Cache
    2 FastEthernet interfaces
    16 Low-speed serial(sync/async) interfaces
    DRAM configuration is 64 bits wide with parity disabled.
    151K bytes of NVRAM.
    62720K bytes of ATA System CompactFlash (Read/Write)
    127104K bytes of ATA Slot0 CompactFlash (Read/Write)

    Configuration register is 0x2102

    R4#rsh 135.15.20.5 /user NMCOPERATOR show run

    Line has invalid autocommand “show run”

    R4#rsh 135.15.20.5 /user NMCADMIN show run

    Building configuration…

    Current configuration : 4907 bytes
    !
    version 12.4
    service timestamps debug datetime msec
    service timestamps log datetime msec
    no service password-encryption
    !
    hostname R5
    !
    boot-start-marker
    boot-end-marker
    !
    !
    no aaa new-model
    ip cef
    !
    !
    !
    !
    no ip domain lookup
    ip multicast-routing

    R4#

  • Last note from this scenario, there was a task instructing that the router should  send a notification when processor memory had fallen below a certain amount, and IO memory below a certain amount.  A follow-up task was to reserve a certain amount of memory so that critical functions such as event logging could continue, even if the router was otherwise out of memory.  These requirements can be met with the following commands:  memory free low-watermark and memory reserve criticalThese are both found in the IOS Configuration Fundamentals of the Doc CD.