المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

التكوين

الرسم التخطيطي للشبكة

التكوينات

التحقق من الصحة

المقدمة

الغرض من هذه المقالة هو منحك فهم العمل الأساسي ل MSR (النسخ المتماثل لخدمة البث المتعدد) باستخدام منصات IOS-XE، من خلال شكل دليل مختبر التكوين.

المتطلبات الأساسية

المتطلبات

الفهم الأساسي للبروتوكول PIM-SM

المكونات المستخدمة

ASR1000 (R2&R4) و ISR4300 (R3) و ISR2900 (R1&R5)

التكوين

سنعرض أدناه التكوينات الشاملة المستندة إلى السيناريو التخطيطي أدناه لإرسال البث المتعدد.

الرسم التخطيطي للشبكة

التكوينات

في المخطط أعلاه، تعمل العقدة R1 كجهاز إستقبال يفترض أن يحصل فقط على موجز بيانات البث المتعدد للبث الأحادي من مصدر البث المتعدد.

تعمل العقدة R5 كمصدر البث المتعدد الذي يقوم بإنشاء حركة مرور ICMP للبث المتعدد المستمدة من واجهة الاسترجاع 0 الخاصة بها.

تقع العقدة R2 ضمن مجال مركز البث المتعدد لمزودي المحتوى، وتقوم بتشغيل PIM-SM باستخدام قاعدة OSPF.

تعمل العقدة R3 كموجه يقوم بتشغيل تطبيق النسخ المتماثل لخدمة البث المتعدد وهو في هذه الحالة موجه حد البث المتعدد الذي من المفترض أن تتم ترجمة حركة مرور بيانات البث المتعدد من خلاله إلى حزمة بيانات البث الأحادي باتجاه المستقبل. وهو يستخدم OSPF و EIGRP مع مزود المحتوى و ISP على التوالي وهو يضم RP (نقطة الاسترداد) على واجهة الاسترجاع الخاصة به في مجال لب البث المتعدد.

تقع العقدة R4 تحت التحكم الأساسي ل ISP وهي ليست ممكنة للبث المتعدد ولا تفهم إلا كيفية الوصول إلى عقدة R3 باستخدام توجيه EIGRP الأساسي.

أدناه، يمكنك العثور على التكوينات ذات الصلة الموجودة على العقد الموجودة في مخطط المخطط الهيكلي أعلاه :

R1:

!

no ip domain lookup

ip cef

no ipv6 cef

!

interface GigabitEthernet0/2

ip address 10.10.20.1 255.255.255.0

duplex auto

speed auto

end

!

router eigrp 100

network 10.10.20.0 0.0.0.255

!

R2:

!

interface GigabitEthernet0/0/0

ip address 10.10.20.2 255.255.255.0

negotiation auto

!

interface GigabitEthernet0/0/2

ip address 10.10.10.1 255.255.255.0

negotiation auto

!

router eigrp 100

network 10.10.10.0 0.0.0.255

network 10.10.20.0 0.0.0.255

!

R3:

!

ip multicast-routing distributed

!

interface Loopback0

ip address 192.168.2.1 255.255.255.255

ip pim sparse-mode

ip ospf 1 area 0

!

interface GigabitEthernet0/0/0

ip address 192.168.30.1 255.255.255.0

ip pim sparse-mode

ip ospf 1 area 0

negotiation auto

!

interface GigabitEthernet0/0/1

ip address 10.10.10.2 255.255.255.0

negotiation auto

!

interface Vif1

ip address 192.169.169.1 255.255.255.0

ip pim sparse-mode

ip service reflect GigabitEthernet0/0/0 destination 224.1.1.0 to 10.10.20.0 mask-len 24 source 192.169.169.169 <<<<

ip igmp static-group 224.1.1.1

ip ospf 1 area 0

!

router eigrp 100

network 10.10.10.0 0.0.0.255

!

router ospf 1

!

ip pim rp-address 192.168.2.1

!

الخادم طراز R4:

!

ip multicast-routing distributed

!

interface GigabitEthernet0/0/0

ip address 192.168.30.2 255.255.255.0

ip pim sparse-mode

