Need to find out Cisco switch serial number?

Yes, you can do it by logging in and running "show idprom backplane" or "show inventory". What if you have hundreds of switches and need to update your inventory list. Going to every switch, typing commands and writing down serial numbers is very time consuming. There is also Expect script, but I am not a big fan of putting clear text passwords into code. So, my favorite SNMP to the rescue.
Serial number OID for modular switches (4500 and 6500) is .1.3.6.1.2.1.47.1.1.1.1.11.1. For Catalyst 2960 and 3500: 1.3.6.1.2.1.47.1.1.1.1.11.1001

Here is the quick shell script to get serial number and location of each switch.

for i in `cat switches.txt`
do
serial=`snmpwalk -Ov -Oq -v2c -c public $i 1.3.6.1.2.1.47.1.1.1.1.11.1001`
location=`snmpwalk -Ov -Oq -v2c -c public $i system.sysLocation`
echo -e "$i \t $serial \t $location"
done

File switches.txt contains ip addresses of my access switches, one per line. It goes without saying that each switch must have "snmp-server location" configured.

JUNOS as a second language

Juniper was kind enough to post "JUNOS As A Second Language" e-learning course aimed at network administrators familiar with Cisco IOS. As somebody who works in production environment I could not help but notice how easy it is to revert changes in JUNOS with "commit confirmed" command.
Well, it turns out that IOS 12.4 has similar feature with "configure replace". From Cisco documentation:

Configuration Rollback Confirmed Change

The Configuration Rollback Confirmed Change feature enables an added criteria of a confirmation to configuration changes. This functionality enables a rollback to occur if a confirmation of the requested changes is not received in a configured time frame. Command failures can also be configured to trigger a configuration rollback.

The following steps outline how this process is achieved:

1. When entering configuration mode, this new option allows you to request confirmation (a confirmation time limit must be supplied) of the configuration changes.

2. After exiting configuration mode, you must enter the confirmation command. If no confirmation is entered within the requested time limit, the configuration will revert to its previous state.

configure replace target-url [nolock] [list] [force] [ignorecase] [revert trigger [error] [timer minutes] | time minutes]

It might come in handy next time when you change IP address on the wrong interface or make mistake in ACL.
Disclaimer: I strongly advise that you have console server with out-of-band access connected to all your critical production routers.

Last Error: PCALC:: No addresses to connect

Ever since I passed "Implementing Cisco MPLS" (642-611) exam, I've been aching to try my hands at MPLS TE. So, here is the task:

Click on image to see bigger version.

Since R2-R4 link is T3, OSPF will pick R2-R3-R5 path from R1 to either R6 or R7 leaving R2-R4-R5 link underutilized. At the same time I know that traffic from R1 to 10.0.0.0/24 is going to low enough to fit comfortably into T3 link. I wanted to create explicit path tunnel R1-R2-R4-R5-R7 with backup dynamic tunnel. I am going to skip configuration part - there are more then enough examples on the 'Net.
Let's see if tunnel is up

R1#sho mpls traffic-eng tunnels

Name: 6503sw2_t0 (Tunnel0) Destination: 192.168.1.4
Status:
Admin: up Oper: down Path: not valid Signalling: Down path option 1, type explicit mypath

Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled

History:
Tunnel:
Time since created: 20 hours, 1 minutes
Time since path change: 3 minutes, 24 seconds
Number of LSP IDs (Tun_Instances) used: 334
Prior LSP:
ID: path option 1 [309]
Removal Trigger: path option removed
Last Error: PCALC:: No addresses to connect 172.16.0.14 to 172.16.0.10

Not good. Searching for this type of error message gives one sage advise:

For cases involving an explicit path option, you can try to narrow down the problem by first checking every hop in the explicit hop list. You can also try to back down the tunnel: Move the tail one hop back each time to see if the tunnel comes up. If the tunnel comes up when you move the tail to a previous hop, you can conclude that there is a problem between that hop and the next hop, and you can start scrutinizing that hop carefully.

And so I did. Let's see how R2 and R5 see R4:

R2# show ip rsvp neighbor
Neighbor Encapsulation Time since msg rcvd/sent
172.16.0.18 Raw IP 00:02:12 00:02:10
172.16.0.21 Raw IP 00:02:10 00:02:23




