vrrp issue

srikanth.ccna2010

Router1:

2901#sh vrrp all
GigabitEthernet0/0 - Group 1
State is Master
Virtual IP address is 172.16.254.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled, delay min 3 secs
Priority is 110
Track object 1 state Up decrement 15
Authentication text, string "sapphire"
Master Router is 172.16.254.100 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec

GigabitEthernet0/1 - Group 2
State is Master
Virtual IP address is 172.20.254.254
Virtual MAC address is 0000.5e00.0102
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Track object 2 state Up decrement 15
Authentication text, string "sapphire"
Master Router is 172.20.254.100 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec

Router2:

1811#sh vrrp all
FastEthernet0 - Group 1
State is Master
Virtual IP address is 172.16.254.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Track object 1 state Up decrement 15
Authentication text "sapphire"
Master Router is 172.16.254.101 (local), priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec

FastEthernet1 - Group 2
State is Backup
Virtual IP address is 172.20.254.254
Virtual MAC address is 0000.5e00.0102
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Track object 2 state Up decrement 15
Authentication text "sapphire"
Master Router is 172.20.254.100, priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec (expires in 3.177 sec)

srikanth.ccna2010

the problem is both routers showing as master

AlanJames

any access lists on the interface?

tanix

I think you need to explain what your objective is and why you configured it the way you did to achieve that.

By doing such, you might find the problems with your configuration in doing so and won't need to ask the question in the first place.

As it is now, I think I see multiple problems depending on your objective requirements.

Why do you use two groups?

The answer to that may solve your problem depending on objective.

Why are both groups using the same gateway?

The answer to that may also solve your problem depending on objective.

Are you doing multiple group load balancing?

Yes or no to that may answer as to what you might be doing wrong from the questions I asked above.



As I said, I am unsure what your objective is, I could speculate, but I think it customary for one to lay out their objective and then explain their problem so people do not waste their time truing to divine the issue.

chmorin

tanix wrote: »

As I said, I am unsure what your objective is, I could speculate, but I think it customary for one to lay out their objective and then explain their problem so people do not waste their time truing to divine the issue.

Agreed. Some people tell us the problem without giving us the information to help them, but you tried to give us the information to help you but never told us your problem.

Heero

looks like a problem with the two routers not seeing each other on the 172.16.254.0 subnet. They seem to be just going along their way being masters because they don't see any other device participating in VRRP. Consider using debugs to see if either is seeing VRRP messages from the other for that group.

Forsaken_GA

If I remember correctly, issues like this are usually caused by the two routers not having layer 2 adjacency. How is everything wired together?

Netwurk

Forsaken_GA wrote: »

If I remember correctly, issues like this are usually caused by the two routers not having layer 2 adjacency. How is everything wired together?

I agree with Forsaken's theory as to the layer 2 adjacency issue. Layer 1 is also obviously important.

VRRP config is pretty straightforward, details here:

Virtual Router Redundancy Protocol [Cisco IOS Software Releases 12.0 ST] - Cisco Systems

Let us know how you make out

Forsaken_GA

To add on to this, if I remember correctly, the VRRP nodes communicate with each other via multicast, so if the path to communicate between the two is setup as such that the multicasts aren't propagated, the two nodes won't be able to hear each other, so they'll both assume the other is dead and transition into the master state.

I've also seen an authentication mismatch cause both nodes to go active, but it looks like that's all correct from the output you posted.

srikanth.ccna2010

tanix wrote: »

I think you need to explain what your objective is and why you configured it the way you did to achieve that.

By doing such, you might find the problems with your configuration in doing so and won't need to ask the question in the first place.

As it is now, I think I see multiple problems depending on your objective requirements.

Why do you use two groups?

The answer to that may solve your problem depending on objective.

Why are both groups using the same gateway?

The answer to that may also solve your problem depending on objective.

Are you doing multiple group load balancing?

Yes or no to that may answer as to what you might be doing wrong from the questions I asked above.



As I said, I am unsure what your objective is, I could speculate, but I think it customary for one to lay out their objective and then explain their problem so people do not waste their time truing to divine the issue.

Thank you for your response.


The thing is i want to do failover. Why two groups because i have two different networks. Inbound ACL's are enabled for multicast packets.
Group 2 is working fine. The problem is with group 1. I have checked the priority and track also.

Provide some troubleshooting steps on vrrp. And give me some case studies on vrrp and hsrp if you have.

Router otherside is also going to switch not wan.

Where can i find good video tutorials?

Once again thank you......

GT-Rob

The problem is not with tracking, or priority, or really anything to do with your VRRP config.


The problem is the two routers do not have IP reachability on the 172.16.254.0 subnet to each other. They obviously do on the other subnet, which is why it works.


Thats what they mean by L2 problems (or L3, however you look at it).



From one router, can you ping the 172.16.254.0 interface of the other? Im going to guess not. Troubleshoot that, and this should solve itself.

tanix

srikanth.ccna2010 wrote: »

Thank you for your response.


The thing is i want to do failover. Why two groups because i have two different networks. Inbound ACL's are enabled for multicast packets.
Group 2 is working fine. The problem is with group 1. I have checked the priority and track also.

Provide some troubleshooting steps on vrrp. And give me some case studies on vrrp and hsrp if you have.

Router otherside is also going to switch not wan.

Where can i find good video tutorials?

Once again thank you......

I think others here have at least pointed out the problem you are having.

I misread your config and didn't catch they were in different sub nets (which is why I was confused *chuckle*). As they have said, your configs look good and the issue is likely a connectivity one between.

I would do as others have suggested, start from the basics of connectivity and eliminate possible problems as you move up to the higher protocol configs.

Most of the books I have read focus on a step based approach as such by first eliminating the basic requirements and moving up each stage checking the higher layer requirements. In fact, the CCNP process of planning and verification discussed by the Cisco books specifies just that before implementation.

Depending on how you have things configured at those levels, as you move up through checking them you should eventually find what is causing your problem.

Also, don't forget to use debugging at various stages to check the different protocols you are evaluating. This should help you see a connectivity issue right off the bat if it is one or help you to identify an issue with one.

srikanth.ccna2010

thank u for all. The problem got resolved.
Resolution...allowed multicast packets

AlanJames

so it was a access-list block the hello messages? ;0