ip ospf 1 area 0

negotiation auto

!

interface GigabitEthernet0/0/2

ip address 192.168.20.1 255.255.255.0

ip pim sparse-mode

ip ospf 1 area 0

negotiation auto

!

router ospf 1

!

ip pim rp-address 192.168.2.1

!

R5:

!

ip multicast-routing

ip cef

no ipv6 cef

!

interface Loopback0

ip address 192.168.168.168 255.255.255.255

ip pim sparse-mode

ip ospf 1 area 0

!

interface GigabitEthernet0/2

ip address 192.168.20.2 255.255.255.0

ip pim sparse-mode

ip ospf 1 area 0

duplex auto

speed auto

!

router ospf 1

!

ip pim rp-address 192.168.2.1

!

التحقق من الصحة

يمكننا التحقق من التكوينات من خلال إجراء إختبار اتصال لمحاكاة حركة مرور البث المتعدد من الموجه R5 باستخدام مصدر لواجهة الاسترجاع 0 الخاصة به [192.168.168.168] الموجهة إلى عنوان البث المتعدد 224.1.1.1. 1. ثم التحقق من إدخالات المسار على العقدة التي تشغل تطبيق MSR، أي R3 :

R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000

Type escape sequence to abort.

Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.168.168

.............................

R3#sh ip mroute 224.1.1.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group,

G - Received BGP C-Mroute, g - Sent BGP C-Mroute,

N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,

Q - Received BGP S-A Route, q - Sent BGP S-A Route,

V - RD & Vector, v - Vector, p - PIM Joins on route,

x - VxLAN group, c - PFP-SA cache created entry

Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:47:41/stopped, RP 192.168.2.1, flags: SJC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vif1, Forward/Sparse, 00:46:36/00:01:23 <<<<

(192.168.168.168, 224.1.1.1), 00:00:20/00:02:43, flags: T

Incoming interface: GigabitEthernet0/0/0, RPF nbr 192.168.30.2

Outgoing interface list:

Vif1, Forward/Sparse, 00:00:20/00:02:39 <<<<

R3#sh ip mroute 224.1.1.1 count

Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics

3 routes using 2938 bytes of memory

2 groups, 0.50 average sources per group

Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second

Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 224.1.1.1, Source count: 1, Packets forwarded: 1455, Packets received: 1458 <<<<

RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0

Source: 192.168.168.168/32, Forwarding: 1454/1/113/0, Other: 1457/3/0

R3#sh ip mroute 224.1.1.1 count

Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics

3 routes using 2938 bytes of memory

2 groups, 0.50 average sources per group

Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second

Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 224.1.1.1, Source count: 1, Packets forwarded: 1465, Packets received: 1468 <<<<

RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0

Source: 192.168.168.168/32, Forwarding: 1464/1/113/0, Other: 1467/3/0

أيضا، أنت يستطيع أخذت على قبض أن يدقق أن الربط بالفعل يحصل ترجمت إلى ال يخطط unicast غاية عنوان على ال R2 عقدة ب يستعمل EPC (يطمر ربط التقاط) سمة على ال IOS-XE مسحاج تخديد :

R2#mon cap TAC int gi 0/0/2 both match any

R2#mon cap TAC buff siz 50 circular

R2#mon cap TAC start

Started capture point : TAC

R2#

*Aug 12 06:50:40.195: %BUFCAP-6-ENABLE: Capture Point TAC enabled.

R2#sh mon cap TAC buff br | i ICMP

6  114   10.684022   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<

7  114   10.684022   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<

8  114   12.683015   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<

9  114   12.683015   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<

