له CE د RIP لارې څخه تر لیرې VRF پورې: export چېرې ترسره کېږي

In RIPv2 update provider edge ته رسېږي، د VRF routing table ته ننوځي او هلته پاتې کېږي، پرته له دې چې څوک یې په صراحت export کړي. درې پرېکړې په پرله‌پسې ډول پېښېږي او هر یو یې prefix د خپل دلیل له مخې ردولی شي. دوی یوازې د یوې پېښې په توګه لوستل هغه دلیل دی چې خلک ناسم بکس تعقیبوي کله چې یو لیرې site هغه network ته نه رسېږي چې CE یې په روښانه ډول اعلانوي. له PE څخه د لارې تعقیب کړئ او ترتیب به روښانه شي.

PE د RIP update سره څه کوي

PE update د VRF interface په سر ترلاسه کوي، تصدیقوي چې سرچینه یو اجازه لرونکی neighbor دی، او prefix د اعلان څخه اخیستل شوي hop count سره VRF routing table کې نصبوي. دا جدول یو نورمال routing table دی چې خپل administrative distance او خپله best-path ټاکنه لري. که CE یو شان prefix دوه ځله د بېلو metricونو سره اعلان کړي، یوازې غوره یې په جدول کې پاتې کېږي. دې مرحلې کې هېڅ شی د provider backbone شامل نه دی.

اوس prefix د یو کسټمر د routing context دننه شته، چې له بل چېرې د رسېدو څخه ډېر لرې دی.

Export یو پالیسي عمل دی، د پروتوکول پایله نه

تر څو له VRF څخه ووځي، یوه route باید هغه MP-BGP process ته redistribute شي چې VPN لارې وړي، او ورته د route target extended community اړتیا ده چې ښیي کوم لیرې VRFونه یې importولی شي. په RFC 4364 کې معماري همدې دلیل لپاره دغه تبادلې د CE-PE پروتوکول څخه جلا ساتي. په edge کې د RIP کارول هېڅ نه وایي چې د provider network له سره څه باید تېر شي.

د هر څه له تنظیمولو مخکې د export تړون ولیکئ: هغه کسټمر prefixونه چې باید له لیرې ځایه ورته رسېدل ممکن وي، هغه routeونه چې باید محلي پاتې شي، او هر ډول default، ډېر ځانګړي routeونه یا د شریکو خدمتونو استثناوې. دا تړون د واقعي VRF سره پرتله کړئ، نه د بل کسټمر د هماغه نوم VRF سره.

Import اړخ دوهمه پالیسي ده چې خپل route targetونه لري، او د import سره ناسمه سمه export هغه prefix جوړوي چې په backbone کې شته او په هېڅ لیرې جدول کې نه ښکاري.

Redistribution او explicit origination بېل چلند کوي

Redistribution هغه routeونه اخلي چې لا دمخه په VRF جدول کې شته او BGP ته یې کاپي کوي، چې د route map له مخې فلټر شوي دي. Map پرېکړه کوي چې کوم prefixونه وړ دي او کوم attributes وړي، او metric باید په صراحت وټاکل شي ځکه چې د RIP hop count د BGP metric په توګه مانا نه لري. هر څه چې تاسو ناسمېږدئ په داسې ډول میراثي کېږي چې معمولاً هغه څوک حیرانوي چې شپږ میاشتې وروسته config لولي.

Mutual redistribution هغه ځای دی چې غلی زیان پېښېږي. BGP ته export شوی prefix د دوهم redistribution point له لارې بېرته راتلای شي، او پرته له tag یا filter، route ټکان خوري په داسې حال کې چې دواړه جدولونه په هر لحظه باوري ښکاري. په edge کې پر تطبیق شوو tagونو فلټر وکړئ، نه دا چې د راستنېدو د مخنیوي لپاره په topology باور وکړئ.

Explicit origination ښایسته ښکاري او بې شرطه نه دی. network statement معمولاً د prefix د origination مخکې routing table کې سمه route غواړي، نو اعلان هغه شېبه ورکېږي چې CE یې اعلانول بند کړي. دا ډېری هغه چلند دی چې تاسو یې غواړئ، او له هغه static route سره یو شان نه دی چې تل تنظیم شوی پاتې کېږي. د پلیټفورم واقعي قاعده وګورئ، نه دا چې یو له دوو چلندونو څخه فرض کړئ.

په هر حال، د هر prefix په اړه پوښتنه دا ده چې کومه فعاله سرچینه یې وړ ګرځوي او کله چې هغه سرچینه ورکې شي څه پېښېږي.

لړ په څلورو ځایونو کې تصدیق کړئ

د CE اعلان، VRF routing table، د route target سره VPN route table، او په لیرې VRF کې import، په همدې ترتیب وګورئ. په IOS کې دا د CE neighbor output مانا لري، show ip route vrf CUSTOMER، show ip bgp vpnv4 vrf CUSTOMER، او په لیرې PE باندې هماغه command. په IOS-XR کې معادل output د show bgp vrf CUSTOMER ipv4 unicast لاندې دی. د commandونو نومونه بېل دي، څلور کنټرول نقطې نه.

هغه prefix چې باید رد شي هماغسې په دقت وګورئ لکه هغه چې باید تېر شي، ځکه هغه پالیسي چې هر څه اجازه ورکوي تر لومړنۍ استثنا پورې د سمې پالیسي سره ورته ښکاري. بیا یو withdrawal وګورئ: د CE interface بند کړئ او تصدیق کړئ چې لیرې entry په تمه شوي timer کې ورکېږي، نه پاتې کېږي.

ولیکئ چې هر پالیسي د چا ملکیت دی. کله چې provider CE چلوي، سپارل شوی چلند د خدمت تړون پورې اړه لري، او په مدیریت شوي وسیله کې بېل پروتوکول یا withdrawal پالیسي لومړی د اسنادو ستونزه ده او بیا د routing ستونزه.