VRRP RFC 3768.docx

VRRP RFC 3768.docx

《VRRP RFC 3768.docx》由会员分享，可在线阅读，更多相关《VRRP RFC 3768.docx（43页珍藏版）》请在冰豆网上搜索。

VRRPRFC3768

NetworkWorkingGroupR.Hinden,Ed.

RequestforComments:

3768Nokia

Obsoletes:

2338April2004

Category:

StandardsTrack

VirtualRouterRedundancyProtocol（VRRP）

StatusofthisMemo

ThisdocumentspecifiesanInternetstandardstrackprotocolforthe

Internetcommunity,andrequestsdiscussionandsuggestionsfor

improvements.Pleaserefertothecurrenteditionofthe"Internet

OfficialProtocolStandards"（STD1）forthestandardizationstate

andstatusofthisprotocol.Distributionofthismemoisunlimited.

CopyrightNotice

Copyright（C）TheInternetSociety（2004）.AllRightsReserved.

Abstract

ThismemodefinestheVirtualRouterRedundancyProtocol（VRRP）.

VRRPspecifiesanelectionprotocolthatdynamicallyassigns

responsibilityforavirtualroutertooneoftheVRRProutersona

LAN.TheVRRProutercontrollingtheIPaddress（es）associatedwith

avirtualrouteriscalledtheMaster,andforwardspacketssentto

theseIPaddresses.Theelectionprocessprovidesdynamicfailover

intheforwardingresponsibilityshouldtheMasterbecome

unavailable.ThisallowsanyofthevirtualrouterIPaddresseson

theLANtobeusedasthedefaultfirsthoprouterbyend-hosts.The

advantagegainedfromusingVRRPisahigheravailabilitydefault

pathwithoutrequiringconfigurationofdynamicroutingorrouter

discoveryprotocolsoneveryend-host.

TableofContents

1.Introduction.........................2

1.1.Contributors......................3

1.2.Scope.........................4

1.3.Definitions......................4

2.RequiredFeatures......................5

2.1.IPAddressBackup...................5

2.2.PreferredPathIndication...............5

2.3.MinimizationofUnnecessaryServiceDisruptions....5

2.4.EfficientOperationoverExtendedLANs.........6

3.VRRPOverview........................6

4.SampleConfigurations....................7

HindenStandardsTrack[Page1]

RFC3768VRRPApril2004

4.1.SampleConfiguration1.................7

4.2.SampleConfiguration2.................9

5.Protocol...........................10

5.1.VRRPPacketFormat...................10

5.2.IPFieldDescriptions.................10

5.3.VRRPFieldDescriptions................11

6.ProtocolStateMachine....................13

6.1.ParametersperVirtualRouter.............13

6.2.Timers.........................14

6.3.StateTransitionDiagram................15

6.4.StateDescriptions...................15

7.SendingandReceivingVRRPPackets..............18

7.1.ReceivingVRRPPackets.................18

7.2.TransmittingPackets..................19

7.3.VirtualMACAddress..................19

8.OperationalIssues......................20

8.1.ICMPRedirects.....................20

8.2.HostARPRequests...................20

8.3.ProxyARP.......................20

8.4.PotentialForwardingLoop...............21

9.OperationoverFDDI,TokenRing,andATMLANE........21

9.1.OperationoverFDDI..................21

9.2.OperationoverTokenRing...............21

9.3.OperationoverATMLANE................23

10.SecurityConsiderations...................23

11.Acknowledgements.......................24

12.References..........................24

12.1.NormativeReferences..................24

12.2.InformativeReferences.................25

13.ChangesfromRFC2338.....................25

14.Editor'sAddress.......................26

15.FullCopyrightStatement...................27

1.Introduction

Thereareanumberofmethodsthatanend-hostcanusetodetermine

itsfirsthoproutertowardsaparticularIPdestination.These

includerunning（orsnooping）adynamicroutingprotocolsuchas

RoutingInformationProtocol[RIP]orOSPFversion2[OSPF],running

anICMProuterdiscoveryclient[DISC]orusingastatically

configureddefaultroute.

Runningadynamicroutingprotocoloneveryend-hostmaybe

infeasibleforanumberofreasons,includingadministrative

overhead,processingoverhead,securityissues,orlackofaprotocol

implementationforsomeplatforms.Neighbororrouterdiscovery

protocolsmayrequireactiveparticipationbyallhostsonanetwork,

leadingtolargetimervaluestoreduceprotocoloverheadintheface

HindenStandardsTrack[Page2]

RFC3768VRRPApril2004

oflargenumbersofhosts.Thiscanresultinasignificantdelayin

thedetectionofalost（i.e.,dead）neighbor,thatmayintroduce

unacceptablylong"blackhole"periods.

Theuseofastaticallyconfigureddefaultrouteisquitepopular;it

