Problém s MTU?

[Petr S.]

Řeším problém, kdy se nedostanu po síti kdekoliv - nejde ani ping ani nic. Je to všechno v jedné mgmt vlan, ale ping funguje vždy jen v části. V části na obrázku jde například ping od 100.64.8.1 až po 100.64.11.254, ale dále ne. Když se poté přihlásím ssh na 100.84.11.240 (tedy na to první SXT), tak můžu pingat na další část sítě, kterou na obrázku nemám, ale je konfigurována obdobně, nicméně už mi nejdou pingy do té první části sítě - tedy IP 100.64.8.1 a 100.64.11.254. Problém jsem obešel tím, že jsem vždy na první z těch zařízení, kam se nedostanu udělal EoIP tunel a takhle mi to funguje, ale nevím, jestli je to úplně košér řešení. Tušíte, kde je problém? Já už přestávám chápat. Jediné, co mě napadá, je že by to mohlo způsobovat MTU, ale ať si s ním hraju, jak chci, nerozjel jsem to doteď.

Díky za jakékoliv nakopnutí ,
Petr S.

[Petr S.]

Žádný nápad?

[Dalibor Toman]

z obrazku moc moudry nejsem. Sit je routovana nebo bridgeovana? Mate me tam ta /19 sit.

1) MTU tezko bude mit vliv na ping, ktery je kratky packet (= mensi nez MTU)
2)pokud je switch bridgeovana - jak je nastavene to zarizeni KLIENT? pokud nema na wirelessu 'station-bridge; ale jen station tak se z nej nedostanes (neni-0li transparentnost bridge resena nejakym tim tunelem)

[Petr S.]

Sit je routovana. Na hlavnim routeru je jeden nat a ostatni uz se routuje. Ta /19 sit je pro management, ten je postaveny na vlane 108. Každé AP má přiřazeno jedno číslo, třeba 11. A když je klient připojený k tomu AP, tak má adresu na wlan 100.84.11.240/24 třeba. Pro koncová zařízení za klientem je pak udělaná ta síť 10.11.240.0/24, ta je na eth. Problém ale vyvstane, když za klienta hodím další RB, který má na eth třeba 10.11.240.200 a managementí adresu 100.64.12.10/19. Ta 12 v adrese značí, že za ní bude další malé AP. Poté ping na 10.11.240.200 z hlavního routeru běhá, ale na 100.64.12.10 už ne.

[Dalibor Toman]

Sit je routovana. Na hlavnim routeru je jeden nat a ostatni uz se routuje.

ale problem resis v te VLANe, ktera musi byt bridgeovana.

1) od kud se pinga? z Hlavni GW?
2) pokud nejde pingat za AP1, tak bych na SXT sniferem zkontroloval, zda ICMP request packety prichazeji (pokud ne tak na AP1 zda odchazeji). Zaroven uvidis zda odchazeji zpet odpovedi a pak muzes jit interface po interafce az kde se ztrati. Taky pri tom uvidis, zda nahodou nechodi ICMP request packety s nejakou necekanou SRC IP

Ta /19 sit je pro management,ten je postaveny na vlane 108.

a to je k cemu dobre? To ten routing je tak nestabilni, ze je treba mit na zarizeni jinou cestu? Je to routovany rucne (zadne OSPF?). Dal bych si na loopback kazdeho MT 'routerID' /32 IPcka v rade za sebou aby v tom byl nejaky system a na tu vlan se vykaslal. Samozrejme pokud se rozpadne routing pak musis vedet jake IP je na interfacu a dostat se tam tudy.

[Petr S.]

Sit je routovana. Na hlavnim routeru je jeden nat a ostatni uz se routuje.

ale problem resis v te VLANe, ktera musi byt bridgeovana.

1) od kud se pinga? z Hlavni GW?
2) pokud nejde pingat za AP1, tak bych na SXT sniferem zkontroloval, zda ICMP request packety prichazeji (pokud ne tak na AP1 zda odchazeji). Zaroven uvidis zda odchazeji zpet odpovedi a pak muzes jit interface po interafce az kde se ztrati. Taky pri tom uvidis, zda nahodou nechodi ICMP request packety s nejakou necekanou SRC IP

Ta /19 sit je pro management,ten je postaveny na vlane 108.

a to je k cemu dobre? To ten routing je tak nestabilni, ze je treba mit na zarizeni jinou cestu? Je to routovany rucne (zadne OSPF?). Dal bych si na loopback kazdeho MT 'routerID' /32 IPcka v rade za sebou aby v tom byl nejaky system a na tu vlan se vykaslal. Samozrejme pokud se rozpadne routing pak musis vedet jake IP je na interfacu a dostat se tam tudy.

Jj, tak to jo, vlana je bridgovana. Než jsi odepsal, stihnul jsem do příspěvku výše hodit další info. Za AP1 pingat jde. Tu vlan jsem si tam udělal kvůli tomu, že mi to přišlo jako dobrej nápad, abych měl na zařízení možnost dostat se tam jinudy kdyby se cokoliv stalo. OSPF jsem tam zatím nedonastavil, takže než si na to udělám čas, tak je to routovaný ručně. Myslíš, že vlany můžou být problém nebo proč bys je nedoporučoval?

Jak myslíš to s tím loopbackem?

[Dalibor Toman]

Jj, tak to jo, vlana je bridgovana. Než jsi odepsal, stihnul jsem do příspěvku výše hodit další info. Za AP1 pingat jde. Tu vlan jsem si tam udělal kvůli tomu, že mi to přišlo jako dobrej nápad, abych měl na zařízení možnost dostat se tam jinudy kdyby se cokoliv stalo. OSPF jsem tam zatím nedonastavil, takže než si na to udělám čas, tak je to routovaný ručně. Myslíš, že vlany můžou být problém nebo proč bys je nedoporučoval?

Jak myslíš to s tím loopbackem?

Ta Vlana mi prijde jako dalsi komplikace navic. Navic na MT jsou ty VLANky implementovany (alespon co se nastaveni tyce) IMHO dost debilne, takze k VLAN na MT mam dost velkou averzi.

Loopback se pouziva prave treba u OSPF k definovani jednoznacneho IPcka pro router. U MT to obnasi vytvorit bridge (bez interfacu) a pridelit mu IPcko (muze byt /32) a pak v nastaveni OSPF reknes ze router-ID je to IP (takze OSPF si ho nevybira automaticky z IPcek v routeru a nehrozi, ze po zmene CFG a restartu OSPF dojde k jeho zmene).

Každé AP má přiřazeno jedno číslo, třeba 11. A když je klient připojený k tomu AP, tak má adresu na wlan 100.84.11.240/24 třeba. Pro koncová zařízení za klientem je pak udělaná ta síť 10.11.240.0/24, ta je na eth. Problém ale vyvstane, když za klienta hodím další RB, který má na eth třeba 10.11.240.200 a managementí adresu 100.64.12.10/19. Ta 12 v adrese značí, že za ní bude další malé AP. Poté ping na 10.11.240.200 z hlavního routeru běhá, ale na 100.64.12.10 už ne.

mam vzdycky problem 'vzit se' do obrazku cizi site ale IMHO plati stale to stejne. Sniferem bych zjistil kam se ICMP requesty dostanou, pokud dorazi kam maji tak zda je nekde videt ICMP echo response a kam se dostane. Pak na prislenem zarizeni kouknout do routovaci tabulky/firewallu atd.

Jo a v posledni dobe jsem videl parkrat problem s ARP resolvenim (nekatualizovala se MAC v ARP tabulce)- takze bych na tom zarizeni z ktereho se pinga kouknul, zda je v ARP tabulce zaznam pri cilove IP a zda je MAC stejna (pripadne smaznou a po pingu se podivat jestli se nezmenila) to same v ARP udelat i na cilovem stroji pro IPcko gatewaye (IP z ktereho chodi ty ICMP hello requesty). Zaroven uvidis jestli ARP mezi temi boardy funguje.

[Majklik]

Jeví se mi pomotané, že management používá 100.64/10 a klienti 10/8. Mělo by to být spíše naopak.
Co řešíš, jsem už potkal. Jen si nepamatuji, jak to pak dopadlo, protože zařízení umřelo dříve a nahradilo se něčím jiným, co už bylo plně L2 transparent a problém zmizel se vyřešil sám.
Pokud routuješ mezi wlan a eth stranou provoz klienta, tak jak bridguješ tu VLANu? To máš přihozenu VLAN 108 nad wlan1 a současně i nad eth1 a pak tyto dvě vlany v bridge?
Tohle nemá s MTU nic společného. Problém je v tom, že ta klientská jednotka nerozdýchá tu VLANu nad tím wlan portem v závislosti na svém nastavneí.

[Petr S.]

Jeví se mi pomotané, že management používá 100.64/10 a klienti 10/8. Mělo by to být spíše naopak.
Co řešíš, jsem už potkal. Jen si nepamatuji, jak to pak dopadlo, protože zařízení umřelo dříve a nahradilo se něčím jiným, co už bylo plně L2 transparent a problém zmizel se vyřešil sám.
Pokud routuješ mezi wlan a eth stranou provoz klienta, tak jak bridguješ tu VLANu? To máš přihozenu VLAN 108 nad wlan1 a současně i nad eth1 a pak tyto dvě vlany v bridge?
Tohle nemá s MTU nic společného. Problém je v tom, že ta klientská jednotka nerozdýchá tu VLANu nad tím wlan portem v závislosti na svém nastavneí.

Na každém zařízení jsou vytvořeny vlaní interface - jak pro eth, tak i wlan - a ty jsou pak prihozeny do jednoho bridge, presne jak pises. Kde myslis ze je tedy problem? To jsem si původně myslel taky, že to bude tak, ale kdyby to bylo tím, že to nerozdýchá vlan nad wlan portem, tak by nesel ani pristup na tu jednotku pres vlan108, ne? ale ten normalne funguje...

[Majklik]

On rozdýchá tu VLAN na WLAN a přístup přes ní funguje, protože na tento přstup se ještě neuplatní bridging a ukončiuje se v podstatě "routovaně" v tom RB. Až na paket, co se má poslat dál, se ten bridging má uplatnit, a to se nestane. A ješto to, myslím, blblo jen jedním směrem, takže pakety jedním směrem přes klienta při takové CFG prošly (wlan->eth) a druhým směrem už ne (eth->wlan).
Jo, také bych zkusil, co se stane, když ručně nastavíč admin MAC na tom bridge, zvláště na něco úplně jiného, než je MAC wlan a eth portu.
Zkusil bych si pohrát s tím, v jakém režimu máš toho wlan klienta, jak blyozmíněno už Daliborem (station-bridge/tation), ale nejsme si jist, zda to tka de oživit.

[Petr S.]

Tak jo, chyba byla v nastaveném režimu station, namísto station-bridge, ale po přenastavení se to začalo chovat tak, že některé pakety procházejí a některé ne - ping střídavě jde a nejde. To by mohl ev. dělat překlad ARP? V Bridge - Hosts je tabulka přiřazení různých IP na různé interface, jedna mac by měla být jen na jednom rozhraní, že? A poznám někde přiřazení konkrétní MAC k určité IP?

Díky.