nevím, jaké kabely jste zkoušel, ale má se použít křížený kabel nebo modem zapojit na hub do UPLINK portu. Nedomnívám se, že v tomto je rozdíl od verze PRO.
Zdravim,
pomohl by mi nekdo pochopit, proc u ADSL nemuzu pripojit Alcatel SpeedHome Touch k pocitaci skrze hub Edimax? Pocitac jej proste nevidi at uz pouziju jakejkoliv kabel. A proc by to po prekonfiguraci modemu na PRO melo jit? A ohledne FTP, ktery ted tedy konecne funguje mam drobnou otazku, proc se nemuzu pripojit na FTP2? Tam je stejnej problem jako s FTP. Budu vdecen kazdymu kdo mi poradi. Diky moc.
Clean
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...
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.
Mozna kdyz si clanek prectes jeste jednou, dvakrat, pochopis ze chyba neni v IP siti ale na SSG.
Kdyz uz pomineme zakladni fakt, ze IP neni rovno MPLS, tak
MPLS sit s timto problemem nema nic spolecneho. Jeji uloha je pouze transportni. Chyba byla v sice v routerech ale v routerech se software na SSG. Ucelem techto SSG je sledovat flow a uzivatel si na nich vybira sluzby, prihlasuje se.
Chyba nebyla ani primo v CEFu ale prave ve spolupraci NATu+SSG+CEF.
A jedna vec je odmonitorovat provoz a druha je opravovat IOS. Filtry s tim nemaji vubec nic delat.
Po této malé exkurzi do způsobu implementace si již můžeme snáze naznačit, kde mělo dojít k chybě. Nebylo to na PE směrovači a za ním, v MPLS síti, jak se mohlo zdát z předchozího článku. Zde CEF (Cisco Express Forwarding) zřejmě nezpůsoboval problémy a byl spuštěn hned od počátku (jako nutný předpoklad k fungování MPLS mezi PE směrovačem a směrovačem na straně ISP).
---------------------------------------------------
Nevsiml jsem si nutnosti pouzivani CEFu mezi PE a ISP. CEF MUSI byt pusten v globalni konfiguraci a MUSI byt pusten na MPLS interface, ale MPLS az k ISP nevede takze tam pusten byt nemusi, ale pravdepodobne bude (kvuli vykonu routeru).
Takze hledat chybu na tomto miste by bylo zrejme hloupe.
Krome toho chyba musela byt na aplikacni urovni, kdyby byla pouze v CEFu tak by nefungovalo nic ne "jen" FTP.
CEF je v podstate obsah cache. Routovaci tabulka se prevede a strci se do pameti nad interfacem. Na prichozim packetu se provede vyhledavani destination adresy v cache a packet je v ramci jednoho interruptu procesoru prehozen na odchozi interface a odeslan. Process switching vyzadoval daleko vice interruptu (podle platformy) a zatezoval centralni procesor. To je taky duvod proc pustit na SSG CEF. SSG je vytezovana jiz samotnymi procesy SSG a process switching mohl procesor zrejme jen dorazit.
Jo, asi mate pravdu, kdyby to vsechno rozepisoval vypadalo by to strasne, mam ale pocit ze se autor ponekud nechal problemem unest a prilis do toho zabredl.
Ja myslim ze problem, v tom ze neslo FTP na ADSL pri pouziti DSLAMu na ATM PVC pripojenych k SSG L3 kde bezi TCP a NAP aby se pripojilo IP sit MPLS pres TCP a pak dale k ISP, vznikl tak ze nejakej BLB z CTc zapojil spatne D.R.A.T. a tak se stalo ze HTTP slo zatimco FTP ne a CTU na to koukal. :-)
Ono taky neni divu kdyz se to menuje, tak aby se v tom nikdo nevyznal, ze to ani panacci z CTc nezvladli.
A takhle to bude pokracovat: Nejakej typek z KGB si da moc THC, koukne se na logo CTC v JPG, vezme BFG, prinde na CTc HQ udela BUM, prijede tam FBI s MP5 a AK47, a cely to tam rozstrili ze nebude ani CTc, ani DLS, ani WI-FI ani nic, a ten typek bude lezet na RTG posleze na ARO na OUNZ, zemre a na hrobe se obevi RIP.
Priste bych prosil autora, aby tolik nesetril zkratkami jako v tomhle clanku kde jejich kadence nedosahuje ani 3 na radek. Priste prostim vynechejte vsechna ostatni slova a piste jen ve zkratkach, a pokud mozno udelejte z veci jdenoduche vec slozitou a budete vypadat velmi chytre.
Je to pravdepodobne tim, ze Nextra diky nasazeni nuloveho instalacniho poplatku, reklamni kampani (kolik potencialnich klientu asi sledovalo Ceske lvy?) a relativni znamosti dokazala ziskat velky podil na "trhu" s ADSL. Klienti Nextry jsou videt nejvice, protoze je jich pomerne hodne. Ja jsem na ruznych forech cetl o dlouhych vypadcich i u klientu jinych ISP. Spolecnym jmenovatelem techto vypadku nebyl nikdo jiny nez CTc. To, ze ma Nextra pekne vykutalenou hotline, jejiz cislo navic pred svymi klienty taji, je vec jina...
Zkoušel někdo netmeeting přes adsl? Mně totiž funguje jen na půl. Nemůžu se přihlásit k ILS serveru a když někomu volám, tak vidí jen on mně, ja jeho ne:-(((
Přes normál modem vše ok.
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).
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.
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.
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.
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.
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?
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.
Kdysi (za mého mládí) se tomu říkalo "kabelový přenos". Nahrálo se na pásku nebo na několik 8" disket, sekretářka vložila do kabely a přenesla tramvají na druhý konec Prahy.
Když přišly 5 1/4 diskety, změnil se přenos na kabelkový...
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 :-)
Čí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.)
Otázkou stojí zda uvedené celovíkendové výpadky jsou výpadky Telecomu. Zatím si na podobné věci stěžují všude jen uživatelé Nextry.
Krom toho Vás jako zákazníka Nextry nemusí zajímat slevy jejich dodavatelů. Jestli Vám to nechodí, tak jim to neplaťte, ať si vzniklou škodu řeší s daným dodavatelem.
Nejsem žádný angličtinář, ale v článku se to opakovalo dvakrát hned za sebou, tak mi to nedalo nereagovat. Z dob studií si pamatuju knížku "Czenglish or English", kde je uvedeno, jako jedna z častých chyb, překládání "well-known" (tak, jak se uvadí v RFC793 apod.) jako "dobře známý". Správný překlad je prostě "známý". Na rozdíl od "well known" :-)
Vsechny tyhle problemy jsou jen z toho, ze tarif Home neni pripojeni k Internetu. Do kdy bude jeste Telecom vnucovat ostatnim tenhle priserny paskvil ktery asi nema ve svete obdoby ?
Pravda, sem velmi zvedav, jak se bude ta jejich slavna sit chovat, az tam budou koncem toku mit tech predpokladanych 40 000 uzivatelu, kdyz to nestiha uz ted.
Naučí, ale z našich peněz... obzvláště, pokud mu stále budeme dovolovat, aby nás tahal za nos tím, že vlastně nabízí služby pouze skrze svou (pochybnou) IP síť, a nikoliv přímo na úrovni datového toku. Pak by nesmysly typu NAT, kvůli kterému stejně nebudou fungovat některé protokoly, zcela odpadly. Bojím se ale, že spousta uživatelů dá ze zoufalství přednost současným "ADSL" řešením nabízeným ČTc, a že spousta ISP se s tímto stavem spokojí...
U ČTc je standardním řešením asi cokoliv. Abychom se nedočkali 100Mb ethernetu na bázi rychle cirkulujících běžců s disketami.. (..nejdražšího v Evropě)
Nejvetsi vtip je v tom, ze SSG je v te sluzbe dost zbytecna.
SSG je prave to, co dela z ceskeho ADSL sluzbu, ktera ma konkurovat dialupum namisto pevnym linkam, kterym by konkurovat mela (hlavne cenou). Napr. slovenska implementace ADSL jej vubec neobsahuje - uzivatel se autentikuje protokolem PPPoE primo. Samozrejme, naskyta se otazka, proc se vubec k ADSL autentifikovat, kdyz uz ucastnik je autentifikovan pristupovym vedenim - je to pouze kvuli pohodli operatoru, aby se nemuseli pracne nastavovat s porty jednotlivych DSLAMu - takze to odnese uzivatel.
Třeba se Český Telecom časem naučí dělat i IP sítě.... Jinak mi to připadá jako takové trochu mlžení s MPLS a IOSem a pod.
Vyfiltrování IP paketu, to je už docela jasné, na to se snad dalo přijít prostě monitorováním provozu...
Takže agregace pomocí CAR (Committed Access Rate) se provádí v SSG? A ví se, jestli je skutečně nastavena na hodnoty dle RAO? Zatím to moc nevypadá, že by byl CAR spuštěný, a jeho spuštění znamená pro ten Cisco box další dost vyskokou zátěž. Kolik je vlastně v celé síti těch SSG, tedy agregačních bodů?
ČLÁNKY DO MAILU