RoutingInformationProtocol

RIP(RoutingInformationProtocol)
RIPisastandardizedDistanceVectorprotocol,designedforuseonsmaller
networks.RIPwasoneofthefirsttrueDistanceVectorroutingprotocols,
andissupportedonawidevarietyofsystems.
RIPadherestothefollowingDistanceVectorcharacteristics:

RIPsendsoutperiodicroutingupdates(every30seconds)
RIPsendsoutthefullroutingtableeveryperiodicupdate
RIPusesaformofdistanceasitsmetric(inthiscase,hopcount)

RIPusestheBellmanFordDistanceVectoralgorithmtodetermine
thebestpathtoaparticulardestination

OthercharacteristicsofRIPinclude:

RIPsupportsIPandIPXrouting.
RIPutilizesUDPport520
RIProuteshaveanadministrativedistanceof120.
RIPhasamaximumhopcountof15hops.

Anynetworkthatis16hopsawayormoreisconsideredunreachableto
RIP,thusthemaximumdiameterofthenetworkis15hops.Ametricof16
hopsinRIPisconsideredapoisonrouteorinfinitymetric.
Ifmultiplepathsexisttoaparticulardestination,RIPwillloadbalance
betweenthosepaths(bydefault,upto4)onlyifthemetric(hopcount)is
equal.RIPusesaroundrobinsystemofloadbalancingbetweenequal
metricroutes,whichcanleadtopinholecongestion.
Forexample,twopathsmightexisttoaparticulardestination,onegoing
througha9600baudlink,theotherviaaT1.Ifthemetric(hopcount)is
equal,RIPwillloadbalance,sendinganequalamountoftrafficdown
the9600baudlinkandtheT1.Thiswill(obviously)causetheslower
linktobecomecongested.

RIPVersions
RIPhastwoversions,Version1(RIPv1)andVersion2(RIPv2).
RIPv1(RFC1058)isclassful,andthusdoesnotincludethesubnetmask
withitsroutingtableupdates.Becauseofthis,RIPv1doesnotsupport
VariableLengthSubnetMasks(VLSMs).WhenusingRIPv1,networks
mustbecontiguous,andsubnetsofamajornetworkmustbeconfigured
withidenticalsubnetmasks.Otherwise,routetableinconsistencies(or
worse)willoccur.
RIPv1sendsupdatesasbroadcaststoaddress255.255.255.255.
RIPv2(RFC2543)isclassless,andthusdoesincludethesubnetmask
withitsroutingtableupdates.RIPv2fullysupportsVLSMs,allowing
discontiguousnetworksandvaryingsubnetmaskstoexist.
OtherenhancementsofferedbyRIPv2include:

Routingupdatesaresentviamulticast,usingaddress224.0.0.9
EncryptedauthenticationcanbeconfiguredbetweenRIPv2routers
Routetaggingissupported(explainedinalatersection)

RIPv2caninteroperatewithRIPv1.Bydefault:

RIPv1routerswillsentonlyVersion1packets
RIPv1routerswillreceivebothVersion1and2updates
RIPv2routerswillbothsendandreceiveonlyVersion2updates

WecancontroltheversionofRIPaparticularinterfacewillsendor
receive.
UnlessRIPv2ismanuallyspecified,aCiscowilldefaulttoRIPv1when
configuringRIP.

RIPv1BasicConfiguration

RoutingprotocolconfigurationoccursinGlobalConfigurationmode.
OnRouterA,toconfigureRIP,wewouldtype:
Router(config)#routerrip
Router(configrouter)#network172.16.0.0
Router(configrouter)#network172.17.0.0

Thefirstcommand,routerrip,enablestheRIPprocess.
ThenetworkstatementstellRIPwhichnetworksyouwishtoadvertiseto
otherRIProuters.Wesimplylistthenetworksthataredirectlyconnectedto
ourrouter.Noticethatwespecifythenetworksattheirclassfulboundaries,
andwedonotspecifyasubnetmask.
ToconfigureRouterB:
Router(config)#routerrip
Router(configrouter)#network172.17.0.0
Router(configrouter)#network172.18.0.0

TheroutingtableonRouterAwilllooklike:
RouterA#showiproute
<eliminated irrelevant header>
Gateway of last resort is not set

C
C
R

172.16.0.0 is directly connected, Ethernet0

172.17.0.0 is directly connected, Serial0
172.18.0.0 [120/1] via 172.17.1.2, 00:00:00, Serial0

TheroutingtableonRouterBwilllooklike:
RouterB#showiproute
<eliminated irrelevant header>
Gateway of last resort is not set

C
C

172.17.0.0 is directly connected, Serial0

172.18.0.0 is directly connected, Ethernet0

172.16.0.0 [120/1] via 172.17.1.1, 00:00:00, Serial0

LimitationsofRIPv1
TheexampleonthepreviouspageworksfinewithRIPv1,becausethe
networksarecontiguousandthesubnetmasksareconsistent.Consider
thefollowingexample:

ThisparticularscenariowillstillworkwhenusingRIPv1,despitethefact
thatwevesubnettedthemajor10.0.0.0network.Noticethatthesubnetsare
contiguous(thatis,theybelongtothesamemajornetwork),andusethe
samesubnetmask.
WhenRouterAsendsaRIPv1updatetoRouterBviaSerial0,itwillnot
includethesubnetmaskforthe10.1.0.0network.However,becausethe
10.3.0.0networkisinthesamemajornetworkasthe10.1.0.0network,it
willnotsummarizetheaddress.Therouteentryintheupdatewill
simplystate10.1.0.0.
RouterBwillacceptthisroutingupdate,andrealizethattheinterface
receivingtheupdate(Serial0)belongstothesamemajornetworkasthe
routeentryof10.1.0.0.ItwillthenapplythesubnetmaskofitsSerial0
interfacetothisrouteentry.
RouterCwillsimilarlysendanentryforthe10.2.0.0networktoRouterB.
RouterBsroutingtablewillthuslooklike:
RouterB#showiproute
Gateway of last resort is not set

C
C
R
R

10.0.0.0/16 is subnetted, 4 subnets

10.3.0.0 is directly connected, Serial0
10.4.0.0 is directly connected, Serial1
10.1.0.0 [120/1] via 10.3.5.1, 00:00:00, Serial0
10.2.0.0 [120/1] via 10.4.5.1, 00:00:00, Serial1

LimitationsofRIPv1(continued)
Considerthefollowing,slightlyaltered,example:

WellassumethatRIPv1isconfiguredcorrectlyonallrouters.Noticethatour
networksarenolongercontiguous.BothRouterAandRouterCcontain
subnetsofthe10.0.0.0majornetwork(10.1.0.0and10.2.0.0respectively).

SeparatingthesenetworksnowaretwoClassCsubnets(192.168.123.0
and192.168.111.0).
Whyisthisaproblem?Again,whenRouterAsendsaRIPv1updateto
RouterBviaSerial,itwillnotincludethesubnetmaskforthe10.1.0.0
network.Instead,RouterAwillconsideritselfaborderrouter,asthe
10.1.0.0and192.168.123.0networksdonotbelongtothesamemajor
network.RouterAwillsummarizethe10.1.0.0/16networktoitsclassful
boundaryof10.0.0.0/8.
RouterBwillacceptthisroutingupdate,andrealizethatitdoesnothave
adirectlyconnectedinterfaceinthe10.x.x.xscheme.Thus,ithasno
subnetmasktoapplytothisroute.Becauseofthis,RouterBwillinstall
thesummarized10.0.0.0routeintoitsroutingtable.
RouterC,similarly,willconsideritselfaborderrouterbetweennetworks
10.2.0.0and192.168.111.0.Thus,RouterCwillalsosendasummarized
10.0.0.0routetoRouterB.

LimitationsofRIPv1(continued)

RouterBsroutingtablewillthenlooklike:
RouterB#showiproute
Gateway of last resort is not set

C
C
R

192.168.123.0 is directly connected, Serial0

192.168.111.0 is directly connected, Serial1
10.0.0.0 [120/1] via 192.168.123.1, 00:00:00, Serial0
[120/1] via 192.168.111.2, 00:00:00, Serial1

Thatsright,RouterBnowhastwoequalmetricroutestogettothe
summarized10.0.0.0network,onethroughRouterAandtheotherthrough
RouterC.RouterBwillnowloadbalancealltraffictoany10.x.x.xnetwork
betweenroutersAandC.Sufficetosay,thisisnotagoodthing.
Itgetsbetter.RouterBthentriestosendroutingupdatestoRouterA
andRouterC,includingthesummaryrouteof10.0.0.0/8.RouterAs
routingtablelookslike:
RouterA#showiproute
Gateway of last resort is not set

C
C

192.168.123.0 is directly connected, Serial0

10.0.0.0/16 is subnetted, 1 subnet
10.1.0.0 is directly connected, Ethernet0

RouterAwillreceivethesummarized10.0.0.0/8routefromRouterB,and
willrejectit.Thisisbecauseitalreadyhasthesummarynetworkof10.0.0.0

initsroutingtable,anditsdirectlyconnected.RouterCwillrespond
exactlythesame,andthe10.1.0.0/16and10.2.0.0/16networkswillnever
beabletocommunicate.

RIPv2Configuration

RIPv2overcomesthelimitationsofRIPv1byincludingthesubnetmaskin
itsroutingupdates.Bydefault,CiscorouterswilluseRIPv1.Tochangeto
Version2,youmusttype:
Router(config)#routerrip
Router(configrouter)#version2

Thus,theconfigurationofRouterAwouldbe:
RouterA(config)#routerrip
RouterA(configrouter)#version2
RouterA(configrouter)#network10.0.0.0
RouterA(configrouter)#network192.168.123.0

DespitethefactthatRIPv2isaclasslessroutingprotocol,westillspecify
networksattheirclassfulboundaries,withoutasubnetmask.
However,whenRouterAsendsaRIPv2updatetoRouterBviaSerial0,by
defaultitwillstillsummarizethe10.1.0.0/16networkto10.0.0.0/8.Again,
thisisbecausethe10.1.0.0and192.168.123.0networksdonotbelongtothe
samemajornetwork.Thus,RIPv2actslikeRIPv1inthiscircumstance
unlessyoudisableautosummarization:
RouterA(config)#routerrip
RouterA(configrouter)#version2
RouterA(configrouter)#noautosummary

ThenoautosummarycommandwillpreventRouterAfromsummarizing
the10.1.0.0network.Instead,RouterAwillsendanupdatethatincludes
boththesubnettednetwork(10.1.0.0)anditssubnetmask(255.255.0.0).

RIPTimers
RIPhasfourbasictimers:
UpdateTimer(default30seconds)indicateshowoftentherouterwill
sendoutaroutingtableupdate.
InvalidTimer(default180seconds)indicateshowlongaroutewill
remaininaroutingtablebeforebeingmarkedasinvalid,ifnonewupdates
areheardaboutthisroute.Theinvalidtimerwillberesetifanupdateis
receivedforthatparticularroutebeforethetimerexpires.
Aroutemarkedasinvalidisnotimmediatelyremovedfromtherouting
table.Instead,therouteismarked(andadvertised)withametricof16,
indicatingitisunreachable,andplacedinaholddownstate.
HolddownTimer(default180seconds)indicateshowlongRIPwill
suppressaroutethatithasplacedinaholddownstate.RIPwillnot
acceptanynewupdatesforroutesinaholddownstate,untiltheholddown
timerexpires.
Aroutewillenteraholddownstateforoneofthreereasons:
Theinvalidtimerhasexpired.
Anupdatehasbeenreceivedfromanotherrouter,markingthatroute
withametricof16(orunreachable).
Anupdatehasbeenreceivedfromanotherrouter,markingthatroute
withahighermetricthanwhatiscurrentlyintheroutingtable.Thisis
topreventloops.

FlushTimer(default240seconds)indicateshowlongaroutecanremain
inaroutingtablebeforebeingflushed,ifnonewupdatesareheardabout
thisroute.Theflushtimerrunsconcurrentlywiththeinvalidtimer,and
thuswillflushoutaroute60secondsafterithasbeenmarkedinvalid.
RIPtimersmustbeidenticalonallroutersontheRIPnetwork,otherwise
massiveinstabilitywilloccur.

RIPTimersConfigurationandExample

Considertheaboveexample.RouterAreceivesaRIPupdatefromRouter
Bthatincludesnetwork172.18.0.0.RouterAaddsthisnetworktoits
routingtable:
RouterA#showiproute
Gateway of last resort is not set

C
C
R

172.16.0.0 is directly connected, Ethernet0

172.17.0.0 is directly connected, Serial0
172.18.0.0 [120/1] via 172.17.1.2, 00:00:00, Serial0

