AbcLinuxu hledá autory!

Inzerujte na AbcPráce.cz od 950 Kč

Rozšířené hledání

napište » Zprávičky

inzerujte » Pracovní nabídky

EVPN - jak bránit únosu MAC adresy

včera 23:33 | Zajímavý článek

Při běžné migraci virtuálního stroje mezi hypervizory se jeho MAC adresa přesune na jiný leaf switch. EVPN tuto změnu distribuuje pomocí BGP Type-2 route a MAC mobility sequence number. Problém nastává, pokud útočník podvrhne zdrojovou MAC adresu jiného zařízení. Leaf může změnu interpretovat jako legitimní přesun MAC a rozšířit ji přes BGP do celé fabric. Výsledkem může být přesměrování provozu určeného původnímu zařízení. Autor článku rozebírá možnosti detekce pomocí sledování MAC moves, BGP route reflektorů a kontroly na přístupové vrstvě.

vencour | Komentářů: 0

Enlightenment 0.28.0 a Enlightenment Foundation Libraries (EFL) 1.29

včera 15:11 | Nová verze

Vývojáři desktopového prostředí Enlightenment (Wikipedie) a souvisejících knihoven Enlightenment Foundation Libraries (EFL) vydali nové verze. Enlightenment byl vydán ve verzi 0.28.0 a Enlightenment Foundation Libraries ve verzi 1.29.

Ladislav Hagara | Komentářů: 3

Některé odpovědi modelu GLM-5.3 obsahovaly části dat z předchozích požadavků jiných zákazníků

včera 13:55 | Zajímavý článek

Cloudflare zjistil, že některé odpovědi modelu GLM-5.3 obsahovaly části dat z předchozích požadavků jiných zákazníků. Příčinou byla kombinace chybné konfigurace a chyby v inference enginu SGLang. Model podporoval kontextové okno 1 048 576 tokenů, ale GPU KV cache pool měl kapacitu pouze 681 280 tokenů. Při překročení kapacity docházelo k nesprávnému zpracování odmítnutého požadavku. Decode část systému následně pracovala se starými

… více »

vencour | Komentářů: 0

Novinky v Knot Resolver 6

včera 13:00 | Zajímavý článek

Vývojáři Knot Resolver vysvětlují, jak změnili rozhodování o tom, které DNS záznamy ponechat v cache a které odstranit. Článek obsahuje skutečná měření: devět hodin DNS provozu při 2 000 QPS, srovnání cache o velikosti 25 MB a 40 GB a také porovnání s BIND 9, kromě algoritmů obsahuje konkrétní doporučení pro konfiguraci a diagnostiku.

vencour | Komentářů: 0

Hackeři zaútočili na Binance, největší kryptoměnovou burzu světa

30.10. 13:44 | IT novinky

Největší kryptoměnová burza světa Binance se stala terčem útoku, při kterém podvodníci odcizili během několika minut kryptoměny v hodnotě přibližně 6,3 miliardy dolarů. Jedná se o největší kryptoměnovou krádež v historii, přibližně čtyřikrát větší než loňský útok na burzu Bybit. Binance se podařilo ve spolupráci s partnery zmrazit aspoň aktiva v hodnotě zhruba 3 miliard dolarů a slíbila, že veškeré ztráty pokryje z vlastních prostředků.

Ladislav Hagara | Komentářů: 16

Kritická zranitelnost v Linux kernelu s CVSS 9.8

30.10. 02:16 | Bezpečnostní upozornění

Zranitelnost CVE-2026-98432 s CVSS 9.8 odhalila AI od společnosti Anthropic. Jedná se o kritickou chybu v implementaci MPTCP (multipath TCP). Debian vydal patche 16.10. a 22.10., ale např. Ubuntu je zatím bez opravy. Více informací na The Hacker News.

Max | Komentářů: 20

Greenie Rally - nová slovenská bezplatná hra

29.10. 23:22 | Zajímavý software

Na Slovensku vznikla úplne nová rally hra, ktorá je zadarmo a funguje vo Windowse, Linuxe či na Macu. Greenie Rally má viac ako 50 tratí a vozidiel, šampionáty či turnaje. Má retro feeling a imituje automobilové hry z prelomu tisícročí. Vyskúšate prejsť všetky mapy na Škode 130RS?

Stanislav Hoferek | Komentářů: 12

NetBSD má nový editor atto

29.10. 14:33 | Komunita

Do základního systému NetBSD -current byl přidán nový editor atto jako alternativa k editorům vi a xedit.

Ladislav Hagara | Komentářů: 1

System76 Thelio Prime Desktop

29.10. 14:11 | IT novinky

Společnost System76 představila kompaktní 11litrový Thelio Prime Desktop. S procesorem AMD Ryzen 9000. S Pop!_OS 24.04 LTS s desktopovým prostředím COSMIC nebo Ubuntu 24.04 LTS.

Ladislav Hagara | Komentářů: 0

Čína nechala zmizet fotbalistu Mbappého z internetu

29.10. 13:44 | Humor

Čínská státní televize pozastavila vysílání španělské La Ligy a čínské internetové platformy omezily obsah s Kylianem Mbappém poté, co slavný fotbalista ve francouzském pořadu The Bridge mluvil o svém oblíbeném memu, v němž je jeho tvář vložena do portrétu zobrazujícího diktátora Mao Ce-tunga. 'Můj oblíbený mem je ten, na kterém dali můj obličej na čínského diktátora. To mě opravdu rozesmívá. S přáteli ho používám pořád' řekl,

… více »

Pendrekama do nich❗ | Komentářů: 16

Centrum | Napsat | Starší

navrhněte » Anketa

Komentářů: 34, poslední 26.10. 08:24

Rozcestník

AbcLinuxu

AbcLinuxu:/ Poradna / Linuxová poradna / Problém s PINGem vetším než je MTU

Štítky: data, Debian, distribuce, hardware, HP, Intel, packet, ping, problém, procesory, RAM, Xeon, 10GbE

Dotaz: Problém s PINGem vetším než je MTU

29.11.2018 10:04 TessiCZ
Problém s PINGem vetším než je MTU

Přečteno: 593×

Odpovědět | Admin

Zdravím Vás tu všechny, už jsem zoufalý. Mám linuxovou gateway ve které mám Intel X710 DA2 s 2x 10GbE. Řeším problém s pingem. Pokud pošlu paket do velikosti MTU (1500) tak je vše v naprostém pořádku. Pokud ale pošlu paket větší než MTU např 1516 tak mám děsný packet loss.
Zařízení na které je ping posílán je RB CCR 1009, na něj ping přijde i odejde zpět, ale zpět nedorazí. Zařízení jsou do sebe napojena přímo.

Nenapadá někoho kde by mohl být problém?

Děkuji za každou radu.

systém: Debian 4.18.0-2-amd64
HW: HP Proliant DL380gen8, 2x Xeon E5-2620, 16GB ram

X710-DA2:


ethtool -i eth9

driver: i40e

version: 2.7.11

firmware-version: 6.01 0x80003483 1.1747.0

expansion-rom-version:

bus-info: 0000:07:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

PING větší než MTU:


ping 10.20.220.200 -s 1508 -i 0.01 -c 1000

PING 10.20.220.200 (10.20.220.200) 1508(1536) bytes of data.

1516 bytes from 10.20.220.200: icmp_seq=916 ttl=64 time=0.156 ms

1516 bytes from 10.20.220.200: icmp_seq=917 ttl=64 time=0.129 ms

1516 bytes from 10.20.220.200: icmp_seq=918 ttl=64 time=0.149 ms

1516 bytes from 10.20.220.200: icmp_seq=919 ttl=64 time=0.203 ms

1516 bytes from 10.20.220.200: icmp_seq=920 ttl=64 time=0.128 ms

1516 bytes from 10.20.220.200: icmp_seq=921 ttl=64 time=0.144 ms

1516 bytes from 10.20.220.200: icmp_seq=922 ttl=64 time=0.132 ms

1516 bytes from 10.20.220.200: icmp_seq=923 ttl=64 time=0.223 ms

1516 bytes from 10.20.220.200: icmp_seq=924 ttl=64 time=0.137 ms

1516 bytes from 10.20.220.200: icmp_seq=925 ttl=64 time=0.147 ms

1516 bytes from 10.20.220.200: icmp_seq=926 ttl=64 time=0.200 ms

1516 bytes from 10.20.220.200: icmp_seq=927 ttl=64 time=0.149 ms

1516 bytes from 10.20.220.200: icmp_seq=928 ttl=64 time=0.133 ms

1516 bytes from 10.20.220.200: icmp_seq=929 ttl=64 time=0.221 ms

1516 bytes from 10.20.220.200: icmp_seq=930 ttl=64 time=0.171 ms

1516 bytes from 10.20.220.200: icmp_seq=931 ttl=64 time=0.142 ms




--- 10.20.220.200 ping statistics ---

1000 packets transmitted, 16 received, 98.4% packet loss, time 860ms

rtt min/avg/max/mdev = 0.128/0.160/0.223/0.033 ms

PING do velikosti MTU:


ping 10.20.220.200 -s 1472 -i 0.01 -c 1000

PING 10.20.220.200 (10.20.220.200) 1472(1500) bytes of data.

1480 bytes from 10.20.220.200: icmp_seq=1 ttl=64 time=0.238 ms

1480 bytes from 10.20.220.200: icmp_seq=2 ttl=64 time=0.088 ms

1480 bytes from 10.20.220.200: icmp_seq=3 ttl=64 time=0.098 ms

1480 bytes from 10.20.220.200: icmp_seq=4 ttl=64 time=0.139 ms

1480 bytes from 10.20.220.200: icmp_seq=5 ttl=64 time=0.093 ms

