Thomson kábel modem DHCP problémák virtualizációnál @ T

Hálózati eszközök

Szeretnék ismét virtualizált routert használni (pfSense), mert hiányoznak az "extra" funkciók, lehetőségek.
De a DHCP-vel megint gondok vannak, úgyhogy a segítségeteket kérném.

Adott egy Thomson TCM470 modem T-Online kábelnethez, ami egy eldobható szintű Belkin routerrel tökéletesen működik:
Először kap egy címet a 192.168.100.1/24 tartományban (modem local subnet),
majd pár másodperccel később lecseréli egy public IP-re (78.*), ami fél éve nem változott.

A host gépről is próbáltam leaselni, kap is egy címet (81.*) valahonnan a 10.*/8 tartományból,
de már nincs net elérés. Gondolom ez egy helyi T-Online DHCP szerver; pingre nem reagál.

Virtualizált pfSense viszont, már egyeltalán nem kap címet. Próbáltam kézzel dhclienttel és semmilyen válasz nincs.
Próbáltam a static 192.168.100.2 címet és a modemet local címmel átjárónak beállítani. Természetesen nem működik.
Bár így a modem már elérhető és egy route felállításával a webui-ja is elérhető a host gépen.

Hátha pfSense bug... Kipróbáltam a Linux alapú IPFire-rel is. Ez első próbálkozásra kapot egy fura 196.* címet (no joy),
majd új setup után már helyi címet kapot (192.168.100.2), vagy megtartotta a static próbálkozásból, de tovább itt se jutottam.

KVM/QUEMU-val virtualizálok, de nem hiszem, hogy a hiba az infrastruktúrában lenne,
mert a modem elérhető a guestekből is, ha static címet használok, csak a DHCP nem akar működni.

Ötletek? :)

  • 8614 megtekintés

( moe | 2013. 06. 27., cs – 09:40 )

Modem áramtalanít, pfsense box rádug, modem áram alá helyez. Miután a modem felállt, lehet IP-t kérni.
Ha nem oldja meg, akkor pfsense box rádug, és szolgáltató felhív.

A probléma az, hogy az NMS 1 db publikus IP-t enged kiosztani. Amíg a lease le nem jár, addig az előző MAC-hez kiosztott IP 'beragad', így nem kap másik eszköz címet erről a modemről.

Meg lehet azt is próbálni, hogy a pfsense box wan lábára klónozod a routered MAC címét.

Legalábbis nálunk ilyen problémák voltak, amikor még ISP-nél dolgoztam.

Kifelejtettem, de próbáltam a router MAC címével is, ill. áramtalanítani is többször.

Az esetleg gond lehet, hogy látja a virtuális interfészt meg az eredeti bridge-t is, ami nincs felkonfigurálva?
Amikor csináltam egy route-ot a modem belső címe és a host gép között, akkora webUI-ra belépve at írja, hogy 2 gépet lát és 2 a maximum.
Ma megpróbálom majd bridge nélkül is, hátha a 2 MAC zavarja.

Nem hiszem, hogy ez lesz a gond, de egy próbát megér.
Esetleg ha van olyan időszak, amikor a végpont nincs használva, akkor huzamosabb ideig (12 óra?) kikapcsolva hagyhatnád a modemet.
De a leggyorsabb a szolgáltató felhívása. Mi ilyen esetekben készségesen segítettünk az ügyfeleknek, szerintem ők is fognak. (Vagy legalábbis illene.)

Nem nagyon van ilyen, csak hajnalban tudom bütykölni. Nem értem, kinek és mire jó ez a zárolósdi.

Az ügyfél szolgálattal nem túl jók a tapasztalataim. Azt se tudják, milyen csomagok érhetőek el a környéken:
25/5-ről akartunk 50/5-re váltani, mert többet fizettünk érte, erre limitelték 20/5-re
és egy hétbe tellet mire kiderítettük, hogy akár a 100+ is beköthető lenne. Ha ma se lesz jó, hátha...

Értem én. De nem jobb lenne a modem MAC címéhez kötni?

Megpróbáltam PCI eszközként bekötni a hálókártyát, amire a modem csatlakozik, de ettől el se indul a VM, mert a host már 'hozzányúl' bootnál és akkor már nem tudja átvenni az irányítást. Régen szívtam ezzel is, úgyhogy nem töltök vele egy egész éjszakát, valószínűleg így se működne. Ehelyett kezdetektől fogva a régi router WAN MAC címét használva macvtap módszerrel passthrough módban kötöttem be a hálót, ha már a bridge nem működött korábban. Ismét kézzel is megnéztem (dhclient) és semmilyen válasz nem érkezett. (Áramtalanítás is volt setup előtt.) Lassan feladom és majd legfelejbb megoldom a host gépen...