Redistribution and Route-Maps (part 1)

This post will be about redistribution and the use of route-maps to influence the redistribution process.

When companies merge, the network has to merge too. Often the networks don’t use the same routing protocols. Sometimes it’s possible to migrate a netwerk from let’s say OSPF to EIGRP, but when the company’s don’t use Cisco only, it’s is hard to migrate.

To tackle this problem it’s is possible to redistribute the OSPF routes into EIGRP and also the other way around. This means that all the routes from OSPF are known in the EIGRP cloud, and al the EIGRP routes are known in the OSPF cloud. Sometimes it is not necessary for the EIGRP cloud to know al the OSPF routes. That’s when route-maps come in. With a route-map it is possible to make sure certain routes will never get to the routing table.

In the next section a configuration example.

First have a look a the network layout:

Network Layout

Al routers have two intfaces to connect to their neighbours and one loopback interface to identify the router.
Below an example of router R3:

Interfaces R3

After that configure OSPF:

EIGRP_redistribute R3

Make sure you configure these steps on all the OSPF routers.
To make sure the configuration is correct, check if the “show ip ospf neighbours” command shows two neighbours
OSPF_neighbours R3


After configuring the correct interfaces, configure EIGRP:


The initial configuration is done. Now the redistribution part can be configured. To make redistribution possible there has to be a redistribution point, in other words, there has to be a router which has an interface (or interfaces) in the OSPF aswell as the EIGRP cloud. In this example R5 is the redistribution point.

Below an example of the redistribution between OSPF and EIGRP on R5:

OSPF_redistribute EIGRP_redistribute R3

As shown in the examples the redistribution command has some options. The default values are enough to make the redistribution work.

To make sure the redistribution works, use the command show ip route on for example router R4.

Routes R4 after redistribution

As can be seen in the above example the EIGRP routes are learned as E2 routes. To make sure the connectivity is correct, use the ping command. As can be seen in the next example, the ping command is succesfull from router R1 to router R7.



In part 2 I will describe the route-map configuration.




Spontanious reboot of Cisco 6509E switch

Lately one of our customers Cisco 6509E switches rebooted spontanious. At first sight it looked like there was no obvious reason for this problem. After investigation, the reason of the spontanious reboot became clear.

The first clue was found when the “show version” command was run. This was the output (the output is omitted):

switch#show version

System returned to ROM by s/w reset at 07:43:59 gmt Sun Dec 8 2013 (SP by processor memory parity error at PC 0x419EEB88, address 0x0)


The fat part of the output triggered me, to download the crashinfo from the sup-bootflash.

show sup-bootflash
-#- –length– —–date/time—— path
-#- ED —-type—- –crc— -seek– nlen -length- ———date/time——— name
1 .. config 4F161C23 9D14C 21 118988 Apr 13 2012 00:26:20 +02:00 BackupSXH513apr12.bak
2 .. crashinfo 1A1C516D 104FF0 32 425506 Dec 8 2013 07:43:55 +01:00 crashinfo_RP_20131208-074355-gmt
copy bootflash:/crashinfo_RP_20131208-074355-gmt tftp:

After investigating the crashinfo I found the following lines:

674670: Dec 8 07:43:55: %C6K_PLATFORM-2-PEER_RESET: RP is being reset by the SP
%Software-forced reload

07:43:55 gmt Sun Dec 8 2013: Breakpoint exception, CPU signal 23, PC = 0x428A667C


Possible software fault. Upon reccurence, please collect

crashinfo, “show tech” and contact Cisco Technical Support.


After reading this meassage it became clear that the RP is rebooted by the SP, so for further information the logging from the SP has to be investigated.

The SP crashinfo can be found:

show sup-bootflash:
-#- –length– —–date/time—— path
1 74788836 Sep 24 2009 09:48:00 +02:00 s72033-ipservicesk9_wan-mz.122-33.SXH5.bin
2 33554432 Sep 24 2009 11:57:50 +02:00 sea_log.dat
3 119027 Apr 12 2012 02:09:34 +02:00 BackupSXH513apr12.bak
4 33554432 Apr 13 2012 01:08:52 +02:00 sea_console.dat
5 139998532 Mar 9 2012 11:40:28 +01:00 s72033-ipservicesk9_wan-mz.122-33.SXJ2.bin
6 439014 Dec 8 2013 07:43:58 +01:00 crashinfo_SP_20131208-074355-gmt
copy sup-bootflash:/crashinfo_SP_20131208-074355-gmt tftp:

In the SP crashinfo the following lines triggered me:

Cache error detected!

CPO_ECC (reg 26/0): 0x000000EC

CPO_CACHERI (reg 27/0): 0x20000000

CP0_CAUSE (reg 13/0): 0x00000C00

Real cache error detected. System will be halted.

Error: Primary instr cache, fields: data,

Actual physical addr 0x00000000,

virtual address is imprecise.

Imprecise Data Parity Error

Imprecise Data Parity Error

07:43:55 gmt Sun Dec 8 2013: Interrupt exception, CPU signal 20, PC = 0x419EEB88


Possible software fault. Upon reccurence, please collect

crashinfo, “show tech” and contact Cisco Technical Support.


After looking up this error messsage on the Cisco support forum only two possible options were left:

1) soft-parity error

Cisco says the following about soft-parity errors:

“These errors occur when an energy level within the chip (for example, a one or a zero) changes, most often due to radiation. When referenced by the CPU, such errors cause the system to crash. In case of a soft parity error, there is no need to swap the board or any of the components.”

2) hard-parity error

Cisco says the following about hard-parity errors:

“These errors occur when there is a chip or board failure that corrupts data. In this case, you need to re-seat or replace the affected component, which usually involves a memory chip swap or a board swap.”

After reading some more about these possible problems it became clear that making a new TAC case for this problem was useless. Cisco states on the official forum that they are not able to tell if it was a soft or hard parity error after just one spontanious reboot.

They state that only 1 out of 100 reboots with this error is a hard-parity error. If the switch doesn’t reboot again in one or two days it is safe to say that it is a soft-parity error. Cisco also states that in case of a soft-parity error an upgrade to the latest IOS version can prevent a spontanious reboot.

Our advise to the customer is to upgrade to the latest IOS version and monitor the switch for odd behaviour. When the switchs reboots a second time, a TAC case has to be opened.

Good old Kron

Nowadays there are several ways to backup a Cisco router or switch configuration. Solarwinds is one of these tools, very often used by myself.
Still there are customers who don’t own one of these program’s or don’t want to invest in such a solution.
But even when a customer won’t invest in such a solution it is possible to backup your router and switch configurations. Cisco uses good old “Kron”.
Kron functions in the same way as cron on a Linux distribution. With Kron it is possible to make a (or more) scheduled event(s).
Beneath a how to:

First of all you want the startup-config to be the same as the running-config, so first create a job that writes the running-config to the startup-config

kron occurrence ; at ; recurring
policy-list ;
kron policy-list ;
cli write

Now that the startup and running-config are the same you can backup the startup-config to a tftp server

kron occurrence ; at ; recurring
policy-list ;
kron policy-list ;
cli show startup-config | redirect tftp:///;/;

With Kron it is possible to automatically write several different commando’s to a tftp server.

SVI’s and Routing on Cisco 2960 switches

As I wrote before, I have been working a lot witch Cisco 2960 switches lately. Although I was aware of the fact that routing was possible on a 2960 switch, I never actually tested this. I never tested this because of the simple fact that routing on an access switch is not done. At least we try to avoid it.

Before Routing is enable on a 2960 switch, you have to change the “SDM” settings, this can be done with the following commands:

switch01# configure terminal
switch01 (config)# sdm prefer lanbase-routing

Now you have to reload the switch to make lanbase-routing active. After reloading the switch you can check the SDM status with the following command:

Switch01#show sdm prefer
The current template is “lanbase-routing” template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 8 routed interfaces and 255 VLANs.
  number of unicast mac addresses:                                  4K
  number of IPv4 IGMP groups + multicast routes:               0.25K
  number of IPv4 unicast routes:                                        4.25K
  number of directly-connected IPv4 hosts:                         4K
  number of indirect IPv4 routes:                                       0.25K
  number of IPv4 policy based routing aces:                        0
  number of IPv4/MAC qos aces:                                        0.125k
  number of IPv4/MAC security aces:                                  0.375k

Keep in mind:

  • You need at least IOS release 12.2(55).
  • Only 8 SVI’s are allowed
  • Only 16 static routes are allowed
  • Advanced routing is NOT possible

I was not able to perform a stress test on the switches, but nevertheless, when routing is required I prefer to use a Cisco 3560 switch (with the right license off course) .