1480 bytes from 10.20.220.200: icmp_seq=6 ttl=64 time=0.105 ms

1480 bytes from 10.20.220.200: icmp_seq=7 ttl=64 time=0.118 ms

1480 bytes from 10.20.220.200: icmp_seq=8 ttl=64 time=0.112 ms

1480 bytes from 10.20.220.200: icmp_seq=9 ttl=64 time=0.085 ms

1480 bytes from 10.20.220.200: icmp_seq=10 ttl=64 time=0.091 ms

.

.

.

1480 bytes from 10.20.220.200: icmp_seq=990 ttl=64 time=0.114 ms

1480 bytes from 10.20.220.200: icmp_seq=991 ttl=64 time=0.100 ms

1480 bytes from 10.20.220.200: icmp_seq=992 ttl=64 time=0.105 ms

1480 bytes from 10.20.220.200: icmp_seq=993 ttl=64 time=0.144 ms

1480 bytes from 10.20.220.200: icmp_seq=994 ttl=64 time=0.105 ms

1480 bytes from 10.20.220.200: icmp_seq=995 ttl=64 time=0.098 ms

1480 bytes from 10.20.220.200: icmp_seq=996 ttl=64 time=0.126 ms

1480 bytes from 10.20.220.200: icmp_seq=997 ttl=64 time=0.145 ms

1480 bytes from 10.20.220.200: icmp_seq=998 ttl=64 time=0.105 ms

1480 bytes from 10.20.220.200: icmp_seq=999 ttl=64 time=0.098 ms

1480 bytes from 10.20.220.200: icmp_seq=1000 ttl=64 time=0.093 ms




--- 10.20.220.200 ping statistics ---

1000 packets transmitted, 1000 received, 0% packet loss, time 824ms

rtt min/avg/max/mdev = 0.079/0.116/8.355/0.262 ms

Nástroje: Začni sledovat (0) ?

Odpovědi

29.11.2018 10:33 Peter Golis | skóre: 65 | blog: Bežné záležitosti | Bratislava
Rozbalit Rozbalit vše Re: Problém s PINGem vetším než je MTU

A prečo si nezapnete jumbo frames keď to chcete používať?

29.11.2018 10:46 TessiCZ
Rozbalit Rozbalit vše Re: Problém s PINGem vetším než je MTU

Protože potřebuji aby fungovalo správně fragmentování packetů...

Tohle se děje i na straně do internetu (druhý port v x710) ne jen v lokální síti.

29.11.2018 10:55 Petr Šobáň | skóre: 80 | blog: soban | Olomouc
Rozbalit Rozbalit vše Re: Problém s PINGem vetším než je MTU

Tak potom firewall přes který blokuje správy že se má poslat menší fragment a nebo to protější strana natvrdo ignoruje?

Prostě sledovat co se odesílá a přijímá za pakety jinak to nezjistíš kde se to zadrhne.

29.11.2018 11:11 TessiCZ
Rozbalit Rozbalit vše Re: Problém s PINGem vetším než je MTU

Ani jedna ze stran neblokuje žádné ICMP správy. Vtip je ještě ten, že jsou chvíle kdy to jede bez problému třeba hodinu a to i když pošlu packet o velikosti 30k. Pak najednou z ničeho nic to zas přestane fungovat. A buď z 1000 neprojde ani jeden nebo pár jak jsem psal výše.

29.11.2018 12:27 TessiCZ
Rozbalit Rozbalit vše Re: Problém s PINGem vetším než je MTU

jinak v tcpdump je:

tcpdump -nni eth9 src 10.20.220.200
11:44:22.937158 IP 10.20.220.200 > 10.20.220.193: ICMP echo reply, id 8906, seq 124, length 1480
11:44:22.937168 IP 10.20.220.200 > 10.20.220.193: ip-proto-1

tcpdump -nni eth9 dst 10.20.220.200
11:45:10.836876 IP 10.20.220.193 > 10.20.220.200: ICMP echo request, id 8991, seq 55, length 1480
11:45:10.836883 IP 10.20.220.193 > 10.20.220.200: ip-proto-1

tedy v tcpdump jsou vidět oba směry a podle mě ok, ale ping stále píše packet loss

29.11.2018 17:52 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Problém s PINGem vetším než je MTU

Přidejte přepínač -v a zkontrolujte jestli sedí ID a offsety fragmentů.

A mimochodem v tomto výpisu máte reply a echo od různých požadavků (nesedí ID). To si taky zkontrolujte.

Obvykle když fragmentace přestane na chvíli fungovat, tak je to způsobeno tím, že se k odesílateli nedostávají ICMP packet to big chybové packety a „samo“ se to zpraví, až když dorazí nesouvisející TCP packet ze stejného směru s nastaveným MSS. Linux se z TCP MSS učí PMTU a naučená hodnota nějakou dobu vydrží ve směrovací cachi.

Založit nové vlákno • Nahoru

Tiskni Sdílej: