تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يوضح هذا المستند كيفية أستكشاف أخطاء الحالات وإصلاحها التي يكون فيها جيران فتح أقصر مسار أولا (OSPF) عالقين في حالات Exstart و Exchange.
يوصى بأن يكون المستخدم على دراية بعملية OSPF الأساسية وتكوينها، لا سيما الدول المجاورة OSPF.
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
الموجهات طراز 2503 من Cisco
برنامج IOS® الإصدار 12.2(24a) من Cisco للتشغيل على كلا الموجهين
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
للحصول على مزيد من المعلومات حول اصطلاحات المستندات، ارجع إلى اصطلاحات تلميحات Cisco التقنية.
تكون حالات OSPF لتكوين التجاور معطلة، Init، ثنائية الإتجاه، Exstart، Exchange، Load و Full. يمكن أن يكون هناك عدد من الأسباب التي تجعل جيران فتح أقصر مسار أولا (OSPF) عالقين في حالة Exstart/Exchange. يركز هذا المستند على عدم تطابق MTU بين جيران OSPF مما يؤدي إلى حالة Exstart/Exchange. للحصول على مزيد من التفاصيل حول كيفية أستكشاف أخطاء OSPF وإصلاحها، ارجع إلى أستكشاف المشاكل الشائعة وإصلاحها باستخدام OSPF .
بعد أن يقوم موجهات OSPF المجاورين بإنشاء اتصال ثنائي الإتجاه واستكمال انتخاب DR/BDR (على شبكات الوصول المتعدد)، تنتقل الموجهات إلى حالة Exstart. في هذه الحالة، تقوم الموجهات المجاورة بإنشاء علاقة أساسية/تابعة وتحديد رقم التسلسل الأولي لواصف قاعدة البيانات (DBD) لاستخدامه أثناء تبادل حزم DBD.
مرة واحدة Primary/Subordinate
تم التفاوض على العلاقة (يصبح الموجه الذي يحتوي على أعلى Router-ID هو الأساسي)، ويتحول الموجهات المجاورة إلى حالة Exchange. في هذه الحالة، تتبادل الموجهات حزم DBD، والتي تصف قاعدة بيانات حالة الارتباط الخاصة بها بالكامل. تقوم الموجهات أيضا بإرسال حزم طلب حالة الارتباط، والتي تطلب المزيد من إعلانات حالة الارتباط الحديثة (LSA) من الجيران.
على الرغم من انتقال جيران OSPF من خلال حالات Exstart/Exchange أثناء عملية بناء تجاور OSPF العادية، إلا أنه ليس من الطبيعي أن يعلق جيران OSPF في هذه الحالة. يصف القسم التالي السبب الأكثر شيوعا لوقوع جيران OSPF في هذه الحالة. ارجع إلى فهم الدول المجاورة ل OSPF لمعرفة المزيد حول حالات OSPF المختلفة.
تحدث المشكلة غالبا عندما تحاول تشغيل OSPF بين موجه Cisco وموجه مورد آخر. تحدث المشكلة عند إعداد الحد الأقصى لوحدة الإرسال (MTU) ل neighboring
واجهات الموجه غير متطابقة. إذا كان الموجه صاحب وحدة الحد الأقصى للنقل (MTU) الأعلى يرسل حزمة أكبر من الحزمة التي قامت وحدة الحد الأقصى للنقل (MTU) بتعيينها على الموجه المجاور، فإن الموجه المجاور يتجاهل الحزمة. عندما تحدث هذه المشكلة، فإن مخرجات show ip ospf neighbor
يعرض الأمر مخرجات مماثلة لما هو موضح في هذا الشكل.
يصف هذا القسم الترفيه الفعلي لهذه المشكلة.
يتم توصيل الموجه 6 والموجه 7 في هذا الشكل عبر ترحيل الإطارات، وقد تم تكوين الموجه 6 باستخدام 5 مسارات ثابتة أعيد توزيعها في OSPF. تحتوي الواجهة التسلسلية على الموجه 6 على وحدة الحد الأقصى للنقل (MTU) الافتراضية طراز 1500، بينما تحتوي الواجهة التسلسلية على الموجه 7 على وحدة الحد الأقصى للنقل (MTU) بسعة 1450. يتم عرض تكوين كل موجه في الجدول (يتم عرض معلومات التكوين الضرورية فقط):
تكوين الموجه 6 | التكوين 7 للموجه |
---|---|
interface Serial2 !--- MTU is set to its default value of 1500. no ip address no ip directed-broadcast encapsulation frame-relay no ip mroute-cache frame-relay lmi-type ansi ! interface Serial2.7 point-to-point ip address 10.170.10.6 255.255.255.0 no ip directed-broadcast frame-relay interface-dlci 101 ! router ospf 7 redistribute static subnets network 10.170.10.0 0.0.0.255 area 0 ! ip route 192.168.0.10 255.255.255.0 Null0 ip route 192.168.10.10 255.255.255.0 Null0 ip route 192.168.10.0 255.255.255.0 Null0 ip route 192.168.37.10 255.255.255.0 Null0 ip route 192.168.38.10 255.255.255.0 Null0 |
interface Serial0 mtu 1450 no ip address no ip directed-broadcast encapsulation frame-relay frame-relay lmi-type ANSI ! interface Serial0.6 point-to-point ip address 172.16.7.11 255.255.255.0 no ip directed-broadcast frame-relay interface-dlci 110 ! router ospf 7 network 172.16.11.6 0.0.0.255 area 0 |
إخراج الأمر show ip ospf neighbor لكل موجه هو:
router-6#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 172.16.7.11 1 EXCHANGE/ - 00:00:36 172.16.7.11 Serial2.7 router-6# router-7#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.170.10.6 1 EXSTART/ - 00:00:33 10.170.10.6 Serial0.6 router-7#
تحدث المشكلة عندما يرسل الموجه 6 حزمة DBD أكبر من 1450 بايت (وحدة الحد الأقصى للنقل (MTU) للموجه 7) أثناء حالة التبادل. أستخدم debug ip packet
و debug ip ospf adj
قم بإصدار أوامر على كل موجه للاطلاع على عملية تجاور OSPF كما تحدث. المخرج من الموجه 6 و 7 من الخطوات 1 إلى 14 هو:
إخراج تصحيح الأخطاء للموجه 6:
<<<ROUTER 6 IS SENDING HELLOS BUT HEARS NOTHING, STATE OF NEIGHBOR IS DOWN>>>
00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on Serial2.7 is dead 00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on Serial2.7 is dead, state DOWN
إخراج تصحيح أخطاء الموجه 7:
<<<OSPF NOT ENABLED ON ROUTER7 YET>>>
إخراج تصحيح الأخطاء للموجه 6:
<<<ROUTER 6 SENDING HELLOS>>>
00:03:53: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), len 64, sending broad/multicast, proto=89 00:04:03: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), Len 64, sending broad/multicast, proto=89
إخراج تصحيح أخطاء الموجه 7:
<<<OSPF NOT ENABLED ON ROUTER7 YET>>>
إخراج تصحيح أخطاء الموجه 7:
<<<OSPF ENABLED ON ROUTER 7, BEGINS SENDING HELLOS AND BUILDING A ROUTER LSA>>>
00:17:44: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 64, sending broad/multicast, proto=89 00:17:44: OSPF: Build router LSA for area 0, router ID 172.16.7.11, seq 0x80000001
إخراج تصحيح الأخطاء للموجه 6:
<<<RECEIVE HELLO FROM ROUTER7>>>
00:04:04: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, Len 64, rcvd 0, proto=89 00:04:04: OSPF: Rcv hello from 172.16.7.11 area 0 from Serial2.7 172.16.7.11 00:04:04: OSPF: End of hello processing
إخراج تصحيح الأخطاء للموجه 6:
<<<ROUTER 6 SEND HELLO WITH ROUTER7 ROUTERID IN THE HELLO PACKET>>>
00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), Len 68, sending broad/multicast, proto=89
إخراج تصحيح أخطاء الموجه 7:
<<<ROUTER 7 RECEIVES HELLO FROM ROUTER6 CHANGES STATE TO 2WAY>>>
00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, Len 68, rcvd 0, proto=89 00:17:53: OSPF: Rcv hello from 10.170.10.6 area 0 from Serial0.6 10.170.10.6 00:17:53: OSPF: 2 Way Communication to 10.170.10.6 on Serial0.6, state 2WAY
إخراج تصحيح أخطاء الموجه 7:
<<<ROUTER 7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD>>>
00:17:53: OSPF: Send DBD to 10.170.10.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32 00:17:53: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 00:17:53: OSPF: End of hello processing
إخراج تصحيح الأخطاء للموجه 6:
<<<ROUTER 6 RECEIVES ROUTER7'S INITIAL DBD PACKET CHANGES STATE TO 2-WAY>>>
00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:04:13: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT 00:04:13: OSPF: 2 Way Communication to 172.16.7.11 on Serial2.7, state 2WAY
إخراج تصحيح الأخطاء للموجه 6:
<<<ROUTER 6 SENDS DBD PACKET TO ROUTER 7 (PRIMARY/SUBORDINATE
NEGOTIATION - ROUTER 6 ISSUBORDINATE
)>>>
00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7
seq 0xE44 opt 0x2 flag 0x7 Len 32
00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7),
Len 52, sending broad/multicast, proto=89
00:04:13: OSPF: NBR Negotiation Done. We are theSLAVE
إخراج تصحيح أخطاء الموجه 7:
<<<RECEIVE ROUTER 6'S INITIAL DBD PACKET (MTU MISMATCH IS RECOGNIZED)>>>
00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:17:53: OSPF: Rcv DBD from 10.170.10.6 on Serial0.6 seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART 00:17:53: OSPF: Nbr 10.170.10.6 has larger interface MTU
إخراج تصحيح الأخطاء للموجه 6:
<<<SINCE ROUTER 6 ISSUBORDINATE
SEND DBD PACKET WITH LSA HEADERS, SAME SEQ# (0x13FD) TO ACK ROUTER 7'S DBD. (NOTE SIZE OF PKT)>>>
00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7),
Len 1492, sending broad/multicast, proto=89
إخراج تصحيح أخطاء الموجه 7:
<<<NEVER RECEIVE ACK TO ROUTER7'S INITIAL DBD, RETRANSMIT>>>
00:17:54: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 68, sending broad/multicast, proto=89 00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: Retransmitting DBD to 10.170.10.6 on Serial0.6 [1]
عند هذه النقطة، يستمر الموجه 6 في محاولة الحصول على الحزمة الأولية DBD من الموجه 7.
00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, Len 68, rcvd 0, proto=89 00:04:13: OSPF: Rcv hello from 172.16.7.11 area 0 from Serial2.7 172.16.7.11 00:04:13: OSPF: End of hello processing 00:04:18: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:04:18: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE 00:04:18: OSPF: Send DBD to 172.16.7.11 on Serial2.7 seq 0x13FD opt 0x2 flag 0x2 Len 1472 00:04:18: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), Len 1492, sending broad/multicast, proto=89 00:04:23: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), Len 68, sending broad/multicast, proto=89 00:04:23: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:04:23: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE
لا يحصل الموجه 7 أبدا على ACK من الموجه 6 لأن حزمة DBD من الموجه 7 كبيرة جدا بالنسبة للموجه 7 MTU. يرسل الموجه 7 بشكل متكرر حزمة DBD.
0:17:58: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: Retransmitting DBD to 10.170.10.6 on Serial0.6 [2] 00:18:03: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 00:18:03: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, Len 68, rcvd 0, proto=89 00:18:03: OSPF: Rcv hello from 10.170.10.6 area 0 from Serial0.6 10.170.10.6 00:18:03: OSPF: End of hello processing 00:18:04: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 68, sending broad/multicast, proto=89 00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: Retransmitting DBD to 10.170.10.6 on Serial0.6 [3] 00:18:08: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 router-7#
نظرا لأن الموجه 6 يحتوي على وحدة الحد الأقصى للنقل (MTU) أعلى، فإنه يستمر في قبول حزمة DBD من الموجه 7، ويحاول الاعتراف بها، ويظل في حالة Exchange.
نظرا لأن الموجه 7 يحتوي على وحدة الحد الأقصى للنقل (MTU) أقل، فإنه يتجاهل حزم DBD مع ACK من الموجه 6، ويستمر في إعادة إرسال حزمة DBD الأولية، ويظل في حالة Exstart.
في الخطوة 9 و 11، يرسل الموجه 7 والموجه 6 أول حزم DBD خاصة بهم مع تعيين العلم 0x7 كجزء من التفاوض الأساسي/التابع. بعد Primary/Subordinate
التحديد، يتم إختيار الموجه 7 كأساسي بسبب المعرف الأعلى للموجه الخاص به. تظهر العلامات في الخطوة 13 و 14 بوضوح أن الموجه 7 أساسي (العلامة 0x7) والموجه 6 تابع (العلامة 0x2).
في الخطوة 10، يستقبل الموجه 6 الحزمة الأولية ل DBD طراز Router 7 ويحول حالته إلى الاتجاهين.
في الخطوة 12، يستلم الموجه 7 الحزمة الأولية DBD للموجه 6 ويتعرف على عدم تطابق MTU. (يمكن أن يتعرف الموجه 7 على عدم تطابق وحدة الحد الأقصى للنقل (MTU) لأن الموجه 6 يتضمن وحدة الحد الأقصى للنقل (MTU) الخاصة به في حقل وحدة الحد الأقصى للنقل (MTU) للواجهة لحزمة DBD). يتم رفض الموجه 6 DBD الأولي بواسطة الموجه 7. يرسل الموجه 7 الحزمة الأولية DBD.
توضح الخطوة 13 أن الموجه 6، ك subordinate
يعتمد رقم التسلسل 7 للموجه ويرسل حزمة DBD الثانية الخاصة به التي تحتوي على رؤوس مناطق LSA الخاصة به، والتي تزيد من حجم الحزمة. ومع ذلك، لا يستقبل الموجه 7 أبدا حزمة DBD هذه لأنها أكبر من الموجه 7 MTU.
بعد الخطوة 13، يستمر الموجه 7 في إعادة إرسال الحزمة الأولية DBD إلى الموجه 6، بينما يستمر الموجه 6 في إرسال حزم DBD التي تلتزم برقم التسلسل الأساسي. تستمر هذه الحلقة إلى أجل غير مسمى، مما يمنع أي من الموجهات من الانتقال خارج حالة exstart/exchange.
نظرا لأن المشكلة تحدث بسبب وحدات الحد الأقصى للنقل (MTU) غير المتطابقة، فإن الحل هو تغيير وحدة الحد الأقصى للنقل (MTU) للموجه لمطابقة وحدة الحد الأقصى للنقل (MTU) المجاورة.
ملاحظة: قام الإصدار 12.0(3) من برنامج Cisco IOS Software بتقديم اكتشاف عدم تطابق وحدة الحد الأقصى للنقل (MTU) للواجهة. يتضمن هذا الكشف OSPF الذي يعلن عن وحدة الحد الأقصى للنقل (MTU) للواجهة في حزم DBD، والتي تكون وفقا ل OSPF RFC 2178، الملحق g.9. عندما يستقبل الموجه حزمة DBD يتم الإعلان عنها بأنها أكبر من الموجه الذي يمكن أن يستلمه، يتجاهل الموجه الحزمة DBD وتظل الحالة المجاورة في Exstart. وهذا يمنع تكوين التجاور. لحل هذه المشكلة، تأكد من أن وحدة الحد الأقصى للنقل (MTU) هي نفسها على كلا طرفي الرابط.
في البرنامج Cisco IOS Software 12.01(3)، تم إدخال أمر تكوين الواجهة ip ospf mtu-ignore أيضا لإيقاف تشغيل اكتشاف عدم تطابق MTU، ومع ذلك، لا يلزم هذا إلا في حالات نادرة، كما هو موضح في هذا المخطط:
يوضح المخطط السابق منفذ واجهة البيانات الموزعة عبر الألياف (FDDI) على Cisco Catalyst 5000 مع وحدة نمطية للتحويل والتوجيه (RSM) متصلة بواجهة FDDI على الموجه 2. الشبكة المحلية الظاهرية (VLAN) على RSM هي واجهة إيثرنت افتراضية مع وحدة الحد الأقصى للنقل (MTU) رقم 1500، وواجهة FDDI على الموجه 2 لديها وحدة الحد الأقصى للنقل (MTU) رقم 4500. عندما إستلمت ربط على ال FDDI ميناء من المفتاح، هو يذهب إلى اللوحة الخلفية وال FDDI إلى إثرنيت يقع تحويل/تجزئة ضمن المفتاح نفسه. هذا إعداد صالح، ولكن باستخدام ميزة اكتشاف عدم تطابق MTU، لا يتم تكوين تجاور OSPF بين الموجه و RSM. ونظرا لاختلاف FDDI و Ethernet MTU، فإن هذا الأمر ip ospf mtu-ignore يكون مفيدا على واجهة VLAN الخاصة ب RSM لإيقاف اكتشاف OSPF لعدم تطابق MTU وتشكيل التجاور.
من المهم ملاحظة أن عدم تطابق MTU، على الرغم من أنه الأكثر شيوعا، ليس هو السبب الوحيد الذي يجعل جيران OSPF عالقين في حالة Exstart/Exchange. تحدث المشكلة في معظم الأحيان بسبب عدم القدرة على تبادل حزم DBD بنجاح. ومع ذلك، قد يكون السبب الجذري أي مما يلي:
عدم تطابق MTU
البث الأحادي مكسور. في حالة Exstart، يرسل الموجه حزمة للبث الأحادي إلى المجاور لاختيار الأساسي والثانوي. وهذا صحيح ما لم يكن لديك إرتباط من نقطة إلى نقطة، وفي هذه الحالة فإنه يرسل حزمة بث متعدد. هذه هي الأسباب المحتملة:
تخطيط الدائرة الظاهرية (VC) الخطأ في وضع النقل غير المتزامن (ATM) أو بيئة ترحيل الإطارات في شبكة عالية التكرار.
مشكلة MTU، مما يعني أن الموجهات يمكنها فقط إختبار اتصال حزمة ذات طول معين.
تمنع قائمة الوصول حزمة البث الأحادي.
nat يركض على المسحاج تخديد ويترجم ال unicast ربط.
جار بين PRI و BRI/المتصل.
يحتوي كلا الموجهين على نفس معرف الموجه (mis-configuration).
بالإضافة إلى ذلك، يشير RFC 2328 الخاص ب OSPF، القسم 10.3، إلى أن عملية Exstart/Exchange قد بدأت لأي من هذه الأحداث (قد يكون أي منها ناجما عن مشاكل برامج داخلية):
رقم التسلسل غير متطابق.
رقم تسلسل DD غير متوقع.
تم تعيين البت "I" بشكل غير متوقع.
حقل "الخيار" مختلف عن حقل "الخيار الأخير" الذي تم تلقيه في حزمة DBD.
BadLSReq
يرسل الجار LSA غير معروف أثناء عملية التبادل.
طلب الجار LSA أثناء عملية التبادل التي لا يمكن العثور عليها.
عندما لا يشكل OSPF جيران، ضع في الاعتبار العوامل المذكورة سابقا، مثل الوسائط المادية وأجهزة الشبكة، من أجل أستكشاف المشكلة وإصلاحها.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
2.0 |
18-Sep-2023 |
تقويم |
1.0 |
10-Dec-2001 |
الإصدار الأولي |