لا تعلن vEdge عن نفسها كما هو الحال عندما يتم الإعلان عن موجهات BGP في OMP
المحتويات
المقدمة
يوضح هذا المستند سبب عدم إعلان موجه vEdge عن رقم النظام الذاتي (AS) الخاص به عند الإعلان عن مسارات بروتوكول العبارة الحدودية (BGP) إلى بروتوكول إدارة التغشية (OMP).
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
- الفهم الأساسي لحل شبكة المنطقة الواسعة (SDWAN) المعرف ببرنامج Viptela
- OMP
المكونات المستخدمة
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
تم إنشاء المعلومات الواردة في هذا المستند بمساعدة الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
التكوين
الرسم التخطيطي للشبكة
فيما يلي مخطط مخطط مخطط مخطط مخطط بسيط يصف الإعداد:
192.168.41 .0/24—|R1—vedge1—تراكب—vedge2—R2|—192.168.51.0/24
و يمكن وصف المشكلة هنا:
للبادئة A على R2 - تتوقع أن ترى AS-Path: 65002 و 64500 و 65001 و 65156، ولكن لم يظهر إلا 65002 64500 65156
للبادئة B في R1 - تتوقع أن ترى AS-Path: 65001 و 64500 و 65002 و 65157 ولكن لم يرى إلا 65001 64500 65157
التحقق من الصحة
استخدم هذا القسم لتأكيد عمل التكوين بشكل صحيح.
1. ألق نظرة على البادئة B (192.168.51.0/24) في vEdge2.
vedge2# show bgp routes 192.168.51.0/24 detail bgp routes-table vpn 40 192.168.51.0/24 best-path 1 info 0 nexthop 192.168.50.115 metric 0 weight 0 origin igp as-path 65157 ri-peer 192.168.50.115 ri-routerid 2.2.2.1 path-status valid,best,external tag 0
كما تلاحظ، يتكون مسار AS هنا من سلوك واحد كما هو الحال مع موجه R2 النظير وهذا السلوك المتوقع. يمكنك مشاهدة هذه البادئة على vEdge2 بالطريقة التي تم الإعلان عنها.
يمكنك ملاحظة سلوك مماثل لموجهات أنظمة تشغيل الربط البيني العادية (IOS®) من Cisco أيضا.
2. الإعلان عن طرق بروتوكول بوابة الحدود (BGP) من خلال برنامج إدارة الأنظمة المفتوحة (OMP).
omp overlay-as 64500 advertise bgp !
الإعلان عن تكوين BGP هو تماما مثل أمر إعادة توزيع معروف من Cisco IOS®Redistribute. OMP مماثل ل BGP، ولكن في الواقع، هو بروتوكول آخر تم تطويره خصيصا لحل SDWAN. لذلك، يمكنك الاحتفاظ بسمات بادئات BGP الموجودة في جدول BGP (ارجع إلى الخطوة 1).
3. دعنا نلقي نظرة على البادئة B (192.168.51.0/24) في vEdge1 بعد أن تكون قد مررت عبر التغشية.
vedge1# show omp routes 192.168.51.0/24 detail
---------------------------------------------------
omp route entries for vpn 40 route 192.168.51.0/24
---------------------------------------------------
RECEIVED FROM:
peer 192.168.30.103
path-id 12
label 1003
status C,I,R
loss-reason not set
lost-to-peer not set
lost-to-path-id not set
Attributes:
originator 192.168.30.105
type installed
tloc 192.168.30.105, mpls, ipsec
ultimate-tloc not set
domain-id not set
overlay-id 1
site-id 50
preference not set
tag not set
origin-proto eBGP
origin-metric 0
as-path "65157"
unknown-attr-len not set
كما تلاحظ، تم الاحتفاظ بسمات هذه البادئة بنفس كيفية عملها لأي بروتوكول توجيه ديناميكي آخر. مسار BGP هو سمة أخرى لبروتوكول التوجيه الخارجي لا معنى لها ل OMP. نموذج واحد فقط كما يظهر في المسار. إنه سلوك متوقع لأن vEdge2 لم يقم بأي إعلان لجارة BGP أخرى. وقد قامت بالفعل بإعادة التوزيع إلى OMP من BGP، لذلك يجب ألا ترجح خاصتها فيما يتعلق بهذه البادئة.
4. إعادة توزيع OMP إلى BGP AS 65001، ولكن الآن على vEdge1.
omp
no shutdown
overlay-as 64500
advertise bgp
!
…
!
vpn 40
router
bgp 65001
propagate-aspath
address-family ipv4-unicast
redistribute omp
!
neighbor 192.168.40.114
no shutdown
remote-as 65156
!
!
!
هنا هو المكان الذي يخطو فيه البرنامج الفرعي AS فعليا ويلعب دوره، ولكن على عكس البرنامج العادي Cisco IOS® لن ترى تغييرات في البادئة كما هو معلن عنه ل R1، نظرا لأنه، على vEdge لا يوجد أمر مماثل ل Cisco IOS® show IPv4 unicast BGP neighbors 192.168.40.114 موجهات معلنة يمكنها أن تساعد في رؤية المسار AS الذي تم إنشاؤه حديثا.
5. لذلك، يتبقى لديك فقط إمكانية التحقق من مسار AS على الموجه المستقبل (في هذه الحالة R1).
R1#show bgp vpnv4 unicast vrf vEdge1_18.3 neighbors 192.168.40.104 routes
BGP table version is 11, local router ID is 192.168.41.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:183 (default for vrf vEdge1_18.3)
*> 192.168.51.0 192.168.40.104 1000 0 65001 64500 65157 ?
استكشاف الأخطاء وإصلاحها
لا تتوفر حاليًا معلومات محددة لاستكشاف الأخطاء وإصلاحها لهذا التكوين.
القرار
يشترك OMP في بعض أوجه التشابه مع بروتوكول بوابة الحدود التجارية، ولكن لا ينبغي لهذه الحقيقة أن تحدث أي لبس عندما يتفاعل بروتوكولان مع بعضهما البعض. و"الطريق" هو أحد المواضيع التي تتسبب عادة في مثل هذا سوء الفهم.
التعليقات