Juniper关于某双层dhcprelay结构问题分析报告Word格式.docx

Juniper关于某双层dhcprelay结构问题分析报告Word格式.docx

《Juniper关于某双层dhcprelay结构问题分析报告Word格式.docx》由会员分享，可在线阅读，更多相关《Juniper关于某双层dhcprelay结构问题分析报告Word格式.docx（6页珍藏版）》请在冰豆网上搜索。

ipdhcppoolvlan-121

network172.20.3.0255.255.255.0

default-router172.20.3.1

iproute0.0.0.00.0.0.012.1.1.1

2、R5配置

ipaddress172.16.16.2255.255.255.0

interfaceFastEthernet1/0

switchportaccessvlan2

interfaceVlan2

ipaddress172.17.17.1255.255.255.0

iphelper-address12.1.1.2

iproute0.0.0.00.0.0.0172.16.16.1

3、R2配置

ipaddressdhcp

4、R6配置

5、MX1配置

interfaces{

ge-0/0/1{

unit0{

familyinet{

address12.1.1.1/24;

}

ge-0/0/4{

address172.16.16.1/24;

ge-0/0/5{

familybridge{

interface-modeaccess;

vlan-id121;

forwarding-options{

server-group{

dhcp-1{

12.1.1.2;

active-server-groupdhcp-1;

groupgroup-1

interfaceirb.121;

routing-options{

static{

route172.17.17.0/24next-hop172.16.16.2;

bridge-domains{

vlan-121{

routing-interfaceirb.121;

三、问题描述

通过上述配置后，则R2能正常获取IP,但PC-2则无法获取。

1、在PC-2debug信息

2、MX-1查看dhcprelay包统计

四、故障处理

通过上述抓包和MX-1上dhcprelay包统计可以看出，在MX-1上对dhcprelay过来的单播包进行了丢弃处理，这个是juniper设备独有的特性，其他厂商不需要额外处理，但juniper自身作为dhcprelay后，则默认对dhcprelay过来的单播报文作丢弃处理。

若需要接受这种报文，则需要开启。

dhcp-relay{

forward-snooped-clientsall-interfaces;

通过如上命令后，R6才可以正常获取到IP地址。

英文解释（http:

//blog.ip.fi/）

TherearetwodifferentwaystoconfigureDHCPinJunos,bootphelperanddhcprelay.Theseworkinverydifferentmanner,bootphelperisbeingphasedoutandisnotsupportedforexampleinQFX10k.Behaviourofbootphelperisobvious,itworkslikeitworksineveryothersensibleplatform.Behaviourofdhcp-relayisveryconfusingandit'

snotdocumentedatallanywhere.

Ifit'

spossibleinyourplatformtoconfigurebootphelper,doit.Ifnot,complaintoJunosaboutdhcp-relayimplementationandaskthemtofixit.Themainproblemwithdhcp-relayimplementationisthatonceyou'

veconfiguredit,you'

repuntingalldhcptrafficinallinterfaces.Normaltransittrafficcrossingyourrouterissubjecttothispunt,sotransitcustomerswillexperiencelargerjitteranddelayofpacketsbeingpuntedandalmostcertainlyreordering,becausethenon-dhcppacketthatcameafterbutwasnotsubjecttopuntwillbeforwardedfirst.Technicallyreorderingdoesnotmatter,aslongasitdoesnothappeninsideaflow,butit'

snotdesirable.

HowthesequenceofoperationworksinJunosfordhcp-relay:

1.TransitpackettouchesingressNPU

2.AfterL2lookup,beforeL3lookupingressNPUpuntsthetransitpackettoPFECPU

3.PFECPU,forreasonsobvioustopeopleondrugsencapsulatesthetransitDHCPpacketwithnewIP,UDPand28magicbytesheader.[ip_new,udp_new,28_bytes,ip_old,udp_old,payload]

4.PFECPUsendstheencapsulatedDHCPpackettoRE,sothatJDHCPDcaninspectit

5.JDHCPDdeterminesifit'

srelevanttoitornot,inourcaseit'

snot,innormalconfigurationitproceedstodropthetransitpacketasitwasnotinterestingtous!

Idon'

tdisagreethatonsomeinstancesitmaybedesirabletosnooptransitDHCPmessages,toseewhatserverunicaststoourclient,butthatissmallpercentageofthetraffic.WeknowtheDHCPserverswehave,whycan'

twedecidewhatispuntedandwhatisnot?

Ifoperatorisdoingherduediligenceandhasexactlo0filterwhichonlyallowsthingstoentercontrol-planewhichareactuallyneededthere,allofthisisbroken,butinaveryconfusingway.FirstlythesetransitDHCPpacketsareNOTsubjecttohardwarelevello0filter,youcannotdropthemthere,whichtomemakessense,theyaretransit,lo0filtershouldn'

taffectthem.Howeverafterpuntandencapsulationtheymagicallybecomesubjecttolo0filteronthesoftwareside!

Inyourtypicallo0filterwithultimate'

discardall'

term,you'

llseethesex.y.z.k=>

255.255.255.255packetsbeingdiscardedandyoumightbebitconfusedhowonearthwe'

regettingDADDR255.255.255.255fromourneighbouringcorerouters!

Soperhapsyou'

llrun'

monitortrafficinterfaceXmatching"

host255.255.55.255detail"

'

tounderstandbetterwhatisgoingon,well,youwon'

tseeanyofthese255.255.255.255packetsyouweredropping,becauseJunoshasaddedsupportintheirowntcpdumpforthisDHCPencapsulation,soyou'

reactuallyseeingtheoriginalembeddedheaders,notthenewtopheaders（wherethehost255.255.255.255ismatching）.Ifyouadd'

write-filedhcp.pcap'

andopenthatfileinwireshark,you'

llseetheinjectednewheadersandpacketbeinginterpretedasDHCP,includingtheoriginalheaderportion,whichmakesoutforaVERYconfusinglookingDHCPpacket.Ifyoumanuallypopfromthepacketip_new,udp_newand28bytes,you'

llseetheexpectedtransitpacket.

Strangenessdoesnotendhere,youcaneasilydiscard/log/countthese'

destination-address255.255.255.255'

inlo0filter（insoftware,notinhardware）,butwhenyouchangethat'

discard'

to'

accept'

youwon'

tseeanythingincounterorlogsanymore!

Yetitiscrucialthatyoudoacceptthem,becauseotherwisetheyaredroppedbeforejdhcpdhaschancetoprocessthem,andyou'

rekillingallyourtransitDHCP.Evenafteryouaddthisconfusingruletopermittransittraffictoenterjdhcpdyou'

restillgoingtobedroppingalltransitdhcpuntilyouconfigure'

setforwarding-optionsdhcp-relayforward-snooped-clientsall-interfaces'

.

Problemhereofcourseis,nowwe'

renotdiscriminatinginlo0filterthetransitpacketshittingSWprocessedlo0,andallrealDHCPdiscoverpacketscomingfromlocalinterfaces.IusuallyspecificallyonlyallowDHCPdiscoverfrominterfaceswhereI'

veenabledDHCP.Butwiththisdhcp-relayconfiguration,Ihavetoallowiteverywhere!

I'

mnolongerprotectedfromcustomershavingL2loopsandinjectingwire-rateofDHCPDiscovertomycontrol-plane,Inowhavetoacceptthose,becauseIcannotdiscriminateinlo0filteriftheyaretransitordiscovers.

WhatshouldJNPRdo?

Continuetosupportbootphelperstyleoperation,wherenotransittrafficiseverpunted.Makedhcp-relayworklikethatout-of-the-box,andpeoplewhoneedtosnooptransit,mustenableitandgivethemtoolstoenableitbasedonvariouskeys,saddr/daddr,interface,npu.I'

mprettysuretherearenowbunchofJNPRboxeswhichsilentlydroptransitDHCP,becausethereisnodocumentationanywhereonhowthisworks.

I'

mnotasconvincedasJTACthatthisisn'

tsimplyabug,itfeelsoddthatallthisreallywouldbetheintendedbehaviour.Thetellingproblemhereis,thatJNPRissomehowavoidinglo0evaluationinHW,Isuspectitis,becausethepacketisnotclassifiedasIPv4protocolbutDHCP-snoopingprotocol（yes,Junoshasipv4,ipv6,mpls,bridge,fibrechannelanddhcp-snoopingprotocolroutetables!

）andasit'

snotIPv4it'

snotsubjecttoHWlo0filter.Howevertheyseemtodroptheballafterpunt,makingtheembeddedpacketsubjecttoSWlo0filter,Ithinkitreallyshouldnotbehavelikethis.

IwishIcouldsaythisisonlysituationwhentransittrafficcanhitlo0filter,butthat'

snottrue.SomeJNPRplatformspunttransitIPoptionsandtransitIPv6HBHthroughlo0filter.Sointhosecasesyouneedtomatchonalllocaladdressesandip-optionsanddrop,thensecondruletoallowallip-options,unlessyouwanttodropalsoalltransitip-options（whichisprobablyjustfine）.Prettymuchnooneknowsthis,sopeoplelikelydon'

tknowwhatistheirnetwork'

spolicyregardingip-optionsandactualpolicyisjustdeterminedbyyournetworkupgradecycle.