Čím se proboha liší otevírání přenosového kanálu na portu 21 a na portu 80 ?
Jedině tím, že 21 je standardně určen pro FTP a tam je potřeba (posléze) otevírat ještě druhý přenosový kanál.
Mohu se zeptat, jestli někdo vyzkoušel otevřít při oné závadě jen (první) přenosový kanál na port 21? (Běžný způsob zjišťování špatně nakonfigurovaných firewallů pro různé režimy FTP.)
vy nejste vyvojar.. Jinak byste podobnych situaci uz davno zazil :-))).. jednoducha odpoved je ze to tak vyvojar chtel a ze 21 nema stejny binarni zapis jako 80 :-)
A co potom port 22 ? Ten má na konci bitové kombinace nulu jako port 80.
Nespolupracuje nyní Sisco s Microsoftem, potom ony absurdnosti možná mohly být i pravdivé.
A co 79 - nikdo určitě nezkoušel, protože to je i není přes TCP.
pokud si pamatuji.. nepsal jsem nic o konci bitove kombinace.. ale mozna mate pravdu a delam absurdnosti :-). Ale pocitace v soucasnem pojeti jsou proste (v mnoha pripadech, jako safe-net kdyby chtel nekdo argumentovat ;-) deterministicke :-), na tom se shodneme ne?
Jak jsem zaznamenal, tak neslo ani pasivni FTP a to se od well-known sluzby na portu 80 (zpravidla HTTP) naprosto nicim nelisi. ToS se stejne v IPv4 nevyuziva, takze je to veru stejne. Jedina cesta byla FTP through HTTP, coz je o necem jinem nez o NATu a tomuto gulasi, co predvedli... - Navic, pokud by to byla pravda, tak nebude fungovat zhola nic co pouziva jiny kanal nez ted se zadosti... - vzhledem k tomu, ze NAT udajne nicemu nebrani a je to 1:1, tak by mne zajimalo, proc zrovna u FTP to vadi a jine protokoly, ktere treba potrebuji rovnez kanal ze serveru na klienta maji bez problemu bezet... (jakykoli server umisteni na pripojce ADSL by mel byt dle vysvetleni CTc do opravy naprosto NEDOSTUPNY!!! - byl? Jak to, ze ne?!) - to, ze se nemasoveji projevil problem u FTP je dano tim, ze lidi ho zkousely, ale problem v technicke rovine je bud trochu jinde a CTc/CISCO dost silne mlzi a nebo je to uplne jinak a toto je vopiti rohlikem.
IMHO - mozna trosku mimo, ale co muzete cekat od firmy, ktera nyni masove propaguje ISDN (btw: takhle tendenci reklamu jsem uz dlouho nevidel) - jako kdyby to byl objev tisicileti. Telecom mlzi a to je fakt. To, ze neinformuje, je taky jeho blbost.
Problem nebyl ve sluzbe ale ciste v portu 21 jak jsem psal uz vyse (nize ?). FTP at uz aktivni nebo pasivni na jiny port proslo OK.
A jeste technicka: pasivni ftp se od http lisi treba tim ze ma porad druhy datovy port na server - ovsem inciatorem konekce je klient a ne server jako u aktivniho ftp.
Pokud tomu dobře rozumím, tak ten Cisco box nepropouštěl alespoň část paketů, je to popsáno tak, že SYN prošel, ale SYN ACK ne. Ten Cisco box překládá adresy přenášené v řídicím kanálu ftp z privátních na veřejné a naopak, takže určitě provoz na portu 21 zpracovává odděleně. No a v tomto odděleném zpracování byla zřejmě chyba.
To přesně souhlasí s tím, jak byl problém popisován i s tím, že pokud se nakonfiguroval ftp server na jiném portu, tak normálně fungoval.
Řada problémů se ale týkalo i neuzavíraných spojení, kdy zžejmě neprošly nějaké FIN pakety, bude zajímavé, jestli bylo vyřešeno i toto. Projevovalo se tím, že zůstávaly otevřené sockety nebo že se nedonačítaly stránky.
Problem neni v samotnem cislu portu, ale v tom ze na portu 21 bezela na vnitrtni vrtve site Ctc sluzba CEF. Vinou spatneho nastaveni pak pakety urcen epro port 21 neprosly protoze je nejaka krabice po ceste povazovala za CEF. K vasi otazce: ano, nesla samotna sluzba na portu 21, s aktivnim/pasivnim FTP to nema co delat. FTP server spusteny na jinem portu byl normalne dostupny i v aktivnim rezimu.
Heh? CEF je sluzba? Nebo snad protokol na vyssi vrstve? A on beha na nejakem portu? To jsou ale veci... Doporucuji nejaky kurs na CCNA a ucte se moudrym byti. CEF je proste metoda zpracovani packetu v ramci routeru, akorat je rychlejsi nez process routing (pak je tu treba jeste PXF). Router pak ovsem rozhodne nefunguje jako layer 3 switch, jak take nejaky neznalek nekde napsal (to by toho totiz moc neuroutoval, pokud tusite, jak L3 switche rozhoduji o smerovani packetu, ony totiz ani zdaleka neprohlizeji hlavicku kazdeho packetu na treti vrstve).
Je to pravda a neni to pravda.
Router se do L3 hlavicek samozrejme diva, ale packet uz nepredava procesoru na prozkoumani routovacich tabulek routeru ani packet neni kopirovan do hlavni pameti routeru.
Proste je prepsan L2 a packet preklopen po sbernici na odchozi port.
Ani tak jednoduché to není. Směrovač musí snížit TTL, do směrovacích tabulek se samozřejmě dívat musí, jenomže to nemusí dělat hlavním procesorem, ale mít ten algoritmus distribuovaný na procesory na interfacech, mít speciálně připravené tabulky, atd.
Ono i samo cisco má několik úrovní této optimalizace: fast switching, distributed fast switching, optimum switching, CEF, DCEF...
ČLÁNKY DO MAILU