VRRP Working Group Atul Bansal
INTERNET DRAFT (FORE Systems)
draft-ietf-vrrp-lane-00.txt Rob Enns
(FORE Systems)
Rob Montgomery
(Cabletron Systems)
Expires October 1999
VRRP Operation over ATM LAN Emulation
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Draft can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of in Internet-Drafts Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This specifies the application of the Virtual Router Redundancy
Protocol (VRRP) over networks built using the ATM Forum LAN Emulation
protocol (LANE).
1. Introduction
The Virtual Router Redundancy Protocol (VRRP) [1] specifies a
protocol used to provide dynamic failover in forwarding
responsibility for a set of IP addresses. VRRP provides high
availability of a default forwarding path without requiring hosts to
run routing or router discovery protocols.
Bansal, Enns, Montgomery [Page 1]
INTERNET DRAFT Expires October 1999
ATM Forum LAN Emulation (LANE) [2,3] specifies a protocol used to
emulate Ethernet/IEEE 802.3 and Token Ring/IEEE 802.5 LANs on an
Asynchronous Transfer Mode (ATM) network. LANE is used to extend LAN
connectivity over an ATM backbone.
This memo specifies the behavior required of a LANE client in order
to interoperate with VRRP.
2. Discussion
VRRP operates by electing a master router which will respond to a
well known virtual MAC address for the virtual router. When a new
master router is elected, the physical device responding to the
virtual MAC address may change. LANE operates by maintaining a set of
mappings from MAC addresses to ATM addresses. When running VRRP on a
LANE network, the LANE protocol must be notified when a new master
router is elected so that it can update its MAC address to ATM
address mapping for the virtual router's MAC address.
There are at least two ways of notifying the LANE protocol of a
change in a MAC address to ATM address mapping. The first is to have
the master router register the virtual MAC address with the LANE
Server (LES). When that router ceases to be the master, it would
unregister the virtual MAC address with the LES and the new master
would register the virtual MAC address. This method will result in
high failover times should the original master router neglect to
unregister the virtual MAC address when it fails.
A second way to notify the LANE protocol of a change in a MAC address
to ATM address mapping is to have the LANE client on a VRRP capable
router register as a proxy client. The master router will respond to
LE_ARP requests for the virtual MAC address with its ATM address.
When a router becomes the master, it first sends an LE_NARP request
to indicate that the MAC to ATM address mapping for the virtual MAC
address has changed. This method is dicussed in more detail in
section 3.
Two common configurations are envisioned when running VRRP over LANE.
In the first, the LANE client is co-located with the router running
VRRP. In other words, the LANE client represents one of the router's
network interfaces. In the second scenario, a router attached to a
LAN such as Ethernet is located behind a bridge running a LANE
client. The scenarios are considered in detail in the following
sections.
Bansal, Enns, Montgomery [Page 2]
INTERNET DRAFT Expires October 1999
2.1 Scenario 1
In this scenario we assume the all routers running VRRP are attached
to the LANE network. This scenario is analagous to the first sample
configuration in [1], replacing the Ethernet/Token Ring/FDDI network
with a LANE network.
VRID=1
+-----+ +-----+
| MR1 | | BR1 |
| | | |
+-----+ +-----+
IP A ---------->* *<--------- IP B
| |
| |
| |
@@@@@@@@@@@@@@@+@@@@@@@@@@+@@@@@+@@@@@@@@+@@@@@@@@+@@@@@@@@+@@
^ ^ ^ ^
| | | |
(IP A) (IP A) (IP A) (IP A)
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
Legend:
@@@+@@@+@@@+@@ = LANE network
H = Host computer
MR1 = Master Router
BR1 = Backup Router
* = IP Address
(IP) = default router for hosts
In the above configuration, the end-hosts install a default route to
virtual router #1's IP Address (IP A). All the end-hosts (H1-H4) bind
(IP A) with the virtual router's (VRID=1) virtual mac address (VMAC1)
which in turn is bound to MR1's link layer address (MR1 LEC's ATM
Address).
Upon MR1 failure, BR1 becomes the master and sends out gratutious
APR with VMAC1 as the source address and LE_NARP for VMAC1.
The gratutious ARP packet with virtual router's mac address (VMAC1)
as a source triggers learning bridges to update their station
learning cache. The station learning is an efficiency improvement in
extended LAN topologies [1]. The station learning handling by the
LANE bridges for the correct operation of VRRP in various extended
LAN topologies is described later in Scenario 2.
Bansal, Enns, Montgomery [Page 3]
INTERNET DRAFT Expires October 1999
The LE_NARP causes the removal of virtal router mac address VMAC1 to
MR1's atm address binding in all the end-hosts. The next IP packet
transmitted by an end-host causes the end-host to send an LE_ARP
request for VMAC1. The backup router BR1 sends the LE_ARP response
for VMAC1 with its own ATM address which reetablishs the binding
between the VMAC1 and the backup router's ATM address at the end-
host.
The following scenario is analogous to the scenario 1 expecpt that
half of the hosts are attached directly to the LANE network and the
other half of the hosts are attched behind the LANE bridges. Since
LANE bridges implementing LEC are no different than the LEC
implemented on the end-hosts, LE_NARP is sufficient for the failover
and there is no special processing requirements for LANE bridges.
VRID=1
+-----+ +-----+
| MR1 | | BR1 |
| | | |
+-----+ +-----+
IP A ---------->* *<--------- IP B
| |
| |
| |
@@@@@@@@@@@+@@@+@@@@@@@@@@@@+@@@@@@@@+@@@@@@@@@@+@@@@@@@@@
| | |
| (IP A) (IP A)
+---+---+ | |
| B1 | +--+--+ +--+--+
| | | H1 | | H2 |
+---+---+ +-----+ +-----+
|
|
---+------+------+------
| |
(IP A) (IP A)
| |
+--+--+ +--+--+
| H3 | | H4 |
+-----+ +-----+
Legend:
@@@+@@@+@@@+@@ = LANE network
---+---+---+-- = Ethernet network
H = Host computer
MR1 = Master Router
BR1 = Backup Router
Bansal, Enns, Montgomery [Page 4]
INTERNET DRAFT Expires October 1999
B1 = LANE Bridge
* = IP Address
(IP) = default router for hosts
2.3 Scenario 2
In this scenario we assume the all routers running VRRP are attached
to the Ethernet network behind the bridges. Furthermore, there are
two virutal routers backing each other. Half of the hosts are using
one virtual router and the other half of the hosts are using the
second virtual router.
VRID=1
+-----+
| MR1 |
| & | +-----+
| BR2 | | H3 |
+-----+ +--+--+
IP A --------->* |
| (IP A)
| |
-------+---+-------------+--
|
+---+---+ +-----+ +-----+
| B1 | | H1 | | H2 |
| | +--+--+ +--+--+
+---+---+ | |
| (IP A) (IP B)
| | |
@@@@@@@@@@+@@@@@@@@@@@@@@@+@@@@@@+@@@@@@@@@@@+@@@@@@
|
+---+---+
| B2 |
| |
+---+---+
|
-+--------+---+------
| |
(IP B) |
| *<---------- IP B
+--+--+ +--+--+
| H4 | | MR2 |
+-----+ | & |
| BR1 |
+-----+
VRID=2
Bansal, Enns, Montgomery [Page 5]
INTERNET DRAFT Expires October 1999
Legend:
@@@+@@@+@@@+@@ = LANE network
---+---+---+-- = Ethernet network
H = Host computer
MR1, MR2 = Master Router
BR1, BR2 = Backup Router
B1,B2 = LANE Bridges
* = IP Address
(IP) = default router for hosts
In the above configuration, MR1 is the master for virtual router #1
serving IP address (IP A) and MR2 is the master for virtual router #2
serving IP address (IP B). The end-hosts H1 and H3 install a default
route to the IP address of virtual router #1 (IP A) and bind (IP A)
with VMAC of the virtual router #1 (VMAC1) which in turn is bound to
the Bridge1's ATM Address (VMAC1 is behind bridge 1). Similarly,
end-hosts H2 and H4 install a default route to (IP B) and bind VMAC2
to Bridges2's ATM address.
Upon MR1 failure, BR1 becomes the master and send out the gratutious
ARP with VMAC1 as the source mac address. The gratutious ARP packet
with virtual router's mac address (VMAC1) as a source triggers Bridge
1 and Bridge2 to update their station learning cache. Upon
detecting the station move, both bridges sends out LE_NARP for VMAC1.
The LE_NARPs causes the removal of the VMAC1 to Bridge1 atm address
binding in all LANE attached end-hosts and bridges. The next IP
packet on LANE attached device triggers LE_ARP request for VMAC1. BR2
sends out the LE_ARP response for VMAC1 with BR2's ATM address which
reetablishs the binding between the VMAC1 and the bridge2's ATM
address at the LANE attahced device.
In the above configuration, it is important that both bridges B1 and
B2 send out LE_NARP for VMAC1. The generation of LE_NARP by all
bridges that detect station move protects from the bridge failures
(B1 failure in this case). The station learning triggering LE_NARP
generation by LANE bridges is essential for the correct operation of
VRRP in various extended LAN topologies as descibed above.
3.0 Detail Description of VRRP over LANE
A VRRP Router co-located with LEC must register as a proxy client and
can optionally register its own MAC address with a LES (for pings,
telnet, SNMP, etc.)
A LANE bridge which could have a VRRP router attached on the LAN
ports must register as a proxy client.
Master must respond for Virtual Router IP address with VMAC
Bansal, Enns, Montgomery [Page 6]
INTERNET DRAFT Expires October 1999
Matser must respond to LEARP for VMAC with its own ATM address and
must set the remote bit.
Upon becoming the Master, it must send out gratutious ARPs with VMAC
as source for every Virtual Routers IP address. This is needed for
bridges to relearn the station addresses on the correct port.
Master must send VRRP advertisements using VMAC as a source and
follow forwarding rules defined in [1].
When Backup router becomes the master, the new master also sends out
gratutious ARPs with VMAC as source to update learning bridges
caches.
The new master sends LE_NARP with its own LECID, its own ATM address
as a source ATM addresss and the target ATM address as 0x00. [This is
a change from the [2] and [3] (Sec 7.4 LE_NARP frame format). [2]and
{3] requires that the LE_NARP frame should use the ATM address of the
LE client which was previously representing VMAC.] Upon receiving
LE_NARP with the Target ATM address of 0x00, all clients (proxy and
non-proxy) should remove VMAC to ATM binding (and to VC binding if
exists). By removing the ATM/VMAC binding, the data packets will be
forwarded via BUS until new binding is established.
Note that LE_NARP as defined in [2] has been replaced by Targetless
LE_ARP Request defined in [3] (Sec 7.1.30). This memo does not
mandate generation of Targetless LE_ARP Requests. This memo does
require LECs to follow the request generation time limits as defined
in [2] and [3].
A LANE bridge must send out LE_NARP upon detecting the station move.
4.0 Security Consideration
This memo does not define any new protocol packets. Therefore, it
follows the same security mechanisms as defined in [1-3].
References
[1] Virtual Router Redundancy Protocol, RFC 2338, Internet Engineering
Task Force, April 1998. ftp://ftp.ietf.org/rfc/rfc2338.txt.
[2] LAN Emulation over ATM Version 1.0, The ATM Forum, January, 1995.
ftp://ftp.atmforum.com/pub/approved-specs/af-lane-0021.000.pdf.
[3] LAN Emulation over ATM Version 2.0 - LUNI Specification, The ATM Forum,
July, 1997. ftp://ftp.atmforum.com/pub/approved-specs/af-lane-0084.000.pdf.
Bansal, Enns, Montgomery [Page 7]
INTERNET DRAFT Expires October 1999
Authors' Addresses
Rob Enns Atul Bansal
FORE Systems FORE Systems
1805 McCandless Drive 1595 Spring Hill Road
Milpitas, CA 95035 USA Vienna, VA 22182 USA
Phone: +1 408 719 3000 Phone: +1 703 245 4544
Email: rpe@fore.com Email: bansal@fore.com
Rob Montgomery
Cabletron Systems
Pease Training Center
Box 5005 ,35 Industrial Way
Rochester, NH 03866-5005 USA
Phone: +1 603 337-9258
EMail: rmontgom@cabletron.com
Bansal, Enns, Montgomery [Page 8]