Immediately,RouterAsetsaninvalidtimerof180secondsandflushtimer
of240secondstothisroute,whichrunconcurrently.Ifnoupdateforthis
routeisheardfor180seconds,severalthingswilloccur:
Therouteismarkedasinvalidintheroutingtable.
Therouteentersaholddownstate(triggeringtheholddowntimer).
Therouteisadvertisedtoallotherroutersasunreachable.
Theholddowntimerrunsfor180secondsaftertherouteismarkedas
invalid.Therouterwillnotacceptanynewupdatesforthisrouteuntil
thisholddownperiodexpires.
Ifnoupdateisheardatall,theroutewillberemovedfromtheroutingtable
oncetheflushtimerexpires,whichis60secondsaftertherouteismarked
asinvalid.Rememberthattheinvalidandflushtimersrunconcurrently.
ToconfiguretheRIPtimers:
Router(config)#routerrip
Router(configrouter)#timersbasic20120120160

Thetimersbasiccommandallowsustochangetheupdate(20),invalid
(120),holddown(120),andflush(240)timers.Toreturnthetimersbackto
theirdefaults:
Router(configrouter)#notimersbasic

RIPLoopAvoidanceMechanisms
RIP,asaDistanceVectorroutingprotocol,issusceptibletoloops.

Letsassumenoloopavoidancemechanismsareconfiguredoneitherrouter.
Ifthe172.18.0.0networkfails,RouterBwillsendoutanupdatetoRouterA
within30seconds(wheneveritsupdatetimerexpires)statingthatrouteis
unreachable(metric=16).
ButwhatifanupdatefromRouterAreachesRouterBbeforethiscanhappen?
RouterAbelievesitcanreachthe172.18.0.0networkinonehop(through
RouterB).ThiswillcauseRouterBtobelieveitcanreachthefailed
172.18.0.0networkintwohops,throughRouterA.Bothrouterswillcontinue
toincrementthemetricforthenetworkuntiltheyreachahopcountof16,
whichisunreachable.Thisbehaviorisknownascountingtoinfinity.

Howcanwepreventthisfromhappening?Thereareseveralloop
avoidancemechanisms:
SplitHorizonPreventsaroutingupdatefrombeingsentouttheinterface
itwasreceivedon.Inouraboveexample,thiswouldpreventRouterA
fromsendinganupdateforthe172.18.0.0networkbacktoRouterB,asit
originallylearnedtheroutefromRouterB.Splithorizonisenabledby
defaultonCiscoRouters.
RoutePoisoningWorksinconjunctionwithsplithorizon,bytriggering
anautomaticupdateforthefailednetwork,withoutwaitingfortheupdate
timertoexpire.Thisupdateissentoutallinterfaceswithaninfinitymetric
forthatnetwork.
HoldDownTimersPreventsRIPfromacceptinganynewupdatesfor
routesinaholddownstate,untiltheholddowntimerexpires.IfRouterA
sendsanupdatetoRouterBwithahighermetricthanwhatiscurrentlyin
RouterBsroutingtable,thatroutewillbeplacedinaholddownstate.
(RouterAsmetricforthe172.18.0.0networkis1;whileRouterBs
metricis0).

RIPPassiveInterfaces
Itispossibletocontrolwhichrouterinterfaceswillparticipateinthe
RIPprocess.

Considerthefollowingscenario.RouterCdoesnotwanttoparticipateinthe
RIPdomain.However,itstillwantstolistentoupdatesbeingsentfrom
RouterB,justnotsendanyupdatesbacktoRouterB:
RouterC(config)#routerrip
RouterC(configrouter)#network10.4.0.0
RouterC(configrouter)#network10.2.0.0
RouterC(configrouter)#passiveinterfaces0

Thepassiveinterfacecommandwillpreventupdatesfrombeingsentoutof
theSerial0interface,butRouterCwillstillreceiveupdatesonthisinterface.
Wecanconfigureallinterfacestobepassiveusingthepassive
interfacedefaultcommand,andthenindividuallyusethenopassive
interfacecommandontheinterfaceswedowantupdatestobesentout:
RouterC(config)#routerrip
RouterC(configrouter)#network10.4.0.0
RouterC(configrouter)#network10.2.0.0
RouterC(configrouter)#passiveinterfacedefault
RouterC(configrouter)#nopassiveinterfacee0