R5#show ip rsvp neighbor
Neighbor Encapsulation Time since msg rcvd/sent
172.16.0.1 Raw IP 00:03:59 00:04:18
172.16.0.6 Raw IP 00:04:16 00:03:59

Hmm, they do not see R4 as RSVP neighbor at all. What's going on on R4?

R4# sho ip rsvp interface detail gi 0/0
Gi0/0:
Interface State: Up
Bandwidth:
Curr allocated: 0 bits/sec
Max. allowed (total): 30M bits/sec
Max. allowed (per flow): 30M bits/sec
Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
Set aside by policy (total): 0 bits/sec
Admission Control:
Header Compression methods supported:
rtp (36 bytes-saved), udp (20 bytes-saved)
Traffic Control:
RSVP Data Packet Classification is ON
Signalling:
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Number of missed refresh messages: 4
Refresh interval: 30
Authentication: disabled

How does it compare with R4-facing interface on R5?

R5#sho ip rsvp interface detail gi 0/2

Gi0/2:
RSVP: Enabled
Interface State: Up
Bandwidth:
Curr allocated: 0 bits/sec
Max. allowed (total): 40M bits/sec
Max. allowed (per flow): 40M bits/sec
Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
Set aside by policy (total): 0 bits/sec
Admission Control:
Header Compression methods supported:
rtp (36 bytes-saved), udp (20 bytes-saved)
Traffic Control:
RSVP Data Packet Classification is ON via CEF callbacks
Signalling:
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Authentication: disabled
Key chain:
Type: md5
Window size: 1
Challenge: disabled
Hello Extension:
State: Disabled

"RSVP: Enabled" string is missing in R4 command output. After some research I found that I need "T" type IOS to run RSVP-TE on R4 which is Cisco 3825.
Let's see what we have after the upgrade:

R4#sho ip rsvp interface detail gi 0/0

Gi0/0:
RSVP: Enabled
Interface State: Up
Bandwidth:
Curr allocated: 5M bits/sec
Max. allowed (total): 30M bits/sec
Max. allowed (per flow): 30M bits/sec
Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
Set aside by policy (total): 0 bits/sec
Admission Control:
Header Compression methods supported:
rtp (36 bytes-saved), udp (20 bytes-saved)
Traffic Control:
RSVP Data Packet Classification is ON
Signalling:
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Authentication: disabled
Key chain:
Type: md5
Window size: 1
Challenge: disabled
Hello Extension:
State: Disabled

and tunnel:

R1#sho mpls traffic-eng tunnels bri
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 3042 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 42 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
6503sw2_t0 192.168.1.4 - Gi2/1 up/up

Much better. Confirm routing

R1#sho ip route 10.0.0.0 255.255.255.0
Routing entry for 10.0.0.0/24
Known via "ospf 100", distance 110, metric 14, type intra area
Last update from 192.168.1.4 on Tunnel0, 19:41:13 ago
Routing Descriptor Blocks:
* 192.168.1.4, from 192.168.1.4, 19:41:13 ago, via Tunnel0
Route metric is 14, traffic share count is 1

Now, since MPLS TE tunnel is unidirectional, I need to create R7-R5-R4-R2-R1 tunnel as well.

CCIP accomplished

Yesterday I passed "Implementing Cisco MPLS" (642-611) exam. That was last one for me to complete CCIP certification process. I want to share my "CCIP reading list":

Routing TCP/IP, Volume 1 (2nd Edition)(CCIE Professional Development)






Routing TCP/IP, Volume II (CCIE Professional Development)








BGP Design and Implementation






Cisco QOS Exam Certification Guide (IP Telephony Self-Study) (2nd Edition)






MPLS Fundamentals







The list is not exclusive. In addition to that I used Cisco's command reference guide and IOS documentation on Cisco's website and built small lab to practice. I also tried using exam simulators like RealExams, a.k.a. Pass4Sure, a.k.a. TestKing. Actually, I am not sure if it is the same company or they steal from each other, but simulators' content is almost identical and I found all of them to be waste of money - ridden with errors and outdated. For 642-611 exam, I tried Bosons Software simulator. This one was of much better quality, but turned out to be too easy to be a good help for MPLS exam preparation. Even if you manage to achieve 80-90% accuracy in this simulator, your real exam score won't be high enough to pass.

