Problems running HSRP and EIGRP

meryanme

Hello Guys I just need some advice on an issue im currently having.

The problem has happened twice on two different routers.

I have 4 3600 routers and 4 3750 switches.

Two routers are connected to two switches the two switches being stacked. Those same two routers are connected to the other two routers via a 100MB link which are also connected to two switches which are also stacked.

HSRP is running on the interfaces of the routers which are connected to the lan with the wan link as a standby track.

This is a portion of the log file...

Oct 18 22:29:34 10.0.1.3 278: 000274: Oct 18 22:31:00.084 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
Oct 18 22:29:34 10.0.1.3 279: 000275: Oct 18 22:31:00.252 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
Oct 18 23:04:10 10.0.1.3 280: 000276: Oct 18 23:05:35.667 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
Oct 18 23:04:10 10.0.1.3 281: 000277: Oct 18 23:05:35.715 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
Oct 18 23:05:58 10.0.1.3 282: 000278: Oct 18 23:07:24.117 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
Oct 18 23:05:58 10.0.1.3 283: 000279: Oct 18 23:07:24.173 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
Oct 18 23:06:05 10.0.1.3 284: 000280: Oct 18 23:07:30.261 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
Oct 18 23:06:05 10.0.1.3 285: 000281: Oct 18 23:07:30.321 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
Oct 18 23:06:19 10.0.1.3 286: 000282: Oct 18 23:07:44.293 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
Oct 18 23:06:19 10.0.1.3 287: 000283: Oct 18 23:07:44.341 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
Oct 18 23:06:31 10.0.1.3 288: 000284: Oct 18 23:07:56.165 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
Oct 18 23:06:31 10.0.1.3 289: 000285: Oct 18 23:07:56.201 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
Oct 18 23:07:21 10.0.1.3 290: 000286: Oct 18 23:08:46.358 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
Oct 18 23:07:21 10.0.1.3 291: 000287: Oct 18 23:08:46.422 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
Oct 19 00:17:13 10.0.1.3 292: 000288: Oct 19 00:18:38.977 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
Oct 19 00:17:15 10.0.1.3 293: 000289: Oct 19 00:18:41.009 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
Oct 19 00:17:21 10.0.1.3 294: 000290: Oct 19 00:18:47.009 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
Oct 19 00:17:21 10.0.1.3 295: 000291: Oct 19 00:18:47.165 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
Oct 19 00:17:26 10.0.1.3 296: 000292: Oct 19 00:18:52.005 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
Oct 19 00:17:27 10.0.1.3 297: 000293: Oct 19 00:18:53.097 AWST: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
Oct 19 00:17:28 10.0.3.4 469: 000465: Oct 19 00:18:54.018 AWST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.101.1 (FastEthernet0/1) is down: holding time expired
Oct 19 00:17:28 10.0.1.3 298: 000294: Oct 19 00:18:54.029 AWST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.1.2 (FastEthernet0/0) is down: holding time expired
Oct 19 00:17:30 10.0.3.4 470: 000466: Oct 19 00:18:55.990 AWST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.101.1 (FastEthernet0/1) is up: new adjacency
Oct 19 00:17:30 10.0.1.3 299: 000295: Oct 19 00:18:56.069 AWST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.1.2 (FastEthernet0/0) is up: new adjacency
Oct 19 00:17:31 10.0.1.2 6256: 006273: Oct 19 00:18:56.697 AWST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.101.2 (FastEthernet0/1) is down: Interface Goodbye received
Oct 19 00:17:31 10.0.1.2 6257: 006274: Oct 19 00:18:56.701 AWST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.1.3 (FastEthernet0/0) is down: Interface Goodbye received
Oct 19 00:17:31 10.0.1.2 6258: 006275: Oct 19 00:18:57.629 AWST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.100.17 (FastEthernet1/0) is down: peer restarted
Oct 19 00:17:32 10.0.1.2 6259: 006276: Oct 19 00:18:57.845 AWST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.100.17 (FastEthernet1/0) is up: new adjacency
Oct 19 00:17:32 10.0.1.2 6260: 006277: Oct 19 00:18:58.417 AWST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.1.3 (FastEthernet0/0) is up: new adjacency
Oct 19 00:17:32 10.0.1.2 6261: 006278: Oct 19 00:18:58.465 AWST: %SEC-6-IPACCESSLOGP: list 102 denied tcp 10.0.1.90(445 (FastEthernet0/0 0011.8512.c9c6) -> 10.0.3.90(1920), 1 packet
Oct 19 00:17:33 10.0.1.2 6262: 006279: Oct 19 00:18:58.509 AWST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.101.2 (FastEthernet0/1) is up: new adjacency


Our network lost connectivity for 48 minutes because the highest priority router in HSRP was not available...we think.

I personally think it is odd that while HSRP is showing the standby router picking up the slack by first becoming active and then into speaking mode it never goes back to standby in the log to go back to active...

During all this eigrp is also losing its adjancencies.

Has anyone got any idea about this problem and how to solve it??

Cheers

romain

Don't duplicate your post please...

darkuser

could be layer2 problems or bugs ....

any recent changes ???
or has it been a stable topology

you would have to draw out the topology and post relevant configs.

also this is what tac support is FOR .....

Humper

you honestly expect us to diagnose your problem with just the debugs? We need a topology diagram and some configs to help you more...

mikej412

meryanme wrote:

Those same two routers are connected to the other two routers via a 100MB link which are also connected to two switches which are also stacked.

The two HSRP Routers share a common 100MB link to the other routers?

What do your WAN Link interface statistics show?

You may want to enable some debugging to see what's happening with HSRP in between those log messages.

niamor wrote:

Don't duplicate your post please...

Actually -- don't "triplicate" your posts. I deleted one of the extra ones that I could....

miguel.corona

I had the exact same problem.

My topology was like this:


INTERNET
|
|
3821
ROUTER
|
|
SWITCH
/ \
/ \
4507 4507
SWITCH SWITCH
HSRP HSRP
ACTIVE STANDBY
/ \
/ \
2960 2960
SWITCH SWITCH
| |
| |
VLAN123 VLAN124




This was a test topology I did on GNS3 for later implementation on a production environment.

I have EIGRP running on the Cisco 3821 and the Cisco 4507. Before I included the other 4507 (standby) everything was working fine. I could reach Internet from any VLAN and had interVLAN connectivity. But as soon as I get the secondary 4507 into the picture, I start to get the same logs as the guy who post this thread.

I will put the logs later since I need to recover the whole topology.

Regards!

peanutnoggin

miguel.corona wrote: »

I had the exact same problem.

My topology was like this:


INTERNET
|
|
3821
ROUTER
|
|
SWITCH
/ \
/ \
4507 4507
SWITCH SWITCH
HSRP HSRP
ACTIVE STANDBY
/ \
/ \
2960 2960
SWITCH SWITCH
| |
| |
VLAN123 VLAN124




This was a test topology I did on GNS3 for later implementation on a production environment.

I have EIGRP running on the Cisco 3821 and the Cisco 4507. Before I included the other 4507 (standby) everything was working fine. I could reach Internet from any VLAN and had interVLAN connectivity. But as soon as I get the secondary 4507 into the picture, I start to get the same logs as the guy who post this thread.

I will put the logs later since I need to recover the whole topology.

Regards!

Where's the redundancy between your two 4507s? If your link on your active 4507 connecting to your switch goes down, how does the 2960s (vlan 123 & 124) get redirected (physically) to the standby 4507? Also remember to use interface tracking and preempt on your Active & Standby switches. HTH.

-Peanut

arun.mohan

[FONT=&quot]CSCdz75312 - EIGRP does not work when seq number becomes negative[/FONT]
[FONT=&quot] [/FONT]
[FONT=&quot]Symptom:[/FONT][FONT=&quot] [/FONT][FONT=&quot]In rare cases, when on a router running EIGRP the sequence number becomes more then 31 bits long, new EIGRP neighbors will not come up. [/FONT][FONT=&quot] [/FONT][FONT=&quot]Workaround:[/FONT][FONT=&quot] [/FONT][FONT=&quot]Restarting EIGRP on the router originating the large sequence numbers will reset the sequence numbers to zero and resolve the problem.[/FONT][FONT=&quot] [/FONT][FONT=&quot]You may upgrade the IOS on the 3750 switches to the latest 12.2(5SE to fix the issue, also as workaround we can reset the EIGRP process on 4500 by reconfiguring EIGRP on it, so that the sequence numbers get reset on them.[/FONT]

amb1s1

Make sure that the switches are working as layer 2.
Do "sh protocols" on the switches and if the switches show "Internet Protocol routing is enabled" thaht means that the switches are not working as layer 2. To make the switches layer 2 do "no ip routing" on config mode.

Forsaken_GA

amb1s1 wrote: »

Make sure that the switches are working as layer 2.
Do "sh protocols" on the switches and if the switches show "Internet Protocol routing is enabled" thaht means that the switches are not working as layer 2. To make the switches layer 2 do "no ip routing" on config mode.

It means no such thing. ip routing enables layer 3 capability, yes, but it does NOT disable layer 2.

Lazydog

miguel.corona wrote: »

I had the exact same problem.

My topology was like this:


INTERNET
|
|
3821
ROUTER
|
|
SWITCH
/ \
/ \
4507 4507
SWITCH SWITCH
HSRP HSRP
ACTIVE STANDBY
/ \
/ \
2960 2960
SWITCH SWITCH
| |
| |
VLAN123 VLAN124

I would suggest using CODE tags and the preview button when posting a layout as above. The CODE tags will keep the formatted text
Makes for reading and seeing the layout much more enjoyable.

Please remember this is only a suggestion.

        INTERNET
           |
           |
          3821
         ROUTER
           |
           |
         SWITCH
        /      \
       /        \
     4507       4507
    SWITCH     SWITCH
     HSRP       HSRP    
    ACTIVE     STANDBY
     /            \
    /              \
  2960            2960
 SWITCH           SWITCH
   |                |
   |                |
VLAN123          VLAN124

Why are you even running HSRP? Both VLANs are single attached so if their 2960 or 4507 goes down they are dead in the water anyway. HSRP isn't going to help them at all.

amb1s1

Forsaken_GA wrote: »

It means no such thing. ip routing enables layer 3 capability, yes, but it does NOT disable layer 2.

I didn't say that it disable layer 2, I was just guessing since we don't have much information or topology of this issue. I have the same problem where HSRP wasn't working properly and the reason why, it was because of the ip routing on the layer 2 switch. look at GNS3 lab that I have on my LAB. DAVID GOMEZ - TSHOOT GNS3 Complete Project with complete Configs . All of the issue that I have on that lab it was the IP routing. I was just trying to put my two cents.

Forsaken_GA

amb1s1 wrote: »

I didn't say that it disable layer 2, I was just guessing since we don't have much information or topology of this issue. I have the same problem where HSRP wasn't working properly and the reason why, it was because of the ip routing on the layer 2 switch. look at GNS3 lab that I have on my LAB. All of the issue that I have on that lab it was the IP routing. I was just trying to put my two cents.

I'd be thinking that's more a problem unique to emulation, or maybe a particular switch model. I've configured HSRP with EIGRP connecting to 3550's in layer 3 mode without any issue.

amb1s1

Forsaken_GA wrote: »

I'd be thinking that's more a problem unique to emulation, or maybe a particular switch model. I've configured HSRP with EIGRP connecting to 3550's in layer 3 mode without any issue.

I just for Training last week and the first lab (real routers) was a problem with ip routing been enable on a one of the layer 2 switches and it causing problem with EIGRP and HSRP.

Forsaken_GA

Ok, so I'll lab it up real quick and show what I mean.

Topology is simple, 2 3660's connected via ethernet to a 3550 running EMI

Ports fa0/3 and fa0/5 on the 3550 are put in vlan 200 (these are the ports the 3660's are connected to)

R3#sh cdp neighbors 
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
stark.cluebatnet Fas 0/0            123        R S I      WS-C3550- Fas 0/3

R5#sh cdp neighbors 
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
stark.cluebatnet Eth 0/0            145        R S I      WS-C3550-4Fas 0/5

stark is the 3550 switch, so both 3660's see it.

I'm using subnet 192.168.200.0/24 for this test. R3 is 192.168.200.3, R5 is 192.168.200.5, HSRP VIP is 192.168.200.1. stark has an SVI for vlan 200 with address 192.168.200.100

R3#sh ip eigrp neighbors 
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   192.168.200.100         Fa0/0             10 00:03:54    5   200  0  5
0   192.168.200.5           Fa0/0             13 00:09:18    8   200  0  5

R5#sh ip eigrp neighbors 
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   192.168.200.100         Et0/0             13 00:04:00    3   200  0  5
0   192.168.200.3           Et0/0             13 00:09:24    4   200  0  6

So R3 and R5 see each other as neighbors. And just for grins, I went ahead and put stark into the EIGRP instance as well, and redistributed my connected routes from stark into eigrp (this proves that stark is in fact in layer 3 mode)

R3#sh ip ro
C    192.168.200.0/24 is directly connected, FastEthernet0/0
D EX 192.168.55.0/24 
           [170/28416] via 192.168.200.100, 00:05:06, FastEthernet0/0
D EX 192.168.4.0/24 [170/28416] via 192.168.200.100, 00:05:06, FastEthernet0/0
D EX 192.168.3.0/24 [170/28416] via 192.168.200.100, 00:05:06, FastEthernet0/0

As you can see, R3 is seeing my redistributed routes from stark, sourced from 192.168.200.100


HSRP is up

R3#sh standby 
FastEthernet0/0 - Group 1
  State is Standby
    1 state change, last state change 00:10:45
  Virtual IP address is 192.168.200.1
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.876 secs
  Preemption enabled
  Active router is 192.168.200.5, priority 110 (expires in 9.235 sec)
  Standby router is local
  Priority 100 (default 100)
  IP redundancy name is "hsrp-Fa0/0-1" (default)

R5#sh standby
Ethernet0/0 - Group 1
  State is Active
    2 state changes, last state change 00:13:35
  Virtual IP address is 192.168.200.1
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.512 secs
  Preemption enabled
  Active router is local
  Standby router is 192.168.200.3, priority 100 (expires in 8.156 sec)
  Priority 110 (configured 110)
  IP redundancy name is "hsrp-Et0/0-1" (default)
R5#

I'm not seeing EIGRP go up and down, and I'm running mtr to keep a running traceroute from my laptop (connected to stark via an AP) for 1000 packets

tyrion.local (0.0.0.0)                                                                      Sat May 14 02:42:11 2011
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                            Packets               Pings
 Host                                                                     Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.4.1                                                            0.0%  1182    4.0   3.2   1.0  20.5   1.5
 2. 192.168.200.1                                                          0.0%  1182    4.8   4.2   1.9  37.7   2.3

So yeah, a switch in layer 3 mode involved with two routers running EIGRP and HSRP is not a death sentence. If the switch being in layer 3 mode causes problems, it's one of 4 things:

#1 code problem
#2 platform problem
#3 configuration problem
#4 design problem

Now, I could probably be convinced that a 2960 with ip routing enabled is causing a problem. That platform isn't a true layer 3 switch, and it only gained the little layer 3 capability it has recently. So I'd buy either a code problem, or a platform problem.

But I cannot accept that the solution for this problem is simply 'disable ip routing on the switch'. That is poor troubleshooting. If your design calls for the switch to be layer 3 capable, then that solution is flat out unacceptable, and whatever problem you had just graduated to a design problem.

If the switch having ip routing turned on is the entire problem, can you explain why? If not, then all you're doing is shotgun diagnostics and turning stuff on and off at random to see what works. You should not be satisfied with that answer. If you encounter this in deployment and implement a nasty hack to solve the problem, it's more likely than not going to come back and bite you on the ass. If you're using this solution as part of your studying, then you're picking up very bad habits that will not serve you well in your career.

Now, with all that being said, please understand, I'm not picking on you. I'm just a rather brusque individual.

The symptoms the OP is showing are classic indications of packet loss. Those are both symptoms of the other router not seeing all of the hello packets that the given protocol is sending. That's the place to begin troubleshooting.

amb1s1

Forsaken_GA wrote: »

Ok, so I'll lab it up real quick and show what I mean.

Topology is simple, 2 3660's connected via ethernet to a 3550 running EMI

Ports fa0/3 and fa0/5 on the 3550 are put in vlan 200 (these are the ports the 3660's are connected to)

R3#sh cdp neighbors 
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
stark.cluebatnet Fas 0/0            123        R S I      WS-C3550- Fas 0/3

R5#sh cdp neighbors 
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
stark.cluebatnet Eth 0/0            145        R S I      WS-C3550-4Fas 0/5

stark is the 3550 switch, so both 3660's see it.

I'm using subnet 192.168.200.0/24 for this test. R3 is 192.168.200.3, R5 is 192.168.200.5, HSRP VIP is 192.168.200.1. stark has an SVI for vlan 200 with address 192.168.200.100

R3#sh ip eigrp neighbors 
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   192.168.200.100         Fa0/0             10 00:03:54    5   200  0  5
0   192.168.200.5           Fa0/0             13 00:09:18    8   200  0  5

R5#sh ip eigrp neighbors 
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   192.168.200.100         Et0/0             13 00:04:00    3   200  0  5
0   192.168.200.3           Et0/0             13 00:09:24    4   200  0  6

So R3 and R5 see each other as neighbors. And just for grins, I went ahead and put stark into the EIGRP instance as well, and redistributed my connected routes from stark into eigrp (this proves that stark is in fact in layer 3 mode)

R3#sh ip ro
C    192.168.200.0/24 is directly connected, FastEthernet0/0
D EX 192.168.55.0/24 
           [170/28416] via 192.168.200.100, 00:05:06, FastEthernet0/0
D EX 192.168.4.0/24 [170/28416] via 192.168.200.100, 00:05:06, FastEthernet0/0
D EX 192.168.3.0/24 [170/28416] via 192.168.200.100, 00:05:06, FastEthernet0/0

As you can see, R3 is seeing my redistributed routes from stark, sourced from 192.168.200.100


HSRP is up

R3#sh standby 
FastEthernet0/0 - Group 1
  State is Standby
    1 state change, last state change 00:10:45
  Virtual IP address is 192.168.200.1
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.876 secs
  Preemption enabled
  Active router is 192.168.200.5, priority 110 (expires in 9.235 sec)
  Standby router is local
  Priority 100 (default 100)
  IP redundancy name is "hsrp-Fa0/0-1" (default)

R5#sh standby
Ethernet0/0 - Group 1
  State is Active
    2 state changes, last state change 00:13:35
  Virtual IP address is 192.168.200.1
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.512 secs
  Preemption enabled
  Active router is local
  Standby router is 192.168.200.3, priority 100 (expires in 8.156 sec)
  Priority 110 (configured 110)
  IP redundancy name is "hsrp-Et0/0-1" (default)
R5#

I'm not seeing EIGRP go up and down, and I'm running mtr to keep a running traceroute from my laptop (connected to stark via an AP) for 1000 packets

tyrion.local (0.0.0.0)                                                                      Sat May 14 02:42:11 2011
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                            Packets               Pings
 Host                                                                     Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.4.1                                                            0.0%  1182    4.0   3.2   1.0  20.5   1.5
 2. 192.168.200.1                                                          0.0%  1182    4.8   4.2   1.9  37.7   2.3

So yeah, a switch in layer 3 mode involved with two routers running EIGRP and HSRP is not a death sentence. If the switch being in layer 3 mode causes problems, it's one of 4 things:

#1 code problem
#2 platform problem
#3 configuration problem
#4 design problem

Now, I could probably be convinced that a 2960 with ip routing enabled is causing a problem. That platform isn't a true layer 3 switch, and it only gained the little layer 3 capability it has recently. So I'd buy either a code problem, or a platform problem.

But I cannot accept that the solution for this problem is simply 'disable ip routing on the switch'. That is poor troubleshooting. If your design calls for the switch to be layer 3 capable, then that solution is flat out unacceptable, and whatever problem you had just graduated to a design problem.

If the switch having ip routing turned on is the entire problem, can you explain why? If not, then all you're doing is shotgun diagnostics and turning stuff on and off at random to see what works. You should not be satisfied with that answer. If you encounter this in deployment and implement a nasty hack to solve the problem, it's more likely than not going to come back and bite you on the ass. If you're using this solution as part of your studying, then you're picking up very bad habits that will not serve you well in your career.

Now, with all that being said, please understand, I'm not picking on you. I'm just a rather brusque individual.

The symptoms the OP is showing are classic indications of packet loss. Those are both symptoms of the other router not seeing all of the hello packets that the given protocol is sending. That's the place to begin troubleshooting.

Ok, may went overboard to tell him that's the way to fix it. There is no way we are going to exactly know without having any more information. To tell you the true when I saw the output and then I scroll down I saw that lazy dog post some kind of topology and he mention that he was doing in GNS3. Now, you made sound like there is no way that an enable ip routing on a switch will not kill a network and I may be wrong.

After I saw re-read the post again, it looks like the network was already up and this is an outage that happened, so it this case, I agree I don't think it is not an ip routing issue.

Now by enable ip routing, the switch will become a layer 3 switch instead of layer 2 and as a result, it will depend on its routing table to route packet, including packet that its generate itself. THis situation means that the configure default gateway will not longer be used to route packet.

In your network is going to work because you design it to work like that, but if you have different subnet and more complicated network, a design network with a layer 2 has to stay layer 2 if not you may or may not have problems.

I jump into the confusion because I thought this was a lab issue and the logs look the same as the one that I was getting.

And thats fine, I don't think you are picking on me. I'm not a CCIE, I'm still a lot to learn and there is something that I'm bad is that I'm not good explaining myself. I may know the answer, but sometime it is hard for me to explain.

If everything that I wrote is wrong feel free to knock me down, that is the only way to learn.

shednik

Good discussion but I seriously hope the op is not having the issue anymore this was posted in 2006

joe

Forsaken_GA

amb1s1 wrote: »

Now by enable ip routing, the switch will become a layer 3 switch instead of layer 2 and as a result, it will depend on its routing table to route packet, including packet that its generate itself. THis situation means that the configure default gateway will not longer be used to route packet.

This is where the breakdown is occurring, I think.

Just because a switch has layer 3 enabled does not mean it doesn't have any switching enabled. In the example of what I was doing above, I could have just as easily not configured my 3550 with an SVI and kept it out of the routing domain entirely. The two ports in VLAN200 would would have used the switch solely for layer2 transit. They were on the same layer 2 network regardless, so there was no routing involved for them to send their hello's to each other, traffic would never have left the subnet.

I don't have a 2960 to test with, but I suspect if you just didn't configure an SVI for the vlan you had you had the two routers connecting to, that would probably take care of the problem.

Either way, anyone trying to use 2960's in place of real layer 3 switches for CCIE studies is being foolish.

Forsaken_GA

shednik wrote: »

Good discussion but I seriously hope the op is not having the issue anymore this was posted in 2006

joe

Well, the guy that reopened it did so saying he had the same thing happen, but that was back in October 2010.

There was never any resolution posted, so while the problem may no longer be valid for the person who original posted the question, the discussion may still prove of some use to others.

I think Lazydog made the mistake of immediately assuming HSRP was applicable to the bottom of the topology where the 2960's were. If I'm reading the topology and the guy who originally posted it correctly, HSRP would actually be applied in the upper portion of the topology, where the 4507's share a switch with a 3821. So the redundancy is being applied to ingress traffic to the network instead of egress traffic.

So I'd be willing to bet there's a configuration issue, as that scenario should work absolutely fine.

It's also possible that the switch is munging multicast traffic, and the two 4507's are dropping EIGRP adjacency because of that. I'd be interested to know if using neighbor commands to establish unicast relationships had any effect on the scenario.

This is why it's bad to jump to conclusions! It could be any number of underlying problems, and immediately saying things like EIGRP and HSRP don't work together is acting like an end user - making assumptions about what the actual problem is instead of actually diagnosing it properly. Symptom does not equal root cause.

amb1s1

Forsaken_GA wrote: »

This is where the breakdown is occurring, I think.

Just because a switch has layer 3 enabled does not mean it doesn't have any switching enabled. In the example of what I was doing above, I could have just as easily not configured my 3550 with an SVI and kept it out of the routing domain entirely. The two ports in VLAN200 would would have used the switch solely for layer2 transit. They were on the same layer 2 network regardless, so there was no routing involved for them to send their hello's to each other, traffic would never have left the subnet.

I don't have a 2960 to test with, but I suspect if you just didn't configure an SVI for the vlan you had you had the two routers connecting to, that would probably take care of the problem.

Either way, anyone trying to use 2960's in place of real layer 3 switches for CCIE studies is being foolish.

Makes a lots of senses. I love this type of discussions, when you take something and kind dissemble into pieces and then you see everything clear. Thanks