RIPNeighbors

RecallthatRIPv1sendsoutitsupdatesasbroadcasts,whereasRIPv2sends
outitsupdatesasmulticaststothe224.0.0.9address.Wecanconfigure
specificRIPneighborcommands,whichwillallowustounicastrouting
updatestothoseneighbors.
OnRouterB:
RouterB(config)#routerrip
RouterB(configrouter)#network10.3.0.0
RouterB(configrouter)#network10.4.0.0
RouterB(configrouter)#neighbor10.3.5.1
RouterB(configrouter)#neighbor10.4.5.1

RouterBwillnowunicastRIPupdatestoRouterAandRouterC.
However,RouterBwillstillbroadcast(ifRIPv1)ormulticast(ifRIPv2)its
updates,inadditiontosendingunicastupdatestoitsneighbors.Inorderto
preventbroadcast/multicastupdates,wemustalsousepassiveinterfaces:
RouterB(config)#routerrip
RouterB(configrouter)#passiveinterfaces0
RouterB(configrouter)#passiveinterfaces1
RouterB(configrouter)#neighbor10.3.5.1
RouterB(configrouter)#neighbor10.4.5.1

Thepassiveinterfacecommandspreventtheupdatesfrombeing
broadcastedormulticasted.Theneighborcommandsstillallow
unicastupdatestothosespecificneighbors.

RIPv2Authentication

RIPv2supportsauthenticationtosecureroutingupdates.
Thefirststepiscreatingasharedauthenticationkeythatmustbeidentical
onbothrouters.Thisisaccomplishedinglobalconfigurationmode:
RouterA(config)#keychainMYCHAIN
RouterA(configkeychain)#key1
RouterA(configkeychainkey)#keystringMYPASSWORD
RouterB(config)#keychainMYCHAIN
RouterB(configkeychain)#key1
RouterB(configkeychainkey)#keystringMYPASSWORD

ThefirstcommandcreatesakeychaincalledMYCHAIN.Wemustthen
associateakeytoourkeychain.Thenweactuallyconfigurethesharedkey
usingthekeystringcommand.
Wethenapplyourkeychaintotheinterfaceconnectingtotheotherrouter:
RouterA(config)#interfaces0
RouterA(configif)#ipripauthenticationkeychainMYCHAIN
RouterB(config)#interfaces0
RouterB(configif)#ipripauthenticationkeychainMYCHAIN

IftherewasanotherrouteroffofRouterBsEthernetport,wecouldcreatea
separatekeychainwithadifferentkeystring.EveryrouterontheRIP
domaindoesnotneedtousethesamekeychain,onlyinterfacesdirectly
connectingtwo(ormore)routers.
Thefinalstepinconfiguringauthenticationisidentifyingwhichencryption
touse.Bydefault,thekeyissentincleartext:
RouterA(config)#interfaces0
RouterA(configif)#ipripauthenticationmodetext

OrwecanuseMD5encryptionforadditionalsecurity:
RouterA(config)#interfaces0
RouterA(configif)#ipripauthenticationmodemd5

WhethertextorMD5isused,itmustbethesameonbothrouters.

AlteringRIPsMetric

Considertheaboveexample.RouterBhastwopathstogettothe
192.168.100.0network,viaRouterAandRouterC.Becausethemetricis
equal(1hop),RouterBwillloadbalancebetweenthesetwopaths.
WhatifwewantedRouterBtoonlygothroughRouterA,anduseRouterC
onlyasabackup?Toaccomplishthis,wecanadjustRIPsmetrictomake
oneroutemorepreferredthantheother.
ThefirststepiscreatinganaccesslistonRouterBthatdefineswhich
routewewishtoalter:
RouterB(config)#ipaccessliststandardMYLIST
RouterB(configstdnacl)#permit192.168.100.00.0.0.255

Next,wetellRIPhowmuchtooffsetthisrouteifreceivedbyRouterC:
RouterB(config)#routerrip
RouterB(configrouter)#offsetlistMYLISTin4s1

WespecifyanoffsetlistpointingtoouraccesslistnamedMYLIST.We
willincreasetheroutingmetricby4forthatroutecominginboundto
interface
Serial1.
Thus,whenRouterCsendsanupdatetoRouterCforthe192.168.100.0

