مرحبا هابر. أنا حاليًا قائد دورة "مهندس الشبكة" في OTUS.
تحسبا لبدء تسجيل جديد للدورة ، لقد أعددت سلسلة من المقالات حول تقنية VxLAN EVPN.
هناك قدر هائل من المواد حول تشغيل VxLAN EVPN ، لذلك أرغب في جمع العديد من المهام والممارسات لحل المشكلات في مركز البيانات الحديث.
في الجزء الأول من دورة تكنولوجيا VxLAN EVPN ، أود التفكير في طريقة لتنظيم اتصال L2 بين المضيفين فوق مصنع الشبكة.
سيتم تنفيذ جميع الأمثلة على Cisco Nexus 9000v ، مجمعة في طبولوجيا Spine-Leaf. لن نتطرق إلى إعداد شبكة Underlay في هذه المقالة.
- شبكة الأساس
- التناظر BGP لعائلة العنوان l2vpn evpn
- إعداد NVE
- سوبريس أرب
شبكة الأساس
الطوبولوجيا المستخدمة هي كما يلي:
لنقم بتعيين العنونة على جميع الأجهزة:
Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102
Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21
Host-1 - 192.168.10.10
Host-2 - 192.168.10.20دعنا نتحقق من وجود اتصال IP بين جميع الأجهزة:
Leaf21# sh ip route
<........>
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 доступен чеерз два Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0 ! Leaf-12 доступен чеерз два Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
*via 10.255.1.22, Lo0, [0/0], 00:02:20, local
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
*via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intraدعنا نتحقق من إنشاء مجال VPC وأن كلا المحولين قد اجتازا اختبار التناسق وأن الإعدادات على كلا العقدتين متطابقة:
Leaf11# show vpc
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1التناظر BGP
أخيرًا ، يمكننا الانتقال إلى تكوين شبكة Overlay.
كجزء من المقالة ، من الضروري تنظيم شبكة بين المضيفين ، كما هو موضح في الرسم التخطيطي أدناه:
لتكوين شبكة Overlay ، تحتاج إلى تمكين BGP على مفاتيح Spine و Leaf مع دعم عائلة l2vpn evpn:
feature bgp
nv overlay evpnبعد ذلك ، تحتاج إلى تكوين مناظرة BGP بين الورقة والعمود الفقري. لتبسيط التكوين وتحسين توزيع معلومات التوجيه ، نقوم بتكوين Spine كخادم Route-Reflector. سنكتب كل Leaf في التكوين من خلال القوالب من أجل تحسين الإعداد.
لذا تبدو الإعدادات في Spine كما يلي:
router bgp 65001
template peer LEAF
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-client
neighbor 10.255.1.11
inherit peer LEAF
neighbor 10.255.1.12
inherit peer LEAF
neighbor 10.255.1.21
inherit peer LEAFيبدو الإعداد على مفتاح Leaf متشابهًا:
router bgp 65001
template peer SPINE
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
neighbor 10.255.1.101
inherit peer SPINE
neighbor 10.255.1.102
inherit peer SPINEفي العمود الفقري ، تحقق من التناظر باستخدام جميع مفاتيح الورق:
Spine1# sh bgp l2vpn evpn summary
<.....>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.1.11 4 65001 7 8 6 0 0 00:01:45 0
10.255.1.12 4 65001 7 7 6 0 0 00:01:16 0
10.255.1.21 4 65001 7 7 6 0 0 00:01:01 0كما ترى ، لم تكن هناك مشاكل مع BGP. دعنا ننتقل إلى إعداد VxLAN. سيتم إجراء المزيد من التكوين فقط على جانب مفاتيح Leaf. يعمل العمود الفقري فقط كنواة الشبكة ويشارك فقط في نقل حركة المرور. كل الأعمال المتعلقة بالتغليف وتعريف المسار تحدث فقط على مفاتيح التبديل الورقية.
إعداد NVE
NVE - واجهة الشبكة الافتراضية
قبل البدء في الإعداد ، دعنا نقدم بعض المصطلحات:
VTEP - Vitual Tunnel End Point ، الجهاز الذي يبدأ أو ينتهي عليه نفق VxLAN. VTEP ليس بالضرورة أي جهاز شبكة. يمكن أيضًا أن يعمل الخادم الذي يدعم تقنية VxLAN. في الهيكل الخاص بنا ، جميع مفاتيح Leaf هي VTEPs.
VNI - فهرس الشبكة الافتراضية - معرف الشبكة داخل VxLAN. يمكنك رسم تشبيه مع VLAN. ومع ذلك، هناك بعض الاختلافات. عند استخدام نسيج ، تصبح شبكات VLAN فريدة من نوعها فقط داخل مفتاح Leaf واحد ولا يتم نقلها عبر الشبكة. ولكن يمكن ربط كل شبكة محلية ظاهرية (VLAN) برقم VNI تم إرساله بالفعل عبر الشبكة. ستتم مناقشة شكله وكيف يمكن استخدامه أدناه.
تمكين ميزة تقنية VxLAN للعمل والقدرة على ربط أرقام VLAN برقم VNI:
feature nv overlay
feature vn-segment-vlan-basedلنقم بتهيئة واجهة NVE ، المسؤولة عن تشغيل VxLAN. هذه الواجهة مسؤولة عن تغليف الإطارات في رؤوس VxLAN. يمكنك رسم تشبيه بواجهة Tunnel لـ GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0على مفتاح Leaf-21 ، يتم إنشاء كل شيء دون مشاكل. ومع ذلك ، إذا تحققنا من إخراج الأمر show nve peers، فسيكون فارغًا. هنا تحتاج إلى العودة إلى إعداد VPC. نرى أن Leaf-11 و Leaf-12 تم إقرانهما وتوحيدهما بواسطة مجال VPC. ينتج عن هذا الموقف التالي:
يرسل Host-2 إطارًا واحدًا إلى Leaf-21 ليتم نقله عبر الشبكة إلى Host-1. ومع ذلك ، يرى Leaf-21 أن عنوان MAC الخاص بـ Host-1 متاح عبر اثنين من VTEPs في وقت واحد. ما الذي يجب أن تفعله Leaf-21 في هذه الحالة؟ بعد كل شيء ، هذا يعني أنه يمكن أن تظهر حلقة في الشبكة.
لحل هذا الموقف ، نحتاج إلى Leaf-11 و Leaf-12 للعمل أيضًا كجهاز واحد داخل المصنع. تم حلها بكل بساطة. في واجهة Loopback التي نبني منها النفق ، أضف العنوان الثانوي. يجب أن يكون العنوان الثانوي هو نفسه في كلا VTEPs.
interface loopback0
ip add 10.255.1.10/32 secondaryوبالتالي ، من وجهة نظر VTEPs الأخرى ، نحصل على الهيكل التالي:
وهذا يعني أنه سيتم الآن بناء النفق بين عنوان IP الخاص بـ Leaf-21 وعنوان IP الافتراضي بين جهازي Leaf-11 و Leaf-12. الآن لن تكون هناك مشاكل في تعلم عنوان MAC من جهازين ويمكن نقل حركة المرور من VTEP إلى آخر. يتم تحديد أي من VTEPs سيعالج حركة المرور باستخدام جدول التوجيه في العمود الفقري:
Spine1# sh ip route
<.....>
10.255.1.10/32, ubest/mbest: 2/0
*via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
*via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intraكما ترى أعلاه ، يتوفر العنوان 10.255.1.10 على الفور من خلال القفزات التالية.
في هذه المرحلة ، اكتشفنا الاتصال الأساسي. دعنا ننتقل إلى إعداد واجهة NVE:
سنقوم على الفور بتمكين Vlan 10 وربطه بـ VNI 10000 في كل ورقة للمضيفين. قم بإعداد نفق L2 بين المضيفين
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPالآن دعنا نتحقق من أقران nve وجدول BGP EVPN:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Видим что peer доступен с secondary адреса
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! От кого именно пришел этот l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! EVPN route-type 3 - показывает нашего соседа, который так же знает об l2VNI10000
10.255.1.10 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.20]/88
10.255.1.20 100 0 i
* i 10.255.1.20 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]/88
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iأعلاه نرى المسارات فقط طريق EVPN من النوع 3. هذا النوع من المسارات يتحدث عن النظير (Leaf) ، ولكن أين مضيفينا؟
والشيء هو أن المعلومات حول مضيفي MAC تنتقل عبر مسار EVPN من النوع 2
لرؤية مضيفينا ، تحتاج إلى تكوين مسار EVPN من النوع 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoدعنا ننتقل من Host-2 إلى Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msأدناه يمكننا أن نرى أن نوع المسار 2 ظهر في جدول BGP مع عنوان MAC للمضيفين - 5001.0007.0007 و 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 и mac адрес хоста 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 и mac адрес хоста 2
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iبعد ذلك ، يمكنك الاطلاع على معلومات مفصلة حول التحديث ، حيث تلقيت معلومات حول مضيف MAC. أدناه ليس الإخراج الكامل للأمر
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! отправил Update с MAC Host. Не виртуальный адрес VPC, а адрес Leaf
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
version 1507
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labe
led nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102) ! с кем именно строим VxLAN тоннель
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 ! Номер VNI, который ассоциирован с VLAN, в котором находится Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Тут видно, что RT сформировался автоматически на основе номеров AS и VNI
Originator: 10.255.1.11 Cluster list: 10.255.1.102
<........>لنرى كيف تبدو الإطارات عند مرورها عبر المصنع:
قمع- ARP
رائع ، لدينا اتصال L2 بين المضيفين وقد تكون هذه نهاية الأمر. ومع ذلك ، ليس كل شيء بهذه البساطة. طالما لدينا عدد قليل من المضيفين ، فلن تكون هناك مشاكل. لكن دعونا نتخيل المواقف التي لدينا مئات وآلاف المضيفين. ما المشكلة التي يمكن أن نواجهها؟
هذه المشكلة هي حركة مرور BUM (البث ، والبث الأحادي غير المعروف ، والبث المتعدد). في إطار هذه المقالة ، سننظر في خيار مكافحة حركة البث.
مولد البث الرئيسي في شبكات Ethernet هو المضيفون أنفسهم عبر بروتوكول ARP.
يقوم Nexus بتنفيذ الآلية التالية للتعامل مع طلبات ARP - suppress-arp.
تعمل هذه الميزة على النحو التالي:
- يرسل Host-1 طلب APR إلى عنوان البث لشبكته.
- يصل الطلب إلى مفتاح Leaf وبدلاً من تمرير هذا الطلب إلى المصنع باتجاه Host-2 ، يجيب Leaf على نفسه ويشير إلى IP و MAC المطلوبين.
وبالتالي ، فإن طلب البث لم يذهب إلى المصنع. ولكن كيف يمكن أن يعمل هذا إذا كان Leaf يعرف فقط عنوان MAC؟
كل شيء بسيط للغاية ، من النوع 2 من مسار EVPN ، بالإضافة إلى عنوان MAC ، يمكنه إرسال حزمة MAC / IP. للقيام بذلك ، يجب تكوين Leaf بعنوان IP في VLAN. السؤال الذي يطرح نفسه ، ما هو IP الذي يجب طرحه؟ على nexus ، من الممكن إنشاء عنوان موزع (واحد) على جميع المحولات:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! задаем virtual mac для создания распределенного шлюза между всеми коммутаторами
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! на всех Leaf задаем одинаковый IP
fabric forwarding mode anycast-gateway ! говорим использовать Virtual macوبالتالي ، من وجهة نظر المضيفين ، ستبدو الشبكة كما يلي:
تحقق من BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.21 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.10 100 0 i
* i 10.255.1.10 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
<......>
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i 10.255.1.20 100 0 i
<......>من إخراج الأمر ، يمكن ملاحظة أنه في مسار EVPN من النوع 2 ، بالإضافة إلى MAC ، نرى الآن أيضًا عنوان IP الخاص بالمضيف.
دعنا نعود إلى إعداد suppress-arp. يتم تمكين هذا الإعداد لكل VNI على حدة:
interface nve1
member vni 10000
suppress-arpثم هناك بعض الصعوبة:
- تتطلب هذه الميزة مساحة في ذاكرة TCAM. سأقدم مثالاً على الإعداد لـ suppress-arp:
hardware access-list tcam region arp-ether 256سيتطلب هذا الإعداد عرضًا مزدوجًا. هذا يعني أنه إذا قمت بتعيين 256 ، فيجب إصدار 512 في TCAM. إعداد TCAM خارج نطاق هذه المقالة ، نظرًا لأن إعداد TCAM يعتمد فقط على المهمة المعينة لك وقد يختلف من شبكة إلى أخرى.
- يجب أن يتم تنفيذ suppress-arp على جميع مفاتيح Leaf. ومع ذلك ، يمكن أن ينشأ التعقيد عند التكوين على أزواج الأوراق الموجودة في مجال VPC. عند تغيير TCAM ، سيتم كسر الاتساق بين الأزواج وقد يتم إخراج عقدة واحدة من الخدمة. بالإضافة إلى ذلك ، قد يلزم إعادة تشغيل الجهاز لتطبيق إعداد تغيير TCAM.
نتيجة لذلك ، يجب أن تفكر جيدًا فيما إذا كان الأمر يستحق تنفيذ هذا الإعداد في مصنع عامل في حالتك.
هذا يختتم الجزء الأول من الدورة. في الجزء التالي ، سننظر في التوجيه من خلال مصنع VxLAN مع فصل الشبكة عبر VRFs المختلفة.
والآن أدعو الجميع ، حيث سأتحدث بالتفصيل عن الدورة. سيحصل أول 20 مشاركًا سجلوا في هذه الندوة عبر الإنترنت على شهادة خصم عبر البريد الإلكتروني في غضون يوم أو يومين بعد البث.
المصدر: www.habr.com