- VRRP over Ethernet
- VRRP and Learning Bridges
- VRRP over FDDI
- VRRP over Token Ring
- VRRP over ATM LANE
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
5.5 VRRP over ATM LANE
VRRP over ATM LAN emulation requires enough configuration complexities to have it relegated to a separate IETF draft. We provide an overview of ATM and ATM LAN emulation in Appendix A as a basis for understanding this section. This section takes a closer look at both Ethernet and Token Ring LAN emulation over ATM and the requirements on part of a LAN emulation client (LEC) to interoperate with VRRP. Additionally, we also discuss the differences between LAN emulation version 1 (LANEv1) and LANEv2 with respect to VRRP.
As Appendix A explains, LAN emulation operates below the MAC layer and each LAN emulation client has a unique ATM address. Each LEC maintains a MAC-to-ATM address mapping. So in the case of routers running VRRP over LAN emulation, the LEC will also maintain a virtual MAC-to-ATM address mapping. When a new router becomes the master for a virtual router, VRRP must notify the LANE stack that the router is now adopting the virtual router's MAC address so that the MAC-to-ATM address mapping is updated on that ELAN.
Let us review some key terms that will be used here to explain VRRP over ATM LANE. These are listed in Appendix A.
Address association. When a LEC represents a specific MAC address, that MAC address is said to be associated with the LEC. No two LECs can be associated with the same MAC address in an ELAN at any given instant.
Address disassociation. When a LEC stops representing a MAC address, the LEC is said to have disassociated itself from that MAC address.
Proxy LEC. A proxy LEC is one that does not register its MAC address associations with the LAN Emulation Server (LES). Instead, proxy LEC itself is responsible for replying to LE_ARP requests for the MAC addresses with which it is associated.
Nonproxy LEC. This is not a proxy LEC, that is, it registers its MAC address associations with the LES. In this case, the LES is responsible for replying to LE_ARP requests for MAC addresses associated with a nonproxy LEC.
Targetless LE_ARP_REQUEST /Gratuitous LE_ARP. As Appendix A explains, the LE_ARP request basically asks the LES to provide the querying LEC with the ATM address of the LEC that owns the specified MAC address (target LAN destination) that is present in the body of the request. The querying LEC usually provides its own list of MAC address associations in the same message. However, a targetless LE_ARP_REQUEST allows a LEC to send out an LE_ARP request containing all its associated MAC addresses to nobody in particular, i.e., the target LAN destination field is set to "not present" in the LE_ARP request message. The purpose of this mechanism is to notify all other LECs on its ELAN about its own ATM-to-MAC address associations so that they update their respective tables. A LEC receiving this targetless LE_ARP_REQUEST will inspect its own LE_ARP cache to see if the source LAN destination entry is present; if it is, it will update its cache with the information in the LE_ARP_REQUEST. If the source LAN destination is not in its cache, it simply ignores the targetless LE_ARP_REQUEST.
No Source LE_NARP_REQUEST. A no source LE_NARP_REQUEST is sent out by a LEC to notify all LECs that it no longer represents a particular MAC address or LAN destination. Any LEC receiving this request would immediately remove the MAC-to-ATM address mapping in its ARP cache.
With these definitions in mind, we will now take a look at how VRRP can be implemented over ATM LANE networks. Generally, there are two common configurations used when running VRRP over LAN emulation. In the first, the LEC is colocated with the router running VRRP. In other words, the LANE client represents one of the router's network interfaces and resides within the physical router. This generally means all VRRP routers are directly attached to a LANE network. In the second scenario, a VRRP router attached to a LAN such as Ethernet is located behind a bridge running a LANE client.
5.5.1 VRRP in a LANE Network
In this configuration, all routers running VRRP have ATM interfaces and are directly attached to the LANE network. This is very similar to the configuration in Figure 5-1, except that the physical medium here is ATM instead of Ethernet. Figure 5-7 shows the configuration mapped to the ATM network.
){kind=link}
Figure 5-7 shows two physical routers, R1 and R2, on an emulated LAN (ELAN). V1 is a virtual router with a virtual IP address of IP(V1) = 192.32.15.1 and VRID of 37. Therefore, the VRRP MAC address is MAC(V1)=00:00:5E:00:01:25. This MAC address is mapped to a unique ATM address ATM(R1)=X associated with a LEC for that interface within router R1. This mapping is done by the LEC, in this case router R1, registering this MAC-to-ATM address association with the LAN emulation server. Also, as described later in Appendix A, each LEC has a unique ATM address so that it can be a unique end-station within an ATM network at all times. R1 is the master for the virtual router, and R2 is the backup. Hosts H1 and H2 are configured to use IP(V1) as the IP address of their default router.
)
Figure 5-7. VRRP over LANE in a pure LANE network
R1 will become the master for virtual router V1, since it is the IP address owner. Also, as described later in Appendix A, a single LEC (that is, a single ATM address ) can represent many MAC addresses, but no two LECs can represent the same MAC address at the same time within an ELAN (that is, two different ATM addresses cannot represent or be associated with one MAC address at the same time). This condition, combined with the uniqueness requirement of ATM addresses in an ELAN, implies that we cannot have a concept of a virtual ATM address to which the virtual MAC address is mapped and can float around between master and backup routers as with a virtual MAC address in the case of the ethernet.
Since R1 is the master, it maps the virtual MAC, MAC(V1) to the ATM address X and registers this association with the LES. It then sends out a targetless LE_ARP_REQUEST containing the MAC(V1) bound to its own ATM address X. It will then periodically send VRRP advertisements using the LAN emulation stack (see Appendix A) and with the source MAC address set to its VRRP address and the destination set to the Ethernet multicast MAC address 01:00:5E:00:00:12 encapsulated within an ATM header. The backup for virtual router V1, in this case R2, will listen passively to the advertisements by registering for the multicast MAC address and implement its state machine, as explained in Chapter 3 and 4.
The hosts H1 and H2 on the network are configured to use IP address IP(V1) as their default router address and communicate to their router via standard ATM LAN emulation mechanism (their LEC stack) using ATM address X.
If R1 fails, R2 will take over as the master for V1 and act as the default router. However, this means that R2, whose ATM address is ATM(R2) = Y, must now represent MAC(V1). If R1 relinquishes its master role voluntarily, it will first disassociate itself from MAC(V1) and then send out a no source LE_NARP with the MAC(V1) to ATM(R1) = X mapping. All LECs, including hosts H1 and H2, update their LE_ARP caches to remove this association. If R1 fails without being able to make the address disassociation, the LES detects the control VC failure to the LEC associated with the MAC(V1) and deletes the current binding for R1, that is, MAC(V1) to ATM(R1) association. When the VRRP timer on R2 expires waiting for an advertisement from R1, R2 sends out a registration to associate MAC (V1) with ATM(R2) = Y mapping. Once the LES acknowledges the registration, R2 sends a targetless LE_ARP_REQUEST to let all the LECs—and in this case hosts H1 and H2—know that MAC(V1) is now mapped to ATM address Y instead of ATM address X. Then it will become the master and start sending VRRP advertisements and route traffic destined to virtual router V1. Hosts H1 and H2 will now be able to use R2 to send their traffic without interruption.
5.5.2 VRRP in a Mix of ATM LANE and LAN Networks
In this mixed network scenario, we consider two possibilities. Figure 5-8 shows VRRP routers in a mixed network, with ATM LAN emulation and Ethernet and the actual VRRP routers being on the Ethernet segment. Figure 5-9 presents the second scenario, with one VRRP router being on the ATM LANE network and the other being on the Ethernet network.
)
Figure 5-8. VRRP routers in LAN with hosts on ATM
Figure 5-8 shows hosts H1 and H2 as ATM hosts running ATM LAN emulation and sitting on the ATM network. The ATM network is connected to Ethernet segment E1 and E2 via LAN emulation bridges B1 and B2 respectively. Router R1 and host H3 are connected to Ethernet segment E1, and router R2 and host H4 are connected to Ethernet segment E2. Routers R1 and R2 are backing each other up. There are two virtual routers: V1, with IP(V1) = 192.32.15.1 with R1 as the master/ owner and router R2 as the backup, and V2, with IP(V2) = 192.32.15.2 with R2 as the master/owner and router R1 as the backup. H1 and H3 use IP(V1) as their default router; H2 and H4 use IP(V2) as their default router.
Host H3, being on the Ethernet network as R1, is unaware of the ATM network and will simply talk to R1 using the virtual MAC MAC(V1). The LECs on ATM bridges B1 and B2 represent Ethernet E1 and E2 respectively and so send out targetless LE_ARP requests with the virtual MAC to their respective ATM address associations. Hosts H1 and H2 will use this to talk to V1 and V2 respectively. Bridges use a proxy LEC scheme rather than registering the actual MAC-to-ATM address associations with the LEC.
If R1 fails, R2 will take over for R1. R2 will now start sending advertisements with MAC(V1) as the source MAC address. This advertisement will come from Ethernet segment E2 because R2 is sending it. It will cause bridges B1 and B2 to update their learning tables, since they would recognize a station move. So bridge B1 will now make an address disassociation from MAC(V1) bridge B2 will now make an address association to MAC(V1) on the ATM network.
Let us now consider another variation shown in Figure 5-9, in which one router, R1, is an ATM router with a LEC stack and is the master for virtual router V1. R2 is the backup for virtual router V1 and is on the Ethernet segment E1. E1 is connected to the ATM segment through the ATM bridge B1. There is also a virtual router, V2, with R2 as master and being backed up by R1. Host H1 and host H2 are ATM hosts; hosts H3 and H4 are on the Ethernet segment. H1 and H2 are configured to use V1 as their default router; H3 and H4 are configured to use V2 as their default router. Router R1 first registers the V1 MAC association with the LES and then sends out a targetless LE_ARP announcing the association. Hosts H1 and H2 update their caches and bind their IP to the V1 MAC and to router R1's ATM address. Bridge B1 will also update its cache.
)
Figure 5-9. VRRP between one router on ATM and another router on legacy
LAN
Router R1 will send out VRRP advertisements for virtual router V1. If R1 fails, R2 will take over and send out a VRRP advertisement. Hosts H3 and H4, being on Ethernet, will not be affected, but hosts H1 and H2 need to know the new ATM binding. This is done with the help of bridge B1. When R2 sends out its VRRP advertisement, bridge B1 will immediately make an address association because it recognizes the station move, since the same MAC(V1) is now seen from R2 (the Ethernet side) rather than from R1 (ATM side). Bridge B1 uses the proxy LEC scheme and will therefore send out a targetless LE_ARP_REQUEST to announce its association with MAC(V1) when R2 becomes the master. This will ensure that ATM hosts H1 and H2 will update their bindings so that MAC(V1) is mapped to B1's ATM address.
5.5.3 Proxy LEC Versus Nonproxy LEC Scheme in a VRRP Environment
In the nonproxy LEC scheme, a LEC joins an ELAN as a nonproxy client, in other words, it relies on the LEC and explicitly registers its address association and disassociation with the LEC. When it needs to make an address association or disassociation, the LEC registers with the LES first and then sends out a targetless LE_ARP_REQUEST with the MAC address to its own ATM address. In the case of a master, the master must send out an LE_ARP_REQUEST with the virtual MAC to ATM address binding. If the registration with the LES fails, the master must persist with the registration phase.
In order to make an address disassociation, a LEC unregisters the virtual MAC with the LES and sends out a no source LE_NARP with the virtual MAC to its own ATM address mapping. Often, however, address disassociation is done because the router containing the LEC failed and so will not be in a position to do actual address disassociation. So when a LEC fails without making an address disassociation, the LES will detect the control VC failure (as explained in Appendix A) to that failed LEC and delete the current virtual MAC-to-ATM binding associated with that LEC. Other LECs in the ELAN that queried the LES and had established VC connections to this failed LEC would also see those VCs fail and would clean up their caches for the virtual MAC-to-ATM binding associated with that failed LEC.
This paves the way for a backup LEC to register the virtual MAC to its own ATM association with the LES.
In the proxy LEC scheme generally used by ATM bridges, the LEC on the bridge simply registers as a proxy client with the LES rather than explicitly registering MAC to ATM address associations. This method is used because bridges generally learn addresses dynamically and need to react to station moves to the LAN segments they represent. Once the proxy LEC makes an association for a virtual MAC address, it immediately sends out a targetless LE_ARP_REQUEST with the virtual MAC-to-ATM address binding. It will also make a regular LE_ARP_REQUEST for this virtual MAC address. If it gets a response, it means that some other LEC on the network is representing this virtual MAC on the ELAN. This can happen if another bridge on the network has not realized yet that a MAC it was representing has moved to some other bridge on the ELAN. This proxy LEC will continue sending LE_ARP_REQUESTs until it receives no reply.
When the proxy LEC makes an address disassociation, it sends out a no source LE_NARP with the virtual MAC to its own ATM binding.
ATM LANE bridges generally register as proxy clients with the LES. However, for VRRP to function properly, a LANE bridge must make an address association on an ELAN port with MAC addresses it learns on all other ports. Similarly, if it hears on an ELAN port a MAC address for which it has already made an association, it must record a station move and immediately make an address disassociation for that MAC.
5.5.4 Modifications to VRRP State Machine for ATM LANE
As we have seen in previous sections, it is clear that some modifications are needed to the VRRP state machine outlined in Chapter 4 to get VRRP to work over ATM LANE. We will summarize the modifications here.
5.5.4.1 Initialize State
All ATM LECs (master or backup router) at initialization will go through their own standard ATM initialization mechanisms and register themselves as a proxy or nonproxy LEC and complete their ATM- and LANE-based initialization. They will check if their priority is 255 and if so, the LEC with priority 255 will make an address association with the virtual MAC associated with its virtual router and then send a VRRP advertisement. The rest of the state machine is no different from Ethernet.
5.5.4.2 Backup State
In this state, a VRRP router must not respond to ARP requests for the IP addresses associated with the virtual router. In addition, in the ATM LANE case they must also not respond to an LE_ARP_REQUEST for a virtual MAC. If the Master_Down_Timer fires, they must first make an address association with the virtual MAC before going through the rest of their VRRP standard state machine if they are running VRRP over ATM LANE.
5.5.4.3 Master State
In the master state, the VRRP router running ATM LANE must respond to ARP requests for the IP addresses associated with the virtual router. It must respond to an LE_ARP_REQUEST for the virtual MAC.
If it receives a shutdown event, then it cancels the Adver_Timer, and before it transitions to the initialize state, it will make an address disassociation with the virtual MAC and only then transition to the initialize state.
If it receives an advertisement that indicates the presence of a better master for that virtual router, it must make an address disassociation with the virtual MAC before transitioning to the backup state.
5.5.5 VRRP over LANE V1 versus LANE V2
When a LEC starts representing a MAC address, we have seen that it needs to notify all LECs on the network of this fact. Similarly, when a LEC has already made an association for a virtual MAC and now wishes to make this disassociation, it needs to notify all LECs that it no longer represents that virtual MAC.
In the case of LANEv2, as described so far in this chapter, the LEC sends out a targetless LE_ARP_REQUEST to notify everybody that it has made an address association. It sends out a no source LE_NARP_REQUEST if it wishes to make a disassociation. All LECs will either add the binding in their caches in the case of the former or remove a binding in the case of a latter.
LANEv1 overlooked the two cases mentioned above. Instead LANEv1 only considered the ability to announce an address association and never considered the need to make an address disassociation. Therefore, VRRP operation over LANEv1 requires a minor change from the LANEv1 protocol. The LANEv1 client must send an LE_NARP_REQUEST with zero TARGET_ATM_ADDRESS field and zero SOURCE_ATM_ADDRESS field. All LANEv1 and LANEv2 LES must forward this to all the LECs, and upon receiving this LE_NARP with TARGET_ATM_ADDRESS of 0x00, all proxy and nonproxy clients should delete the MAC-to-ATM address mapping for the MAC listed in the TARGET_LAN_ADDRESS field. This ensures that the LANEv1 LEC wishing to announce the address disassociation is able to do so.
5.5.6 VRRP Operation over Token Ring LANE
VRRP operation over Token Ring LANE is very similar to the Ethernet case we have discussed so far. However, as discussed in section 5.4, VRRP over Token Ring requires the use of a Token Ring functional address for the virtual MAC address because of the absence of a general multicast mechanism in Token Ring.
So if we were to follow the same operation on VRRP over Token Ring LANE, all hosts on the Token Ring LANE subnet can use the Token Ring functional address associated with their default virtual router as the destination MAC in order to send IP traffic through the virtual router. However, all multicast and broadcast traffic over a LANE network has to go through the ATM LANE BUS (see Appendix A) and therefore can cause potential congestion of the BUS.
Because Token Ring over ATM LANE is an emulation of Token Ring and there is no real Token Ring adapter, there is nothing that forces a user to use a functional address. So VRRP implementations over pure Token Ring ATM LANE networks can use the IEEE 802 MAC address used over Ethernet 00:00:5e:00:01-{VRID}rather than functional address. This will reduce multicast traffic and protect the BUS from being congested. As long as the master and all backups are on Token Ring ATM LANE, there is no need to use the functional address, even in a Token Ring bridged environment (mix of Token Ring and Token Ring LANE). Hosts on both Token Ring and Token Ring LANE can both use this address rather than the functional address.
However, if a master or any of the backups are on a real Token Ring in a mixed environment, then the use of a functional address cannot be avoided.