2 more Netscreen's OIDs

1.3.6.1.4.1.3224.4.1.1.1.27.X shows what Netscreen thinks latency (in ms) is through IPSec tunnel number X. See my old post on how to find tunnel number.

Here is another one. How much data was transferred via policy number Y.

1.3.6.1.4.1.3224.10.2.1.6.Y.0
Beware, it reports in Bytes/sec. In order to make it work, you'll have to configure policy with "count" option.

3 down, 1 more to go

Yesterday I passed "Implementing Cisco QoS" exam 642-642. I need to pass 642-611 "Implementing Cisco MPLS" to complete CCIP certification.

Tracking routing entries on Cisco7600 via SNMP

I have Cisco7604 with SUP720 running c7600rsp72043-ipservicesk9-mz.122-33.SRD.bin. Cisco's SNMP object navigator claims that this image supports RFC1213-MIB which has ipRouteTable. In reality here is what I got

~$ snmpwalk -v2c -c public [myrouter] ipRouteDest
RFC1213-MIB::ipRouteDest = No Such Object available on this agent at this OID

After "Asking" around, I found RFC2096, that states:

The ipForwardTable updates the RFC 1213 ipRouteTable to display multipath IP Routes. This is in turn obsoleted by the ipCidrRouteTable.

The ipCidrRouteTable updates the RFC 1213 ipRouteTable to display multipath IP Routes having the same network number but differing network masks.


ipCidrRouteTable is actually supported by my IOS image, even though Cisco's SNMP object navigator declares it "depricated" and recommends using inetCidrRouteTable (1.3.6.1.2.1.4.24.7)

~$ snmpwalk -v2c -c public [myrouter] inetCidrRouteTable
IP-FORWARD-MIB::inetCidrRouteTable = No Such Object available on this agent at this OID


No luck again, but ipCidrRouteTable (numeric 1.3.6.1.2.1.4.24.4) works just fine.

Here is the list of the objects in ipCidrRouteTable
ipCidrRouteTable 1.3.6.1.2.1.4.24.4
ipCidrRouteEntry 1.3.6.1.2.1.4.24.4.1
ipCidrRouteDest 1.3.6.1.2.1.4.24.4.1.1
ipCidrRouteNextHopAS 1.3.6.1.2.1.4.24.4.1.10
ipCidrRouteMetric1 1.3.6.1.2.1.4.24.4.1.11
ipCidrRouteMetric2 1.3.6.1.2.1.4.24.4.1.12
ipCidrRouteMetric3 1.3.6.1.2.1.4.24.4.1.13
ipCidrRouteMetric4 1.3.6.1.2.1.4.24.4.1.14
ipCidrRouteMetric5 1.3.6.1.2.1.4.24.4.1.15
ipCidrRouteStatus 1.3.6.1.2.1.4.24.4.1.16
ipCidrRouteMask 1.3.6.1.2.1.4.24.4.1.2
ipCidrRouteTos 1.3.6.1.2.1.4.24.4.1.3
ipCidrRouteNextHop 1.3.6.1.2.1.4.24.4.1.4
ipCidrRouteIfIndex 1.3.6.1.2.1.4.24.4.1.5
ipCidrRouteType 1.3.6.1.2.1.4.24.4.1.6
ipCidrRouteProto 1.3.6.1.2.1.4.24.4.1.7
ipCidrRouteAge 1.3.6.1.2.1.4.24.4.1.8
ipCidrRouteInfo 1.3.6.1.2.1.4.24.4.1.9

If you run BGP and accept all routes from the internet, it might be useful to watch the size of your routing table. ipCidrRouteNumber (1.3.6.1.2.1.4.24.3)does just that. If you want to graph it in Cacti use 1.3.6.1.2.1.4.24.3.0 For some reason Cacti needs .0 in the end

I worked in environment like this once.

This is what I call really bad cabling.

©AP Photo/Bela Szandelszky

Connect F5 LTM/GTM to Perle IOLAN console server

