AbcLinuxu hledá autory!

Inzerujte na AbcPráce.cz od 950 Kč

Rozšířené hledání

napište » Zprávičky

inzerujte » Pracovní nabídky

X.Org X server 21.1.25 a Xwayland 24.1.14 řeší 12 bezpečnostních chyb

včera 23:22 | Bezpečnostní upozornění

Nejnovější X.Org X server 21.1.25 a Xwayland 24.1.14 řeší 12 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 0

Google Chrome 155 s podporou JPEG XL (.jxl)

včera 16:33 | Nová verze

Google Chrome 155 byl prohlášen za stabilní. Přináší podporu JPEG XL (.jxl). Opraveno bylo 247 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 1

Konference OpenAlt 2026 hledá přednášející

včera 16:00 | Komunita

Konference OpenAlt 2026 hledá přednášející. Přihlásit přednášky lze do neděle 11. října. Konference proběhne o víkendu 7. a 8. listopadu na půdě Fakulty informačních technologií VUT v Brně. Témata konference jsou: Otevřený a svobodný software, IoT a Hnutí tvůrců, Vzdělávání, Bezpečnost a soukromí, Otevřená společnost, komunity a data, OpenMobility a další.

Ladislav Hagara | Komentářů: 0

OpenSSH 10.6

včera 13:22 | Nová verze

Byla vydána nová verze 10.6 sady aplikací pro SSH komunikaci OpenSSH. Přináší řadu důležitých bezpečnostních oprav, vylepšení funkcí a oprav chyb. Povoluje hybridní postkvantový podpisový algoritmus ssh-mldsa44-ed25519.

Ladislav Hagara | Komentářů: 0

Open-weight model Beam od Reflection AI

včera 04:00 | Zajímavý software

Americká společnost Reflection AI světu představila Beam, open-weight model s 501 miliardami parametrů (z toho 23 miliard aktivních), určený především pro programování a práci autonomních agentů. Podle autorů jejich model nabízí výkon srovnatelný s většími modely při výrazně nižších nárocích na výpočetní výkon. Beam nyní ještě prochází závěrečným testováním, na stránkách Reflection AI se však lze zaregistrovat a získat předběžný přístup. Váhy modelu, dokumentace a nástroje pro vývojáře mají být zveřejněny v průběhu tohoto měsíce.

AfD 💙 | Komentářů: 0

OpenCourant, komunitní fork OpenRadioss

včera 02:00 | Komunita

OpenCourant je komunitní fork OpenRadioss, tj. open source softwaru pro simulace havárií, nárazů a vysoce nelineárních dynamických dějů metodou konečných prvků. Společnost Siemens v loňském roce dokončila akvizici společnosti Altair Engineering, jež před čtyřmi lety uvolnila open source verzi OpenRadioss svého proprietárního softwaru Radioss. Minulý týden Siemens OpenRadioss pohřbil. Integroval jej do svého softwaru Simcenter, webovou stránku OpenRadioss přesměroval na Simcenter a repozitář OpenRadioss na GitHubu odstranil.

Ladislav Hagara | Komentářů: 0

Organizátoři síťařského setkání CSNOG 2027 vyhlásili Call for Abstracts

včera 00:22 | Pozvánky

Pořadatelé devátého ročníku komunitního setkání správců nejen českých a slovenských sítí – CSNOG 2027, které se uskuteční 20. a 21. ledna, vyhlásili Call for Abstracts. Náměty na vystoupení mohou zájemci přihlašovat do 31. října na webu akce a vybírat mohou ze tří sekcí – správa sítí, legislativa a regulace a akademické projekty. Zveřejněny byly také Call of Partners určené sponzorům a partnerům setkání, kteří by například chtěli mít na

… více »

VSladek | Komentářů: 0

Strata, obří AI v herním PC

6.10. 16:11 | Zajímavý software

Strata je open-source inferenční engine, který umožňuje lokálně provozovat rozsáhlý čínský model Qwen3.8-Flash-Next, který by jinak nejspíše vyžadoval serverovou infrastrukturu, na běžném herním počítači s alespoň 12 GB VRAM, 32 GB RAM a dostatkem místa na SSD. Nároky na paměť a rychlost generování se liší s použitou variantou modelu Qwen. Zdrojový kód je dostupný na GitHubu, pod licencí MIT.

AfD 💙 | Komentářů: 2

Trump tasí superzbraň, federální jednotku pro superinteligenci

6.10. 15:11 | Humor

Americký prezident Donald Trump oznámil vznik federální Jednotky pro superinteligenci (Super Intelligence Force), která má koordinovat postup vlády, technologických firem, náboženských organizací a dalších institucí v oblasti rychle se rozvíjející umělé inteligence (Trumpem oficiálně nazývanou superinteligencí). SIF, podřízená přímo Trumpovi, má pomoci Spojeným státům udržet v oblasti SI technologický náskok nad světem a

… více »

AfD 💙 | Komentářů: 8

Klient, e-mailový klient pro GNOME s nativní podporou Proton Mailu, PGP a spamfiltrem řízeným AI

6.10. 13:11 | Zajímavý software

Klient je e-mailový klient pro GNOME s nativní podporou Proton Mailu, PGP a spamfiltrem řízeným AI. Napsaný je v Go s GTK4 a libadwaita. Připojuje se přímo k Proton Mailu (bez Proton Bridge), ke Gmailu, k Seznam.cz a k libovolné schránce IMAP/SMTP. Každou novou zprávu nejdřív posoudí spamfiltr a teprve potom ji ukáže a ohlásí. Rozhraní je česky a anglicky.

Ladislav Hagara | Komentářů: 5

Centrum | Napsat | Starší

navrhněte » Anketa

Komentářů: 31, poslední 13.8. 00:27

Rozcestník

AbcLinuxu

HDmag.cz

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: 580×

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: