These are some items that might need to be upgraded in addition to the IOS:

• CEF720 line card firmware
• SUP720 switch processor firmware
• MSFC3 route processor firmware
• Field Programmable Device firmware

Each of the above have their own firmware naming conventions and it can be difficult to find these files. Try to Google partial file names to locate the correct images on the Cisco site. Here are some tips for finding firmware:

1. The CEF720 line card firmware starts with c2lc-rm2. As of this writing, 12.2(18r)S1 is the current version and the current file name is c2lc-rm2.srec.122-18r-S1
2. The SUP720 firmware starts with c6ksup720. As of this writing, 8.5(4) is the current version and the current file name is c6ksup720-rm2-srec.8-5-4.srec.
3. The MSFC3 firmware starts with c6msfc, as of this writing 12.2(17r)SX7 is the current version and the current file name is c6msfc3-rm2-srec.122-17r.SX7.
4. The field programmable device firmware starts with c6500-fpd-pkg. As of this writing, 12.2(33)SXJ3 is the current version and the current file name is c6500-fpd-pkg.122-33.SXJ3.pkg
5. The IOS images for the 6500 series SUP720 firmware starts with s72033. As of this writing, 12.2(33)SXJ3 is the current version and the current file name is s72033-ipbase-mz.122-33.SXJ3, depending on your IOS license version

Field programmable devices start with SIP or SPA as part of the module name. You can verify if your chassis has a field programmable device by issuing the following command in the CLI:

show hw-module all fpd

The Line Card Upgrade

Always review the release notes, open caveats, and perform a bug scrape on the Cisco web site to determine if any of these upgrades will affect your production network, also verify that your line cards are supported with the new IOS and firmware versions.

First, copy all the necessary files to the flash on the switch, either to the disk0: or sup-bootflash: or bootflash: depending on what space is available in flash: and verify the md5 checksum of the IOS .bin images. (For purposes here, I copied the files to bootlfash:)

Second, backup of the config (use your current backup methodology).

Third, enter the “show module” look for CEF720 modules. As shown in the card type column, each of these CEF720 line cards will need to have their firmware upgraded. (If there are none listed, the line card firmware upgrade step can be skipped).

For each of these modules:

show rom-monitor slot x (where x is the module number from the show module output)

Router# show rom-monitor slot 4
   Region F1:APPROVED, preferred
   Region F2:INVALID Currently running ROMMON from F1 region
Router#

The output will display where the active ROMMON is running

For each of the CEF720 line cards we are going to enter the following command (where # is the slot number of the CEF720 Line Card, (4 is used in this example)

To upgrade the line card firmware, use the command upgrade rom-monitor slot # file bootflash:c2lc-rm2.srec.122-18r.S1

Router# upgrade rom-monitor slot 4 file bootflash:c2lc-rm2.srec.122-18r.S1
Copying bootflash:c2lc-rm2.srec.122-18r.S1 onto bootflash of dfc#4 CCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
Router#
19:40:08: DFC4: ROMMON image upgrade in progress
19:40:08: DFC4: Erasing flash
19:40:11: DFC4: Programming flash
19:40:13: DFC4: Verifying new image
19:40:13: DFC4: ROMMON image upgrade complete
 The card must be reset for this to take effect

If you are not seeing similar output, check your log .i.e. show logging, it should be there.

Next, verify the firmware is ready to run.

Use the show rom-monitor slot 4 command to verify

Router# show rom-monitor slot 4
Region F1:APPROVED
Region F2:FIRST_RUN, preferred
Currently running ROMMON from F1 region
Router#

Reset the line card to have the new line card firmware take effect.

Use the following command to reset the line card
hw-module module 4 reset

Router# hw-module module 4 reset

Verify the new firmware is running with the command show rom-monitor slot 4
 

Router# show rom-monitor slot 4
   Region F1:APPROVED
   Region F2:APPROVED, preferred
   Currently running ROMMON from F2 region
Router#

Verify the line card is running the new firmware with the show module command

 show module

Perform this action for each of your CEF720 line cards.

The SUP720 Switch Processor Firmware

Once confirmed we can move on to the SUP720 firmware, which is a similar process (where X is the slot your SUP720 is in, (for this example Slot 5)

We use a slightly modified version on the same command show rom-monitor slot X sp

Router# show rom-monitor slot 5 sp
   Region F1:APPROVED, preferred
   Region F2:INVALID
   Currently running ROMMON from F1 region
Router#

The output will display where the active switch processor ROMMON is running

To upgrade the switch processor firmware we will use the command upgrade rom-monitor slot 5 sp file bootflash:c6ksup720-rm2-srec.8-5-4.srec

upgrade rom-monitor slot 5 sp file bootflash:c6ksup720-rm2-srec.8-5-4.srec
   ROMMON image upgrade in progress

   Erasing flash
   Programming flash
   Verifying new image
   ROMMON image upgrade complete
   The card must be reset for this to take effect

Again, if you are not seeing similar output, check your log .i.e. show logging

Verify the firmware is ready to run with the command show rom-monitor slot 5 sp

Router# show rom-monitor slot 5 sp
   Region F1:APPROVED
   Region F2:FIRST_RUN, preferred
   Currently running ROMMON from F1 region
Router#

Reload the switch

reload

When the system comes back up, verify the new firmware is running with the command show rom-monitor slot 5 sp

Router# show rom-monitor slot 5 sp
   Region F1:APPROVED
   Region F2:APPROVED, preferred
   Currently running ROMMON from F2 region 
Router#

show version

The SUP720 MSFC Firmware

Once confirmed we can move on to the SUP720 MSFC Firmware, again a similar process (where X is the slot your SUP720 is in (for this example Slot 5).

We use a slightly modified version on the same command show rom-monitor slot X rp

Router# show rom-monitor slot 5 rp
   Region F1:APPROVED, preferred
   Region F2:INVALID
   Currently running ROMMON from F1 region
Router#

The output will display where the active switch processor ROMMON is running

We use the following command to upgrade the Route Processor firmeware
upgrade rom-monitor slot 5 rp file bootflash:c6msfc3-rm2-srec.122-17r.SX7

Router# upgrade rom-monitor slot 5 rp file bootflash:c6msfc3-rm2-srec.122-17r.SX7
   ROMMON image upgrade in progress
   Erasing flash
   Programming flash
   Verifying new image
   ROMMON image upgrade complete
   The card must be reset for this to take effect

Verify the firmware is ready to run with the command show rom-monitor slot 5 rp

Router# show rom-monitor slot 5 rp
   Region F1:APPROVED
   Region F2:FIRST_RUN, preferred
   Currently running ROMMON from F1 region 
Router#

reload the switch

reload

When the system comes back up, verify the new ROMMON is running with the command show rom-monitor slot 5 rp

Router# show rom-monitor slot 5 rp
   Region F1:APPROVED
   Region F2:APPROVED, preferred
   Currently running ROMMON from F2 region 
Router#

 show version

The field programmable devices are probably the easiest, if your hardware requires it, copy the file to the same location as the IOS image, the IOS image is smart enough to look for the firmware upgrade and will load it if it finds it, via the location specified in the boot statement. (If the 6500 does not find this file, your modules may not power up). For this example I uploaded the file to Disk0: and copy the file to bootflash:.

Router# copy disk0:c6500-fpd-pkg.122-33.SXJ3.pkg bootflash: c6500-fpd-pkg.122-33.SXJ3.pkg

Before we reload the switch, we need to make sure the new IOS image is in the same location as stated above.

Router# copy disk0: s72033-ipbase-mz.122-33.SXJ3 bootflash:s72033-ipbase-mz.122-33.SXJ3

Remove the old boot statements (Your images and location may vary, depending on your configuration).

Router# Config term
Router# no boot system bootflash:s72033-ipbase-mz.122-33.SXJ1
Router# no boot system bootflash:s72033-ipbase-mz.122-33.SXH8

Add the new boot statements, preserving the previous known good IOS version,  in case fallback is needed

Router# boot system bootflash:s72033-ipbase-mz.122-33.SXJ3
Router# boot system bootflash:s72033-ipbase-mz.122-33.SXJ1

Reload the switch

Router# reload

When the system comes back up, verify the new IOS is running with the command show ver

Router# show ver

Run your post upgrade test to verify that all production is functioning as expected.

Note: If firmware has never been upgraded on the device, you may see different output when you perform the command show rom-monitor slot 4

router#show rom-monitor slot 4
Region F1: INVALID
Region F2: INVALID
Currently running ROMMON from S (Gold) region

Also, your initial upgrade may go into Region F1, rather than Region F2 as is described in this document

Running from the S (Gold region) simply means that the firmware is running from the embedded EEPROM chip in the CEF720 Card/SUP720/MSFC. This is normal.

Comments

A thread has been created on the site forum specifically for commenting on this blog post.

There are many products on the market that can backup Cisco device configurations and typically require the user to make a config file that defines each IP address of the device to backup. I manage a lab infrastructure that consists of an aggregate /17 network (consists of ~700 live hosts at any one time) and devices in the lab are constantly being removed/added. Trying to track individual IP addresses in this environment is difficult. The ability to execute automatic host discovery, and once a host is discovered backup the configuration. The aforementioned challenge has to be solved post-haste and I have a budget of $0 for new products. Here is my solution for automated host discovery and config backup.

Configurations are backed up by FTP after writing to the appropriate MIB objects. Networks are scanned by NMAP using ICMP (automatic host discovery). Hosts that reply to the ICMP request are a candidate for backup. Configuration backup will succeed provided that device is using SNMPv2c write access communities or SNMPv3 write access users. Script below uses SNMPv3 as an example. Script will create a directory (named by date) under the users home directory and the backup files will appear as the IP addresses of the device.

Platform Dependencies

1. NMAP
2. Perl
3. NET-SNMP
4. FTP Server
5. Crontab (optional)

Automated Flow Process

1. Populate the @NET array with networks to scan
2. Populate these 6 variables with your network credentials

$snmpuser="tmev3user";
$user = "ftpuser";
$pass = "ftppassword";
$auth = "tmev3user";
$priv = "tmev3user";
$FTPSERVER="192.168.0.125";

3. Launch the script manually or add to crontab for automated backup

#!/usr/bin/perl

system(clear);
$date = `date +%b_%d_%Y`;
$date =~ s/\n//g;
$home = $ENV{HOME};
$dirname = "$home/$date";
$dir = `mkdir $dirname`;
print "\n nmap scanning networks ....\n";
@NET = qw(192.168.0.0/24);
  foreach $NET (@NET) {
  @IPP = `nmap -sP $NET`;

    foreach $IP (@IPP) {
      if ($IP =~ /Host (\d+\.\d+\.\d+\.\d+) is up .*/){
      push(@IP , "$1\n");
      } elsif ($IP =~ /^Nmap scan report for (\d+\.\d+\.\d+\.\d+)/) {
      $address = $1;
      push(@IP , "$address\n");
      }
    }
}
print "Host Candidates for backup:
@IP";
open(STDERR , ">> /dev/null");
print "\n\n
----------------------------------------------------------------
Backup on $date
----------------------------------------------------------------\n\n";
foreach $IP (@IP) {
$IP =~ s/\n//;
print "\nSNMP info for $IP\n";
$snmpuser="tmev3user";
$user = "ftpuser";
$pass = "ftppassword";
$auth = "tmev3user";
$priv = "tmev3user";
$FTPSERVER="192.168.0.125";
$FILENAME="$date/$IP";
$RND="10";

system("snmpset -M /dev/null -v3 -u $snmpuser -l authPriv -a md5 -A $auth -x AES -X $priv $IP 1.3.6.1.4.1.9.9.96.1.1.1.1.2.$RND i 2 1.3.6.1.4.1.9.9.96.1.1.1.1.3.$RND i 4 1.3.6.1.4.1.9.9.96.1.1.1.1.7.$RND s $user 1.3.6.1.4.1.9.9.96.1.1.1.1.8.$RND s $pass 1.3.6.1.4.1.9.9.96.1.1.1.1.4.$RND i 1 1.3.6.1.4.1.9.9.96.1.1.1.1.5.$RND a $FTPSERVER 1.3.6.1.4.1.9.9.96.1.1.1.1.6.$RND s $FILENAME 1.3.6.1.4.1.9.9.96.1.1.1.1.14.$RND i 4");
sleep 5;
system("snmpget -M /dev/null -On -v3 -u $snmpuser -l authPriv -a md5 -A $auth -x AES -X $priv $IP 1.3.6.1.4.1.9.9.96.1.1.1.1.10.$RND");
sleep 5;
system("snmpset -M /dev/null -On -v3 -u $snmpuser -l authPriv -a md5 -A $auth -x AES -X $priv $IP 1.3.6.1.4.1.9.9.96.1.1.1.1.14.$RND i 6");
}

SNMPv3 Example for Cisco IOS Devices

snmp-server user tmev3user WriteTest v3 auth md5 tmev3user priv aes 128 tmev3user
snmp-server group WriteTest v3 auth read ViewTest write WriteTest
snmp-server view ViewTest iso included
snmp-server view WriteTest iso included

Example

1. Populate @NET array and 6 variables for your network
2. Launch script

$ ./backupv3.pl 
 nmap scanning networks ....
Host Candidates for backup:
192.168.0.1
 192.168.0.250
 192.168.0.251

----------------------------------------------------------------
Backup on Sep_10_2012
----------------------------------------------------------------


SNMP info for 192.168.0.1
iso.3.6.1.4.1.9.9.96.1.1.1.1.2.10 = INTEGER: 2
iso.3.6.1.4.1.9.9.96.1.1.1.1.3.10 = INTEGER: 4
iso.3.6.1.4.1.9.9.96.1.1.1.1.7.10 = STRING: "ftpuser"
iso.3.6.1.4.1.9.9.96.1.1.1.1.8.10 = STRING: "ftppassword"
iso.3.6.1.4.1.9.9.96.1.1.1.1.4.10 = INTEGER: 1
iso.3.6.1.4.1.9.9.96.1.1.1.1.5.10 = IpAddress: 192.168.0.125
iso.3.6.1.4.1.9.9.96.1.1.1.1.6.10 = STRING: "Sep_10_2012/192.168.0.1"
iso.3.6.1.4.1.9.9.96.1.1.1.1.14.10 = INTEGER: 4
.1.3.6.1.4.1.9.9.96.1.1.1.1.10.10 = INTEGER: 3
.1.3.6.1.4.1.9.9.96.1.1.1.1.14.10 = INTEGER: 6

SNMP info for 192.168.0.250
iso.3.6.1.4.1.9.9.96.1.1.1.1.2.10 = INTEGER: 2
iso.3.6.1.4.1.9.9.96.1.1.1.1.3.10 = INTEGER: 4
iso.3.6.1.4.1.9.9.96.1.1.1.1.7.10 = STRING: "ftpuser"
iso.3.6.1.4.1.9.9.96.1.1.1.1.8.10 = STRING: "ftppassword"
iso.3.6.1.4.1.9.9.96.1.1.1.1.4.10 = INTEGER: 1
iso.3.6.1.4.1.9.9.96.1.1.1.1.5.10 = IpAddress: 192.168.0.125
iso.3.6.1.4.1.9.9.96.1.1.1.1.6.10 = STRING: "Sep_10_2012/192.168.0.250"
iso.3.6.1.4.1.9.9.96.1.1.1.1.14.10 = INTEGER: 4
.1.3.6.1.4.1.9.9.96.1.1.1.1.10.10 = INTEGER: 3
.1.3.6.1.4.1.9.9.96.1.1.1.1.14.10 = INTEGER: 6

SNMP info for 192.168.0.251
iso.3.6.1.4.1.9.9.96.1.1.1.1.2.10 = INTEGER: 2
iso.3.6.1.4.1.9.9.96.1.1.1.1.3.10 = INTEGER: 4
iso.3.6.1.4.1.9.9.96.1.1.1.1.7.10 = STRING: "ftpuser"
iso.3.6.1.4.1.9.9.96.1.1.1.1.8.10 = STRING: "ftppassword"
iso.3.6.1.4.1.9.9.96.1.1.1.1.4.10 = INTEGER: 1
iso.3.6.1.4.1.9.9.96.1.1.1.1.5.10 = IpAddress: 192.168.0.125
iso.3.6.1.4.1.9.9.96.1.1.1.1.6.10 = STRING: "Sep_10_2012/192.168.0.251"
iso.3.6.1.4.1.9.9.96.1.1.1.1.14.10 = INTEGER: 4
.1.3.6.1.4.1.9.9.96.1.1.1.1.10.10 = INTEGER: 3
.1.3.6.1.4.1.9.9.96.1.1.1.1.14.10 = INTEGER: 6

3. Verify configuration files are present

$ cd Sep_10_2012/
Sep_10_2012]$ ls -1
192.168.0.1
192.168.0.250
192.168.0.251

Comments

A thread has been created on the site forum specifically for commenting on this blog post.

This leaves us with an issue in that when your BGP peer becomes unreachable, because your local FastEthernet interface on the CE will still be up/up as it will probably be connected to some Layer 2 device, the customer network could suffer a complete outage for up to 3 minutes. The BGP default hold time is 180 seconds. For a customer that has been sold a 100M pipe with resilience this is not going to make them happy.

Here is the topology I am using for this example:

Gateways 1 & 2 have an iBGP neighborship over the f0/0 cross-link and provide a virtual default gateway using HSRP on the f0/1 LAN.

The LAN_HOST is not aware of routing and simply has a default route pointed to the HSRP address 192.168.1.1.

Gateway 1 is the primary router for inbound and outbound traffic. This is enforced using the following policies:

• Gateway 1 is the HSRP primary
• Gateway 1 has an inbound route map which sets the local preference to 150 for the prefix 198.77.64.40 witch is also the gateway of last resort as defined by a static route. This manipulates outbound traffic.
• Gateway 1 and Gateway 2 both have an outbound route map which sets the Med to 50 & 200 respectively. This manipulates inbound traffic.

Under normal conditions, the LAN can reach the Internet.

Here is an extended PING while PE1 experiences an outage.

That’s a long outage!

There are 2 problems:

• HSRP is monitoring the interface status and, even though PE1 went down, g1/0 on Gateway 1 didn’t.
• Because g1/0 didn’t go down, BGP didn’t shut the peering to PE1 down, instead it waited until the hold time expired. During this time, outbound/inbound traffic was being black holed.

Now let’s speed things up.

Using IP SLA & BGP Failover

On Gateway 1 create an IP SLA process which starts PINGing the eBGP peer 10.1.1.253 every 5 seconds.

Next create an object which tracks this process. Use number 2 because Object 1 is used on the HSRP interface tracker.

Next create a /32 static route to the peer using the peer itself as the next hop which uses the object status to validate itself. This will override the /30 connected route.

Next create a prefix list to match this route.

Then create a route-map which matches the prefix-list.

Finally add the following neighbor statement under the BGP process which uses the route-map and the BGP failover feature.

The output is truncated, the full command is:  “neighbor 10.1.1.253 fall-over route-map PEER_REACHABLE”

With this in effect, outage time is shorter because the eBGP peer on Gateway 1 is shut down immediately upon it being unreachable which will purge any stagnant routes in the routing table.

Another final touch is to switch over the HSRP primary to avoid sub optimal routing by tracking the same object we created for BGP Failover.

This at least removes a hop from our trace.

There is little more we can do on the customer’s network AS100 as the remaining failover delay exists on the service provider network AS200.

PE1 & PE2 peer using loopbacks learned via OSPF with the Next-Hop-Self option set. The default OSPF hold-time is 40 seconds on the broadcast segment over the 172.16.0.0/30 network. When OSPF dies, the BGP Next-hop becomes unreachable and the associated routes are removed long before the BGP peering times out.

Just for giggles, changing the OSPF Hello & dead intervals to 2 & 6 respectively results in the following improved failover time.

We could just avoid all this headache and reduce the BGP hold timers in the first place, but that would be no fun

I am open for constructive criticism from the senior forum members as to what better designs could be deployed in this scenario.

I hope you enjoyed reading and it has been beneficial for you.

For completeness, please see below the configs for both Gateways and PEs.

Gateway 1

track 2 rtr 1
!
!
!
!
interface FastEthernet0/0
ip address 192.168.255.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.1.253 255.255.255.0
duplex full
speed 100
standby 1 ip 192.168.1.1
standby 1 priority 105
standby 1 preempt
standby 1 track GigabitEthernet1/0
standby 1 track 2 decrement 10
!
interface GigabitEthernet1/0
ip address 10.1.1.254 255.255.255.252
negotiation auto
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 192.168.1.0
neighbor 10.1.1.253 remote-as 200
neighbor 10.1.1.253 fall-over route-map PEER_REACHABLE
neighbor 10.1.1.253 route-map INTERNET in
neighbor 10.1.1.253 route-map PRIMARY out
neighbor 192.168.255.2 remote-as 100
neighbor 192.168.255.2 next-hop-self
no auto-summary
!
ip forward-protocol nd
ip route 10.1.1.253 255.255.255.255 GigabitEthernet1/0 10.1.1.253 track 2
ip route 0.0.0.0 0.0.0.0 198.77.64.40
no ip http server
no ip http secure-server
!
!
!
!
ip prefix-list INTERNET seq 5 permit 198.77.64.40/32
!
ip prefix-list PEER_REACHABLE seq 5 permit 10.1.1.253/32
!
ip prefix-list PRIMARY seq 5 permit 192.168.1.0/24
ip sla 1
icmp-echo 10.1.1.253
frequency 5
ip sla schedule 1 life forever start-time now
logging alarm informational
!
!
!
route-map PEER_REACHABLE permit 10
match ip address prefix-list PEER_REACHABLE
!
route-map INTERNET permit 10
match ip address prefix-list INTERNET
set local-preference 150
!
route-map INTERNET permit 20
!
route-map PRIMARY permit 10
match ip address prefix-list PRIMARY
set metric 50
!
route-map PRIMARY permit 20

Gateway 2

interface FastEthernet0/0
ip address 192.168.255.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.1.254 255.255.255.0
duplex auto
speed auto
standby 1 ip 192.168.1.1
standby 1 preempt
standby 1 track GigabitEthernet1/0
!
interface GigabitEthernet1/0
ip address 10.2.2.254 255.255.255.252
negotiation auto
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 192.168.1.0
neighbor 10.2.2.253 remote-as 200
neighbor 10.2.2.253 route-map BACKUP out
neighbor 192.168.255.1 remote-as 100
neighbor 192.168.255.1 next-hop-self
no auto-summary
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 198.77.64.40
no ip http server
no ip http secure-server
!
!
!
!
ip prefix-list BACKUP seq 5 permit 192.168.1.0/24
!
ip prefix-list INTERNET seq 5 permit 198.77.64.40/32
logging alarm informational
!
!
!
route-map BACKUP permit 10
match ip address prefix-list BACKUP
set metric 200
!
route-map BACKUP permit 20

PE1

interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface GigabitEthernet1/0
ip address 10.1.1.253 255.255.255.252
negotiation auto
!
interface FastEthernet2/0
ip address 172.16.1.1 255.255.255.252
ip ospf hello-interval 2
ip ospf dead-interval 6
duplex auto
speed auto
!
interface FastEthernet2/1
no ip address
shutdown
duplex auto
speed auto
!
interface GigabitEthernet3/0
no ip address
shutdown
negotiation auto
!
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 172.16.0.0 0.0.255.255 area 0
!
router bgp 200
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 update-source Loopback0
neighbor 2.2.2.2 next-hop-self
neighbor 10.1.1.254 remote-as 100
no auto-summary

PE2

interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface GigabitEthernet1/0
ip address 10.2.2.253 255.255.255.252
negotiation auto
!
interface FastEthernet2/0
ip address 172.16.1.2 255.255.255.252
ip ospf hello-interval 2
ip ospf dead-interval 6
duplex auto
speed auto
!
interface FastEthernet2/1
no ip address
shutdown
duplex auto
speed auto
!
interface GigabitEthernet3/0
ip address 10.3.3.253 255.255.255.252
negotiation auto
!
router ospf 1
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 0
network 172.16.0.0 0.0.255.255 area 0
!
router bgp 200
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 200
neighbor 1.1.1.1 update-source Loopback0
neighbor 1.1.1.1 next-hop-self
neighbor 10.2.2.254 remote-as 100
neighbor 10.3.3.254 remote-as 40
no auto-summary

Finally here are the IP Routing and BGP table on Gateway 1 before and after a failover.

Gateway1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 198.77.64.40 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.1.1.252/30 is directly connected, GigabitEthernet1/0
S       10.1.1.253/32 [1/0] via 10.1.1.253, GigabitEthernet1/0
192.168.255.0/30 is subnetted, 1 subnets
C       192.168.255.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1
198.77.64.0/32 is subnetted, 1 subnets
B       198.77.64.40 [20/0] via 10.1.1.253, 00:01:04
S*   0.0.0.0/0 [1/0] via 198.77.64.40
Gateway1#show ip bgp sum
Gateway1#show ip bgp
BGP table version is 30, local router ID is 192.168.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
* i192.168.1.0      192.168.255.2            0    100      0 i
*>                  0.0.0.0                  0         32768 i
*> 198.77.64.40/32  10.1.1.253                    150      0 200 40 i
Gateway1#
*May 28 23:41:08.563: %TRACKING-5-STATE: 2 rtr 1 state Up->Down
*May 28 23:41:08.563: %BGP-5-ADJCHANGE: neighbor 10.1.1.253 Down Route to peer lost
Gateway1#
*May 28 23:41:09.631: %HSRP-5-STATECHANGE: FastEthernet0/1 Grp 1 state Active -> Speak
Gateway1#
Gateway1#
Gateway1#
Gateway1#
Gateway1#
*May 28 23:41:19.631: %HSRP-5-STATECHANGE: FastEthernet0/1 Grp 1 state Speak -> Standby

Gateway1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 198.77.64.40 to network 0.0.0.0

10.0.0.0/30 is subnetted, 1 subnets
C       10.1.1.252 is directly connected, GigabitEthernet1/0
192.168.255.0/30 is subnetted, 1 subnets
C       192.168.255.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1
198.77.64.0/32 is subnetted, 1 subnets
B       198.77.64.40 [200/0] via 192.168.255.2, 00:00:16
S*   0.0.0.0/0 [1/0] via 198.77.64.40
Gateway1#show ip bgp
BGP table version is 32, local router ID is 192.168.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
* i192.168.1.0      192.168.255.2            0    100      0 i
*>                  0.0.0.0                  0         32768 i
*>i198.77.64.40/32  192.168.255.2            0    100      0 200 40 i

Comments

A thread has been created on the site forum specifically for commenting on this blog post.

ISSU (In-Service Software Upgrade) is a feature that allows the operator to upgrade (or downgrade) the IOS on device without having to take the entire device down and potentially impact service. This is partly accomplished with the SSO supervisor redundancy mode that performs the subsecond supervisor switchovers while each supervisor is restarted and loaded with the new (or old) IOS.

In brief, the process works as follows: Both supervisors are running the old image. The standby supervisor is restarted and loaded with the new image. The operator switches over to the standby supervisor to ‘test drive’ the new image. The switchover automatically restarts the active supervisor, bringing it up as the standby and making the current standby supervisor the active.  Finally, the standby supervisor, which started as the active, is restarted and loaded with the new image. In the end, both supervisors have the new image.

This is all done with four commands, 1) issu loadversion, 2) issu runversion, 3) issu acceptversion, and 4) issu commitversion. A fifth command, issu abortversion, allows the operator to abort the process up to the third step and undo the changes automatically.