هنا، النقطة المهمة التي تجدر ملاحظتها هي أنه بشكل منتظم عند إجراء إختبارات اتصال ICMP للبث المتعدد في "بيئات المختبر"، كنت تتوقع عادة أنك تستلم حزم الرد على ICMP بالصدى مرة أخرى من جانب المتلقي نحو المصدر، على افتراض أن هناك إمكانية وصول كاملة بين الاثنين (المصدر والمستقبل). ومع ذلك، من المهم، في هذا السيناريو، ملاحظة أنه حتى إذا حاولنا الإعلان عن عنوان مصدر NATted لحزم ICMP للبث المتعدد، أي 192.169.169.169 طوال الطريق إلى أن يقوم المستقبل أي R1 عبر EIGRP، فإنه ما يزال ردود صدى ICMP للبث الأحادي لن تعبر الموجه R3، نظرا لعدم تكوين NAT العكسي على عقدة تطبيق MSR. يمكننا إختبار ذلك، من خلال محاولة تنفيذ إعلان مسار EIGRP الخاص بواجهة VIF 1 على R3 داخل EIGRP (التوجيه الأساسي ل ISP) :

ISR4351(config)#router eigrp 100

ISR4351(config-router)#network 192.169.169.0 0.0.0.255 <<<<

الآن، يمكننا التحقق من عمليات الالتقاط التي تم التقاطها في عقدة R2 على ردود صدى ICMP التي يتم إرسالها نحو R3 :

R2#sh mon cap TAC buff br | i ICMP

249  114  317.847948   192.169.169.169  ->  10.10.20.1       0  BE   ICMP

250  114  317.847948   192.169.169.169  ->  10.10.20.1       0  BE   ICMP

251  114  317.847948   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<

252  114  317.847948   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<

253  114  319.847948   192.169.169.169  ->  10.10.20.1       0  BE   ICMP

254  114  319.847948   192.169.169.169  ->  10.10.20.1       0  BE   ICMP

255  114  319.848955   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<

256  114  319.848955   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<

259  114  321.848955   192.169.169.169  ->  10.10.20.1       0  BE   ICMP

260  114  321.848955   192.169.169.169  ->  10.10.20.1       0  BE   ICMP

261  114  321.848955   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<

262  114  321.848955   10.10.20.1       ->  192.169.169.169  0  BE   ICMP <<<<

و لكن إختبارات التصنيفات ستفشل كما هو موضح في مصدر R5 :

R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000

Type escape sequence to abort.

Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.168.168

......................................................................

......................................................................

الآن أن يحصل الرد أن يبلغ كل الطريق إلى المصدر، نحن يستطيع شكلت nat ميناء forwarding على ال MSR تطبيق عقدة R3 أن يترجم الحركة مرور معد ل إلى 192.169.169.169 إلى 192.168.168.168، ب يشكل nat قابل للتمديد :

R3(config)#int gi 0/0/1

R3(config-if)#ip nat out

R3(config-if)#int gi 0/0/0

R3(config-if)#ip nat ins

R3(config-if)#exit

R3(config)#ip nat inside source static 192.168.168.168 192.169.169.169 extendable <<<<

الآن وبالتحقق من مصدر عقدة R5، يمكننا أن نرى الاستجابة تعود :

R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000

Type escape sequence to abort.

Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.168.168

......................................................................

Reply to request 716 from 10.10.20.1, 1 ms

Reply to request 716 from 10.10.20.1, 1 ms

Reply to request 717 from 10.10.20.1, 1 ms

Reply to request 717 from 10.10.20.1, 1 ms

Reply to request 718 from 10.10.20.1, 1 ms

Reply to request 718 from 10.10.20.1, 1 ms

تم تنفيذ ما سبق فقط لشرح تدفق الحزمة وفهم كيفية إنشاء مسار/تدفق البث الأحادي العكسي لحركة مرور البيانات وحركة مرور البث المتعدد لتدفق البيانات. بما أنك في سيناريو الإنتاج العادي، فلن تأتي عادة بحالات/مثيلات تتطلب فيها تطبيقات البث المتعدد التي تعمل على الخادم/المصدر حزم إقرار عكسي من أجهزة الاستقبال في نموذج البث الأحادي.

من خلال الاختبارات وعمليات التحقق المذكورة أعلاه، يجب أن تكون قد قدمت نظرة عامة مختصرة على كيفية تشغيل تطبيق النسخ المتماثل لخدمة البث المتعدد على إحدى العقد الحدودية للبث المتعدد وكيفية نشر نفس الإجراء إذا كان سيتم توسيع نفس الإجراء الموضح أعلاه إلى عملية نشر واسعة النطاق.