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]