I personally prefer Cyclades (now part of Avocent) console servers since they run Linux and I can use vi to edit configuration files. The only problem is that Cyclade's console servers come with only one Ethernet port. What if a switch to which Cyclade console server is connected via Ethernet dies and you need to access its console to figure out what is going on? You can always hook up modem to you console server and dial in, but in this case only one person can connect and with proliferation of VoIP analog phone lines in offices are getting hard to come by.
So, after some search I found Perle's IOLAN console server which have 2 Ethernet ports. These ports can be used in Active/Standby configuration, meaning you can assign 1 IP address and when 1st Ethernet port goes down, IOLAN moves this IP address automatically to second port. For this feature alone I am willing to tolerate their Windows configuration client software.

Now I need to connect IOLAN to F5 LTM/GTM console. Since LTM's console is DB9 male connector and IOLAN is RJ45, I need RJ45-DB9 female converter. I buy these converters at pccables.com. The wires in that converter on RJ45 side are connected like this:
1 Blue
2 Orange
3 Black
4 Red
5 Green
6 Yellow
7 Brown
8 White

I need to plug those wires into DB9 side of the converter like this
RJ45 DB9
Blue 6
Orange 8
Black 4
Red 2
Green 3
Yellow 5
Brown 7
White 1

Now, take regular straight network cable, plug one end into RJ45-DB9 converter, another into IOLAN port. Done. Do not forget that by default IOLAN's port speed is 9600 and F5's is 19200.

Packetization Layer Path MTU Discovery

A lot of network administrators block all ICMP traffic on the network's edge. Although some ICMP packets can be used in DDoS, ICMP type 3 plays important role in Paht MTU discovery. If ICMP is completely blocked, sending side can not reliably determine MTU and that can lead to re-transmissions and slower data transfer. Sometimes, ICMP blocking network could be outside your control, so you can not change ACL or firewall rules. In this case Packetization Layer Path MTU Discovery can be used. It utilizes TCP for maximum packet size discovery (RFC4821). To enable PLPMTUD on Linux:
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing
or
in /etc/sysctl.conf net.ipv4.tcp_mtu_probing = 2

Exam 642-901

I just passed Cisco's 642-901 exam - Building Scalable Cisco Internetworks. What interesting, though, is that I scored higher for OSPF than for BGP and EIGRP sections of the exam, even though I work with BGP and EIGRP every day. I guess I got overconfident in what I thought I knew. On the other hand, I knew my weak OSPF spots and payed more attention.

Etherchannel notes

If you initially issue the channel-group command under the physical interface, it automatically creates the port-channel interface. If you configured the port-channel interface before you channeled physical interfaces, remove the port-channel interface first. This is only relevant on Catalyst switches. The order of configuration changes on the 7500 router. You must configure the port-channel interface before you configure the channel group under the physical interface.

The order of configuration of a port channel in Catalyst 6500/6000 and 4500/4000 Cisco IOS Software is important. It is best to issue any switchport command before you issue the channel-group command in a physical interface.

When you issue the channel-group command prior to the switchport command on a physical interface (interface Gigabit Ethernet 1/1), the port-channel interface is created automatically and becomes a L3 interface. If you then issue the switchport command under the physical interface, the physical interface becomes a L2 interface. Also, the port-channel interface that you created earlier has no physical interface associated with it. Notice that the channel-group command is absent from under the physical interface. In this case, you must first issue the switchport command under the newly configured port-channel interface. Then, the physical port accepts the channel-group command again. In this case, the port channel has changed from a L3 interface to a L2 interface.

Consider, in contrast, if you issue the switchport command first on a physical interface and then add the channel-group command. In this case, the port-channel interface is automatically created and inherits all the configured switchport commands.

On a Catalyst 6500/6000 switch running Cisco IOS Software, all ports are L3 ports by default. On a Catalyst 4500/4000 switch running Cisco IOS Software, all ports are L2 ports by default.

SUP720-3C TCAM exeption

If you are running BGP on Catalyst 6500 or 7600 with SUP 72-3C and receiving full routing table from a peer, sooner rather than later you'll get this message
%CFIB-SP-7-CFIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched
Meaning that your router's performance will be degraded, since some of the traffic processed by CPU as opposed to hardware. The only way to get out of this state is to reboot the router. Here is how to check whether your router is in exception state:

cisco-7600#show mls cef exception status
Current IPv4 FIB exception state = TRUE
Current IPv6 FIB exception state = FALSE
Current MPLS FIB exception state = FALSE

If you are not running IPv6 or MPLS you can postpone inevitable upgrade to 720-3CXL by allocating entire TCAM memory to IPv4 routes
cisco-7600#mls cef maximum-routes ip 239
reboot

To see TCAM utilization
cisco-7600##show platform hardware capacity | begin L3 Forwarding Resources
L3 Forwarding Resources
FIB TCAM usage: Total Used %Used
72 bits (IPv4, MPLS, EoM) 196608 184013 94%
144 bits (IP mcast, IPv6) 32768 3 1%


.....skipping the rest

RANCID and Netscreen firewall

I installed RANCID 2.3.1 and encountered a problem which, as far as I know, happens in previous versions of RANCID as well. It does not work with Juniper Netscreen firewalls. The error message is
Missing right curly or square bracket at
/usr/local/libexec/rancid//nrancid line 302, at end of line
syntax error at /usr/local/libexec/rancid//nrancid line 302, at EOF

Here is how I fixed it.

1.fix bin/nlogin

find following section and comment it out (it starts on line 488 in my case)

if { $enable } {
if {[do_enable $enauser $enapasswd]} {
if { $do_command || $do_script } {
close; wait
continue
}
}
}

after you are done it should look like this

#    if { $enable } {
#       if {[do_enable $enauser $enapasswd]} {
#           if { $do_command || $do_script } {
#               close; wait
#               continue
#           }
#       }
#    }

2. fix bin/nrancid
find section (around line 200)

"!set admin user $1 password  privilege $3\n"); 
next;
ProcessHistory("","","","$_");

and make it look like this

"!set admin user $1 password  privilege $3\n"); 
next;
}
ProcessHistory("","","","$_");

i.e. put curly bracket "}" (no quotes) after line "next". In my case curly bracket goes on line 200.

3. enjoy

Cisco Cat6500 copy configuration over SNMP

Cisco has a way to copy configuration to/from TFTP server using SNMP commands. I tried to follow Cisco's documentaion, but it did not work. Here is the right way:

~$ snmpset -v2c -c secret cr2 1.3.6.1.4.1.9.9.96.1.1.1.1.14.222 i 5
~$ snmpset -v2c -c secret cr2 1.3.6.1.4.1.9.9.96.1.1.1.1.2.222 i 1
~$ snmpset -v2c -c secret cr2 1.3.6.1.4.1.9.9.96.1.1.1.1.3.222 i 4
~$ snmpset -v2c -c secret cr2 1.3.6.1.4.1.9.9.96.1.1.1.1.4.222 i 1
~$ snmpset -v2c -c secret cr2 1.3.6.1.4.1.9.9.96.1.1.1.1.5.222 a 10.20.4.20
~$ snmpset -v2c -c secret cr2 1.3.6.1.4.1.9.9.96.1.1.1.1.6.222 s aaa
~$ snmpset -v2c -c secret cr2 1.3.6.1.4.1.9.9.96.1.1.1.1.14.222 i 1


Step 1.
-------------

In the tftpboot directory (or the directory of the tftp server) create a new empty text
file and name it config.txt. Make sure everybody can read and write to the file, i.e. "chmod 666 config.txt".


Command Syntax:
snmpset -v 2c -c <> <> <> <> <>

Step 2.
-------------

First snmpset we need to make is to create a new ROW in the device within the ccCopyTable
Mib, where all the values are going to be stored in order to gather the device running configuration.
Please check ccCopyEntryRowStatus MIB

snmpset -v2c -c <> <> 1.3.6.1.4.1.9.9.96.1.1.1.1.14.222 i 5

NOTE: var_type is ?i? for Interger

Value 5 is for createAndWait

The number.222 is the entry index in the table. If the row is occupied then destroy it first and try to create it again.

Step 3.
-------------

We are going to use TFTP to transfer the device configuration with the OID ccCopyProtocol.

Check ccCopyProtocol MIB for details

snmpset -v2c -c <> <> 1.3.6.1.4.1.9.9.96.1.1.1.1.2.222 i 1

NOTE: Value is 1 for tftp

Step 4.
-------------

We want to copy running configuration.

Please look into MIB ccCopySourceFileType

snmpset -v2c -c <> <> 1.3.6.1.4.1.9.9.96.1.1.1.1.3.222 i 4

NOTE: Value is 4 for runningConfig
NOTE: Value is 3 for StartupConfig

Apparently, there is an error in the documentation.

Step 5.
-------------

Once we have specified the Source, we need to specify destination
ccCopyDestFileType MIB

snmpset -v2c -c <> <> 1.3.6.1.4.1.9.9.96.1.1.1.1.4.222 i 1

NOTE: Value is 1 for networkFile

Step 6.
-------------
TFTP's server IP address is important part of the destination.

Check ccCopyServerAddress MIB for additional details

snmpset -v2c -c <> <> 1.3.6.1.4.1.9.9.96.1.1.1.1.5.222 a < Server's IP>

NOTE: var_type is "a" for IP address

Value is the TFTP server's IP address

Step 7.
-------------
Now, we need to tell the name of the file where the data is going to be sent to or stored.

Please look into MIB ccCopyFileName

snmpset -v2c -c <> <> 1.3.6.1.4.1.9.9.96.1.1.1.1.6.222 s config.txt

NOTE: var_type is "s" for Display String

Value is the file name in the TFTPboot previously created with full privileges

Step 8.
-------------
Now we activate row 222 with the following command.

Details are in ccCopyEntryRowStatus MIB

snmpset -v2c -c <> <> 1.3.6.1.4.1.9.9.96.1.1.1.1.14.222 i 1

NOTE: Value is 1 for active.

Update: There is perl module to do the same thing.

CISCO-STACK-MIB

"tftpHost" "1.3.6.1.4.1.9.5.1.5.1"
"tftpFile" "1.3.6.1.4.1.9.5.1.5.2"
"tftpModule" "1.3.6.1.4.1.9.5.1.5.3"
"tftpAction" "1.3.6.1.4.1.9.5.1.5.4"
"tftpResult" "1.3.6.1.4.1.9.5.1.5.5"

tftpHost DESCRIPTION "Name of source/destination host for the TFTP
transfer or storage device transfer. If the name
is for the TFTP transfer, it can be the IP
address or the host name. If the name for the
storage device transfer, it will be in the format
of deviceName: (e.g. slot0:, slot1:)."


tftpFile DESCRIPTION "Name of file for the TFTP transfer or for storage device transfer."

tftpModule DESCRIPTION "Which module's code/configuration is being transferred."

tftpAction DESCRIPTION "Setting this object to one of the acceptable values initiates the requested action using the information given in tftpHost, tftpFile,

downloadConfig(2): receive configuration from host/file
uploadConfig(3) : send configuration to host/file
downloadSw(4) : receive software image from host/file
uploadSw(5) : send software image to host/file
downloadFw(6) : receive firmware image from host/file
uploadFw(7) : send firmware image to host/file
Setting this object to any other value results in an error."

tftpResult OBJECT-TYPE
SYNTAX INTEGER {
inProgress(1),
success(2),
noResponse(3),
tooManyRetries(4),
noBuffers(5),
noProcesses(6),
badChecksum(7),
badLength(8),
badFlash(9),
serverError(10),
userCanceled(11),
wrongCode(12),
fileNotFound(13),
invalidTftpHost(14),
invalidTftpModule(15),
accessViolation(16),
unknownStatus(17),
invalidStorageDevice(18),
insufficientSpaceOnStorageDevice(19),
insufficientDramSize(20),
incompatibleImage(21)
}

MAX-ACCESS read-only
DESCRIPTION "Contains result of the last tftp action request."

How to generate SYN-flood, linux style

Warning: malicious use of SYN-flood is punishable by law.
I needed to check SYN-Defense (TM) feature of Foundry's SI450. In order to do so I had to generate SYN-flood some how. It can be done with hping

hping --faster -S <dst. host>

