రేటు వద్ద కొత్త ప్రవాహం ప్రారంభానికి కొన్ని రోజులు మిగిలి ఉన్నాయి OTUS నుండి. ఈ విషయంలో, మేము ఈ అంశంపై ఉపయోగకరమైన అంశాల అనువాదాన్ని మీతో పంచుకోవాలనుకుంటున్నాము.
IPv6 పింగ్ సమస్యల పరిష్కారానికి చిట్కాలు మరియు ఉపాయాలపై బ్లాగ్ పోస్ట్‌ల శ్రేణి (ICMPv6 ఎకో రిక్వెస్ట్/ఎకో ప్రత్యుత్తరం)
నేను Linux (ప్రత్యేకంగా Fedora 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 ఎకో ప్రత్యుత్తరాలను ఆమోదించకుండా మరియు ప్రదర్శించకుండా పింగ్‌ను నిరోధిస్తుంది. బదులుగా, ఎన్ని ICMPv1 ఎకో అభ్యర్థనలు లేదా ఎకో ప్రత్యుత్తరాలు పంపబడినా లేదా స్వీకరించబడినా పింగ్ 6 సెకను తర్వాత పూర్తి చేయాలని పేర్కొనడానికి మేము -w ఎంపికను ఉపయోగించాము.
శ్రద్ధ వహించాల్సిన మరో విషయం ఏమిటంటే (DUP!) రెండవ మరియు తదుపరి సమాధానాలపై అవుట్‌పుట్. ఈ ప్యాకెట్లు మొదటి స్థానంలో పంపబడిన వ్యక్తిగత ICMPv6 ఎకో అభ్యర్థనలకు సమానమైన ICMP శ్రేణి విలువను కలిగి ఉన్నందున అవి నకిలీ ప్రతిస్పందనలుగా గుర్తించబడ్డాయి. ICMPv6 మల్టీక్యాస్ట్ ఎకో అభ్యర్థన బహుళ వ్యక్తిగత యూనికాస్ట్ ప్రతిస్పందనలకు దారితీసినందున అవి కనిపిస్తాయి. గణాంకాల సారాంశంలో నకిలీల సంఖ్య కూడా సూచించబడింది.
ఇంటర్‌ఫేస్‌లను నిర్వచించడం - జోన్ ID
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 ఇంటర్‌ఫేస్‌లను కలిగి ఉంటుంది. ఈ ఇంటర్‌ఫేస్‌లు ఒకే జోన్‌లో సభ్యులు.
ఆపరేటింగ్ సిస్టమ్ కింద ఒక జోన్‌లో బహుళ ఇంటర్‌ఫేస్‌లను సమూహపరచడం సాధ్యమవుతుంది; ప్రస్తుతం ఇది Linuxలో సాధ్యమవుతుందా లేదా ఎలా చేయాలో నాకు తెలియదు.
ప్రత్యయం ఉపయోగించి %<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 లేదా లింక్-స్థానిక చిరునామాలను పింగ్ చేస్తున్నప్పుడు చిరునామాతో జోన్ ID.
ఈసారి మనం ఉపయోగించుకోవచ్చు -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>, లింక్-లోకల్ చిరునామాలు కూడా అవుట్‌గోయింగ్ ఇంటర్ఫేస్ గురించి సమాచారాన్ని అందించవు కాబట్టి.
కాబట్టి అన్ని ఇతర నోడ్‌లను పింగ్ చేసి, వాటి గ్లోబల్ యూనికాస్ట్ అడ్రస్‌లు (GUAలు) (అంటే ఇంటర్నెట్‌లో వారి పబ్లిక్ అడ్రస్‌లు) లేదా వాటి ప్రత్యేకమైన స్థానిక యూనికాస్ట్ చిరునామాలు (ULAలు) పొందడం గురించి ఏమిటి? మేము దీనిని తదుపరి బ్లాగ్ పోస్ట్‌లో చూద్దాం.
అంతే.
మీరు మా కోర్సు గురించి మరింత తెలుసుకోవచ్చు.
మూలం: www.habr.com