*NIX as a second language

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.

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

Labels: BGP, Hacks-n-tricks

I installed RANCID 2.3.1 and as far as I know it happens in previous versions of RANCID as well. It does not work with 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

Labels: Hacks-n-tricks

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?. Give it full privileges.


Command Syntax:
snmpset -v 2c -c < RW_string> < device_name or IP> < OID> < var_type> < value>

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 look into MIB ccCopyEntryRowStatus

snmpset -v2c -c < RW_string> < device_name or IP> 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 is 5 for createAndWait

In the MIB the last .222 is the entry index in the table. If the row is occupied then
please destroy it first and try to create it and wait again.

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

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

Please look into MIB ccCopyProtocol

snmpset -v2c -c < RW_string> < device_name or IP> 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 are going to specify that what we want to copy is the running configuration.

Please look into MIB ccCopySourceFileType

snmpset -v2c -c < RW_string> < device_name or IP> 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 tell what would be the destination to where we are copying th
e file.
Please look into MIB ccCopyDestFileType

snmpset -v2c -c < RW_string> < device_name or IP> 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.
-------------
Let?s now setup the IP address of the server where the TFTP service is currently running and where the conf
iguration is going to get copied.

Please look into MIB ccCopyServerAddress

snmpset -v2c -c < RW_string> < device_name or IP> 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 < RW_string> < device_name or IP> 1.3.6.1.4.1.9.9.96.1.1.1.1.6.222 s config.tx
t

NOTE: var_type is ?s? for Display String

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

Step 8.
-------------
Last thing is deploying the settings so the config archive takes place. Before activating the row 222, we m
ust double-check that the TFTP service is up and running in the server.

Is the service running?
If yes, then activate the row with the following snmpset.

Please look into MIB ccCopyEntryRowStatus

snmpset -v2c -c < RW_string> < device_name or IP> 1.3.6.1.4.1.9.9.96.1.1.1.1.14.222 i 1

NOTE: Value is 1 for active.

Labels: Network management

Labels: Monitoring, Network management

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

Labels: Hacks-n-tricks

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.

Labels: Network management