The problem is that when SI replies with SYN/ACK packet back to my server, it sends RST in response, hping is not expecting any replies back. And ServerIron terminates the session immediately not letting SYN-Defense feature to kick-in. I had to block outgoing packets with RST flag set and destined to the dst. host above. Iptables to the rescue:

iptables -A OUTPUT -p tcp -d <dst. host> -m tcp --tcp-flags SYN,ACK,FIN,RST RST -j DROP

Enjoy

Centralized TACACS+ management

I've got TACACS+ servers running in every location where I have network equipment. That's fine, until I have to add a user or change password. Then I have to log into every server, edit tacacs.conf file and restart tacacs daemon. Here is what I've done.
1. Install Open LDAP server in every location.

2. Configure replication:

In master LDAP server's slapd.conf:

replica         uri=ldap://10.10.10.2:389
                binddn="cn=admin,dc=example,dc=com"
                bindmethod=simple credentials=SecretPassword

for every replica

in replca LDAP server's slapd.conf:

updatedn       "cn=admin,dc=example,dc=com"
updateref      ldap://10.10.10.1

Note, that updatedn must match binddn and must have read/write access to LDAP database. See Open LDAP documentation for details.

3. Compile TACACS+ with LDAP support. If you run Debian, simply run "apt-get install tac-plus". It's already compiled with LDAP support.

in tacacs.conf file put

default authentication = ldap "ldap://localhost:389/dc=example,dc=com"

and restart tacacs.
replace "dc=example,dc=com" with your BaseDN

You can use phpLDAPadmin to manage master LDAP server.
Now, if I want to add new user or change my password, I do it on master LDAP server.

For enable password create user $enab15$ in LDAP server. Beware, LDIF format treats dollar sign as line separator.

Find a device on Cisco switch

I have a few dozens of Cisco switches running CatOS and IOS and from time to time I need to find the port on the switch where particular network device is connected to. Sometimes I know the MAC address and sometimes I know IP address only. Logging into every switch and running "show cam" or "show mac-address-table" is time consuming, but all my switches have SNMP on. I wrote a script which polls list of switches to find the device either by MAC or IP address.

get_mac_port.pl ([-m <mac-address>]| [-i <ip address> -r <router>]) -f <file> -c <community> [-hV]
Where:
<file> - list of switches (IP or names) in a text file, one per line.
<mac-address> - MAC address of the host. It should be in form of aa:23:cc:dd:ee:ff or aabb.ccdd.eeff
Both lower and upper case letters accepted.
<ip address> - IP address of the host.
<router> - IP address or name of the default gateway for the host's network. This is the best source to get host's MAC address from.
<community> - SNMP community string.

Known problem: If switches are interconnected via trunks, the script will report the device as connected to a trunk port.
Download

More Netscreen's OID

netscreen to get name of VPN tunnels
[mrtg@monitor1 etc]$ snmpwalk -v2c -c public 10.44.222.248 1.3.6.1.4.1.3224.4.1.1.1.4
SNMPv2-SMI::enterprises.3224.4.1.1.1.4.0 = STRING: "MCI-PSN"
SNMPv2-SMI::enterprises.3224.4.1.1.1.4.1 = STRING: "MCI-EVL"
SNMPv2-SMI::enterprises.3224.4.1.1.1.4.2 = STRING: "MCI-NAT"
SNMPv2-SMI::enterprises.3224.4.1.1.1.4.3 = STRING: "ten43-ten48"
SNMPv2-SMI::enterprises.3224.4.1.1.1.4.4 = STRING: "MCI-DUB"
SNMPv2-SMI::enterprises.3224.4.1.1.1.4.5 = STRING: "MCI-EWR"
SNMPv2-SMI::enterprises.3224.4.1.1.1.4.6 = STRING: "MCI-CN"
SNMPv2-SMI::enterprises.3224.4.1.1.1.4.7 = STRING: "MCI-CITY"
SNMPv2-SMI::enterprises.3224.4.1.1.1.4.8 = STRING: "MCI-AN"
SNMPv2-SMI::enterprises.3224.4.1.1.1.4.9 = STRING: "MCI-Village"

