مقالات

چگونه ARP یک مسیر استاتیک را کشت «وبلاگ ippace.net


مقدار چیزهای عجیب و غریب که در تست های ادغام NetLab پیدا می کنیم شگفت انگیز است یا شاید من این توانایی را دارم که به زوایای تاریک اشتباه نگاه کنم (همسرم قطعاً با آن موافق است). ویژه امروز: وقتی دو امید بعدی دارید ، یک مسیر استاتیک را می کشد.

TL & DR: تنظیمات ARP به طور پیش فرض میزبان لینوکس چند گروهی کمتر از بهینه است.

ما هنگام ایجاد از این اصول استفاده می کنیم باکله تست های ادغام:

  • آنها باید برای یک دستگاه تست و یک دسته از پروب های پیوست حاوی یک آزمایش باشند.
  • آنها باید یک عملکرد را آزمایش کنند.
  • آنها نباید به آزمایش دستگاه در زیر اعتماد کنند. تمام اعتبار سنجی باید در پروب انجام شود.

چگونه مسیرهای استاتیک را تحت این محدودیت ها آزمایش می کنید؟ این کاری است که ما انجام دادیم:

  • یک دستگاه را در زیر آزمایش به گره لینوکس (کار با Fruition) با رابط Loopback وصل کنید.
  • یک مسیر استاتیک را برای رابط Loopback در تست دستگاه با هاپ بعدی که در آدرس IP اترنت گره لینوکس هدف قرار گرفته است ، پیکربندی کنید.
  • روی گره لینوکس ، رابط اترنت پینگ تست دستگاه تحت آدرس IP Loopback.

بسته خروجی درخواست های ICMP همیشه باید ارسال شود (آدرس مقصد IP مستقیماً به هم متصل است). با این حال ، پاسخ فقط هنگامی بازگردانده می شود که دستگاه تست مسیر استاتیک به درستی پیکربندی شده برای منبع آدرس IP بسته درخواست ICMP داشته باشد.

در اینجا یک توپولوژی نمونه از شبکه (آزمایشی که دریافتیم که این عجیب و غریب کمی گیج تر است) وجود دارد:


این مربوطه است باکله توپولوژی آزمایشگاهی:

باکله توپولوژی آزمایشگاهی پیکربندی یک مسیر استاتیک

---
provider: clab
module: [ routing ]

nodes:
  dut:
    device: vjunos-switch
    routing.static:
    - node: probe
      nexthop.node: probe
  probe:
    device: frr

links: [ dut-probe ]

همانطور که انتظار می رود ، هر دستگاه به درستی پیکربندی شده به راحتی از این آزمایش عبور می کند. ماموریت برآورده شد.

کاوشگر می تواند پینگ کند

$ netlab connect probe
Connecting to container clab-X-probe, starting bash

Use vtysh to connect to FRR daemon

probe(bash)# ping -c 3 10.1.0.1 -I 10.0.0.2
PING 10.1.0.1 (10.1.0.1) from 10.0.0.2: 56 data bytes
64 bytes from 10.1.0.1: seq=0 ttl=64 time=0.484 ms
64 bytes from 10.1.0.1: seq=1 ttl=64 time=0.759 ms
64 bytes from 10.1.0.1: seq=2 ttl=64 time=0.661 ms

--- 10.1.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.484/0.634/0.759 ms

واقعاً نیست در این حالت ممکن است بیش از یک ارتباط بین دستگاه ها وجود داشته باشد باکله چندین مسیر استاتیک را برای همان مقصد پیکربندی می کند. بیایید آزمون را با توپولوژی زیر تکرار کنیم:

دو پیوند ، دو هاپ بعدی برای همان مقصد

دو پیوند ، دو هاپ بعدی برای همان مقصد

در اینجا باکله اگر می خواهید آزمایش را تکرار کنید ، توپولوژی. تنها تغییر در خط 13 است (دو اتصال به جای یک).

باکله توپولوژی آزمایشگاهی پیکربندی دو مسیر استاتیک برای همان مقصد

provider: clab
module: [ routing ]

nodes:
  dut:
    device: vjunos-switch
    routing.static:
    - node: probe
      nexthop.node: probe
  probe:
    device: frr

