Mam dotaz, chci nasadit reseni, OSFP, iBGP. Mam nakonfiguravanou celou sit v osfp, ale nejak nevim, jak na to BGP.
Zkusim rict, ceho chci dosahnout.
Mam napriklad 3 routery
eth1 10.255.0.1
eth1 10.255.0.2
eth2 10.255.0.5
eth1 10.255.0.6
eth2 192.168.1.1/24
Vysledek by melo byt navazani ibgp sessiony, ktera vytvori spojeni pro klienty na 192.168.1.0/24 a propoji je s hranicnim routerem 10.255.0.1, tak aby zakaznik nevidel spodni routovanou sit.
Podotknu, ze osfp mam rozchozene, vsichni se navzajem vidi. Nejde mi primo o konfiguraci, ale o princip, jak toho dosahnout.
Dekuji.
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Nastaveni BGP
Ehm, obávám se, že jsem dneska ještě stále střízliv, tak mi uniká čeho chceš vlatně dosáhnout? Co má být výsledkem?
To jako chceš, když klient s IP někde s 192.168.1.X dá traceroute http://www.porno.cz, a nemá vidět přes jaké routery to prochází? Má zmizet ten s IPčkama 10.255.0.2/10.255.0.5? Pak to ale není práce pro BGP.
To jako chceš, když klient s IP někde s 192.168.1.X dá traceroute http://www.porno.cz, a nemá vidět přes jaké routery to prochází? Má zmizet ten s IPčkama 10.255.0.2/10.255.0.5? Pak to ale není práce pro BGP.
0 x
Majklik píše:Ehm, obávám se, že jsem dneska ještě stále střízliv, tak mi uniká čeho chceš vlatně dosáhnout? Co má být výsledkem?
To jako chceš, když klient s IP někde s 192.168.1.X dá traceroute http://www.porno.cz, a nemá vidět přes jaké routery to prochází? Má zmizet ten s IPčkama 10.255.0.2/10.255.0.5? Pak to ale není práce pro BGP.
Tak pak je mozna chyba v tom, jak tu problematiku chapu. Nicmene dam treba priklad. Kdyz dam traceroute nix.cz nejde to pres 100 routeru, ktere jsou na siti, ale prakticky hned na nix.cz, podobny princip chci udelat ja. Kdyz teda zapomenu na myslenku traceroute, jaka by mela byt teorie ohledne toho bgp. Pokud se nemylim, tak bgp udela session spojeni na tcp protokolu, tim padem te session je uplne jedno, kolik je dole routeru. Zkuste me tedy trosku zasvetit.
0 x
Ne, tak tohle opravdu BGP samo o sobě nedělá. Že používá pro komunikaci mezi BGP routery TCP spojení pro výměnu routovacích informací nemá nic společného s tím, že by se provoz klientů také tunelovat v TCP. Takže když místo OSPF budeš routovat pomocí BGP, tak klient uvidí úplně stejné traceroute jak s OSPF.
Na co narážíš se řeší třeba pomocí MPLS, které buď je použito jako IP akcelerátor, kde při zakázaním propagování TTL z IP zálhaví do MPLS "vymizí" infrastriktura na pohled pro zákoše. Případně se dělají tunely, které dělají bod-bod trasy mezi zákošem a hlavní branou, které také umí vygumovat infrastrukturu. První řešení vůbec BGP nepoužívá, druhá nemusí i může (je výhodnější, pokud je síť velká a tunelů hodně)...
Na co narážíš se řeší třeba pomocí MPLS, které buď je použito jako IP akcelerátor, kde při zakázaním propagování TTL z IP zálhaví do MPLS "vymizí" infrastriktura na pohled pro zákoše. Případně se dělají tunely, které dělají bod-bod trasy mezi zákošem a hlavní branou, které také umí vygumovat infrastrukturu. První řešení vůbec BGP nepoužívá, druhá nemusí i může (je výhodnější, pokud je síť velká a tunelů hodně)...
0 x
Mohl bych taky dostat trošku školení
mám sit cca 40 MK a potřebuju zakruhovat
ale mam to nacpat na IBGP na jedno číslo AS nebo je lepší to rozdělit a vzít si nějaky privátní ASka
za druhe je lepši na routru hodit distribuci připojenejch siti nebo je zapsat do Network
Kdyby bylo demo abych to mohl někde okoukat bylo by to fajn ted jedu za plnyho provozu a vše musím dvakrát zvažovat než odkliknu OK
Diky jura
mám sit cca 40 MK a potřebuju zakruhovat
ale mam to nacpat na IBGP na jedno číslo AS nebo je lepší to rozdělit a vzít si nějaky privátní ASka
za druhe je lepši na routru hodit distribuci připojenejch siti nebo je zapsat do Network
Kdyby bylo demo abych to mohl někde okoukat bylo by to fajn ted jedu za plnyho provozu a vše musím dvakrát zvažovat než odkliknu OK
Diky jura
0 x
Konfigurovat BGP mezi čtyřiceti routery se celkem pěkné cvičení... A je celkem fuk, zda to bude jedno AS s pomocí route reflektorů a čistě vše iBGP nebo rozděleno na víc AS jako konfederace nějakých bloků, čí co router to jedno AS. Záleží, čeho cchceš dosáhnout, jaká je architektura a politika.
A máš k tomu i nějaký důvod, proč zrovna BGP a ne klasické OSPF, které je přeci jen pro jednu síť k tomu více určen?
A máš k tomu i nějaký důvod, proč zrovna BGP a ne klasické OSPF, které je přeci jen pro jednu síť k tomu více určen?
0 x
je to jednoduchý mám rád oříšky 
ne BGP se mě víc libi než OSPF a zdá se mě že přes to jde dělat více věcí a lepe
ne BGP se mě víc libi než OSPF a zdá se mě že přes to jde dělat více věcí a lepe
0 x
Které ty věci potřebuješ? Krom toho, že to reaguje pomalu a neflapuje to na mizerných wifinách?
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
hlavně mě de o zakruhování a rozdělení zátěže mezi 2 dodavatele na ruzných koncích sítě
0 x
Jenom větší množství zkonzumovaných oříšků může být smrt (pokud konzumujeme oříšky rostlé mimo naši geografickou oblast, některá odlišné vybavení oříšků cizopasníky ve větší dávce se projeví jako krevní jed). 
Oboje žádáné jde udělat i s OSPF. Řekl byh to tak - OSPF nastavíš a ono obvykle relativně slušně routuje, ale nenechá si do některých věcí moc kecat. BGP dělá přesně to, co mu řekneš, když mu to řekneš blbě, tak to s maximální pečlivostí bude blbě dělat, ale ani o píď víc.
Co přesně a jak použít je závislé od topologie sítě a jak si představuješ kudya co má téci. Obecně pěkné popsané možnosti BGP a jak s nima zacházet je třeba tento Cisco dokumnet:
http://www.cisco.com/en/US/tech/tk365/t ... 95bb.shtml
V podstatě to platí (až na pár odlišností nebo chybějících funkcí) i pro RouterOS, jen je trošku jiný formát příkazů.
Oboje žádáné jde udělat i s OSPF. Řekl byh to tak - OSPF nastavíš a ono obvykle relativně slušně routuje, ale nenechá si do některých věcí moc kecat. BGP dělá přesně to, co mu řekneš, když mu to řekneš blbě, tak to s maximální pečlivostí bude blbě dělat, ale ani o píď víc.
Co přesně a jak použít je závislé od topologie sítě a jak si představuješ kudya co má téci. Obecně pěkné popsané možnosti BGP a jak s nima zacházet je třeba tento Cisco dokumnet:
http://www.cisco.com/en/US/tech/tk365/t ... 95bb.shtml
V podstatě to platí (až na pár odlišností nebo chybějících funkcí) i pro RouterOS, jen je trošku jiný formát příkazů.
0 x
Začal jsem to překopávat z statiky a když mam rozjety BGP a študuju to jak se da nezahodím to a jak zbabělec neuteču na ospf
mno chci to dat do kupy prakticky to je na spojení a filtrech zjištuju že něco udělám blbě ale člověk se učí stejně jak tomu bylo v začátku
mno chci to dat do kupy prakticky to je na spojení a filtrech zjištuju že něco udělám blbě ale člověk se učí stejně jak tomu bylo v začátku
0 x
U všeho je jedna z nejdůležitějších vlastností poměr cena/výkon. Podle mě je BGP uvnitř sítě drahé ... náročnost konfigurace převáží případné výhody.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Přesně tak, s BGP je v tomto dost hnusná práce. Prřidám někde pár segmentů, prolézat všehny routery a kontrolovat filtry, stačí přidat další linku a dle toho měnit váhy nebo local pref (kde změnou snadno rozniju i něco na druhé straně sítě), ....
Pokud máš BGP v provozu na těch dovu uplinkách, nech je tak a zbytek přenech na OSPF (pro 40 rotuerů už RIP není). Maximálně můžu řešit v závislosti na struktuře sítě, že ji rozdělím na několiki logických celků, v kterých pojede OSPF samostatně a mezi nima BGP výměna (ale tento bod se obvkyle motivuje větou: představme si menšího ISP, který má tak 500.000 zákazníků přes několik krajů).
Od ROS6 se dá použít rozumně i víceinstanční OSPF a funguje i na kruhách (konečně funguje správně route tag).
Když to pojedeš jako jedno AS, tak se srát s route reflektory/clustery nebo to rozbíjet na konfederace... Akademické cvičení pěkné, ale po čase pak v tom dělat nějaké změny může být snadno s velkým nadáváním a bolestí....
A nebo chceš být drsňák, co použije plochou strukturu s jedním AS a full mesh, kolik pak budeš konfigurovat peerů a přidávat jich po přidání jendoho routeru (proto byly vymyšleny ty konfederace a RR)?
Full mesh konfigurace navíc nejrychleji žere RAM a likviduje CPU (plus i konfigurující obsluhu a má i největší režii na síť). Má ale nejrychlejší odezvu na změny, jenže nad 5 routerů je to už na palici. Jak pak vypadají routovací tabulky a jak se dělá next hop selekce? Každou routu mít v routovací tabulce X-krát...
Pokud se použijí route reflektory, tak koncové BGP routery jsou celkem v klidu s RAM i CPU, na prášky s RAM+CPU trpí ty reflektory (které to chce mít aspoň 2 v clusteru, kdyby jeden zdechl, ať se ti to nesloží). I když při použítí jako náhrada za OSPF se to dá dělat jako next hop reklektování, když to dělám s jendím AS, pak jsou na tom věechny routery stejně blbě. Zase použití reflektorů má asi nejhorší latenci na změny.
Pak je možnost těch confederací bloků routerů, ty celkem snižují zátěž na CPU uvnitř jedné konfederace a je rychlá odezva na změnu uvnitř konfederace, ale když je změna v síti mimo konfederaci, tak všechny routery v confederaci dostanou nakládačku na CPU na přepočítávání externích věcí. Confederace v podstatě je podobná situace, jako arei v OSPF.
Pak jsou případně možné zajimavé opičárny s next hop selekcí a přepisem, aby se něco ušetřilo....
Takže se to v praxi různě kombinuje, dle struktury sítě aby to rozumně fungovalo.... Pro 40 routerů a pár set rout to zatížen CPU/RAM v těch řešeních se moc lišit nebude (pokud tma fakt nemáš střepy typu RB133). Také třeba bod, pokudmám víc ekvivalentních tras a chtěl bych mezi ně dělat rozkládání zátěže, holé BGP to neumí, je na to obezlička, ale musím buď to podložit přes OSPF nebo něco statických rout - OSPF to umí od přírody. Půje spíše o to, co psychicky snese obsluha a kolik rumu padne, než to naladíš do OK stavu a kolik práce dá případně někomu dalšímu do toho v případě šáhnout, když nebudeš schopen týden výlez z hampejzu...
BGP není lbost, ale má smysl interně ve velké síti, kterou rozbíjím na X menších sítí, kterí interně jedou něco jako OSPF, ale totálně pouze holé full iBGP... Jsou příjemnější způsoby, jak umřít...
Pokud máš BGP v provozu na těch dovu uplinkách, nech je tak a zbytek přenech na OSPF (pro 40 rotuerů už RIP není). Maximálně můžu řešit v závislosti na struktuře sítě, že ji rozdělím na několiki logických celků, v kterých pojede OSPF samostatně a mezi nima BGP výměna (ale tento bod se obvkyle motivuje větou: představme si menšího ISP, který má tak 500.000 zákazníků přes několik krajů).
Od ROS6 se dá použít rozumně i víceinstanční OSPF a funguje i na kruhách (konečně funguje správně route tag).
Když to pojedeš jako jedno AS, tak se srát s route reflektory/clustery nebo to rozbíjet na konfederace... Akademické cvičení pěkné, ale po čase pak v tom dělat nějaké změny může být snadno s velkým nadáváním a bolestí....
A nebo chceš být drsňák, co použije plochou strukturu s jedním AS a full mesh, kolik pak budeš konfigurovat peerů a přidávat jich po přidání jendoho routeru (proto byly vymyšleny ty konfederace a RR)?
Full mesh konfigurace navíc nejrychleji žere RAM a likviduje CPU (plus i konfigurující obsluhu a má i největší režii na síť). Má ale nejrychlejší odezvu na změny, jenže nad 5 routerů je to už na palici. Jak pak vypadají routovací tabulky a jak se dělá next hop selekce? Každou routu mít v routovací tabulce X-krát...
Pokud se použijí route reflektory, tak koncové BGP routery jsou celkem v klidu s RAM i CPU, na prášky s RAM+CPU trpí ty reflektory (které to chce mít aspoň 2 v clusteru, kdyby jeden zdechl, ať se ti to nesloží). I když při použítí jako náhrada za OSPF se to dá dělat jako next hop reklektování, když to dělám s jendím AS, pak jsou na tom věechny routery stejně blbě. Zase použití reflektorů má asi nejhorší latenci na změny.
Pak je možnost těch confederací bloků routerů, ty celkem snižují zátěž na CPU uvnitř jedné konfederace a je rychlá odezva na změnu uvnitř konfederace, ale když je změna v síti mimo konfederaci, tak všechny routery v confederaci dostanou nakládačku na CPU na přepočítávání externích věcí. Confederace v podstatě je podobná situace, jako arei v OSPF.
Pak jsou případně možné zajimavé opičárny s next hop selekcí a přepisem, aby se něco ušetřilo....
Takže se to v praxi různě kombinuje, dle struktury sítě aby to rozumně fungovalo.... Pro 40 routerů a pár set rout to zatížen CPU/RAM v těch řešeních se moc lišit nebude (pokud tma fakt nemáš střepy typu RB133). Také třeba bod, pokudmám víc ekvivalentních tras a chtěl bych mezi ně dělat rozkládání zátěže, holé BGP to neumí, je na to obezlička, ale musím buď to podložit přes OSPF nebo něco statických rout - OSPF to umí od přírody. Půje spíše o to, co psychicky snese obsluha a kolik rumu padne, než to naladíš do OK stavu a kolik práce dá případně někomu dalšímu do toho v případě šáhnout, když nebudeš schopen týden výlez z hampejzu...
BGP není lbost, ale má smysl interně ve velké síti, kterou rozbíjím na X menších sítí, kterí interně jedou něco jako OSPF, ale totálně pouze holé full iBGP... Jsou příjemnější způsoby, jak umřít...
0 x
Ale kdo chce kam, kopněme ho tam....
Jestli máš veřejné AS, udělej to celé jako konfederaci, všechny routery budou mít společné veřejné AS a zároveň svoje vlastní privátní plus v confederation peers uvedeš seznam vnitřně použitých AS (pokud veřejné nemáš, tak Confederation AS nenastavuješ, stjeně tak confederation peers list. Dále je to už stejné)...
Co jeden router, to mu dáš jedno privátní AS (64512~65534, 4,200,000,000~4,294,967,295). Pokud někde máš pohromadě víc routerů a chceš pro ně společnou řízenou politiku routování, třeba na jednom malém Ethernet switchi spojených víc rotuerů, můžeš je udělat jako jedno privátní AS a mezi nima dělat iBGP (do 4 routerů dělej full mesh, pro víc dva router reflektory).
Nicméně většina bude jako klasické eBGP s využítím přímo navazujících IP na segmentech mezi peery. Čili jako adresu peera dávej přímo dosažitelnou IP přes interfejs a nastavuj update source na hodnotu jména odchozího interface (nebudeš využívat rekurzivních rout).
Do routeru dej vstupní filtry, které budou dropovat příchozí segmenty odpovídající tomu, co je přímo připojeno k routeru (a co budeš tedy vlastně propagovat ven), odchozí filtr tím pádem asi ani netřeba. Pokud bude víc routerů jedno AS, tak mají všichni stejný filtr, který likoviduje všechny segmenty těch routerů na eBGP linkách, na iBGP linkách nefiltruj nic. Na iBGP peer linkách musíš nastavit nexthop choice=propagate self (nebo mezi iBGP routery pustit i RIP nebo OSPF).
Routy posílej ven jako connected. Na hlavních bránách samozřejmě i default routu posílat (konfigurace per peer). Networks bych se vyhnul, hlavně pokud dojde na iBGP a budeš mít routery s ROS5, tak networks blbne. Pokud na routeru je vedle sebe víc navazujících segmentů, třeba /24, které jdou agregovat např. do jednoho /20, tak se to nastavit v agregates, že pošle jednu sumární routu a ty /24 dropne. U agregace nesmiš agregovat segmenty, které jsou zároveň spojovací k dalším routerům, jinak to bude dělat bordel.
Toť asi v principu vše.
V podstatě jsem něco podobného používal dříve pro IPv6, dokud nezačlo opravdu fungovat OSPFv3...
shooter píše:mám sit cca 40 MK a potřebuju zakruhovat
ale mam to nacpat na IBGP na jedno číslo AS nebo je lepší to rozdělit a vzít si nějaky privátní ASka
za druhe je lepši na routru hodit distribuci připojenejch siti nebo je zapsat do Network
Jestli máš veřejné AS, udělej to celé jako konfederaci, všechny routery budou mít společné veřejné AS a zároveň svoje vlastní privátní plus v confederation peers uvedeš seznam vnitřně použitých AS (pokud veřejné nemáš, tak Confederation AS nenastavuješ, stjeně tak confederation peers list. Dále je to už stejné)...
Co jeden router, to mu dáš jedno privátní AS (64512~65534, 4,200,000,000~4,294,967,295). Pokud někde máš pohromadě víc routerů a chceš pro ně společnou řízenou politiku routování, třeba na jednom malém Ethernet switchi spojených víc rotuerů, můžeš je udělat jako jedno privátní AS a mezi nima dělat iBGP (do 4 routerů dělej full mesh, pro víc dva router reflektory).
Nicméně většina bude jako klasické eBGP s využítím přímo navazujících IP na segmentech mezi peery. Čili jako adresu peera dávej přímo dosažitelnou IP přes interfejs a nastavuj update source na hodnotu jména odchozího interface (nebudeš využívat rekurzivních rout).
Do routeru dej vstupní filtry, které budou dropovat příchozí segmenty odpovídající tomu, co je přímo připojeno k routeru (a co budeš tedy vlastně propagovat ven), odchozí filtr tím pádem asi ani netřeba. Pokud bude víc routerů jedno AS, tak mají všichni stejný filtr, který likoviduje všechny segmenty těch routerů na eBGP linkách, na iBGP linkách nefiltruj nic. Na iBGP peer linkách musíš nastavit nexthop choice=propagate self (nebo mezi iBGP routery pustit i RIP nebo OSPF).
Routy posílej ven jako connected. Na hlavních bránách samozřejmě i default routu posílat (konfigurace per peer). Networks bych se vyhnul, hlavně pokud dojde na iBGP a budeš mít routery s ROS5, tak networks blbne. Pokud na routeru je vedle sebe víc navazujících segmentů, třeba /24, které jdou agregovat např. do jednoho /20, tak se to nastavit v agregates, že pošle jednu sumární routu a ty /24 dropne. U agregace nesmiš agregovat segmenty, které jsou zároveň spojovací k dalším routerům, jinak to bude dělat bordel.
Toť asi v principu vše.
V podstatě jsem něco podobného používal dříve pro IPv6, dokud nezačlo opravdu fungovat OSPFv3...
0 x
Diky za troška nakopnutí ale občas hodím nějáky dotazek
nevěděl bys o nejaky demu nebo přistup na demo ?
diky
nevěděl bys o nejaky demu nebo přistup na demo ?
diky
0 x