Problems running HSRP and EIGRP
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
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
![icon_cool.gif](https://us.v-cdn.net/6030959/uploads/images/smilies/icon_cool.gif)
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
Ryan McAuliffe
Network Officer
SCADA & Information Systems
Western Power
T: (08) 9427 4255 | M: 040 017 3545
E: ryan.mcauliffe@westernpower.com.au
W: www.westernpower.com.au
Network Officer
SCADA & Information Systems
Western Power
T: (08) 9427 4255 | M: 040 017 3545
E: ryan.mcauliffe@westernpower.com.au
W: www.westernpower.com.au
Comments
-
darkuser Member Posts: 620 ■■■□□□□□□□
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 .....rm -rf / -
Humper Member Posts: 647
you honestly expect us to diagnose your problem with just the debugs? We need a topology diagram and some configs to help you more...Now working full time! -
mikej412 Member Posts: 10,086 ■■■■■■■■■■
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.
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...:mike: Cisco Certifications -- Collect the Entire Set! -
miguel.corona Registered Users Posts: 1 ■□□□□□□□□□
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 Member Posts: 1,096 ■■■□□□□□□□
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.
-PeanutWe cannot have a superior democracy with an inferior education system!
-Mayor Cory Booker -
arun.mohan Registered Users Posts: 1 ■□□□□□□□□□
[FONT="]CSCdz75312 - EIGRP does not work when seq number becomes negative[/FONT]
[FONT="] [/FONT]
[FONT="]Symptom:[/FONT][FONT="] [/FONT][FONT="]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="] [/FONT][FONT="]Workaround:[/FONT][FONT="] [/FONT][FONT="]Restarting EIGRP on the router originating the large sequence numbers will reset the sequence numbers to zero and resolve the problem.[/FONT][FONT="] [/FONT][FONT="]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 Member Posts: 408
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 Member Posts: 4,024
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 Member Posts: 19 ■□□□□□□□□□
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.--
Regards
Robert
Smile....... it increases your face value! -
amb1s1 Member Posts: 408
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 Member Posts: 4,024
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 Member Posts: 408
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 Member Posts: 4,024
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.100R3#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 upR3#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 packetstyrion.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 Member Posts: 408
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.100R3#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 upR3#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 packetstyrion.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 Member Posts: 2,005
Good discussion but I seriously hope the op is not having the issue anymore this was posted in 2006
joe -
Forsaken_GA Member Posts: 4,024
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 Member Posts: 4,024
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 Member Posts: 408
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.