ਇੱਕ ਚੈਨਲ 'ਤੇ ਸਾਰੇ IPv6 ਨੋਡਾਂ ਨੂੰ ਪਿੰਗ ਕਰੋ

ਦਰ 'ਤੇ ਨਵਾਂ ਪ੍ਰਵਾਹ ਸ਼ੁਰੂ ਹੋਣ ਤੱਕ ਕੁਝ ਦਿਨ ਬਾਕੀ ਹਨ "ਨੈੱਟਵਰਕ ਇੰਜੀਨੀਅਰ" OTUS ਤੋਂ। ਇਸ ਸਬੰਧ ਵਿੱਚ, ਅਸੀਂ ਤੁਹਾਡੇ ਨਾਲ ਵਿਸ਼ੇ 'ਤੇ ਉਪਯੋਗੀ ਸਮੱਗਰੀ ਦਾ ਅਨੁਵਾਦ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

IPv6 ਪਿੰਗ ਮੁੱਦਿਆਂ (ICMPv6 ਈਕੋ ਬੇਨਤੀ/ਈਕੋ ਜਵਾਬ) ਦੇ ਨਿਪਟਾਰੇ ਲਈ ਸੁਝਾਵਾਂ ਅਤੇ ਜੁਗਤਾਂ 'ਤੇ ਬਲੌਗ ਪੋਸਟਾਂ ਦੀ ਇੱਕ ਲੜੀ

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਮੈਂ ਲੀਨਕਸ (ਖਾਸ ਤੌਰ 'ਤੇ ਫੇਡੋਰਾ 31) ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਹਾਂ, ਹਾਲਾਂਕਿ ਹੋਰ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਲਈ ਪਿੰਗ ਕਮਾਂਡ ਸੰਟੈਕਸ ਉਮੀਦ ਹੈ ਕਿ ਬਹੁਤ ਸਮਾਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਚੈਨਲ 'ਤੇ ਸਾਰੇ IPv6 ਨੋਡਾਂ ਨੂੰ ਪਿੰਗ ਕਰੋ

ਪਹਿਲੀ ਅਤੇ ਸਰਲ ਟਿਪ ਲਿੰਕ 'ਤੇ ਸਾਰੇ IPv6 ਨੋਡਾਂ ਨੂੰ ਪਿੰਗ ਕਰਨਾ ਹੈ।

IPv6 ਸਾਰੀਆਂ ਕਿਸਮਾਂ ਦੇ ਇੱਕ ਤੋਂ ਕਈ ਸੰਚਾਰਾਂ ਲਈ ਮਲਟੀਕਾਸਟ ਪਤਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਕੋਈ ਪ੍ਰਸਾਰਣ (ਜਾਂ ਪ੍ਰਸਾਰਣ) IPv6 ਪਤੇ ਨਹੀਂ ਹਨ। ਇਹ IPv6 ਨੂੰ IPv4 ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਪ੍ਰਸਾਰਣ ਪਤੇ ਦੀਆਂ ਕਈ ਕਿਸਮਾਂ ਹਨ, ਉਦਾਹਰਨ ਲਈ, "ਸੀਮਤ ਪ੍ਰਸਾਰਣ" ਪਤਾ 255.255.255.255 [RFC1122]।

ਹਾਲਾਂਕਿ, ਇੱਥੇ ਇੱਕ "ਆਲ-ਨੋਡਸ ਮਲਟੀਕਾਸਟ" IPv6 ਐਡਰੈੱਸ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਲਿੰਕ 'ਤੇ ਸਾਰੇ IPv6 ਨੋਡਾਂ ਨੂੰ ਪਿੰਗ ਕਰਨ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ। (ਇੱਕ "ਪ੍ਰਸਾਰਣ" ਪਤਾ ਅਸਲ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਨਾਮ ਦਿੱਤਾ ਗਿਆ ਮਲਟੀਕਾਸਟ ਐਡਰੈੱਸ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਮਲਟੀਕਾਸਟ ਸਮੂਹ ਹੈ ਜਿਸ ਵਿੱਚ ਸਾਰੇ ਨੋਡ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਧਿਆਨ ਦਿਓ ਕਿ, ਉਦਾਹਰਨ ਲਈ, ਲਿੰਕ ਲੇਅਰ 'ਤੇ ਈਥਰਨੈੱਟ ਪ੍ਰਸਾਰਣ ਪਤਿਆਂ ਵਿੱਚ "ਸਮੂਹ" ਜਾਂ ਮਲਟੀਕਾਸਟ ਐਡਰੈੱਸ ਬਿੱਟ ਚਾਲੂ ਹੈ। ).