links: [ dut-probe, dut-probe ]

بیشتر دستگاه ها این تست را با رنگ های پرواز می گذرانند اما پینگ این فرمان با Vjunos-Switch شکست می خورد تا زمانی که ما از یک رابط لینوکس به طور مستقیم متصل شویم:

پینگ از رابط Linux Loopback تا زمانی که یک پینگ ساده درست کنیم شکست می خورد

probe(bash)# ping 10.1.0.1 -I 10.0.0.2
PING 10.1.0.1 (10.1.0.1) from 10.0.0.2: 56 data bytes
^C
--- 10.1.0.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
probe(bash)# ping -c 1 10.1.0.1
PING 10.1.0.1 (10.1.0.1): 56 data bytes
64 bytes from 10.1.0.1: seq=0 ttl=64 time=2.248 ms

--- 10.1.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 2.248/2.248/2.248 ms
probe(bash)# ping -c 3 10.1.0.1 -I 10.0.0.2
PING 10.1.0.1 (10.1.0.1) from 10.0.0.2: 56 data bytes
64 bytes from 10.1.0.1: seq=0 ttl=64 time=0.437 ms
64 bytes from 10.1.0.1: seq=1 ttl=64 time=0.775 ms
64 bytes from 10.1.0.1: seq=2 ttl=64 time=0.489 ms

--- 10.1.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.437/0.567/0.775 ms

این بدیهی است که یک لحظه غول پیکر WTAF است ، اما خوشبختانه من قبلاً چنین چیزهایی را تجربه کرده ام و بلافاصله مشکوک شده ام که باید حافظه پنهان ARP را در یکی از دستگاه ها گرم کنیم. مرحله بعدی: یک بسته اتصال را که درخواست ICMP باید منتقل شود ، ضبط کنید. این می تواند فک شما را کاهش دهد

درخواست های عجیب ARP ارسال شده توسط Linux Knot

$ netlab capture probe eth1 ip or arp
Starting packet capture on probe/eth1: sudo ip netns exec clab-X-probe tcpdump -i eth1 --immediate-mode -l -vv ip or arp
tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:31:43.900846 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.0.1 tell 10.0.0.2, length 28
11:31:44.903669 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.0.1 tell 10.0.0.2, length 28
11:31:45.927675 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.0.1 tell 10.0.0.2, length 28
11:31:47.901226 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.0.1 tell 10.0.0.2, length 28

من نمی توانم تصمیم بگیرم چه چیزی دشوارتر است:

  • لینوکس درخواست ARP را از آدرس IP متعلق به یک رابط دیگر ارسال می کند
  • Junos به این درخواست ARP پاسخ نمی دهد.

نکته جانبی: پینگ 10.1.0.1 از 10.1.0.2 حافظه نهان Linux ARP و سوئیچ Junos را گرم می کند ، بنابراین بسته بعدی ICMP ارسال شده از آدرس IP Loopback به وضوح ARP احتیاج ندارد.

خواندن RFC 826 بی فایده است. بسیار نامشخص است که پاسخ دادن به اینکه آیا لینوکس آن را می شکند (احتمالاً نه) غیرممکن است. علاوه بر این ، همانطور که من آن را خواندم ، گیرنده درخواست ARP باید به هر چیزی پاسخ دهد و معرفی کند هرگونه اطلاعات آدرس در جدول ARP او. من احتمالاً چیزی را از دست می دهم (از جمله برخی از لینوکس های عجیب سس پارامتر) ؛ نظرات بهتر است

در اینجا قسمت خراشیده شده است: چرا تست یک لینک در حالی که آزمایش دو لینک نیاز به یک تمرین گرمایش ARP دارد ، کار می کند؟

به نظر می رسد که Junos (مانند هر دستگاه شبکه مناسب دیگر) از هاپ بعدی مسیرهای استاتیک جلوگیری می کند. این یک ورودی ARP را در هر دو انتهای اتصال و کارهای پینگ ایجاد می کند.

پیکربندی ، مسیریابی و جدول ARP با Vjunos-Switch با یک اتصال با یک اتصال

