cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
635
Views
0
Helpful
9
Replies
Highlighted
Beginner

VRRP causes interference with edge router

In our environment we have multiple routers in a DMZ that I had tried to deploy VRRP. After one of the routers "failed" (VZW1) and the VRRP switched to the backup (VZW2) , this caused interruptions to our primary internet feed. And by interruptions I mean just that, the actual internet access was not taken down, but access was slowed and intermittent. To make things more complicated, it was only one of our edge routers that was affected, but our secondary edge feed was not. Both the edge routers run VRRP, and we also have two CPE routers with HSRP.

From what little knowledge I do have with VRRP, I do not see how this could have affected our network, why it would only affect one edge router. From the outside internet I could connect to that edge router without issue. It was devices/servers behind that had issues. 

So I am beyond curious to understand how VRRP could have been the cause. Any thoughts or comments would really be appreciated.

VZW1 config;

vrrp 1 ip 192.168.0.117
vrrp 1 timers advertise 3
vrrp 1 timers learn
vrrp 1 priority 250
vrrp 1 authentication text 20v20

VZW2 config:

vrrp 1 ip 10.1.1.10
vrrp 1 timers advertise 3
vrrp 1 timers learn
vrrp 1 authentication text 20v20

2 ACCEPTED SOLUTIONS

Accepted Solutions
Highlighted
Participant

sean,

sean,

This design is a little confusing. Are your VZW routers and your Edge routers all on the same VLAN? If so, this could be an issue where all 4 routers are in the same VRRP group but are running different VRRP VIPs. Typically, each VLAN will only have a single VRRP or HSRP VIP where all routers in the group are sharing the same VIP. In this diagram it looks like theyre all running in the same group but the VZW routers are sharing a different VIP than the Edge Routers. Also, the text authentication on VZW1 does not match that of VZW2, not sure if thats a typo. 

View solution in original post

Highlighted
Participant

sean,

sean,

That is correct, in a typical deployment of VRRP (or any FHRP for that matter) there should be a 1 to 1 correlation between the Group # and the VIP being shared. One VIP to one group. Ive honestly never tried to run two VIPs in the same group but can easily see how that might cause some issues in the group. The Virtual MAC address that represents the VIP is partially made up of the group # (the last 2 hex digits in the Virtual MAC).You should run Edge routers in a different group # than the VZW routers otherwise you may be with a type of "dual-active" scenario where you have 2 Masters in the same group fighting over which VIP they're going to use etc. Which in theory should be impossible because even if they have the same priority, the router with the higher IP will win the master role. but in this case with two different VIPs, I'm not sure. Like I said I've never tried this in production or in a lab but if I had to guess, that is at least part of the issue. 

View solution in original post

9 REPLIES 9
Highlighted
Hall of Fame Expert

Can you clarify?

Can you clarify?

In your diagram, the firewall connects to ISP2 only?

Also, is there a typo in the config as I don't see the physical IP addresses? 

Highlighted
Beginner

The firewall's default

The firewall's default gateway is 192.168.0.10 which is VRRP between the 2 edge routers, with R1 Edge as the primary. As for physical IP, I don't understand what you mean?

Highlighted
Hall of Fame Expert

Each interface needs to have

Each interface needs to have a physical IP and a virtual (vip) ip.  The Virtual IP needs to be the same on both routers and the physical IPs need to be different.

Have a look at this example:

http://www.pearsonitcertification.com/articles/article.aspx?p=2141275

HTH

Highlighted
Beginner

Sorry I got confused.  Here

Sorry I got confused.  Here is the full existing config for the edge routers that I have no issues with;

R1 Edge
interface GigabitEthernet0/0/1
ip address 192.168.0.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip nbar protocol-discovery
ip flow monitor MONITOR-1 input
negotiation auto
vrrp 1 ip 192.168.0.10
vrrp 1 timers advertise 3
vrrp 1 timers learn
vrrp 1 priority 250
vrrp 1 authentication text 10v10

R2 Edge
interface GigabitEthernet0/0/1
ip address 192.168.0.5 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip nbar protocol-discovery
ip flow monitor MONITOR-1 input
negotiation auto
vrrp 1 ip 192.168.0.10
vrrp 1 timers advertise 3
vrrp 1 timers learn
vrrp 1 authentication text 10v10

And here are the configs (since removed) for the 2 VZW routers that I did have the issue with;

VZW1
interface FastEthernet4
ip address 192.168.0.118 255.255.255.0
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
vrrp 1 ip 192.168.0.117
vrrp 1 timers advertise 3
vrrp 1 timers learn
vrrp 1 priority 250
vrrp 1 authentication text 20v20

VZW2
interface FastEthernet4
ip address 192.168.0.119 255.255.255.0
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
vrrp 1 ip 192.168.0.117
vrrp 1 timers advertise 3
vrrp 1 timers learn
vrrp 1 authentication text 20v20

Highlighted
Participant

sean,

sean,

This design is a little confusing. Are your VZW routers and your Edge routers all on the same VLAN? If so, this could be an issue where all 4 routers are in the same VRRP group but are running different VRRP VIPs. Typically, each VLAN will only have a single VRRP or HSRP VIP where all routers in the group are sharing the same VIP. In this diagram it looks like theyre all running in the same group but the VZW routers are sharing a different VIP than the Edge Routers. Also, the text authentication on VZW1 does not match that of VZW2, not sure if thats a typo. 

View solution in original post

Highlighted
Beginner

Yes, that was a typo I just

Yes, that was a typo I just corrected the text. And yes, they are on the same VLAN, but as I understood since the Edge routers were configured for 192.168.0.10 and the VZW were configured for 192.168.0.117, this would not conflict as the Edge routers were not configured for that virtual IP. 

Here is where I am beginning to make some sense of things, when I configured the VZW routers to use VRRP, I just did "vrrp 1 ....:" without thought. I see now that the group should have been a different ID #, is that correct? "vrrp 2" is what I could have used?

And since Edge router 1 had the same group number, and had the priority at that time, I see now how it would have affected connections only to that one edge feed, but not the other

Highlighted
Participant

sean,

sean,

That is correct, in a typical deployment of VRRP (or any FHRP for that matter) there should be a 1 to 1 correlation between the Group # and the VIP being shared. One VIP to one group. Ive honestly never tried to run two VIPs in the same group but can easily see how that might cause some issues in the group. The Virtual MAC address that represents the VIP is partially made up of the group # (the last 2 hex digits in the Virtual MAC).You should run Edge routers in a different group # than the VZW routers otherwise you may be with a type of "dual-active" scenario where you have 2 Masters in the same group fighting over which VIP they're going to use etc. Which in theory should be impossible because even if they have the same priority, the router with the higher IP will win the master role. but in this case with two different VIPs, I'm not sure. Like I said I've never tried this in production or in a lab but if I had to guess, that is at least part of the issue. 

View solution in original post

Highlighted
Beginner

Thanks all for your help on

Thanks all for your help on this, it was a good lesson to learn. The role of the 2 VZW routers are for a VTI tunnel, and I was paying more attention to configuring that tunnel than anything else. Now this all makes perfect sense. Again, thanks all, this really helped me out a lot

Highlighted
Participant

You're welcome sean, thanks

You're welcome sean, thanks for the positive feedback. 

CreatePlease to create content
Content for Community-Ad