In my particular case, I was upgrading from IOS XE 3.1.1 to IOS XE 3.2.4. First, I started off by verifying some prerequisites — that the old and new IOS images were on the flash memory of both supervisors, that both supervisors were running the same old image, that the config register was set to 0×2102, and that the supervisors were running in SSO redundancy mode:

Switch#show bootflash:
-#- --length-- ---------date/time--------- path
  1   88204596 Jul 22 2011 23:45:07 +00:00 cat4500e-universalk9.SPA.03.01.01.SG.150-1.XO1.bin
  2   90677420 Apr 15 2012 02:45:47 +00:00 cat4500e-universalk9.SPA.03.02.04.SG.150-2.SG4.bin

Switch#show slavebootflash:
-#- --length-- ---------date/time--------- path
  1   88204596 Jul 22 2011 23:57:21 +00:00 cat4500e-universalk9.SPA.03.01.01.SG.150-1.XO1.bin
  2   90677420 Apr 15 2012 02:50:01 +00:00 cat4500e-universalk9.SPA.03.02.04.SG.150-2.SG4.bin

Switch#show redundancy

[text omitted]

Current Processor Information :
------------------------------
               Active Location = slot 3
        Current Software state = ACTIVE
       Uptime in current state = 9 minutes
                 Image Version = Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 03.01.01.SG RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Tue 14-Dec-10 22:12 by prod
               BOOT = bootflash:cat4500e-universalk9.SPA.03.01.01.SG.150-1.XO1.bin,1;
        Configuration register = 0x2102