admin@dut> show configuration routing-options
static {
    route 10.0.0.2/32 next-hop 10.1.0.2;
}

admin@dut> show route table inet.0

inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Limit/Threshold: 1048576/1048576 destinations
+ = Active Route, - = Last Active, * = Both

10.0.0.1/32        *[Direct/0] 00:02:29
                    >  via lo0.0
10.0.0.2/32        *[Static/5] 00:02:26
                    >  to 10.1.0.2 via ge-0/0/0.0
10.1.0.0/30        *[Direct/0] 00:02:29
                    >  via ge-0/0/0.0
10.1.0.1/32        *[Local/0] 00:02:29
                       Local via ge-0/0/0.0

admin@dut> show arp
MAC Address       Address         Name                      Interface               Flags
52:55:0a:00:00:02 10.0.0.2        probe                     fxp0.0                  none
aa:c1:ab:81:dd:60 10.1.0.2        10.1.0.2                  ge-0/0/0.0              none
02:00:00:00:00:10 128.0.0.16      fpc0                      em1.0                   none
Total entries: 3

Vjunos-translumer ، با این حال فقط برای یکی از هاپ بعدیS در اسکریپت دو لینک دو هاپ بعدی وجود دارد ، اما ما فقط می توانیم یک رکورد ARP را در جدول ARP مشاهده کنیم:

Junos Static Rout

admin@dut> show configuration routing-options
static {
    route 10.0.0.2/32 next-hop [ 10.1.0.2 10.1.0.6 ];
}

admin@dut> show route table inet.0

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Limit/Threshold: 1048576/1048576 destinations
+ = Active Route, - = Last Active, * = Both

10.0.0.1/32        *[Direct/0] 00:13:08
                    >  via lo0.0
10.0.0.2/32        *[Static/5] 00:13:05
                       to 10.1.0.2 via ge-0/0/0.0
                    >  to 10.1.0.6 via ge-0/0/1.0
10.1.0.0/30        *[Direct/0] 00:13:08
                    >  via ge-0/0/0.0
10.1.0.1/32        *[Local/0] 00:13:08
                       Local via ge-0/0/0.0
10.1.0.4/30        *[Direct/0] 00:13:08
                    >  via ge-0/0/1.0
10.1.0.5/32        *[Local/0] 00:13:08
                       Local via ge-0/0/1.0

admin@dut> show arp
MAC Address       Address         Name                      Interface               Flags
52:55:0a:00:00:02 10.0.0.2        probe                     fxp0.0                  none
aa:c1:ab:b7:35:90 10.1.0.6        10.1.0.6                  ge-0/0/1.0              none
02:00:00:00:00:10 128.0.0.16      fpc0                      em1.0                   none
Total entries: 3

حافظه پنهان ARP آینه های لینوکس که:

حافظه پنهان ARP در Linux Knot شامل یک آدرس IP Junos است

$ netlab connect probe arp
Connecting to container clab-X-probe, executing arp
ge-0-0-1.0.dut (10.1.0.5) at 0c:00:8b:48:ac:02 [ether]  on eth2
ge-0-0-0.0.dut (10.1.0.1) at   on eth1

در پایان ، “شانس” باورنکردنی من (من رابط کاربری اشتباه پینگ را انتخاب کردم) این طوفان کامل را ایجاد کردم و نمی خواهم به شما بگویم که چه مدت هدر رفته ایم ، این گریم خاص را دنبال می کنیم.

البته یک هک sysctl وجود دارد

چند روز پس از نوشتن این پست وبلاگ ، استفانو ساسو در آزمایش مسیرهای استاتیک Vyos با همان رفتار عجیب و غریب روبرو شد. این بار او دکمه Nerd را پیدا کرد تا بتواند لینوکس را مانند یک دستگاه معقول با یک زیر شبکه بسیار عمل کند. ما افزودیم که تنظیم به اسکریپت پیکربندی اولیه Linux و FRR ، امیدواریم که در آینده گزینه پیشرفته دیگری را برآورده نکنیم.


Source link

نوشته های مشابه

دیدگاهتان را بنویسید

دکمه بازگشت به بالا