R

rga

Potřeboval jsem si odchytat nějaký problém a narazil jsem na chování, které nechápu:

Mám několik rozhraní ether1-x vložené do rozhraní bridge1,

pokud zapnu packet sniffer nad konkrétním ehterX rozhraním (nebo nechám možnost all) a nechám zachytávat pakety, vidím IP provoz.

Pokud si ale zapnu filtr na ARP, nevidím vůbec nic. Jako by na jednotlivých rozhraních žádný ARP provoz nešel.

ARP provoz vidím jedině, pokud zachytávám přímo rozhraní bridge1.

Zde ale nevidím, který provoz teče na kterém portu.

To je normální chování?

Nerozumím tomu...

Už jsem se chtěl ohradit, že přece nejsem lama... ale jsem... ;-)

NB samozřejmě GW má (jinak by nefungoval ping na 192.168.28.1), ale modem ne.

Modem ji ani mít nemůže, na LAN rozhraní modemu GW nastavit nejde

a na WAN rozhraní ji dostane až po připojení přes PPPoE (pokud je v režimu router).

Jenže já mám modem v režimu bridge.

I když je modem v režimu bridge, má pořád dostupnou záložku static route.

Bohužel, i když jsem tam přidal:

Destination: 172.18.0.0

Mask: 255.255.192.0

Gateway: 192.168.28.1

tak to pořád nejede...

No, očividně bude problém v konfiguraci toho ADSL modemu,