Peer Processor Information :
------------------------------
              Standby Location = slot 4
        Current Software state = STANDBY HOT
       Uptime in current state = 0 minute
                 Image Version = Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 03.01.01.SG RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Tue 14-Dec-10 22:12 by prod
               BOOT = bootflash:cat4500e-universalk9.SPA.03.01.01.SG.150-1.XO1.bin,1;
        Configuration register = 0x2102

1) Loadversion

I was ready to begin. I started off by issuing the issu loadversion command. This command restarts the standby supervisor and loads it with the new image:

Switch#issu loadversion 3 bootflash:cat4500e-universalk9.SPA.03.02.04.SG.150-2.SG4.bin 4 flash:cat4500e-universalk9.SPA.03.02.04.SG.150-2.SG4.bin
% issu loadversion executed successfully, Standby is being reloaded

The standby supervisor is restarted, and after several minutes it comes up with the new IOS. ISSU also detected the standby supervisor and told me the next step:

Apr 15 12:28:54.845 UTC: %INSTALLER-7-ISSU_OP_SUCC: Peer state is [STANDBY SSO]; Please issue the runversion command

Switch#show redundancy

[text omitted]

Current Processor Information :
------------------------------
               Active Location = slot 3
        Current Software state = ACTIVE
       Uptime in current state = 16 minutes
                 Image Version = Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 03.01.01.SG RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Tue 14-Dec-10 22:12 by prod
               BOOT = bootflash:cat4500e-universalk9.SPA.03.01.01.SG.150-1.XO1.bin,1;
        Configuration register = 0x2102

