Zabránění Neighbors při transportu VLANou.

[sub_zero]

Ahoj, přemýslím, jak zabránit následujícímu chování.

Na hlavním routeru je na iface vytvořena vlana, řekněmě 222, na ní je spojovací rozsah /30, dále je tato vlana trunkama transportována přes celou síť (HP switche) až na poslední switch, kde do portu 3 je zapojen Summit a na druhé straně za Summitem je již router zákazníka. Ten má vytvořenou na iface tu samou vlanu a nastavenou IP. Tohle je standart, to funguje. Ale...ty Summity a veškerý prvky v síti máme na management vlaně, což je samozřejmě z dob dávných ta defaultní, vlan1. A tak logicky, když ten zákazník udělá v tom svém routeru Neighbors, uvidí ostatní naše zařízení + samozřejmě adresní rozsah.
Jde nějak tohle zakázat? Předpokládám, že si to čichá přes broadcast. Tak jsem zkusil na těch ProCurvách nastavit limit broadcastu na co nejmeněí hodnotu, ale bez výsledku. Samozřejmě, řešením by bylo posadit management všech prvků na jinou vlanu, ale při tom množství to je hardcore.

Díky za tipy.

[Viktor Novotný]

predavkovy router (rozhrani mezi spojem a zakaznikem) je tvuj ne ? tak to zakaz na nem

[sub_zero]

Žádnej router tam není. Je to čistá L2. Jak sem psal, pouze hraniční router - L2 - router zákazníka.

[net.work]

zakazat na svych zarizenich aby odpovidali na neighbour?

[Viktor Novotný]

a router zakaznika je tedy uz v jeho sprave ? toto prave nedelam, davam jim router nas (only nas pristup), aby v nem bylo ochranene vse co ma byt a tedy zakaznim nemohl nic nez jen vyuzivat svou linku

[sub_zero]

Zakázat Neighbors není řešení, protože bych to zakázal na všech mašinách i sobě. Tzn. hledám řešení, jak to ošetřit na L2 popř. přímo na portech switchu. Samozřejmě mu tam dát router je čisté řešení a asi to tak dopadne, jen mě zajímá, zda existuje i jiné řešení.

[hapi]

pokud vim tak nestavíte na levných shitech takže co třeba dropnout multicast nebo ten port pro neighbor na poslednim vašem switchy? Určitě tam máte něco co dokáže ovlivnit i L3/L4 jenom na jejich portu. Určo tam máte L2+ switche který to dokážou. Ale nějak stejně nechápu jak to může vidět. Tady u nás prostě nevidim absolutně nic z jiných vlanů.

[sub_zero]

k tomuto výsledku téma spěje... JAK dropnout broadcast na HP

edit: Stando, úplně normálně.. z portu koncovýho switche jde tagovaná vlana zákazníka + untag vlan na management těch prvků po ceste (summity). No a ze Summitů už jde ether přímo do zakazníkova boxu, už chápeš? No a zakoš klikne na Neighbors a vidí na své vlaně jen jeden router (jeho bránu-což je ok), ale na té untag vlaně celou L2 síť

[ludvik]

To také záleží, jaké HP máš. Možnosti jsou mezi absolutně tupým kde neuděláš nic a modulárním, kde uděláš všechno. Např. na 1800 (což je management, ale "lowcost") to neuděláš určitě.
Musíš tam mít něco, co umí ACL až na úroveň UDP portu. Což není až tak obvyklé. Teoreticky by ti mohlo stačit bloknout port 5678 z jeho IP.

Otázkou také zůstává, jestli je vhodné bloknout komplet broadcast ... řekl bych, že ne
Druhou otázkou je, proč má zákazník full přístup na router. Zakaž discovery na ethernetu a jemu dej max. read-only.

k tomuto výsledku téma spěje... JAK dropnout broadcast na HP

edit: Stando, úplně normálně.. z portu koncovýho switche jde tagovaná vlana zákazníka + untag vlan na management těch prvků po ceste (summity). No a ze Summitů už jde ether přímo do zakazníkova boxu, už chápeš? No a zakoš klikne na Neighbors a vidí na své vlaně jen jeden router (jeho bránu-což je ok), ale na té untag vlaně celou L2 síť

[Viktor Novotný]

to ludvik, protoze router je zrejme zakaznika ...

[hapi]

k tomuto výsledku téma spěje... JAK dropnout broadcast na HP

edit: Stando, úplně normálně.. z portu koncovýho switche jde tagovaná vlana zákazníka + untag vlan na management těch prvků po ceste (summity). No a ze Summitů už jde ether přímo do zakazníkova boxu, už chápeš? No a zakoš klikne na Neighbors a vidí na své vlaně jen jeden router (jeho bránu-což je ok), ale na té untag vlaně celou L2 síť