protože když jsem si místo něj hodil jiný RB, selo to na první pokus... :-(

Má někdo zkušenost s touto konfigurací?

V mém případě jde konkrétně o ZyXEL P-660H-T3.

Je možné ho mít takhle připojený pro účely managementu i když je v bridge módu?

Co mě ale zaráží je Torch. Jak to teda funguje?

Jak je možné, že když modem nevěděl kudy routovat zpět ICMP echo reply,

tak na RB v Torchu byly vidět příchozí pakety (viz výstup výše)???

Připadám si jako lama lamatá... :-(

Mám tu jeden RB, k němu na ehther1 připojený ADSL modem ZyXEL nakonfigurovaný na bridging.

Na LAN rozhraní toho ADSL modemu mám nastaveno 192.168.28.254/24

Do tohoto rozhraní je připojen RB přes rozhraní ether1, 192.168.28.1/24.

IP jsou nastaveny "jen" z důvodu managementu toho ADSL modemu,

PPPoE spojení bude vytáčet samotný RB (ale to vám určitě došlo ;-)).

Dál mám na RB ether2-9 v bridge a na něm nastavenu IP adresu 172.28.1.1/18

A do tohoto subnetu připojený testovací NB s IP 172.28.10.251.

Z něj si pingnu na 172.28.1.1, 192.168.28.1, ale už ne na 192.168.28.254!

IP adresy:

[admin@MikroTik] /ip address> print

Flags: X - disabled, I - invalid, D - dynamic

# ADDRESS NETWORK BROADCAST INTERFACE

0 172.28.1.1/18 172.28.0.0 172.28.63.255 LAN

1 192.168.28.1/24 192.168.28.0 192.168.28.255 ether1

Routy:

[admin@MikroTik] /ip route> print

Flags: X - disabled, A - active, D - dynamic,

C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,

B - blackhole, U - unreachable, P - prohibit

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE

0 ADC 172.28.0.0/18 172.28.1.1 LAN 0

1 ADC 192.168.28.0/24 192.168.28.1 ether1 0

Ping z RB na ADSL modem:

[admin@MikroTik] > /ping 192.168.28.254 count=3

192.168.28.254 64 byte ping: ttl=254 time=1 ms

192.168.28.254 64 byte ping: ttl=254 time=1 ms

192.168.28.254 64 byte ping: ttl=254 time<1 ms

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max = 0/0.6/1 ms

Ping z RB na NB:

[admin@MikroTik] > /ping 172.28.10.251 count=3

172.28.10.251 64 byte ping: ttl=128 time=2 ms

172.28.10.251 64 byte ping: ttl=128 time=69 ms

172.28.10.251 64 byte ping: ttl=128 time=13 ms

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max = 2/28.0/69 ms

Když ale pingám z NB na ADSL modem, žádná odpověď.

Torch říká, že se ICMP (nebo TCP pro HTTP) packet vrací, ale RB ho nemá? :-O jak vrátit na NB:

[admin@MikroTik] > /tool torch ether1 src-address=192.168.28.254 dst-address=172.28.10.251 port=any

SRC-ADDRESS SRC-... DST-ADDRESS DST... TX RX TX-PACKETS

192.168.28.254 172.28.10.251 120bps 0bps 0

192.168.28.254 80 (... 172.28.10.251 3549 128bps 0bps 0

Jak nemá?! Routu přece zná, ne?

Co je špatně? V tomto případě přeci NAT (src-nat a masquarade) není potřeba je to odroutovatelné...

Kde je sakra ta sabáka... :-(

Potřeboval bych ještě jeden originál CA/IN3 case

pro RouterBOARD 532A + daughterboard 564

:)...

Jednou zákon něco nařizuje. Tak se přeci nejde ohánět: " on to neděla a je velký zvíře, tak proč bych to měl dělat já"

O to mi jde! Opravdu to zákon nařizuje a náš operátor lže když tvrdí,

že mu zákon neumožňuje tyto údaje shromažďovat?

jelikoz vam operator odmitnul dolozit vyfakturovanou castku, odmitnul bych fakturu zaplatit

pred jakou dobou to bylo ?

Bylo právě předchozí měsíc,

a fakturu jsme zaplatit odmítli a pohrozili přechodem k jinému operátorovi.

Ale spíš mi jde o to, jak to teda opravdu je, pokud něco takového (že jim to zákon neumožňuje)

tvrdí operátor těchto rozměrů, má smysl, aby to řešil malý ISP z Horních Kotěhůlek?

Přidám svou zkušeností do mlýna:

Nejmenovaný zaměstnanec nejmenované firmy u nejmenovaného mobilního operátora.

Zaměstnanec má paušál na Internet přes GPRS/Edge.

Zaměstnanec byl ale v zahraničí, tam se platí za přenesená data.

Došla faktura na x0.000.

Zaměstnanec tvrdí, že Internet v dané dny vůbec nepoužil.

Obrátili jsme se tedy na mobilního operátora s tím, že bychom rádi věděli,

kdy a na jaké stránky dané číslo "chodilo".

Odpověď nás dostala:

dle zákonů ČR (s odkazem na ČTU) nesmí tyto informace nejen podat,

oni ani tyto informace nesmí schromažďovat.

Tohle jsme dostali jako oficiální vyjádření oddělení pro firemní zákazníky

jednoho z českých mobilních operátorů. Co si dál myslet?

Nemáte někdo tip na český obchod, kde by ještě měli skladem jeden kousek indoor case CA/IN3

na RouterBOARD 532A + daughterboard 564?

Hledám, nenacházím...

Nemaťte ho pojmem rezervace : ...

já coby "síťař" odrostlý na M$ měl zažit pojem DHCP Reservation,

kolik hodin jsem se nahledal, když jsem začínal s MikroTiky,

než jsem zjistil, že v ne-M$ světě se tomu neříká DHCP Reservation, ale DHCP Static Lease :

Šlo mi spíš o to, že takové záslepky nejspíš existují, mám takové pro optické vany,

ale pigtail na ST konektory má kapku jiný průměr než SMA konektor.

Tak mi šlo spíš o to pod jakým názvem a kde to hledat...

než o nějaké "provizorní" řešení.

Nevím, jestli jsem se tu už neptal, pokud se opakuji, snad mě neukamenujete.

Máme indoor case CA/IN2 pro RB532A (ale to asi není úplně podstatné),

má otvor pro 2× SMA konektor, 2× N konektor.

Jsou to takové ty "zploštělé" díry (viz. příloha).

Case je přišroubován na stěnu těmi dírami nahoru, a aby do něj nepadal bortel,

zalepili jsme to izolepou, ale nevypadá to profesionálně :

Máte zkušenost, existují pro nepoužíté díry záslepky?

Kde a pod čím hledat?

Nemáte někdo zkušenost s MikroTik RouterBOARD 564?

Jde jeho porty propojit do "switche"? Jak u zmiňovaného RB?

Nechápu přesně, co je účelem/cílem, takže vařím z vody.

Podle toho krátkého popisu nevím, jestli je VLAN to pravé řešení, možná ano, možná ne.

Mně osobně připadá k použití nastavení příslušných interface jako "private"

("private" porty/interfacy nemohou komunikovat mezi sebou,

mohou komunikovat jen s "public" porty/interfacy):

switch(config)#interface fastEthernet 0/1

switch(config-if)#switchport protected

http://www.cisco.com/en/US/docs/switche ... #wp1029319

A DHCP Snooping 2960 určitě umí:

http://www.cisco.com/en/US/docs/switche ... #wp1078853

Nějaké příklady:

http://www.samuraj-cz.com/clanek/cisco- ... a-switchi/

http://wh.cs.vsb.cz/sps/images/7/7f/Vyc ... jektv2.pdf

Ještě, nějaké -- možná srozumitelnějí -- info by mohlo být tu:

<--- l -->viewtopic.php?f=5&t=1023<--- l -->

enabled

Standardní stav, chování jako např. u jakéhokoliv switche.

MikroTik se učí, jakou MAC adresu vidí na jakém interface (portu)

a dynamicky si jednotlivá zařízení a vazby mezi jejich MAC<>IP adresami

ukládá do své MAC tabulky.

Aktuální stav MAC tabulky je možné zjistit přes

/ip arp print

disabled

MikroTik si nevytváří dynamicky záznamy do MAC tabulky,

veškerá zařízení připojená k příslušnému interface MikroTiku

je nutné do MAC tabulky MikroTiku zadat ručně (staticky), a to pomocí

/ip arp add mac-address=xx address=xxx.xxx.xxx.xxx interface=name

To stejné platí i pro druhou stranu!

Na všech zařízeních připojených k tomuto interface by bylo nutné zadat

ručně vazby MAC<>IP MikroTiku,

na Windows pomocí

arp -s xxx.xxx.xxx.xxx xx-xx-xx-xx-xx-xx

na Linuxu pak

arp -s xxx.xxx.xxx.xxx xx

(ani jeden nesežere opačnou notaci :)

pokud by šlo např. o bridge, pak je nutné zadat pro komunikaci i vazby

na veškeré zařízení připojené do stejného subnetu na daný interface bridge.

reply-only

Stejné jako předchozí případ,

je nutné na MikroTiku zadat vazby MAC<>IP všech zařízení, co mají s MikroTikem komunikovat,

"jen" odpadá nutnost to stejné dělat na druhé straně,

MikroTik na požadavky o překlad své IP na MAC adresu odpovídá; ale neučí se (odtud reply-only).

proxy-arp

Používá se např. u VPN nebo u "zvláštního" rozsegmentování sítě (viz. dokumentace MikroTiku nebo odkaz na Cisco web).

Je potřeba použít např. u VPN, kdy je LAN rozsah např. 192.168.2.0/24

a VPN klienti dostávají při připojení přes PPTP/L2TP adresu z tohoto rozsahu.

V tom případě je potřeba pro příslušný LAN interface nastavit právě právě arp=proxy-arp.

Při pokusu z LAN o překlad IP<>MAC pro zařízení připojeného přes VPN vrátí MikroTik žadateli

IP vzdáleného zařízení a k tomu svou vlastní MAC adresu

(prostě ARP proxy "je něco jako" HTTP proxy nebo NAT :).

Víc viz.

http://www.mikrotik.com/testdocs/ros/2.9/ip/address.php

Jinak, celkem dobře to mám popsáno na svých stránkách Cisco:

http://www.cisco.com/en/US/tech/tk648/t ... 4adb.shtml

nějaké užitečné info se dá najít i tu:

http://en.wikipedia.org/wiki/Proxy_ARP

http://wiki.webstep.net/czfree/11

http://www.earchiv.cz/a92/a242c110.php3

BTW: Psal jsem to ve spěchu, snad je to alespoň trošku srozumitelné.

Snad jsem tam nenaflákal pravopisné chyby, a co případně hůř, faktické chyby...

Když už tu někdo nakousl The Dude...

Používám ho v práci na SNMP monitoring vešekrých zařízení na síti.

Jednou ze sledovaných věcí jsou SNMP čítače Tx/Rx jednotlivých portů switchů.

A pak sledování daily grafů.

Problém je ten, že na daily graf se podívám jen 24 hodin zpět.

Je možné nějak graf vygenerovat za libovolnou dobu?

IMHO když jsou data jednou v databázi, tak by to mělo jít.

Nebo stará data maže???

To je alespoň řeč :

No, to není odpověď na mou otázku... :?

Mají, nebo nemají? :

Jednoduchá otázka:

RB nemají baterii, co by držela čas nastavený přes

/system clock

time-zone si RB zapamatuje (předpokládám standardní nastavení uložené na NAND),

ale date/time po vypnutí a zapnutí ztratí.

Zatím jsem to nezkoušel, ale plánuji to používat:

Přes VPN se připojím do LAN (IP dostanu z rozsahu probouzeného počítače).

Tím pádem jsem ve stejném broadcastovém subnetu.

A pak už jen stačí poslat Magic Packet formou broadcastu.

Potud teorie.

Může to někdo ověřit v praxi? Než se k tomu dostanu?

A L2TP/PPTP připojení můžu iniciovat snad téměř odkudkoliv...