Peer Processor Information :
------------------------------
              Standby Location = slot 4
        Current Software state = STANDBY HOT
       Uptime in current state = 0 minute
                 Image Version = Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 03.02.04.SG RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Mon 19-Mar-12 16:17 by prod
               BOOT = bootflash:cat4500e-universalk9.SPA.03.01.01.SG.150-1.XO1.bin,1;
        Configuration register = 0x2102

2) Runversion

At this point, the standby supervisor has the new image, but we’re still operating on the active supervisor. The next step is to execute the issu runversion command, which will switch us over to the standby supervisor, automatically restart the active supervisor and bring it back up as the standby.  This also forces the current standby to become the active:

Switch#issu runversion 4 slavebootflash:cat4500e-universalk9.SPA.03.02.04.SG.150-2.SG4.bin
This command will reload the Active unit.  Proceed ? [confirm]

Switch#
Please stand by while rebooting the system...
                                                               Restarting system.

The active supervisor is restarted and functionality failsover to the standby. I consoled into the new active supervisor (slot 4) and waited for the new standby supervisor (slot 3) to load back up. After a few minutes, the standby supervisor came up and ISSU gave me further instructions:

Apr 15 12:35:06.355 UTC: %INSTALLER-7-ISSU_OP_SUCC: Peer state is [STANDBY SSO]; Please issue the acceptversion command

