PPPoE cisco switchen keresztül

Hálózati eszközök

Következő a felállás:

van egy SOHO router ( 1 db WAN láb, meg 1 db LAN láb)
van 1 Cisco Switch, x db swithcport, 2x VLAN
és van 1 db szolgáltatói modem

szolgáltatói modem portja a Cisco switch fe0/1 portjába dugva (switchport mode Access, VLAN100)
soho router WAN portja Cisco switch fa0/2 portjába dugva (switchport mode Access, VLAN100)
soho router LAN portja Cisco switch fa0/3 portjába dugva (switchport mode Access, VLAN1)

A PPPoe kliens az a soho router.
Ebben a felállásban a PPPOe frame-k (látszólag) nem jutnak el fa0/2 -> fa0/1-ig, folyamatosen auth retry / PADI resend van a rúteren.

Ha direktbe kötöm a soho router WAN portját a szolgáltatói modemmel, akkor meg sikeresen behitelesít a pppoe.

Milyen interface konfig okozhatja ezt a Cisco switchen?

  • 3602 megtekintés

( stra | 2018. 04. 10., k – 23:09 )

A VLAN 100 létezik a VLAN adatbázisban? Ha létezik, akkor nem kellene ilyennek előfordulnia.
Az egyébként látszik, hogy a PADI kimegy a Fa0/1-en? És az látszik, hogy a Fa0/1-en bejön a PADO?

Meg tudtad nézni az interfészek és controllerek számlálóinak változását egy-két próbálkozás idejéig? (PADI: broadcast; PADO: unicast)
A SPAN-t sikerült megvizuálnod?
A Fa0/1-en látsz valamilyen MAC-et? A VLAN 100-ban látsz valamilyen MAC-et?
Bár nagyon triviális, de azért írjuk le, az ethernet teljesen rendben van? A Fa0/1 autonegotiation jó eredménnyel végződött (pl. 100-FD), nincs MDI/MDIX probléma?

( muszi v | 2018. 04. 11., sze – 07:40 )

A szolgaltatoi modemek (ADSL es kabelteves is) tapasztalataim szerint megjegyzik maguknak a legelso MAC cimet, amivel kliens oldalrol talalkoznak, es utana mas MAC-kel nem hajlandoak beszelgetni. Probald igy: 

no spanning-tree vlan 100

interface FastEthernet0/1
 description ADSL
 switchport access vlan 100
 switchport mode access
 no keepalive
 no cdp enable
 spanning-tree portfast

A keepalive-ot inkább ne tiltsa le - ha a keepalive mechanizmus nem működik, akkor legalább az egyik fél interfészének down-ban kell látszania. Az interfészállapot ellenőrzése alap, szóval úgy vélem, az NT-n is világít a LAN LED, és switchen is up-ban van az interface.

A CDP letiltható, mert az NT illeve a DSLAM nem fog CDP-zni, de a probléma szempotjából nem látom relevánsnak. Az STP-re ugyanez vonatkozik.

ADSL NT nem korlátoz MAC alapján. A DSLAM-ban lehet egyidejű korlát, de csak ideiglenes időtartamra, ez maximum néhány perc. De mint ismert, a switch nem nyúl bele a keret forráscímébe, a DSLAM számára switch nélkül, és switchen keresztül is a router WAN ethernet interfészének MAC-je látszik.

Nalam pont ezzel a konfiggal megy sok eve (igaz, a kabelteves nethez kiserleteztem ki), de az ADSL modem sem panaszkodik.

Annak idejen wireshark-kal figyeltem a forgalmat, es amit a switch magatol kuldott, mind letiltottam :-) Javasolnam ugyanezt az OP-nek, akkor valoszinuleg hamarabb kiderul, hogy mi tortenik.

( lajos22 | 2018. 04. 11., sze – 14:03 )

Ennek a felállásnak így mi az értelme, mi haszna?

--
openSUSE 42.2 x86_64

Ezt fentebb kicsit félve én is kérdeztem, de szerintem ha ilyen jellegű kommunikációs problémát keres az ember, az már az első pillantásra feltűnik, ha az interface down-ban van, nem világít a link LED-je, ha a számlálók nullán állnak, ha a logban nem jelenik meg "%LINK-3-UPDOWN" vagy "%LINEPROTO-5-UPDOWN".

Világított a zöld LED.

Viccet félretéve, up/up volt fa0/1 és 0/2 is, auto-100 fdx, és vmi kevés rx/tx forgalmat is láttam (nyilván ez a stat lesz érdekes, mikor újrapróbálom)

Update: miután nem volt szabad gigás switchport, végül direktbe kötve hagytam a rútert és a modemet, nem volt energiám se tovább troubleshootolni. Ha esetleg vki idetalál majd évek múlva, azért megírhatja a megoldást.
--

A nyitó poszt szerint a probléma ugye még a PPPoE indulásánál van, a PADI és PADO szakasznál. Ez L2. Ilyenkor még messze vagyunk bármiféle TCP SYN-től, ami L4. Ha majd felépül a PPPoE, és utána sem menne, akkor lehet MTU-t és MSS-t csökkenteni, de akkor sem a LAN eszközökön, hanem a routeren illene.

Ha már így bedobtad a kérdést:
Cisco-n kívül tudsz még egy gyártót, aki soho pénztárcával megfizethető nem túlzottan szar managelhető switchet gyárt?
Olyat is, amelyik "hw-ből switch-el"?

Pl. gyanítom ubnt termékeknél elég erős üvegnyakak vannak belül az architektúrában... legalábbis a mindenféle sheetjeiket böngészve.
A HP kiesik a "nem szar" feltétel mentén.
A *link glob-ra illeszkedő nevű gyártók dettó.

Dell-el meg IBM-mel még nem volt dolgom, de gyanítom a "nem szar" mércén max kicsit lehetnek csak a kevésbé szarhoz közelebb a HP-nál. Egyszerűen nem ez a niche ezeknél a cégeknél.

Juniper-nek nem tudok olyan modelljét, ami mondjuk "soho" méretekre lenne becélozva, de ha tudsz ilyet, kiváncsi vagyok rá!
Ha más értelmes gyártót tudsz, arra is!

Mindenki hw-ből switchel ethernet portok között. A leggagyibb soho cuccok is. Egy 8-10 portos gigaswitch-hez 10 évvel ezelőtt is már csak egy chip kellett, 16 porthoz kettő, 24 porthoz 3. Ha jó chipet használnak (a chipek között 10g van), akkor igazából 24 portig nincs szűk keresztmetszet. Fölötte meg nyitni kell a pénztárcát...

Ahol el lehet vérezni, az a menedzsment. De ebben szinte mindenki többé-kevésbé szar (még a Cisco is, csak kevésbé - a Linksys meg Cisco emblémával sem hozta a Cisco színvonalat).

Nekünk vannak soho kategóriás, full menedzselhető TP-Linkjeink (konkrétan TL-SG3109, 5426 és 3216), azok az 'elmegy' kategóriába esnek (és nem utolsó sorban: működnek). Price/performance-ban meg überelhetetlenek. Az SG3109-et konkrétan itthonra is megvettem volna, ha kellett volna bármi itthonra: fémházas, beépített tápos (ennek minden előnyével és hátrányával), ventimentes, "single-chip switching" megoldás, anno adtak rá 5 év garit, de tizenkettő darabból nulla darab hibásodott meg kb. 7-8 év alatt. Bekapcsoltuk, aztán megy. Szoftvert ne akarjál frissíteni, mert az nincs hozzá, csak az, amivel kijött a gyárból... ez mondjuk jól jellemzi a potenciális problémát: ha valami extra feature bugos, igen kicsi az esély, hogy valaha megjavítják.

A Ubiquiti Edgeswitcheket megnézném még, a többi termékük alapján valószínűleg azok is fogyaszthatók.

Otthonra egy használt SG300-at újítottam be. Ha jól rémlik 100font körül volt szállítással. Igaz, akkor még a szomszéd szigeten laktam :)

Kb. elégedett is vagyok vele.

A linksys-ekkel képben vagyok, hogy csak a logó a Cisco rajtuk, a minőség nem annyira.

Ubnt-ből meg, ahogy láttam amik tűrhetően switchelnek, azok vadiújak és kb. drágák.
Otthonra pénztárcabarátabbnak tűnik egy használt Cisco-t nézni, mint ahogy az SG300-al is tettem. Nézegettem pedig az ubnt-ket is. De ahogyan azt írtam is: azokból nem láttam használtpiacon semmit, meg fene tudja azok mennyire állják ki az idő próbáját. Az SG300-nak van egy ocsmány kis külső tápja. De azt leszámítva elégedett vagyok vele.

( ricsip v | 2019. 07. 06., szo – 10:41 )

Up
feldobom, hátha. Időközben lett gigás sokportos switch, szóval megint érdekes lenne a megoldás.
--

Es azzal a switch-el sem megy? Mi a tipusa?

Egy helyen en is hasonlot csinaltam, de egy OpenWRT-s gigabites TP-Link-el oldottam meg a VLAN-okat es a wifit is (az volt keznel) es a router egy pfSense-es 1 portos (router-on-a-stick) vekonykliens volt. Szoval meg cifrabb config es azota is tokeletesen mukodik..

( fairlane | 2019. 07. 06., szo – 13:14 )

Pontos típust, sw verziót megírod?
Hátha közelebb visz a megoldáshoz.

--------------------------------
...úgyis jönnek...

( debtamas88 | 2019. 07. 07., v – 11:35 )

Szia!

Fenti konfig rendben van.
A hibát a szolgáltatónál keresd, MAC-címhez rendelte belépésedet,
Mivel több MAC-címet lát azon a porton, ezért nem enged belépni.

Ennek fussunk már neki még1x, mert nem értem. Ha a modemet egy switch-re kötöm, egy olyan VLAN-ba ahol csak a modem és a rúter WAN lába van, ott honnan fog a modem több MAC cím-et látni, mint amikor a rúter WAN lábát közvetlenül drótozom a modem-be?
Plusz a rúter MAC címet sosem kérték el, rútert is cseréltem a szerződés élesítése óta, nem kellett betelefonálni mielőtt működni kezdett volna az új rúter.
--

En is talalkoztam olyan eszkozzel, amin volt portsecurity es csak az elso MAC-et fogadta el. Ha ujrainditottam az ISP eszkozet csak akkor engedett fel mas eszkozzel. Lehetseges hogy a switched "cseveg" valamit az ISP eszkoze fele es mar kesz is a masik eszkoz blokkolasa. Javaslok egy network TAP-ot az ISP eszkoze es a switch koze, aztan Wireshark!

Azt olvasom, hogy PPPoE esetén nem a szokásos módon működik a MAC address learning, sőt lehet, hogy a Catalyst switchek nem is támogatják:

https://networkengineering.stackexchange.com/questions/35451/pppoe-inte…

Ellenben bekonfigurálhatod a Fa0/1 portot L3 interfésznek, és akkor lehet a switch PPPoE kliens.

L3 nem kell MAC tanulashoz mivel az L2 szint. PPPoE kliens L2 szintu broadcastet kuld (ff:ff:ff:ff:ff:ff) a sajat forras MAC cimevel, amit a switchnek hubkent kell floodolnia (az adott VLAN-ban). Maris megtanulja igy a kliens MAC cimet azon a porton ahonnan feladta az a csomagot. A PPPoE szerver oldal valaszol a sajat MAC cimevel (maris megtanulja a switch melyik porton van a szerver) es a cel MAC cim a kliens MAC cime lesz, amit a switch mar ismer igy csak 1 portra tovabbitja. Es igy tovabb..

Szia!

DIGI-vel volt ugyan ilyen problémám.
Az volt a megoldás, hogy a DIGI hozott egy 8 portos kis switch-et (PSH-2109F), azon keresztűl egyből működött.

Ha közvetlen dugtam a GPON-modembe a kábelt, akkor ugyan azt tapasztaltam mint te, nem jött semmilyen válasz a PPPOE kérésekre.

(ZTE GPON)----(PSH-2109F)----(saját switch)

Szia!

Cisco switchen nem lehet állítani külön tagged/untagged -PVID- módot.
pl.: Egyes szolgáltatóknál így adnak internetet+VOIP-t, az egyik tagged, a másik untagged.

Így visszagondolva, a kimenő kérések untagged - és a PPPOE pedig tagged lehetett, próbáld meg így beállítani a cisco switch-et:

Nem tudom, hogy működik-e:

interface fa0/1
description ISP_modem
switchport mode trunk
switchport trunk native vlan 100

interface fa0/2
description router_WAN
switchport mode trunk
switchport trunk native vlan 100

Ha megvan milyen tagged-el jön a szolgáltató (X):

interface fa0/1
description ISP_modem
switchport mode trunk
switchport trunk native vlan 100
switchport trunk allowed vlan 100,X

interface fa0/2
description router_WAN
switchport mode trunk
switchport trunk native vlan 100
switchport trunk allowed vlan 100,X

:)

Felhasznalonak a sajat halozataban nem szabad talalkozni ISP VLAN-al. Az hogy a szolgaltato VLAN-al oldja meg a sajat halozataban rendben van, de magaban az ISP eszkozeben van a VoIP ATA.

"külön tagged/untagged -PVID"
Ezt nem ertem.
"The PVID of a port is the VLAN id that will be assigned to any untagged frames entering the switch on that port."

Szia!

Itt arra gondoltam, CISCO (Catalyst szériás switcheknél) 1db port vagy tagged (trunk) vagy untagged (access) viszont olyan mód nincs, hogy egyszerre mindkettő - (vagyis a fenti konfiggal tud valamennyire).

Pl.: Van 4db vlan, és azt akarod, hogy 1db porton legyen: 2db tagged-vlan és 2db untagged-vlan.

Itt is ezen szenvednek:

https://www.dslreports.com/forum/r30951496-HELP-Capturing-Traffic-in-Ci…

A javaslat az, hogy trunk-öt kell konfigurálni a modem és a switch, valamint a switch és a SOHO router WAN interfésze között. A LAN interfészt és a klienseket pedig betenni egy VLAN-ba. De nem végződött [SOLVED]-del...

En ezt beallitas hibanak gondolom, egyaltalan nem bonyolult dolog.

Rakj egy szappantartot LAN porttal az ONT helyere! Figyelj ra, hogy mas legyen a tartomany, mint ami a masik oldali routeren van (belul). Allitsd DHCP-re azon a WAN portot!

WAN porton meg kell jelennie a szappantarto DHCP-je altal osztott cimnek. Ha ez nem jelenik meg, akkor nincs ertelme itt PPPoE-rol beszelgetni..

Masik:
Az ONT-nek is van alap IP cime, amit tipusa alapjan meg tudsz keresni. Tehat a router helyere raksz egy gepet, berakod ebbe a tartomanyba. Elobb direkten kotve pingeled, utana sw VLAN-on keresztul.

Továbbra se értem, ezzel a szappantartó performansszal mit akarsz megvalósítani? A rúter nem-PPPOE típusú (máshogy mondva: WAN TYPE== szimpla dynamic v. szimpla static IP) internetet tudott a switchen keresztül használni korábban. Ha rákötök a WAN portjára egy másik (legyen mondjuk tplink) rútert, akkor annyi fog történni, hogy a tplinktől dhcp-n fog kapni a WAN interfész egy olyan IP-t, amilyet a tplink oszt neki. És akkor nem lettünk előrébb semmivel. Mert ilyen erővel nekem egy pppoe szimulátort kéne a rúterem WAN portjára kötni.
--

Azt akarom elerni, hogy probald ki hogy egyaltalan most megy-e a rendszer, mert amikor ilyen jellegu hibakhoz hivnak, akkor ezzel kezdem. En is ismerem a "de hat mukodott" anekdotakat es 90%-ban tevesnek bizonyulnak. Egyebkent Mikrotik RouterOS tud PPPoE server lenni, mielott kikuldok egy adag routert videkre, elotte elkerem az ISP belepesi adatait es letesztelek mindent. Kitalalhatod hany %-ban "talaljak el" rendszegazdak a sajat internetjuk hozzaferesi adatait..

( fairlane | 2019. 07. 11., cs – 00:20 )

GNS3-ban összeraktam az adott konfigot.
PPPoE szerver és a PPPoE kliens egy-egy Mikrotik CHR volt, a switch pedig egy IOU (IOS-On-Unix) 15.0.b verzióval.

Elsőre direktbe kötöttem a két mikrotik-ot, a kapcsolat felépült.
Másodikra közberaktam a switchet, de nem konfiguráltam külön vlanokat, csak az 1-es volt. A kapcsolat így felépült.
Harmadikra az eredeti felállást állítottam be, a 2 mikrotik közötti switchportok access módban és a 100 VLAN-ban szerepeltek. A Kapcsolat így is felépült.

Mindegyik esetben ment a wireshark, PADI/PADO szépen összefütyült.

Ezek alapján a koncepció jó szerintem.

Ahogy tovább lehetne haladni, az az lenne, ha TAP-et raksz be a modem és a switch közé (előttem már említették), vagy pedig SPAN a 100-as VLAN-ra és megnézed, hogy mi történik.

--------------------------------
...úgyis jönnek...