ਚੈਨਲ ਲਈ ਆਲ-ਨੋਡ ਮਲਟੀਕਾਸਟ IPv6 ਐਡਰੈੱਸ: ff02::1. ff ਇੱਕ ਮਲਟੀਕਾਸਟ IPv6 ਐਡਰੈੱਸ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਅਗਲਾ 0 ਅਣਸੈੱਟ ਬਿੱਟਾਂ ਦੇ ਨਾਲ ਫਲੈਗ ਦਾ ਹਿੱਸਾ ਹੈ।

ਹੋਰ ਅੱਗੇ 2 ਮਲਟੀਕਾਸਟ ਸਮੂਹ ਦੇ ਖੇਤਰ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਮਲਟੀਕਾਸਟ IPv4 ਪਤਿਆਂ ਦੇ ਉਲਟ, ਮਲਟੀਕਾਸਟ IPv6 ਪਤਿਆਂ ਦਾ ਇੱਕ ਸਕੋਪ ਹੁੰਦਾ ਹੈ। ਸਕੋਪ ਵੈਲਯੂ ਨੈਟਵਰਕ ਦੇ ਉਸ ਹਿੱਸੇ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜਿਸ ਉੱਤੇ ਇੱਕ ਮਲਟੀਕਾਸਟ ਪੈਕੇਟ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਦੀ ਆਗਿਆ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਇੱਕ ਪੈਕੇਟ ਨਿਰਧਾਰਤ ਸਕੋਪ ਦੀ ਸੀਮਾ 'ਤੇ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪੈਕੇਟ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵੇਂ ਇਸਦਾ ਹੌਪ ਕਾਉਂਟ ਖੇਤਰ ਗੈਰ-ਜ਼ੀਰੋ ਹੈ ਜਾਂ ਨਹੀਂ। ਬੇਸ਼ੱਕ, ਜੇਕਰ ਨਿਰਧਾਰਤ ਮਲਟੀਕਾਸਟ ਸਮੂਹ ਸੀਮਾ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੌਪ ਦੀ ਗਿਣਤੀ ਜ਼ੀਰੋ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਤੁਰੰਤ ਰੀਸੈਟ ਵੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਥੇ IPv6 ਮਲਟੀਕਾਸਟ ਸਕੋਪ ਦੀ ਇੱਕ ਪੂਰੀ ਸੂਚੀ ਹੈ।

ਅੰਤ ਵਿੱਚ ::1 ਇੱਕ ਆਲ-ਨੋਡ ਮਲਟੀਕਾਸਟ ਸਮੂਹ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ।

ਪਤੇ ਬਾਰੇ ff02::1 ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਅਸਪਸ਼ਟ ਹੈ. ਇੱਕ IPv6 ਹੋਸਟ ਉੱਤੇ ਮਲਟੀਪਲ ਇੰਟਰਫੇਸ, ਜਿਵੇਂ ਕਿ ਰਾਊਟਰ ਜਾਂ ਮਲਟੀਹੋਮਡ ਹੋਸਟ, ਐਡਰੈੱਸ ff02::1 ਇੱਥੇ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ICMPv6 ਈਕੋ ਬੇਨਤੀਆਂ ਨੂੰ ਭੇਜਣਾ ਹੈ ਜਾਂ ਉਹਨਾਂ ਦੇ ਪਹੁੰਚਣ 'ਤੇ ICMPv6 ਈਕੋ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਉਮੀਦ ਹੈ। ff02::1 ਵੈਧ ਹੈ ਅਤੇ ਮਲਟੀ-ਇੰਟਰਫੇਸ ਨੋਡ ਨਾਲ ਜੁੜੇ ਕਿਸੇ ਵੀ ਇੰਟਰਫੇਸ ਅਤੇ ਚੈਨਲਾਂ 'ਤੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਇਸ ਲਈ ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਲਿੰਕ 'ਤੇ ਸਾਰੇ IPv6 ਨੋਡ ਪਿੰਗ ਕਰਦੇ ਹਾਂ, ਸਾਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਉਪਯੋਗਤਾ ਨੂੰ ਵੀ ਦੱਸਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ping IPv6 ਲਈ, ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਵਰਤਣਾ ਹੈ।

ਇੰਟਰਫੇਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ - ਕਮਾਂਡ ਲਾਈਨ ਵਿਕਲਪ

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਦੇਖਿਆ ਹੈ, ਆਲ-ਨੋਡਜ਼ ਮਲਟੀਕਾਸਟ ਐਡਰੈੱਸ ਜੋ ਅਸੀਂ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹਾਂ − ਹੈ ff02::1 - ICMPv6 ਈਕੋ ਬੇਨਤੀ ਅਤੇ ਈਕੋ ਜਵਾਬ ਪੈਕੇਟ ਭੇਜਣ ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕਿਹੜੇ ਇੰਟਰਫੇਸ ਬਾਰੇ ਕੋਈ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ।

ਤਾਂ, ਅਸੀਂ ਮਲਟੀਕਾਸਟ ਐਡਰੈੱਸ ਸਪੇਸ ਜਾਂ ਯੂਨੀਕਾਸਟ ਲਿੰਕ-ਲੋਕਲ ਐਡਰੈੱਸ ਸਪੇਸ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਨੂੰ ਕਿਵੇਂ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਹਾਂ?

ਪਹਿਲਾ ਅਤੇ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਇਸ ਨੂੰ ਸਾਡੇ ਦੁਆਰਾ ਵਰਤੀ ਜਾ ਰਹੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਇੱਕ ਪੈਰਾਮੀਟਰ ਦੇ ਤੌਰ 'ਤੇ ਪ੍ਰਦਾਨ ਕਰਨਾ ਹੈ।

ਸਹੂਲਤ ਲਈ ping ਅਸੀਂ ਇਸਨੂੰ ਵਿਕਲਪ ਰਾਹੀਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ -I.

[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
 
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$

ਇਸ ਆਲ-ਨੋਡਸ ਮਲਟੀਕਾਸਟ ਪਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਸਾਨੂੰ 6 IPv6 ਨੋਡਾਂ ਤੋਂ ਜਵਾਬ ਮਿਲੇ ਹਨ। ਜਵਾਬ ਲਿੰਕ-ਲੋਕਲ IPv6 ਨੋਡ ਪਤਿਆਂ ਤੋਂ ਆਏ, ਅਗੇਤਰ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹੋਏ fe80::/10.

ਹੈ, ਜੋ ਕਿ ping ICMPv6 ਈਕੋ ਬੇਨਤੀਆਂ ਨੂੰ ਅਣਮਿੱਥੇ ਸਮੇਂ ਲਈ ਭੇਜਣਾ ਜਾਰੀ ਨਹੀਂ ਰੱਖਦਾ ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਇਸਨੂੰ ਰੋਕ ਨਹੀਂ ਦਿੰਦੇ, ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ -c ਵਿਕਲਪ ਦੁਆਰਾ ਭੇਜਣ ਲਈ ਪੈਕੇਟਾਂ ਦੀ ਗਿਣਤੀ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ। ਹਾਲਾਂਕਿ, ਇਹ ਮਲਟੀਕਾਸਟ ICMPv6 ਈਕੋ ਬੇਨਤੀ ਭੇਜਣ ਵੇਲੇ ਪਿੰਗ ਨੂੰ ਇੱਕ ਤੋਂ ਵੱਧ ICMPv6 ਈਕੋ ਜਵਾਬ ਸਵੀਕਾਰ ਕਰਨ ਅਤੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਤੋਂ ਵੀ ਰੋਕਦਾ ਹੈ। ਇਸਦੀ ਬਜਾਏ, ਅਸੀਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ -w ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਕਿ ਪਿੰਗ 1 ਸਕਿੰਟ ਬਾਅਦ ਪੂਰੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਭਾਵੇਂ ਕਿੰਨੀਆਂ ICMPv6 ਈਕੋ ਬੇਨਤੀਆਂ ਜਾਂ ਈਕੋ ਜਵਾਬ ਭੇਜੇ ਜਾਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਹੋਣ।

ਧਿਆਨ ਦੇਣ ਵਾਲੀ ਇਕ ਹੋਰ ਗੱਲ ਹੈ (DUP!) ਦੂਜੇ ਅਤੇ ਬਾਅਦ ਦੇ ਜਵਾਬਾਂ 'ਤੇ ਆਉਟਪੁੱਟ। ਇਹਨਾਂ ਪੈਕੇਟਾਂ ਨੂੰ ਡੁਪਲੀਕੇਟ ਜਵਾਬਾਂ ਵਜੋਂ ਪਛਾਣਿਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਕੋਲ ਵਿਅਕਤੀਗਤ ICMPv6 ਈਕੋ ਬੇਨਤੀਆਂ ਦੇ ਸਮਾਨ ICMP ਕ੍ਰਮ ਮੁੱਲ ਹੈ ਜੋ ਪਹਿਲਾਂ ਭੇਜੀਆਂ ਗਈਆਂ ਸਨ। ਉਹ ਪ੍ਰਗਟ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇੱਕ ICMPv6 ਮਲਟੀਕਾਸਟ ਈਕੋ ਬੇਨਤੀ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਕਈ ਵਿਅਕਤੀਗਤ ਯੂਨੀਕਾਸਟ ਜਵਾਬ ਹੁੰਦੇ ਹਨ। ਡੁਪਲੀਕੇਟ ਦੀ ਗਿਣਤੀ ਅੰਕੜਿਆਂ ਦੇ ਸੰਖੇਪ ਵਿੱਚ ਵੀ ਦਰਸਾਈ ਗਈ ਹੈ।

ਪਰਿਭਾਸ਼ਿਤ ਇੰਟਰਫੇਸ - ਜ਼ੋਨ ਆਈ.ਡੀ

ਵਰਤੋਂ ਲਈ ਇੱਕ ਇੰਟਰਫੇਸ ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰਨ ਦਾ ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਇੱਕ IPv6 ਐਡਰੈੱਸ ਪੈਰਾਮੀਟਰ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਹੈ।

ਅਸੀਂ ਪਿੰਗ ਆਉਟਪੁੱਟ ਵਿੱਚ ਇਸਦਾ ਇੱਕ ਉਦਾਹਰਨ ਦੇਖ ਸਕਦੇ ਹਾਂ, ਜਿੱਥੇ ਜਵਾਬ ਦੇਣ ਵਾਲੇ IPv6 ਹੋਸਟਾਂ ਦੇ ਪਤਿਆਂ ਵਿੱਚ ਵੀ ਪਿਛੇਤਰ ਹੁੰਦਾ ਹੈ %enp3s2, ਉਦਾਹਰਨ ਲਈ:

64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms

ਇੰਟਰਫੇਸ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਇਹ ਵਿਧੀ [RFC4007], "IPv6 ਪਰਿਭਾਸ਼ਿਤ ਐਡਰੈੱਸ ਆਰਕੀਟੈਕਚਰ" ਵਿੱਚ ਰਸਮੀ ਤੌਰ 'ਤੇ ਵਰਣਨ ਕੀਤੀ ਗਈ ਹੈ। ਹਾਲਾਂਕਿ ਉਹਨਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਇੰਟਰਫੇਸ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਉਹ ਅਸਲ ਵਿੱਚ ਕੁਝ ਹੋਰ ਆਮ-ਇੱਕ "ਜ਼ੋਨ" ਜਾਂ "ਸਕੋਪ" ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ।

ਵਧੇਰੇ ਆਮ ਜ਼ੋਨ ਜਾਂ ਸਕੋਪ ਜ਼ੋਨ ਹੋਣ ਦਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ, ਜਿਵੇਂ ਕਿ [RFC4007] ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇੱਕ IPv6 ਨੋਡ ਵਿੱਚ ਇੱਕੋ ਚੈਨਲ ਨਾਲ ਜੁੜੇ ਕਈ ਵੱਖ-ਵੱਖ IPv6 ਇੰਟਰਫੇਸ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ ਇੰਟਰਫੇਸ ਇੱਕੋ ਜ਼ੋਨ ਦੇ ਮੈਂਬਰ ਹਨ।

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਅਧੀਨ ਇੱਕ ਜ਼ੋਨ ਦੇ ਅੰਦਰ ਮਲਟੀਪਲ ਇੰਟਰਫੇਸਾਂ ਦਾ ਸਮੂਹ ਕਰਨਾ ਸੰਭਵ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ; ਵਰਤਮਾਨ ਵਿੱਚ ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਹ ਲੀਨਕਸ ਦੇ ਅਧੀਨ ਸੰਭਵ ਹੈ ਜਾਂ ਇਸਨੂੰ ਕਿਵੇਂ ਕਰਨਾ ਹੈ।

ਪਿਛੇਤਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ %<zone_id>, ਅਸੀਂ ਕਮਾਂਡ ਲਾਈਨ ਵਿਕਲਪ ਨੂੰ ਹਟਾ ਸਕਦੇ ਹਾਂ -I ping.

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
 
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
 
[mark@opy ~]$

ਲਿੰਕ-ਸਥਾਨਕ ਪਤਾ ਜਵਾਬ

ਇਸ ਆਲ-ਨੋਡਸ ਮਲਟੀਕਾਸਟ ਪਿੰਗ ਤੋਂ ਸਾਨੂੰ ਕੁੱਲ 6 ਵਿਲੱਖਣ ਜਵਾਬ ਮਿਲੇ ਹਨ।

ਇਹ ਜਵਾਬ ਯੂਨੀਕਾਸਟ ਲਿੰਕ-ਲੋਕਲ IPv6 ਹੋਸਟ ਪਤਿਆਂ ਤੋਂ ਆਏ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ ਪਹਿਲਾ ਜਵਾਬ ਹੈ:

64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms

ਯੂਨੀਕਾਸਟ ਲਿੰਕ-ਸਥਾਨਕ IPv6 ਪਤੇ ਸਾਰੇ IPv6-ਸਮਰੱਥ ਇੰਟਰਫੇਸਾਂ [RFC4291], “IP ਸੰਸਕਰਣ 6 ਐਡਰੈਸਿੰਗ ਆਰਕੀਟੈਕਚਰ” ਉੱਤੇ ਲੋੜੀਂਦੇ ਹਨ। ਇਸਦਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਇੱਕ IPv6 ਨੋਡ ਵਿੱਚ ਹਮੇਸ਼ਾਂ ਆਪਣੇ ਆਪ ਹੀ ਇੱਕ ਯੂਨੀਕਾਸਟ IPv6 ਪਤਾ ਹੁੰਦਾ ਹੈ, ਜਿਸਦੀ ਵਰਤੋਂ ਇਹ ਆਪਣੇ ਸਿੱਧੇ ਜੁੜੇ ਲਿੰਕਾਂ ਤੇ ਦੂਜੇ ਨੋਡਾਂ ਨਾਲ ਸੰਚਾਰ ਕਰਨ ਲਈ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਲਿੰਕ-ਸਥਾਨਕ ਹੋਸਟ ਪਤਿਆਂ ਰਾਹੀਂ ਦੂਜੇ ਮੇਜ਼ਬਾਨਾਂ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨਾਲ ਸੰਚਾਰ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ।

ਇਹ ਪ੍ਰੋਟੋਕੋਲ ਜਿਵੇਂ ਕਿ IPv6 ਨੇਬਰ ਡਿਸਕਵਰੀ ਅਤੇ OSPFv3 ਦੇ ਡਿਜ਼ਾਈਨ ਅਤੇ ਲਾਗੂਕਰਨ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਮੇਜ਼ਬਾਨਾਂ 'ਤੇ ਅੰਤ-ਉਪਭੋਗਤਾ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਚੈਨਲ 'ਤੇ ਕਿਸੇ ਹੋਰ ਸਹਿਯੋਗੀ IPv6 ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ ਚੈਨਲ 'ਤੇ ਸੰਚਾਰ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਕਨੈਕਟ ਕੀਤੇ IPv6 ਹੋਸਟਾਂ ਵਿਚਕਾਰ ਸਿੱਧੇ ਸੰਚਾਰ ਲਈ ਕਨੈਕਸ਼ਨ 'ਤੇ IPv6 ਰਾਊਟਰ ਜਾਂ DHCPv6 ਸਰਵਰ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ।

ਲਿੰਕ-ਸਥਾਨਕ ਪਤੇ 10-ਬਿੱਟ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ fe80, ਉਸ ਤੋਂ ਬਾਅਦ 54 ਜ਼ੀਰੋ ਬਿੱਟ ਅਤੇ ਫਿਰ ਇੱਕ 64-ਬਿੱਟ ਇੰਟਰਫੇਸ ਪਛਾਣਕਰਤਾ (IID)। ਉਪਰੋਕਤ ਪਹਿਲੇ ਜਵਾਬ ਵਿੱਚ 2392:6213:a15b:66ff ਇੱਕ 64-ਬਿੱਟ IID ਹੈ।

ਲੂਪਡ ਮਲਟੀਕਾਸਟ

ਮੂਲ ਰੂਪ ਵਿੱਚ, ਮਲਟੀਕਾਸਟ ਪੈਕੇਟ ਨੋਡ ਵਿੱਚ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਵਾਪਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਿਸਨੇ ਉਹਨਾਂ ਨੂੰ ਭੇਜਿਆ ਸੀ। ਇਹ IPv6 ਅਤੇ IPv4 ਐਡਰੈਸਿੰਗ ਦੋਵਾਂ ਲਈ ਹੁੰਦਾ ਹੈ।

ਇਸ ਡਿਫੌਲਟ ਵਿਵਹਾਰ ਦਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਮਲਟੀਕਾਸਟ ਪੈਕੇਟ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਸੁਣਨ ਵਾਲੀ ਲੋਕਲ ਮਲਟੀਕਾਸਟ ਐਪਲੀਕੇਸ਼ਨ ਵੀ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਭੇਜਣ ਵਾਲੇ ਹੋਸਟ 'ਤੇ ਚੱਲ ਰਹੀ ਹੈ, ਨਾਲ ਹੀ ਨੈੱਟਵਰਕ 'ਤੇ ਕਿਤੇ ਵੀ। ਇਸ ਸਥਾਨਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਮਲਟੀਕਾਸਟ ਪੈਕੇਟ ਵੀ ਮਿਲਣੇ ਚਾਹੀਦੇ ਹਨ।

ਅਸੀਂ ਆਪਣੇ ਪਿੰਗ ਆਉਟਪੁੱਟ ਵਿੱਚ ਇਸ ਮਲਟੀਕਾਸਟ ਲੋਕਲ ਲੂਪ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਾਂ:

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...

ਪਹਿਲਾ ਅਤੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਜਵਾਬ (0,106 ms ਦੇ ਮੁਕਾਬਲੇ 0,453 ms) ਇੰਟਰਫੇਸ 'ਤੇ ਹੀ ਕੌਂਫਿਗਰ ਕੀਤੇ ਲਿੰਕ-ਲੋਕਲ ਐਡਰੈੱਸ ਤੋਂ ਆਉਂਦਾ ਹੈ। enp3s2.

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

ਉਪਯੋਗਤਾ ping ਪੈਰਾਮੀਟਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਥਾਨਕ ਮਲਟੀਕਾਸਟ ਫੀਡਬੈਕ ਨੂੰ ਦਬਾਉਣ ਦਾ ਤਰੀਕਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ -L. ਜੇਕਰ ਅਸੀਂ ਇਸ ਫਲੈਗ ਨਾਲ ਇੱਕ ਆਲ-ਨੋਡ ਮਲਟੀਕਾਸਟ ਪਿੰਗ ਭੇਜਦੇ ਹਾਂ, ਤਾਂ ਜਵਾਬ ਰਿਮੋਟ ਨੋਡਾਂ ਤੱਕ ਸੀਮਿਤ ਹੁੰਦੇ ਹਨ। ਸਾਨੂੰ ਭੇਜਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਦੇ ਲਿੰਕ-ਸਥਾਨਕ ਪਤੇ ਤੋਂ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਮਿਲਦਾ।

[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
 
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...

ਪਿੰਗ ਲਿੰਕ-ਸਥਾਨਕ ਪਤੇ

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ, ਯੂਨੀਕਾਸਟ ਲਿੰਕ-ਸਥਾਨਕ ਪਤੇ ਆਪਣੇ ਆਪ ਵੀ ਇਹ ਦਰਸਾਉਣ ਲਈ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੇ ਹਨ ਕਿ ਉਹਨਾਂ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਵਰਤਣਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਆਲ-ਨੋਡ ਮਲਟੀਕਾਸਟ ਪਿੰਗ ਦੇ ਨਾਲ, ਸਾਨੂੰ ਕਮਾਂਡ ਲਾਈਨ ਪੈਰਾਮੀਟਰ ਦੇ ਤੌਰ 'ਤੇ ਇੰਟਰਫੇਸ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਨ ਦੀ ਵੀ ਲੋੜ ਹੈ। ping ਜਾਂ ਲਿੰਕ-ਸਥਾਨਕ ਪਤਿਆਂ ਨੂੰ ਪਿੰਗ ਕਰਦੇ ਸਮੇਂ ਪਤੇ ਦੇ ਨਾਲ ਜ਼ੋਨ ਆਈ.ਡੀ.

ਇਸ ਵਾਰ ਅਸੀਂ ਵਰਤ ਸਕਦੇ ਹਾਂ -cਭੇਜੇ ਅਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਪੈਕੇਟਾਂ ਅਤੇ ਜਵਾਬਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਤ ਕਰਨ ਲਈ ping, ਕਿਉਂਕਿ ਅਸੀਂ ਯੂਨੀਕਾਸਟ ਪਿੰਗ ਕਰ ਰਹੇ ਹਾਂ।

[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
 
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
 
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$

ਪਿੰਗ (ਸਾਰੇ) ਹੋਰ IPv6 ਪਤੇ?

ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ ਦੇਖਿਆ ਹੈ ਕਿ ਇੱਕ ਆਲ-ਨੋਡ ਮਲਟੀਕਾਸਟ IPv6 ਐਡਰੈੱਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਚੈਨਲ 'ਤੇ ਸਾਰੇ IPv6 ਨੋਡਾਂ ਨੂੰ ਕਿਵੇਂ ਪਿੰਗ ਕਰਨਾ ਹੈ। ff02::1. ਅਸੀਂ ਇਹ ਵੀ ਦੇਖਿਆ ਕਿ ਆਲ-ਨੋਡਸ ਮਲਟੀਕਾਸਟ IPv6 ਐਡਰੈੱਸ ਨਾਲ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਵਰਤਣਾ ਹੈ, ਕਿਉਂਕਿ ਪਤਾ ਖੁਦ ਇਹ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਜਾਂ ਤਾਂ ਕਮਾਂਡ ਲਾਈਨ ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ ping, ਜਾਂ ਪਿਛੇਤਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੰਟਰਫੇਸ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ %<zone_id>.

ਫਿਰ ਅਸੀਂ ਯੂਨੀਕਾਸਟ ਲਿੰਕ-ਲੋਕਲ ਐਡਰੈੱਸ ਬਾਰੇ ਸਿੱਖਿਆ, ਜੋ ਕਿ ਆਲ-ਨੋਡ ਮਲਟੀਕਾਸਟ ICMPv6 ਈਕੋ ਬੇਨਤੀਆਂ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਪਤੇ ਹਨ।

ਅਸੀਂ ਇਹ ਵੀ ਦੇਖਿਆ ਕਿ ਕਿਵੇਂ ਮਲਟੀਕਾਸਟ ਪੈਕੇਟ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਭੇਜਣ ਵਾਲੇ ਨੋਡ ਵਿੱਚ ਵਾਪਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਪਯੋਗਤਾ ਲਈ ਇਸਨੂੰ ਕਿਵੇਂ ਅਸਮਰੱਥ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ping.

ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਪਿਛੇਤਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸਿੰਗਲ ਲਿੰਕ-ਲੋਕਲ ਐਡਰੈੱਸ ਨੂੰ ਪਿੰਗ ਕੀਤਾ %<zone_id>, ਕਿਉਂਕਿ ਲਿੰਕ-ਲੋਕਲ ਐਡਰੈੱਸ ਖੁਦ ਵੀ ਆਊਟਗੋਇੰਗ ਇੰਟਰਫੇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੇ ਹਨ।

ਇਸ ਲਈ ਹੋਰ ਸਾਰੇ ਨੋਡਾਂ ਨੂੰ ਪਿੰਗ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਗਲੋਬਲ ਯੂਨੀਕਾਸਟ ਐਡਰੈੱਸ (GUAs) (ਭਾਵ, ਇੰਟਰਨੈੱਟ 'ਤੇ ਉਹਨਾਂ ਦੇ ਜਨਤਕ ਪਤੇ) ਜਾਂ ਉਹਨਾਂ ਦੇ ਵਿਲੱਖਣ ਸਥਾਨਕ ਯੂਨੀਕਾਸਟ ਪਤੇ (ULAs) ਬਾਰੇ ਕੀ? ਅਸੀਂ ਇਸਨੂੰ ਅਗਲੀ ਬਲੌਗ ਪੋਸਟ ਵਿੱਚ ਦੇਖਾਂਗੇ।

ਇਹ ਸਭ ਹੈ.

ਤੁਸੀਂ ਸਾਡੇ ਕੋਰਸ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਇੱਥੇ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਖੁੱਲੇ ਦਿਨ ਦੇ ਨੋਟ.

ਸਰੋਤ: www.habr.com