But before continuing, I verified the redundancy status and running IOSs:

Switch#show redundancy

[text omitted]

Current Processor Information :
------------------------------
               Active Location = slot 4
        Current Software state = ACTIVE
       Uptime in current state = 9 minutes
                 Image Version = Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 03.02.04.SG RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Mon 19-Mar-12 16:17 by prod
               BOOT = bootflash:cat4500e-universalk9.SPA.03.01.01.SG.150-1.XO1.bin,1;
        Configuration register = 0x2102

Peer Processor Information :
------------------------------
              Standby Location = slot 3
        Current Software state = STANDBY HOT
       Uptime in current state = 0 minute
                 Image Version = Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 03.01.01.SG RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Mon 19-Mar-12 16:17 by prod
               BOOT = bootflash:cat4500e-universalk9.SPA.03.01.01.SG.150-1.XO1.bin,1;
        Configuration register = 0x2102

3) Acceptversion

After the issu runversion command, a rollback timer is started. The timer acts as a safety mechanism for automatic image rollback. If you fail to stop the timer within 45 minutes, ISSU will assume that the upgrade (or downgrade) either failed or that you lost access to manually abort or continue the process, at which point ISSU will automatically perform a rollback.

To stop the timer, issue the third command, issu acceptversion:

Switch#issu acceptversion 4 bootflash:cat4500e-universalk9.SPA.03.02.04.SG.150-2.SG4.bin
% Rollback timer stopped. Please issue the commitversion command.

4) Commitversion

The last step is the issu commitversion command, which finalizes the process. This reloads the standby supervisor (the one that started as the active) and loads it with the new IOS:

Switch#issu commitversion 3 slavebootflash:cat4500e-universalk9.SPA.03.02.04.SG.150-2.SG4.bin
Building configuration...
Compressed configuration from 47049 bytes to 9639 bytes
[OK]
% issu commitversion executed successfully

The standby supervisor is restarted shortly after. After it came up, I verified that all supervisors had the new IOS:

Switch#show redundancy

[text omitted]

Current Processor Information :
------------------------------
               Active Location = slot 4
        Current Software state = ACTIVE
       Uptime in current state = 16 minutes
                 Image Version = Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 03.02.04.SG RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Mon 19-Mar-12 16:17 by prod
               BOOT = bootflash:cat4500e-universalk9.SPA.03.02.04.SG.150-2.SG4.bin,12;bootflash:cat4500e-universalk9.SPA.03.01.01.SG.150-1.XO1.bin,1;
        Configuration register = 0x2102

Peer Processor Information :
------------------------------
              Standby Location = slot 3
        Current Software state = STANDBY HOT
       Uptime in current state = 0 minute
                 Image Version = Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 03.02.04.SG RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Mon 19-Mar-12 16:17 by prod
               BOOT = bootflash:cat4500e-universalk9.SPA.03.02.04.SG.150-2.SG4.bin,12;bootflash:cat4500e-universalk9.SPA.03.01.01.SG.150-1.XO1.bin,1;
        Configuration register = 0x2102

Switch#show version
Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 03.02.04.SG RELEASE SOFTWARE (fc1)

[text omitted]

During the upgrade, I had several continuous pings running across the switch and I never took a hit on any of them.  The procedure delivered as promised.

Comments

A thread has been created on the site forum specifically for commenting on this blog post.

Thanks to all of the forum members who posted up great questions and a special thanks to Wendell Odom for taking time out of his busy schedule to reply! Keep up with Wendel on his website, certskills.com, and on his Facebook page.

Comments

A thread has been created on the site forum specifically for commenting on this blog post.

Therefor: an explanation about various appliances you’ll likely meet or need in a company. An appliance is a device that performs a specific purpose. Most simple example is a router: it’s actually a computer, but it can only provide routing. Here’s a list of other common devices:

Appliances

A (stateful) firewall: a device that protects your network. It’s main purpose is to keep track of conversations between devices (often based on layer 4 TCP and UDP ports) and to filter out unwanted packets. I mention stateful because it keeps track of all connection states to make decisions. A stateless firewall just uses access lists to filter traffic.

An IDS or Intrusion Detection System. Scans traffic for signatures that may indicate malicious behavior, and sends out alerts when these are detected.