network,RouterBwillincreaseitsmetricof1hopto5hops,thus
makingRouterAsroutepreferred.
WecouldhavealsoconfiguredRouterCtoadvertisethatroutewitha
highermetric(noticetheoutintheoffsetlistcommand):
RouterC(config)#ipaccessliststandardMYLIST
RouterC(configstdnacl)#permit192.168.100.00.0.0.255
RouterC(config)#routerrip
RouterC(configrouter)#offsetlistMYLISTout4s0

InteroperatingbetweenRIPv1andRIPv2

Recallthat,withsomeconfiguration,RIPv1andRIPv2caninteroperate.By
default:

RIPv1routerswillsentonlyVersion1packets
RIPv1routerswillreceivebothVersion1and2updates
RIPv2routerswillbothsendandreceiveonlyVersion2updates

IfRouterAisrunningRIPv1,andRouterBisrunningRIPv2,
someadditionalconfigurationisnecessary.
EitherwemustconfigureRouterAtosendVersion2updates:
RouterA(config)#interfaces0
RouterA(configif)#ipripsendversion2

OrconfigureRouterBtoacceptVersion1updates.
RouterB(config)#interfaces0
RouterB(configif)#ipripreceiveversion1

Noticethatthisisconfiguredonaninterface.Essentially,were
configuringtheversionofRIPonaperinterfacebasis.
Wecanalsohaveaninterfacesendorreceivebothversionssimultaneously:
RouterB(config)#interfaces0
RouterB(configif)#ipripreceiveversion12

WecanfurtherforRIPv2tosendbroadcastupdates,insteadofmulticasts:
RouterB(config)#interfaces0
RouterB(config)#ipripv2broadcast

TriggeringRIPUpdates
Onpointtopointinterfaces,wecanactuallyforceRIPtoonlysendrouting
updatesifthereisachange:
RouterB(config)#interfaces0.150pointtopoint
RouterB(configif)#ipriptriggered

Again,thisisonlyapplicabletopointtopointlinks.Wecannotconfigure
RIPtriggeredupdatesonanEthernetnetwork.

TroubleshootingRIP
VarioustroubleshootingcommandsexistforRIP.
ToviewtheIProutingtable:
Router#showiproute
<eliminated irrelevant header>
Gateway of last resort is not set

C
C
R
R

172.16.0.0 is directly connected, Ethernet0

172.17.0.0 is directly connected, Serial0
172.18.0.0 [120/1] via 172.17.1.2, 00:00:15, Serial0
192.168.123.0 [120/1] via 172.16.1.1, 00:00:00, Ethernet0

ToviewaspecificroutewithintheIProutingtable:
Router#showiproute172.18.0.0
Routing entry for 172.18.0.0/16
Known via rip, distance 120, metric 1
Last update from 172.17.1.2 on Serial 0, 00:00:15 ago

TodebugRIPinrealtime:
Router#debugiprip

TroubleshootingRIP(continued)
ToviewinformationspecifictotheRIPprotocol:
Router#showipprotocols
Routing Protocol is "rip"
Sending updates
every 30 seconds, next due in 20 seconds
Invalid after 180 seconds, hold
down 180, flushed after 240
Outgoing update
filter list for all interfaces is not set
Incoming update
filter list for all interfaces is not set
Incoming routes
will have 4 added to metric if on list 1
Redistributing:
connected, static, rip
Default version
control: send version 1, receive any version
Interface
Send Recv Triggered RIP Key-chain
Ethernet0
1
1 2
Serial0
1 2
1 2
Automatic network summarization
is in effect
Maximum path: 4
Routing for Networks:
172.16.0.0
172.17.0.0
Routing Information Sources:
Gateway
Distance
Last Update
172.17.1.2
120
00:00:17
Distance: (default is 120)

ThiscommandprovidesuswithinformationonRIPtimers,ontheRIP
versionsconfiguredoneachinterface,andthespecificnetworksRIPis
advertising.
ToviewallroutesintheRIPdatabase,andnotjusttheentriesaddedtothe
routingtable:
Router#showipripdatabase
7.0.0.0/8 auto-summary
7.0.0.0/8
[5] via 172.16.1.1, 00:00:06, Ethernet0
172.16.0.0/16 directly connected, Ethernet0
172.17.0.0/16 directly connected, Serial0