minimizesconfigurationandprocessingoverheadontheend-hostand

issupportedbyvirtuallyeveryIPimplementation.Thismodeof

operationislikelytopersistasdynamichostconfiguration

protocols[DHCP]aredeployed,whichtypicallyprovideconfiguration

foranend-hostIPaddressanddefaultgateway.However,this

createsasinglepointoffailure.Lossofthedefaultrouter

resultsinacatastrophicevent,isolatingallend-hoststhatare

unabletodetectanyalternatepaththatmaybeavailable.

TheVirtualRouterRedundancyProtocol（VRRP）isdesignedto

eliminatethesinglepointoffailureinherentinthestaticdefault

routedenvironment.VRRPspecifiesanelectionprotocolthat

dynamicallyassignsresponsibilityforavirtualroutertooneofthe

VRRProutersonaLAN.TheVRRProutercontrollingtheIP

address（es）associatedwithavirtualrouteriscalledtheMaster,

andforwardspacketssenttotheseIPaddresses.Theelection

processprovidesdynamicfail-overintheforwardingresponsibility

shouldtheMasterbecomeunavailable.Anyofthevirtualrouter'sIP

addressesonaLANcanthenbeusedasthedefaultfirsthoprouter

byend-hosts.TheadvantagegainedfromusingVRRPisahigher

availabilitydefaultpathwithoutrequiringconfigurationofdynamic

routingorrouterdiscoveryprotocolsoneveryend-host.

VRRPprovidesafunctionsimilartotheproprietaryprotocols"Hot

StandbyRouterProtocol（HSRP）"[HSRP]and"IPStandbyProtocol"

[IPSTB].

Thekeywords"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT",

"SHOULD","SHOULDNOT","RECOMMENDED","MAY",and"OPTIONAL"inthis

documentaretobeinterpretedasdescribedin[RFC2119].

1.1.Contributors

Thefollowingpeople,whoaretheauthorsoftheRFC2338thatthis

documentisbasedonandreplaces,contributedtothetextinthis

document.TheyareP.Higginson,R.Hinden,P.Hunt,S.Knight,A.

Lindem,D.Mitzel,M.Shand,D.Weaver,andD.Whipple.Theyarenot

listedasauthorsofthedocumentduetocurrentRFC-Editorpolicies.

HindenStandardsTrack[Page3]

RFC3768VRRPApril2004

1.2.Scope

Theremainderofthisdocumentdescribesthefeatures,designgoals,

andtheoryofoperationofVRRP.Themessageformats,protocol

processingrulesandstatemachinethatguaranteeconvergencetoa

singleVirtualRouterMasterarepresented.Finally,operational

issuesrelatedtoMACaddressmapping,handlingofARPrequests,

generationofICMPredirectmessages,andsecurityissuesare

addressed.

ThisprotocolisintendedforusewithIPv4routersonly.Aseparate

specificationwillbeproducedifitisdecidedthatsimilar

functionalityisdesirableinanIPv6environment.

1.3.Definitions

VRRPRouterArouterrunningtheVirtualRouterRedundancy

Protocol.Itmayparticipateinoneormore

virtualrouters.

VirtualRouterAnabstractobjectmanagedbyVRRPthatacts

asadefaultrouterforhostsonasharedLAN.

ItconsistsofaVirtualRouterIdentifierand

asetofassociatedIPaddress（es）acrossa

commonLAN.AVRRPRoutermaybackuponeor

morevirtualrouters.

IPAddressOwnerTheVRRProuterthathasthevirtualrouter's

IPaddress（es）asrealinterfaceaddress（es）.

Thisistherouterthat,whenup,willrespond

topacketsaddressedtooneoftheseIP

addressesforICMPpings,TCPconnections,

etc.

PrimaryIPAddressAnIPaddressselectedfromthesetofreal

interfaceaddresses.Onepossibleselection

algorithmistoalwaysselectthefirst

address.VRRPadvertisementsarealwayssent

usingtheprimaryIPaddressasthesourceof

theIPpacket.

VirtualRouterMasterTheVRRProuterthatisassumingthe

responsibilityofforwardingpacketssentto

theIPaddress（es）associatedwiththevirtual

router,andansweringARPrequestsforthese

IPaddresses.NotethatiftheIPaddress

ownerisavailable,thenitwillalwaysbecome

theMaster.

HindenStandardsTrack[Page4]

RFC3768VRRPApril2004

VirtualRouterBackupThesetofVRRProutersavailabletoassume

forwardingresponsibilityforavirtualrouter

shouldthecurrentMasterfail.

2.RequiredFeatures

Thissectionoutlinesthesetoffeaturesthatwereconsidered

mandatoryandthatguidedthedesignofVRRP.

2.1.IPAddressBackup

BackupofIPaddressesistheprimaryfunctionofthe