રાઉટર પિંગ વિરુદ્ધ VLAN હોસ્ટ: કઈ PBR નીતિ લાગુ પડે છે?

VLAN 10 એ VPN વાપરવું જોઈએ અને VLAN 20 એ WAN, તેથી પ્રથમ પરીક્ષણ એ VLAN 10 ના ઇન્ટરફેસ સરનામાને સ્રોત બનાવીને રાઉટરથી કરેલો પિંગ છે. તે સફળ થાય છે, route-map કાઉન્ટર વધે છે અને બધા માને છે કે ડિઝાઇન કામ કરે છે. તે કામ કરતું નથી. તે પિંગ સ્થાનિક રીતે ઉત્પન્ન થયો હતો, અને સ્થાનિક રીતે ઉત્પન્ન થયેલ ટ્રાફિક VLAN ઇન્ટરફેસ પર આવતા પેકેટ કરતાં નીતિના બીજા જોડાણ બિંદુ સુધી પહોંચે છે.

ત્રણ શરતો નક્કી કરે છે કે તમે ખરેખર કઈ નીતિ ચકાસી રહ્યા છો: પેકેટ ક્યાં બને છે, તે ક્યાં પ્રવેશે છે અને શે સાથે મેળ ખાય છે.

પેકેટ ક્યાં પ્રવેશે છે તે નક્કી કરે છે કઈ નીતિ ચાલે છે

ip policy route-map સાથે જોડાયેલ ઇન્ટરફેસ route-map તે ઇન્ટરફેસ પર આવતા પેકેટને લાગુ પડે છે, જેમ IOS XE PBR માર્ગદર્શિકા વર્ણવે છે. VLAN 10 નો હોસ્ટ તેની વિનંતી મોકલે છે, ફ્રેમ VLAN સબઇન્ટરફેસ પર આવે છે અને રાઉટર ત્યાં નીતિનું મૂલ્યાંકન કરે છે. રાઉટરનું પોતાનું પેકેટ ક્યારેય તે ઇન્ટરફેસ પર આવતું નથી, કારણ કે તે રાઉટરમાં જન્મ્યું હતું.

VLAN સરનામાને સ્રોત તરીકે પસંદ કરવાથી હેડર બદલાય છે. તે મૂળ બદલતું નથી.

સ્રોતવાળું પિંગ હજી પણ હોસ્ટ કેમ નથી

સ્રોત સરનામું ACL મેળ માટે મહત્ત્વનું છે, અને એટલે જ આ પરીક્ષણ એટલું વિશ્વાસપાત્ર લાગે છે. પેકેટ સ્રોત શરત સાથે મેળ ખાય છે, કાઉન્ટર વધે છે અને આઉટપુટ સાચું દેખાય છે. પરીક્ષણ એ બતાવી શકતું નથી કે પ્રવેશ ઇન્ટરફેસ કયું છે, આગમનનો સંદર્ભ શું છે, અથવા હોસ્ટનું પેકેટ એ જ શાખા લેશે કે નહીં.

જે પરીક્ષણ મેળનું પુનરાવર્તન કરે છે પણ સંદર્ભનું નહીં, તે ડિઝાઇનનો અડધો ભાગ સાબિત કરે છે, અને અડધા પુરાવા સાથે જ ડિઝાઇન ખોટી નીતિ સાથે બહાર જાય છે.

સ્થાનિક નીતિ ક્યારે સાચો જવાબ છે

Cisco ip local policy route-map નું દસ્તાવેજીકરણ એ ટ્રાફિક માટે કરે છે જે રાઉટર પોતે ઉત્પન્ન કરે છે. તે અલગ વ્યાપ છે, અને જ્યારે જરૂરિયાત ખરેખર રાઉટરના પોતાના ટ્રાફિકને લગતી હોય ત્યારે તે યોગ્ય સાધન છે. તે એવું ચૂકી ગયેલું પગલું નથી જે દરેક VLAN-સ્ટીયરિંગ ડિઝાઇનને જરૂરી હોય. ત્યાં વ્યાપક મેળ વ્યવસ્થાપન અને સહાયક જોડાણોને પણ અસર કરી શકે છે, જે દેખાય તેના કરતાં ઘણો મોટો ફેરફાર છે.

સ્થાનિક રીતે ઉત્પન્ન થયેલ TCP માટે એક વધારાની પૂર્વશરત છે: નીતિ બીજો માર્ગ પસંદ કરે તો પણ તેને રાઉટિંગ કોષ્ટકમાં લાગુ ગંતવ્ય નોંધની જરૂર છે. ICMP પરિણામ TCP માટે એ જ વર્તન સાબિત કરતું નથી.

તેના બદલે હોસ્ટ પર શું ચકાસવું

પરીક્ષણ VLAN 10 ના અધિકૃત હોસ્ટ પરથી તેના વાસ્તવિક સ્રોત સરનામા, ગંતવ્ય, પ્રોટોકોલ અને પોર્ટ સાથે ચલાવો. પ્રવેશ ઇન્ટરફેસ અને route-map મેળને પરિણામ સાથે નોંધો, જેથી પુરાવો ચાલેલી નીતિનું નામ લે. પછી VLAN 20 ના હોસ્ટ માટે પુનરાવર્તન કરો અને ખાતરી કરો કે તે બીજો માર્ગ લે છે.

બંને માર્ગોને કામ કરતા next hop, પરત પહોંચ અને જ્યાં લાગુ પડે ત્યાં VPN કવરેજની જરૂર છે. PBR ફોરવર્ડિંગ નિર્ણય પસંદ કરે છે; તે દૂરની સેવા બનાવતું નથી કે એપ્લિકેશનને પરવાનગી આપતું નથી.

પરિણામ શું સાબિત કરી શકે છે અને શું નહીં

સફળ હોસ્ટ પ્રવાહ સાબિત કરે છે કે નીતિ મેળ ખાઈ અને પસંદ કરેલો માર્ગ તે ક્ષણે કામ કરતો હતો. તે સાબિત કરતું નથી કે રાઉટરનો પોતાનો ટ્રાફિક નિર્દેશિત થઈ રહ્યો છે, અને તે સાબિત કરતું નથી કે એપ્લિકેશન અધિકૃત હતી, કારણ કે આ અલગ પ્રશ્નો છે અને તેમના પુરાવા અલગ છે.

પિંગને રેકોર્ડમાં સ્થાનિક પેકેટના પુરાવા તરીકે રાખો. પછી હોસ્ટ-પ્રવાહનો પુરાવો લેવા જાઓ, તેના બદલે નીતિનો વ્યાપ ત્યાં સુધી ન વધારો જ્યાં સુધી બંને પરીક્ષણો આકસ્મિક રીતે સરખા ન દેખાય.