An IPS or Intrusion Prevention System. Like an IDS, it scans traffic for signatures, but it drops any suspicious traffic instead. Note that this doesn’t render an IDS useless: an IDS may be used to gather evidence, alert an IPS, check if the IPS still works, or give orders to other devices to change behavior based on incoming signatures.

A load balancer: this device forwards requests to a pool of servers to balance the load, e.g. a website receives 60,000 page views an hour but a server can only handle up to 25,000. Using a load balancer to spread the requests over three servers will solve the problem. A modern load balancer can have different load-balancing methods, adapt in case one of the servers goes down, and filter out malformed requests.

A VPN endpoint is a device that terminates VPN tunnels. It can be used as a dedicated device to control all VPN sessions from teleworkers, or to control all site-to-site VPNs between the main office and branch offices. Sometimes contains specialized circuits to perform encryption, which would take a high CPU load otherwise.

A WLC or Wireless LAN Controller is a device that controls a group of LAPs, or Lightweight Access Points. It makes sure they are configured the right way, use the right channel and SSIDs, and allows roaming between them.

A SSL offloading device takes care of encrypting and decrypting SSL sessions, usually for https-websites. This way, the webserver(s) needs less CPU and can accept more requests, and the decrypted https session can also be checked with an IPS for malicious traffic inside the session, as encrypted traffic normally can’t be checked.

A RADIUS or Remote Authentication Dial In User Server is a server that checks if a user is permitted  to a certain resource. That resource can be anything: switches and access points can forward 802.1x authentication requests from computers that want to connect, various devices can forward Telnet or SSH logins to check if they’re allowed, and so on.

A proxy server is a server that caches (and often also firewalls) web content. It can speed up browsing through caching or increase security by filtering or hiding the client computers from the outside world.

A WAN accelerator is a device that translates data to signatures/hashes which are smaller, to send over a slow WAN link to another accelerator, which will translate the signature/hash back to the original data. Usually these devices have an internal hard drive to store data and signatures and adapt to traffic patterns. Basically they ‘zip data on the fly’.

Comments

A thread has been created on the site forum specifically for commenting on this blog post.

The topology above is an example network, consisting of four OSPF areas (one backbone, area 0) and one external EIGRP area. I’ve set up an IP addressing scheme using 10.0.0.0/8 for OSPF and 172.16.0.0/12 for EIGRP. In case you didn’t notice, the second part of the IP address is the same as the area number (10.x.0.0 for area x).

All interfaces are configured with the correct IP addresses, OSPF and EIGRP have been configured correctly and are running. Basic redistribution between the two routing protocols is done on router R5 and also works fine. Here’s the output of ‘show ip route’ on router R0 in area 5:

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
O E2    172.16.0.0/24 [110/20] via 10.5.3.2, 00:18:54, FastEthernet0/1
O E2    172.16.1.0/30 [110/20] via 10.5.3.2, 00:19:39, FastEthernet0/1
10.0.0.0/8 is variably subnetted, 8 subnets, 4 masks
O IA    10.0.0.8/30 [110/20] via 10.5.3.2, 00:36:09, FastEthernet0/1
O IA    10.15.1.0/30 [110/40] via 10.5.3.2, 00:31:07, FastEthernet0/1
O IA    10.15.0.0/24 [110/50] via 10.5.3.2, 00:28:57, FastEthernet0/1
O IA    10.0.0.0/29 [110/30] via 10.5.3.2, 00:33:51, FastEthernet0/1
C       10.5.3.0/30 is directly connected, FastEthernet0/1
C       10.5.2.0/24 is directly connected, FastEthernet1/0
C       10.5.0.0/23 is directly connected, FastEthernet0/0
O IA    10.25.0.0/30 [110/40] via 10.5.3.2, 00:27:00, FastEthernet0/1

The other routers in the OSPF area show similar routing tables. While this configuration works, it’s not that efficient in larger networks in particular. The more routers that are added, the more routes are stored in the routing table using up memory. Dividing the network in areas works, but only if you do something with those areas.

So what can you do with those areas? There are several options: assign them a specific role, or filter the routing table. First something about area roles: these influences how Link-State Advertisements (LSA) are sent, which OSPF routers send to each other to inform about connected and learned routes. These LSAs are gathered in a database. Here’s the output of router R2′s database:

R2#show ip ospf database

OSPF Router with ID (10.0.0.10) (Process ID 1)

Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.0.0.10       10.0.0.10       572         0x80000004 0x00E2C3 2
10.5.3.2        10.5.3.2        767         0x80000003 0x008355 1
10.15.1.1       10.15.1.1       469         0x80000004 0x005284 1
10.25.0.1       10.25.0.1       191         0x80000004 0x00A91A 1

Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.0.2        10.0.0.10       319         0x80000003 0x006F58
10.0.0.9        10.5.3.2        767         0x80000002 0x00A349

Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.5.0.0        10.5.3.2        767         0x80000002 0x00E81D
10.5.2.0        10.5.3.2        767         0x80000002 0x007D8E
10.5.3.0        10.5.3.2        767         0x80000002 0x0056B8
10.15.0.0       10.15.1.1       469         0x80000002 0x0039BA
10.15.1.0       10.15.1.1       473         0x80000002 0x00B748
10.25.0.0       10.25.0.1       194         0x80000002 0x0001EC

Summary ASB Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.16.1.1      10.25.0.1       1748        0x80000001 0x001C33

Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
172.16.0.0      172.16.1.1      1699        0x80000003 0x00BE64 0
172.16.1.0      172.16.1.1      1754        0x80000001 0x00A581 0

The router link states (type 1 LSAs) are advertisements from the routers in the area and can’t be influenced. They’re the same for every router in an area. Four routers, four LSAs. The net link states (type 2 LSAs) are advertisements coming from a Designated Router (DR) announcing a subnet. There are two subnets in area 0, so two LSAs. These can be influenced. The third type are LSAs from an Area Border Router, announcing inter-area routes. Six subnets outside area 0, six type 3 LSAs. These can be influenced, but not in the backbone area (area 0). The fourth and fifth types of LSA are to announce an Autonomous System Border Router (ASBR) and routes external to the OSPF network, respectively. They can be influenced everywhere except in the backbone area too.