jo aha, takže váš koncovej port z vašeho pohledu je ještě před summitama. Tedy port vašeho switche, summit a zákoš. hmm tak proč to neuděláš opačně? netaguješ management a neodtagováváš zákazníka? pak by nikoho z nich nenapadlo zapnout vlan. Přijde mi trochu divný posílat zákošům data na vlanu když to stejně z naší sítě leze přes řiditělnej switch kde to zákazníkovy odtaguju. Ale tak každej to dělá jinak.

[sub_zero]

k tomuto výsledku téma spěje... JAK dropnout broadcast na HP

edit: Stando, úplně normálně.. z portu koncovýho switche jde tagovaná vlana zákazníka + untag vlan na management těch prvků po ceste (summity). No a ze Summitů už jde ether přímo do zakazníkova boxu, už chápeš? No a zakoš klikne na Neighbors a vidí na své vlaně jen jeden router (jeho bránu-což je ok), ale na té untag vlaně celou L2 síť

jo aha, takže váš koncovej port z vašeho pohledu je ještě před summitama. Tedy port vašeho switche, summit a zákoš. hmm tak proč to neuděláš opačně? netaguješ management a neodtagováváš zákazníka? pak by nikoho z nich nenapadlo zapnout vlan. Přijde mi trochu divný posílat zákošům data na vlanu když to stejně z naší sítě leze přes řiditělnej switch kde to zákazníkovy odtaguju. Ale tak každej to dělá jinak.

protože ten port switche není jen pro toho zakoše je tam i víc vlanů.. no a řešení dát management na jinou vlnanu = smrt, protože moc zařízení a některý z historických důvodů nepodporujou jinou mngmt vlanu než 1. JInak to jsou 2510G a 2610G switche

[hapi]

hehe, tak asi nevim jak to máš, nakresli to, myslim že i jiný reakce uvažujou jinak než ty myslíš.

[sub_zero]

hehe, tak asi nevim jak to máš, nakresli to, myslim že i jiný reakce uvažujou jinak než ty myslíš.

Nebuďte líní a zapojte mozek, Malování sem odinstaloval Jednoduše:

1.)iGw, na něm vytvořena vlan222, ta vytvořena na ether2, což je mngmt vlan1
2.)x-mngmt switchů po ceste, kde je ta vlan222 tagovaná a ta vlan1 všude v untagu (logicky=management těch prvků)
3.)koncevej mngmt switch, kde ten port obsahuje: vlan222 a vlan333 v tagu a vlan1 untag, protože za tím jsou ty Summity a spravujou se přes to
4.)za Summitem hloupej Zyxel, z něho jde ta vlan222 k zakazníkovi a vlan333 do našeho boxu (vše opět v tagu) a vlan1 v untagu na správu toho našeho boxu

Takže probém je ten, že ten zájazník vidí do naší vlan1, protože je v UNTAGU. Takže hledám řešení jiný, než tam dávat další router, jako naše předávací rozhraní - ale asi vidím, že to bude jednosušší

[Majklik]

Z toho Zyxellu už jde linka k zákošovi a tvoji bedně každá vlastním ethernetem?
Pak je cesta nejmenšího odporu ten Zyxell vyhodit a dát tam něco, co tuší VLANy a umí je trochu řídit. Asi ti to dá i mikrotik RB250GS (pokud 5 portů stačí). Nastavíš, že směrem k zákazníkovi se pouští (a od něj bere) jen tagovaná VLANa 222 a ostatní je odřízlé (takže port v režimu trunk). Pokud máš šanci ukacet zákazníka, ať to změní, že dál už nebude mít na portu aktivní VLAN, ale jen přímo port bez tagu, tak mu z toho uděláš access port a na té RB250GS budeš odtagovávat/tagovat co jde tím portem. K danému portu přiřadíš jen VLAN 222 a žádnou jinou a ort bude v režimu filtrace jen povolených VLAN.

Nicméně toto ti řeší jen to, co chodí jinými VLANama. Co se ti dostne přímo do té 222, to uvidí. V podstatě buď jde o ten Miktotikový Neighbor protokol (MNDP - UDP broadcast na port 5678). Ten se dá odfiltrovat v tom 250GS asi snadno.
Další věc e, co ti tam posílají jiné bedny. Může jit o Cisco CDP protokol a Mikrotik ho umí interpretovat a zobrazuje co v něm vidí v tom neighbor také. Ten nejde nad IP, posílá se na multicast MAC adresu 01:00:0C:CC:CC:CC. Tu bohužel používá řada jiných protokolů, které není vhodné moc blokovat, to je třeba filtrovat asi dle LLC AAAA03 (v RB250GS asi neuděláš). Nicméně HP switche CDP už tak 5 let neposílají, pokud tam nemáš něco historického, před cca 5-ti lety upgrade firmware vysílání CDP odřízl a nadále ho umí jen přijímat a zobrazovat (podobně jako ROS) a vysílají bonz o sobě pomocí normalizovaného LLDP. Ten jede také na MAC muticast adresy, používá jich několik v 01:80:c2:00:00:0x. Tam se nejlépe řeže pomoci ethertype 88CC. To by mohlo jít zaříznot.