netscreen to get remote VPN tunnel destination
[mrtg@monitor1 etc]$ snmpwalk -v2c -c public 10.44.222.248 1.3.6.1.4.1.3224.4.1.1.1.13
SNMPv2-SMI::enterprises.3224.4.1.1.1.13.0 = IpAddress: 10.1.1.2
SNMPv2-SMI::enterprises.3224.4.1.1.1.13.1 = IpAddress: 10.5.5.254
SNMPv2-SMI::enterprises.3224.4.1.1.1.13.2 = IpAddress: z.z.z.125
SNMPv2-SMI::enterprises.3224.4.1.1.1.13.3 = IpAddress: r.r.r.173
SNMPv2-SMI::enterprises.3224.4.1.1.1.13.4 = IpAddress: t.t.t.193
SNMPv2-SMI::enterprises.3224.4.1.1.1.13.5 = IpAddress: u.u.u.5
SNMPv2-SMI::enterprises.3224.4.1.1.1.13.6 = IpAddress: f.f.f.98
SNMPv2-SMI::enterprises.3224.4.1.1.1.13.7 = IpAddress: q.q.q.2
SNMPv2-SMI::enterprises.3224.4.1.1.1.13.8 = IpAddress: c.c.c.5
SNMPv2-SMI::enterprises.3224.4.1.1.1.13.9 = IpAddress: 10.11.11.66

netscreen to get VPN tunnle inbytes counter
[mrtg@monitor1 etc]$ snmpwalk -v2c -c public 10.44.222.248 1.3.6.1.4.1.3224.4.1.1.1.35
SNMPv2-SMI::enterprises.3224.4.1.1.1.35.0 = Counter32: 3574013013
SNMPv2-SMI::enterprises.3224.4.1.1.1.35.1 = Counter32: 3615791047
SNMPv2-SMI::enterprises.3224.4.1.1.1.35.2 = Counter32: 12630018
SNMPv2-SMI::enterprises.3224.4.1.1.1.35.3 = Counter32: 67249688
SNMPv2-SMI::enterprises.3224.4.1.1.1.35.4 = Counter32: 337567075
SNMPv2-SMI::enterprises.3224.4.1.1.1.35.5 = Counter32: 3816042333
SNMPv2-SMI::enterprises.3224.4.1.1.1.35.6 = Counter32: 108651803
SNMPv2-SMI::enterprises.3224.4.1.1.1.35.7 = Counter32: 68491303
SNMPv2-SMI::enterprises.3224.4.1.1.1.35.8 = Counter32: 67229052
SNMPv2-SMI::enterprises.3224.4.1.1.1.35.9 = Counter32: 208267531

netscreen to get VPN tunnel outbytes counter
[mrtg@monitor1 etc]$ snmpwalk -v2c -c public 10.44.222.248 1.3.6.1.4.1.3224.4.1.1.1.36
SNMPv2-SMI::enterprises.3224.4.1.1.1.36.0 = Counter32: 4198953760
SNMPv2-SMI::enterprises.3224.4.1.1.1.36.1 = Counter32: 566033608
SNMPv2-SMI::enterprises.3224.4.1.1.1.36.2 = Counter32: 2140626864
SNMPv2-SMI::enterprises.3224.4.1.1.1.36.3 = Counter32: 159163576
SNMPv2-SMI::enterprises.3224.4.1.1.1.36.4 = Counter32: 2146079992
SNMPv2-SMI::enterprises.3224.4.1.1.1.36.5 = Counter32: 855445376
SNMPv2-SMI::enterprises.3224.4.1.1.1.36.6 = Counter32: 682270400
SNMPv2-SMI::enterprises.3224.4.1.1.1.36.7 = Counter32: 205882792
SNMPv2-SMI::enterprises.3224.4.1.1.1.36.8 = Counter32: 159275584
SNMPv2-SMI::enterprises.3224.4.1.1.1.36.9 = Counter32: 2795282320

In input/output packet counters OIDs last number corresponds to last number in VPN tunnel destination and name OIDs. So, MRTG config for input/output traffic through VPN tunnel "MCI-CITY" will look like this

Target[fw]: 1.3.6.1.4.1.3224.4.1.1.1.35.7&1.3.6.1.4.1.3224.4.1.1.1.36.7:public@10.44.222.248:::::2

Tunnel status OID 1.3.6.1.4.1.3224.4.1.1.1.20