Home > Articles > Networking

  • Print
  • + Share This
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.

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-7Figure 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-8Figure 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-9Figure 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.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020