First, type 2 LSA advertisements. They provide additional information in case of a broadcast subnet, like Ethernet. But when there are only two routers on a subnet, it’s better to make it a point-to-point link. This way, no type 2 LSA is generated, though the type 1 LSA for that link still is, and the routers communicate directly instead of selecting a DR. You can change the interface type with the ‘ip ospf network’ command on the interfaces at both sides of the link:

R2(config)#int f0/0
R2(config-if)#ip ospf network point-to-point

The same is done on f0/0 of router R31. Here’s part of the new database output, with just one link-state now:

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.0.2        10.0.0.10       1218        0x80000003 0x006F58
Next LSA type 5, external routes. By making an area a stub area, you prevent the ABR from flooding type 5 LSA in the area, instead announcing a default route. The command has to be applied to every router in that area. For example, I make area 5 a stub area using the command 'area 5 stub' on routers R0 and R1. After this, the link-state database of R0 doesn't have any type 5 LSA anymore. The routing table has changed too:
Gateway of last resort is 10.5.3.2 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 8 subnets, 4 masks
O IA    10.0.0.8/30 [110/20] via 10.5.3.2, 00:08:42, FastEthernet0/1
O IA    10.15.1.0/30 [110/40] via 10.5.3.2, 00:08:42, FastEthernet0/1
O IA    10.15.0.0/24 [110/50] via 10.5.3.2, 00:08:42, FastEthernet0/1
O IA    10.0.0.0/29 [110/30] via 10.5.3.2, 00:08:42, FastEthernet0/1
C       10.5.3.0/30 is directly connected, FastEthernet0/1
C       10.5.2.0/24 is directly connected, FastEthernet1/0
C       10.5.0.0/23 is directly connected, FastEthernet0/0
O IA    10.25.0.0/30 [110/40] via 10.5.3.2, 00:08:43, FastEthernet0/1
O*IA 0.0.0.0/0 [110/11] via 10.5.3.2, 00:08:43, FastEthernet0/1

That’s two routes less than before. But if you make it a totally stubby area, you can filter out the inter-area routes too. The command is ‘area 5 stub no-summary’ on the ABR, R1. It’s not needed on the internal routers (they still need to be stub, though). After this command is done, all type 3 LSA are gone from the link-state database of R1, and the routing table is small and efficient:

Gateway of last resort is 10.5.3.2 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
C       10.5.3.0/30 is directly connected, FastEthernet0/1
C       10.5.2.0/24 is directly connected, FastEthernet1/0
C       10.5.0.0/23 is directly connected, FastEthernet0/0
O*IA 0.0.0.0/0 [110/11] via 10.5.3.2, 00:01:11, FastEthernet0/1

Note that you have to consider if it’s really an advantage to use these commands if there are multiple ABRs because some inter-area routes may take more hops or a slower route using the default route.

The other method, filtering the routing table, requires more thought, but is easier if there are multiple ABRs. This doesn’t influence any sent or received LSAs, but can make the routing table shorter and more efficient. I’m using the following prefix-list:

R8(config)#ip prefix-list PFX-NoLinks permit 0.0.0.0/0 le 26

This defines a prefix-list, name PFX-NoLinks, which will permit any route (0.0.0.0/0) which has 26 or less network-bits. So anything smaller than a /26 (62 hosts) is filtered because of the implicit deny. This can be used on a router towards end users, like R8, who don’t need to reach any of the internal links in the backbone area, just other host subnets. To apply it between the OSPF process and the routing table:

R8(config)#router ospf 1
R8(config-router)#distribute prefix PFX-NoLinks in

The result is clear in the routing table:

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
O E2    172.16.0.0 [110/20] via 10.15.1.1, 00:00:41, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C       10.15.1.0/30 is directly connected, FastEthernet0/0
C       10.15.0.0/24 is directly connected, FastEthernet0/1
O IA    10.5.2.0/24 [110/41] via 10.15.1.1, 00:00:41, FastEthernet0/0
O IA    10.5.0.0/23 [110/50] via 10.15.1.1, 00:00:41, FastEthernet0/0

Except for a connected route (not handled by OSPF), nothing smaller than a /24 can be seen. Pinging between the host subnets still works.

These are a few methods to improve performance in larger OSPF networks, but certainly not the only ones. Thanks for reading!

About the Author

Reggle is a forum regular and community blog contributor. Visit and bookmark his blog which is updated with new material regularly.

Comments

A thread has been created on the site forum specifically for commenting on this blog post.

It’s going to take a few days but it will have an exact replica of the Samba server on the Rsync server and you don’t have to have any clients installed on other machines for Rsync to work. All you need is administrative credentials on the machine you are going to Rsync with.

Once I’ve figured all of this out, I will be setting my Rsync box to start backing up automatically every night (full backup) and also, when a file is changed on the Samba Server. I’m going to try and figure out the latter as I haven’t figured out how Rsync will be able to detect that a file has changed or been removed, etc. Once I have done so though I’m sure it’s going to be very handy, also I’ll be setting the Rsync box to backup all of the the user areas and profiles held on the DCs and also the users folder on the PCs.

First create a folder on your CentOS box in which you can mount the drive you want to backup, for example I created the folder mount_tmp and mounted our Samba share onto this folder.

The commands I have been using so far are:

mount -t cifs \\\\<ip address>\\sharename /mount_tmp -o user=<username on remote machine>%<password>

This mounts the remote drive onto the backup folder, make sure you have administrative rights on the remote machine and use the correct username and password. To start to Rsync you’ll want to create another folder on your CentOS box to actually back up to so I created a folder called Backup. To Rsync I issue the following command:

rsync --progress --stats -v -r /mount_tmp/* /backup

This starts backing up the mount on the mount_tmp folder. You can read the Rsync man pages to find out what the switches are but from memory -v enables verbosity and -r means recursive directories. You must use -r to backup folders and directories and don’t forget to use –progress and –stats as this will show you the percentage of files copied to the backup folder.

After all that is done I use the following command to check drive space:

df -h

You can set this up using the “mail” command so that you get an email of the log.

I hope this blog helps you, it has been an interesting journey with Rsync this is the first time I’ve used it.

Comments

A thread has been created on the site forum specifically for commenting on this blog post.