Subject: Protecting different subnets within 1 virtual router on multinett ed interfaces

From: "A. K. Srikanth" <[email-masked]>
Date: Tue, 3 Apr 2001 14:10:34 -0400

I don't see a good reason why the following will not work even though the it
makes sense to restrict a virtual router within a subnet.. can anybody else
?

    Look at a multinetted case say an interface with IP address 1.1.1.1 and
2.2.2.1 on two different subnets on the same physical interface of Router
R1... This is backed up by Router R2 which is configured with multinetted
interfaces 1.1.1.2 and 2.2.2.2.... So essentially there is 1 virtual Router
V1 backing up both 1.1.1.1 and 2.2.2.1

As long as you pick one of the subnets to be the primary (say 1.x) address
and use that IP address as the source IP in VRRP advertisments, you could
still have hosts on the network some on the 1.0 net and some on the 2.0 net
and have VRRP work properly... 

Because the backups are multinetted, IP on 1.0 net will allow the packet
through to get to VRRP and VRRP will know which is the primary and which
address is in the associated table and therefore will be able to protect the
interface.We would be using the same VRRP MACs

The only restriction on this setup is that the backup routers must have a
similar multinetted configuration... 

I guess technically I am just piggybacking 1 interface on the other.... Does
anybody see a problem with this ?

Thanks,
Ayikudy Srikanth

---

From: "Erick B." <[email-masked]>
Date: Tue, 3 Apr 2001 12:28:30 -0700 (PDT)

Why not use a Virtual IP for each subnet (multiple
groups/VRIDs). I'm not a fan of multinetting and it
should only be used for temporary cutovers to new
addressing scheme. 

The term "virtual router" is confusing and so are some
other terms in the RFC. IMHO there is no "virtual
router" but a "virtual default gateway" for hosts.

The gear I have used VRRP on sources it from the
primary (or first) IP address on the interface. Same
for routing protocols. 

> anybody see a problem with this ?

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

---

From: "Danny J. Mitzel" <[email-masked]>
Date: Tue, 03 Apr 2001 18:45:58 -0700

>> anybody see a problem with this ?

the configuration you describe is exactly how the protocol is intended
to be deployed in an multiple IP subnets on single wire.

one deficiency in the scenario you describe is that typically each 
of the routers should be backing each other up.  in your example you
have a VRID associated with the .1 router addresses and the .2
router backs those up.  you should also deploy a VRID associated with
the .2 router addresses and the .1 router backs those up.  that way
if the .1 router ever sends an ICMP redirect to the host to send 
traffic through the .2 router then you'll still have redundancy
for that traffic.

danny

---

From: "Danny J. Mitzel" <[email-masked]>
Date: Tue, 03 Apr 2001 19:00:26 -0700

>> Why not use a Virtual IP for each subnet (multiple groups/VRIDs).

reasons to use a single VRID with multiple associated IP address
include:
  - the protocol is designed to support it
  - less configuration
  - less protocol traffic and processing

>> IMHO there is no "virtual router" but a "virtual default gateway" 
>> for hosts.

early RFC used the term ``gateway'' for routers but over time the
preferred usage is ``router'' while ``gateway'' is used to describe
application-level translation/gateway.

an end host may have multiple routes present, whether from admin
static configuration, ICMP redirect, or dynamic routing protocol, etc.
there is no implicit assumption in VRRP that the host is using a
default route (0/0) [although that is a common deployment].  therefore
no reason to imply default routing in the naming.

applying these transforms ``virtual default gateway'' => ``virtual router''.
:-)

danny

---

From: "Erick B." <[email-masked]>
Date: Tue, 3 Apr 2001 23:39:25 -0700 (PDT)

Comments inline...

>   - less protocol traffic and processing

Ahh. I need to review this part of the RFC. Most of
the implentations/configurations I have worked with
always have 1 Virtual IP per VRID/group which is
logical. I need to go play with this to see if I can
get multiple Virtual IPs assigned to one VRID on the
gear I have. 

> application-level translation/gateway.

Ok, then ''virtual gateway'' or ''virtual next-hop''
:) My problem with using the term ''virtual   router''
is that all implementations I'm familiar with use the
real IP address on the interfaces for routing updates,
etc. Are there any implementations out there that use
the VRRP IP address for actual routing functions? I
wouldn't think so as this would break routing since
the VRRP IP is active on one device at a time and
standby on others. 

Just my opinion on the terms since they can be
confusing. But thats why it's a RFC :) 

> gateway'' => ``virtual router''.

Thanks for your reply. 

Erick

---

From: "Danny J. Mitzel" <[email-masked]>
Date: Wed, 04 Apr 2001 11:38:39 -0700

>> the VRRP IP is active on one device at a time and

the ``virtual nexthop'' sounds pretty good.  in general
it is very difficult to come up with a term that by
itself implicitly implies the intent of VRRP operation.
many people come in with preconceptions on similar
terms: ``virtual router'' ``virtual address''
``virtual host'' from other uses in clustering and
high availability.  in the end I think the working group
decided ``virtual router'' was acceptable compromise and then
try to make the RFC text explicit in defining terms and
consistent in their use.  but still haven't reached 
perfection. :-(

there are some ways to inject VRRP addresses into routing for improved
[re]convergence.  but they're highly routing protocol specific and
vendor specific.  in general I prefer to tune the features of the
actual dynamic routing protcol rather than hacks based on VRRP.

danny