-
PROHARDVER!
Haladó szintű hálózati témák topikja
Új hozzászólás Aktív témák
-
#13069
E.Kaufmann
veterán
E.Kaufmann
veterán
Szerintetek mi a fenének akarja egy weboldalkészítő, hogy átirányítsak egy domain nevet teljesen az ő szerverükre (NS rekordok átírása)? Üzentem neki, hogy levelezés miatt nem igazán passzolnám át, de ha megadja, hogy milyen rekordok kellenek (azon kívül) neki, beállítom.
-
#13067
SutPet
aktív tag
MasterMark
#13066
SutPet
aktív tag
válasz
MasterMark
#13066
üzenetére
dynu ddns ad ingyen anno ezt keztem el használni aztán sose volt vele gond de úgy látom mástól vásárol domainnel hiába elvileg működnie kellene nem akarja az igazat
-
#13066
MasterMark
titán
SutPet
#13065
MasterMark
titán
válasz
SutPet
#13065
üzenetére
Ha nem találja a domain-t, akkor cname-et se fogja megtalálni.
Milyen DNS szervertől kérdezted le? Próbáld az 1.1.1.1 vagy 8.8.8.8, azok hamarabb frissülnek általában.
Én azt se értem mi ez a dynu és miért ezzel "szenvedsz".
Cloudflare domain kezelés ingyen van és jól működik. -
#13065
SutPet
aktív tag
MasterMark
#13064
SutPet
aktív tag
válasz
MasterMark
#13064
üzenetére
Letelt az 1 nap sőt 2 is. domain kezelő jelzi hogy átvan állítva a névszerver ,de nslookup nem talál ilyen domaint. de lehet mindjárt megunom az ezzel való b*szakodás és beállítok egy cname-et a ddns-es domainre aztán levan tojva.
-
SutPet
aktív tag
Sziasztok, nem biztos hogy jó hely de talán ide illik a legjobban ez a hálózatos kérdésem.
dynu-t használok egy jó ideje de akartam valami saját domaint amit meg is vettem. Elméletileg annyi kell hogy névszervernek a dynu névszervereit állítsam be a regisztrátornál amit meg is tettem, ennek ellenér nem érhető el. A korábbi dynus domain megy, ahogy felvettem a domaint az látszik is a domainek között, ddns updater frissíti is rendesen, ennek ellenére nem elérhető a .hu-s domainen keresztül. Bármi ötlet mit nézzek meg esetleg? -
Reggie0
félisten
válasz
bambano
#13061
üzenetére
Nem tehetek rola, ha nem erted az adat masolas, data pipe es az ethernet switch kozotti osszefuggeseket. Tovabbra sem irtam azt, hogy ethernet switch lenne a prociban, akarhogy is erolteted felremagyarazni. Majd egyszer olvass utana, hogy milyen reszegysegekbol epul fel egy ethernet switch chip, hatha rajosz, mi is lehet a fontos.
-
bambano
titán
válasz
Reggie0
#13060
üzenetére
Ezt te írtad, ezzel kezdődött a tilera-s subthread: "Nem feltetlen. Nalam pl. az a lenyege, hogy nem kellett 2.5 gigas port a NAS-hoz, bamivel megvan a 2 gigabit. CCR1009 eszrevehetetlen overheaddel tudja a round robint, a linuxnak meg nem gond."
A téma egyértelműen ethernet switch volt, te felhoztad a tilera-t, amiben NINCS ETHERNET SWITCH. Az, hogy processzor-interconnect van benne, az a 2.5 gigás ethernet témakörben IRRELEVÁNS.
A magam részéről hanyagolom ezt a subthreadet a továbbiakban akkor is, a megint tévedést írsz.
-
#13057
mrots
junior tag
E.Kaufmann
#13051
mrots
junior tag
válasz
E.Kaufmann
#13051
üzenetére
"De a DNS szerver címnek milyen esetben nem lesz jó a link-local cím? Pont ez lenne a kérdés."
En ket okot tudok elkepzelni. Az egyik, hogy a link local cimed csak ugy hagyod, hogy legyen. Ekkor ugye a prefix az adott, a suffix viszont generalt. Ez a generalas tulajdonkeppen determinisztikus tehat kb mindig ugyanazt generalja, azaz lehet ra fixkent tekinteni, de nincs ra garancia. Ha barmilyen okbol a hoszt masik ID-t general maganak, akkor valtozik a link local cime, tehat nem hasznalhato DNS szervernek amig mindenki nem tudja az uj link local. cimet. Ha kezzel fixen adsz neki ipv6 cimet, akkor mindegy, nem fog valtozni.
A masik ok:
"Valamint van több alhálóm"A link local cim csak a subneten belul egyedi, a routerek nem tovabbitjak a link local cimekre kuldott csomagokat, azaz masik alhalozatbol a link local cimen a dns szervered nem lesz elerheto.
A fentieken tulmenoen termeszetesen a DNS konfiguralasanal is varnak csapdak, peldaul ha nem interfeszre, hanem IP cimre bind-oltatod a DNS-t, akkor valtozo IP cimnel a konfigot is modositani kell. Ha IPv6 lekerdezeseket kell inditania a DNS szervernek kifele, akkor link local cimrol nem tudja inditani, kell hozza valodi cim, ha pedig van valodi cim, akar hasznalhatnad azt is belulrol. Persze az is lehet, hogy a kereseket mar v4-en inditod kifele, elvegre miert ne lehetne v6 dns rekordokat v4 kapcsolaton at lekerdezni.
-
#13054
MasterMark
titán
E.Kaufmann
#13053
MasterMark
titán
válasz
E.Kaufmann
#13053
üzenetére
Tűzfalban ki tudod wildcardozni jó esetben a network prefixet, ha arra kell.
-
#13053
E.Kaufmann
veterán
MasterMark
#13052
E.Kaufmann
veterán
válasz
MasterMark
#13052
üzenetére
Na a dinamikus cserélgetés a másik. Így csak a DHCP klienshez kell egy scriptet rögzíteni, ami átírja a netmap szabályokat, de miért kell ezt is cserélgetni
-
#13052
MasterMark
titán
E.Kaufmann
#13051
MasterMark
titán
válasz
E.Kaufmann
#13051
üzenetére
Nem magával az eléréssel lehet gond, hanem inkább kliens oldalon ha azt mondja egy kliens hogy nem fogja használni, mert nem tetszik neki.
Amúgy is prefix translation-t csinálok.
Minek?
szerk.: Ja értem, az hogy a szolgáltató /64-et ad, az egy hibás implementáció. De amúgy az is, ha dinamikusan cserélgetik a prefixet.
-
#13051
E.Kaufmann
veterán
MasterMark
#13050
E.Kaufmann
veterán
válasz
MasterMark
#13050
üzenetére
De a DNS szerver címnek milyen esetben nem lesz jó a link-local cím? Pont ez lenne a kérdés.
Ha az átjáró lehet LL, akkor a DNS szervernek milyen esetben lehet probléma az LL, ha ott van azon az alhálón (mert ugye ő a router is)?IPv6 NAT. Mindenkinek megvan a saját perverziója, másnak a BDSM, nekem meg ez
![;]](//cdn.rios.hu/dl/s/v1.gif)
és még az asszonyt se zavarja 
Amúgy is prefix translation-t csinálok. Valamint van több alhálóm és a szolgáltató meg sóher és csak /64-et ad. Na ilyenkor mit lehet csinálni? -
#13050
MasterMark
titán
E.Kaufmann
#13049
MasterMark
titán
válasz
E.Kaufmann
#13049
üzenetére
Teljesen jól értettem mit csinálsz, pont ezt mondom, hogy nem jó így.
Működni működik, csak nem egészséges. Ahogy az sem hogy NAT-olod a globális címet, hiszen pont azért van az IPv6, hogy ne legyen NAT.
Nem tudom mi a cél, ha csak annyi, hogy működjön akkor jóvanazúgy. Ha az hogy normális IPv6-ot építs ki, akkor nem jó.
-
#13049
E.Kaufmann
veterán
MasterMark
#13048
E.Kaufmann
veterán
válasz
MasterMark
#13048
üzenetére
Akkor nem értjük egymást.
Van globális címtartomány (db8-as mert NAT-olom )
Az a kérdés, hogy a kliensek felé jó ha a router (ami a DNS szerver is) LL címe van hirdetve DNS-nek vagy van olyan helyzet, mikor nem egészséges?Amúgy a Kame teki bólogat, a vatizmájájpí oldalak mutatják a publikus IPv6 címet és a gugli szerint is ok a v6-om.
-
#13048
MasterMark
titán
E.Kaufmann
#13047
MasterMark
titán
válasz
E.Kaufmann
#13047
üzenetére
Link-local címet csak interfész azonosítval lehet elérni, mert nem routeolható cím, azaz nem lehet rá routingot állítani a gépen se, hogy merre fele keresse. Ez teljesen normális.
Kiosztani ne ossz ki link-local címet. A global címet oszd ki amit a router interfésze kapott. A host része legyen fixálva csak.
-
#13047
E.Kaufmann
veterán
E.Kaufmann
veterán
IPv6 kérdés.
Jó-e az, ha a DNS szerver is a link-local címén van meghirdetve (a router továbbítja a kéréseket), vagy lehet-e gond belőle (pl valamilyen VPN kliens esetén vagy más speciális esetben, mikor nem a router az átjáró).
A RouterOS-ben már lehet egyedi link-local címet adni, úgyhogy a belső lábakra az fe80::1 lett címkézve és ezt használnám DNS szerver címeként is a kliensek felé hirdetve.Úgy néz ki, a Windows odabiggyeszti az interfész azonosítót a DNS szerver címéhez.
-
#13046
bambano
titán
ArthurShelby
#13044
bambano
titán
válasz
ArthurShelby
#13044
üzenetére
Emlékeim szerint a dhcp discover az ethernet broadcast címre megy.
-
#13045
MasterMark
titán
ArthurShelby
#13044
MasterMark
titán
válasz
ArthurShelby
#13044
üzenetére
Itt van példa pcap: [link]
De akár egy igazit is megnézhetsz.
-
#13044
ArthurShelby
addikt
MasterMark
#13043
ArthurShelby
addikt
válasz
MasterMark
#13043
üzenetére
A MAC az layer 2. A dhcp üzenetek layer 4 és udp (ha jól tudom).
-
#13043
MasterMark
titán
ArthurShelby
#13041
MasterMark
titán
válasz
ArthurShelby
#13041
üzenetére
Csak a discover broadcast, a többi az unicast. (MAC cím alapon ugye.)
-
Köszi!
-
#13041
ArthurShelby
addikt
ArthurShelby
addikt
Hirtelen sok kérdésem lett a DHCP-vel kapcsolatban.
1. Ha 50%-nál kap a kliens egy NAK-ot, akkor egyből elkezd új ip-t kérni (DHCPOFFER), vagy még tovább vár és próbálkozik 87,5%-nál? (sejtésem szerint előbbi)
2. Mikor broadcast egy DHCP üzenet? Megújításkor a 4 lépésból (discover, offer, request, ack) az utolsó 2-t újra játssza (request, ack).
Mikor elsőre kér ip-t, akkor minden üzenet broadcast (mind a 4), de a megújítás már unicast (vagy az is broadcast)?3. Melyik üzenet megy az 255.255.255.255 (FFFFFFFF), és melyik a hálózat broadcast címén?
Az előbbit minden switch átenged, vagy nem (DHCP realy agent ezért kell?)? Ez úgy jött szóba nálam, hogy ha relay agent van, akkor unicast már a második lépésben. [link] -
#13040
mrots
junior tag
ArthurShelby
#13038
mrots
junior tag
válasz
ArthurShelby
#13038
üzenetére
SCTP es RSVP ami hirtelen beugik es talan elterjedtebb, a QUIC-et mar irta mas. De amugy lenyegeben ja, a tcp es az udp kabe lefedi az egesz internet forgalmat.
-
#13039
MasterMark
titán
ArthurShelby
#13038
MasterMark
titán
válasz
ArthurShelby
#13038
üzenetére
QUIC van ami még terjed a HTTP/3-mal. (Sajnos.
) -
#13038
ArthurShelby
addikt
ArthurShelby
addikt
A 4-es rétegben (osi modell) UDP-n és TCP-n kívül a gyakorlatban normális halandók használnak más protokollokat is, vagy csak ezt a 2-t?
-
mrots
junior tag
Az RFC is jol leirja, de a logika is ugyanarra jut. Amikor nincs IP cimed, akkor discover uzenetet kuld a kliens, mert nincs mit megujitani, kerni kell, raadasul azt sem tudja ki/mi fog neki IP cimet adni, fog-e egyatalan.
Mikor megkapta a cimet, utana hasznalja. Amikor letelt az ido, akkor nem discover, hanem request uzenetet kuld, amiben azonositja magat, benne van az IP cim is, amije van. Amennyiben erre egy ACK uzenetet kap, akkor hasznalhatja tovabb az uj idotartamig. Ha NAK uzenetet kap, akkor uj IP cimet kell kernie.
ACK eseten a folyamat transzparens, a vegfelhasznalo nem vesz eszre semmit. NAK eseten a megujitas is lenyegeben azonnal lejatszodik, tehat kieses a halozati forgalomban nem igazan lesz, ugyanakkor TCP session-ok meg fognak szakadni, hiszen hirtelen az egyik vegpont egy uj IP cimrol kezd el kommunikalni, amihez nincs felepitett session, nem volt hozza handshake. UDP forgalom elvileg nem szakad, nem akad, ugyanakkor az alkalmazas a protokoll felett fennakadhat azon, hogy miert van most hirtelen masik IP cim.
Magyarul a valasz a kerdesedre, hogy ha ugyanaz a cimet megtarthatja (ACK) akkor nem szunik meg semmi, nincs kieses, nem dob el semmit amig nem kotelezik ra (NAK).
-
#13033
DroiDMester
nagyúr
MasterMark
#13031
válasz
MasterMark
#13031
üzenetére
köszi az infót beállítottam őket, majd tesztelem!
-
Köszönöm a válaszokat!
-
#13031
MasterMark
titán
DroiDMester
#13024
MasterMark
titán
válasz
DroiDMester
#13024
üzenetére
LACP / 802.3ad ahogy mondtam... Ott van a switchen a listában az LACP, a nason meg a 802.3ad az ugyanaz.
-
Magnat
veterán
válasz
Gyurka6
#13027
üzenetére
ChatGpt szerint:
DHCP lease mechanizmusa:
Lease időszak kezdete – A DHCP kliens egy adott időtartamra (lease time) kap egy IP-címet a szervertől.
T1 idő (50% eltelte után) – A kliens elkezdi megújítani a bérletét az aktuális DHCP szervernél. Ha sikerül, a lease idő nullázódik és folytatja a használatot.
T2 idő (87,5% eltelte után) – Ha az első próbálkozás sikertelen volt, a kliens más DHCP szervereket is keres, hogy meghosszabbítsa a lease-t.
Lease lejárata – Ha a kliens nem tudta megújítani a bérletet, akkor az IP-címe érvénytelen lesz, és egy új címet kell kérnie a teljes DHCP-kiosztási folyamaton keresztül. -
uzerto
tag
Sziasztok!
Ide írok, hátha tudtok segíteni. Sajnos nem értek túlzottan a hálózatokhoz, de hátha tudtok segíteni, hogy merre tapogatózzak.
Van egy kis céges hálózatunk kiépítve, amin keresztül el tudjuk érni a fájlszerverünket. Ezt a hálózatot csak a benti számítógépek érik el. Ahhoz, hogy valaki otthonról is tudjon csatlakozni távoli asztallal a benti gépekre, illetve otthonról is el lehessen érni a fájlszervert (sok túlóra miatt) kaptunk egy-egy névre szóló config fájlt amit a WireGuard-ba betötve hozzáférünk a első hálózathoz (egyszerre mindenki csak egy eszközön használhatja). Eddig minden rendben is ment, de a hétvégén alaplapot kellett cseréljek. Az alaplap csere óta viszont nem tudom életre lehelni a kapcsolatot (pedig a hozzáférés nem géphez kötött, bármilyen gépről használhatnám a névre szóló konfig fájlt, csak az a lényeg, hogy egyszerre egy gépen fusson). Először tűzfal problémára gondoltam, de hiába adom a kivtelekhez, hiába tiltom a tűzfalat nem változik semmi.
Van esetleg valakinek ötlete merre induljak el?
Előre is köszönöm a segítséget. -
A DHCP-ről lenne kérdésem: Amikor lejár a bérleti idő, akkor
elkezdi megkeresni a dhcp-szervert, és új címet kér magának. Eközben megtartja a régi címét, vagy egyből eldobja, és megszűnik létezni a többi gép számára? -
#13024
DroiDMester
nagyúr
Patice
#13023
válasz
Patice
#13023
üzenetére
hát ebből nekem nemigazán derül ki hogy mi lenne a jó, és a switch-et mire állítsam!
Switch User Manual - Important Notes
Technical Parameters
I/O Interface
Power: DC 2.1
Ethernet Ports: 8 * 100/1000/2500M RJ45 ports, 1 * 10G SFP+ port
Performance
Bandwidth: 60Gbps
Packet Forwarding Rate: 44.64Mpps
Package Cache: 8Mbit
VLAN: VLAN range 1-4094, max active VLANs 31
MAC Address Table: 4K
Jumbo Frame: 16356 bytes
Forwarding Mode: Store and Forward
Network Parameter
Network Protocols: IEEE802.3 (Ethernet), IEEE802.3u (Fast Ethernet), IEEE802.3ab (Gigabit Ethernet), IEEE 802.3bz (5G Ethernet), IEEE 802.3z (Gigabit Ethernet), IEEE 802.3ae (10G Ethernet), IEEE802.3x (Flow control)
Industry Standard: EMS: EN61000-4-2 (ESD), EN61000-4-5 (Surge)
Network Medium: 10Base-T, 100Base-TX, 1000Base-TX, SFP Medium
Certification
Safety Certification: CE, FCC, RoHS
Environmental Standard
Working Environment: Operating temperature -10~50°C, Operating humidity 10%~90%
Storage Environment: Storage temperature -40~70°C, Storage humidity 5%~95%
Functional Indication
PWR (Power Indicator): On - Powered on, Off - Powered off
SYS: Flashing - System startup, Lighting - System Running
Port 1-8: Green On - 2.5G Link connect normal, Yellow On - 10/100/1000M Link connect normal, Off - Link off, Flashing - Data transmitting
Port 9: Green On - 10G Link connect normal, Off - Link off, Flashing - Data transmitting
Reset: Long press for 6 seconds to Factory reset
L2 Function
Port Switch, Port Speed, Port Duplex, Port Flow Control, Jumbo Frames (Up to 16356 bytes), EEE
Link Aggregation: Static Group, Up to 2 groups, Max. 4 members per group
Storm Control: Broadcast, Unknown Multicast, Unknown Unicast
Port Mirroring, Port Security: MAC Address Constraints, Port Isolation, Port Rate-limit
Loopback Detection, VLAN: Access/Trunk/Hybrid, Configurable VID from 1 - 4094, Max. 31 static VLAN groups
MAC Address: Dynamic Address, Static Address
Spanning Tree Protocol: STP/RSTP, Edge Port
Multicast: IGMP Snooping, IGMP V1/V2, Router Port, Static IGMP Join
QoS: Traffic classification based, Strict priority and WRR, Port Priority, Supports up to 8 queues per port
Services
Access Protocol: HTTP
Diagnostics: Port Statistics
Management
Manager Access: HTTP
Manager IP: Static Address, DHCP Client
User, Firmware: Firmware Upgrade
Configuration: Upload and Download, Save, Restart, Factory Defaults
Standards Compliance
IEEE 802.3x flow control and back pressure
IEEE 802.1D Spanning Tree Protocol
IEEE 802.1w Rapid Spanning Tree Protocol
IEEE 802.1Q VLAN tagging
RFC 768 UDP, RFC 791 IP, RFC 792 ICMP, RFC 2068 HTTP, RFC 1112 IGMP v1, RFC 2236 IGMP v2
-
#13023
Patice
nagyúr
DroiDMester
#13022
Patice
nagyúr
válasz
DroiDMester
#13022
üzenetére
Szerintem a korábbi kommentek alapján adja magát, hogy mit tudsz kiválasztani, azt, amit a switch is támogat.
-
#13022
DroiDMester
nagyúr
Reggie0
#13012
válasz
Reggie0
#13012
üzenetére
a Switch egy kínai AMPCOM 2.5GbE
a NAS egy Asustor LOCKERSTOR 4 Gen2 AS6704T 2.db 2,5 gigabites Ethernet portal
ennyi van a linkhez
7-8.as portot linkeltem össze, ide van 2 kábellal kötve a NAS
és így mutatja az infónál
-
Reggie0
félisten
válasz
bambano
#13019
üzenetére
Raadasul eleg sok celhardveres networking tamogatasa is van a sok magon kivul, igy a bitlapatolas sem terheli annyira. A round-robin terheleselosztast szerintem csak packetenkent egy bit billegtetesevel elintez, a tobbi megy hardverbol a switch engine altal.
Raadasul a procis megoldasoknal sokszor a switch chip es proci kozotti savszel is szuk keresztmetszet, igy ha valamit procibol kell megoldani, akkor mar azonnal bottleneck lesz a belso interfesz altal.
-
bambano
titán
válasz
Reggie0
#13018
üzenetére
Az első generációs ccr-eket úgy szoktuk hívni, hogy dinnye, mert annyi mag van benne. A 1009-esben 9, és ez felmegy 72-ig, ráadásul az órajelük sem kevés.
Amit egy rendesebb pc vagy egy dinnye elvisel prociból, abba egy sima router beleszakad. A switchek dettó, vannak switchek, amik az ad-t tudják hardverből, a roudrobint meg prociból, csak az nincs bennük.
-
#13018
Reggie0
félisten
MasterMark
#13017
Reggie0
félisten
válasz
MasterMark
#13017
üzenetére
Igen, mindket iranyban.
Az 1G-s portok szinte ingyen vannak es olcso 1g-s usb-s adapterrel lehet boviteni szinte barmit. A router meg tudja ezt alapbol, szoval ez volt a legolcsobb megoldas. Meg igazabol a HDD-knek mindegy, hogy 2 vagy 2.5 giga, mert csak olyan 2-ot tudnak nagyjabol.
-
#13016
Reggie0
félisten
MasterMark
#13015
Reggie0
félisten
válasz
MasterMark
#13015
üzenetére
Nem feltetlen. Nalam pl. az a lenyege, hogy nem kellett 2.5 gigas port a NAS-hoz, bamivel megvan a 2 gigabit. CCR1009 eszrevehetetlen overheaddel tudja a round robint, a linuxnak meg nem gond.
Meg ugye a masik problema ezzel a XOR-os modszerrel(vagy 802.3ad-vel), hogy 3 kapcsolat eseten legjobb esetben is 2x500 es 1x1000-res kapcsolat lesz, de ha szerencsetlenul jonnek ki a bitek, akkor 3x333-as, mig round-robinnal 3x666-ra oszik, ha minden kliens teljesen kihajtana es egyforma prioritasuak.
-
#13015
MasterMark
titán
Reggie0
#13014
MasterMark
titán
válasz
Reggie0
#13014
üzenetére
Mind a kétféleképpen be lehet állítani az LACP-t is. Azért jó, mert elég csak egyoldalt beállítani, a másik oldal pedig alkalmazkodik hozzá.
Ennek a link aggregationnak meg a lényege inkább a több kliens egyidejű kiszolgálása, mint az, hogy egy kliens legyen gyorsabb. Bár adott körülmények között akár működhet, pl. SMB multichannel.
-
#13014
Reggie0
félisten
MasterMark
#13013
Reggie0
félisten
válasz
MasterMark
#13013
üzenetére
Hat azert ez nem nyilvanvalo. A 802.3ad rosszabb, mint a round-robin, hasonloan mukodik mint a xor, azaz a mac cim/ip cim es ip port alapjan kalulalja, hogy melyik linkre terelje a forgalmat. Azaz sosem lesz 2x1 gb-bol 2 gigabit egy aggregalt linken, ha peldanak okaert csak egy tcp kapcsolatot kell kiszolgalni maximalis savszelen.
A round-robin sokkal jobb, mert ott a ket port kozott felvaltva kuldi a csomagokat, azaz egyetlen kapcsolattal is tudja a 2 gigabitet. Viszont nem szabvanyos, kevesebb cucc tudja es ezt foleg szoftverbol szoktak megoldani, a hardveres tamogatas riktabb. Valamint csak akkor mukodik jol, ha a linkek kesleltetese egyforma, kulonben tcp-nel torlodast es retransmittet okoz.
-
#13013
MasterMark
titán
DroiDMester
#13011
MasterMark
titán
válasz
DroiDMester
#13011
üzenetére
802.3ad/LACP mind a két oldalra nyilván.
Az összes többi arra van, hogy ha az egyik oldal nem támogatja a link aggregation-t.
Ha a switch nem tudja, akkor csak egy irányba lesz kiszolgálva a többlet sávszél, ott érdekes hogy ezek közül mit választasz. -
#13012
Reggie0
félisten
DroiDMester
#13011
Reggie0
félisten
válasz
DroiDMester
#13011
üzenetére
Attol fugg, hogy mit tamogat(es milyen eszkoz az, hw-bol vagy sw-bol tamogatja) a masik oldal es hogy kozvetlen-e a link.
-
#13011
DroiDMester
nagyúr
sziasztok!
Mire érdemes ezek közül állítani a portokat Link Aggregation esetén, ha azt szeretném hogy stabilabb és gyorsabb legyen kapcsolat!
illetve amire csatlakozik SWITCH-en(Menedzselhető) kell e valamit állítani, mindha ott is láttam volna Aggregation ra vonatkozó beállításokat
Bocsi a sok kérdésért, de ilyen hálózati beállításokban nagyon nem vagyok jártas
-
#13009
garga01
őstag
MasterMark
#13008
garga01
őstag
válasz
MasterMark
#13008
üzenetére
Szuper, köszi sikerült. Van dyndns-em is (loseyorip.com) úgy is megy, csak a Chrome szerint burtál veszélyes
Gondolom a domainen keresztül sok az adathalász bejelentés... -
#13008
MasterMark
titán
garga01
#13007
-
garga01
őstag
Sziasztok!
Remélem jó helyen járok. Van egy Rasbperry-m amire NUT-ot (Network UPS Tools) telepítettem. Ez kiolvassa a szünetmentes adatait és egy weblapon elérhetővé teszi a Rasberry IP-címén. Az RPI-nek fix IP-je van a hálózaton.
A kérdésem az, ezt az oldalt hogy tudom megoldani, hogy kívülről elérhető legyen egy adott porton?
Azért nem triviális (nekem) a kérdés, mert az elrési út így néz ki a belső hálón:<rasberryip>/cgi-bin/nut/upsstats.cgi
Ezt hogy tudom kinyitni kifelé? A routerem egy Fritzbox 7590, a szokásos port nyitós beállítások vannak. Vagy az RPI-n kellene vmit konfigolni?
-
bambano
titán
válasz
MrSealRD
#13004
üzenetére
Egyrészt 5 méteren 200 megabitre nagyjából mindegy, ami a hangfaldrótnál komolyabb, az jó.
Másrészt én kipróbálnám a helyedben, nem nagy költség, nem jön be, akkor van egy felesleges kábeled. A lapos kábelt sem engednék ki a piacra, ha alapvetően nem lenne jó.
A kábelen egyébként gigabites moduláció fog menni, tehát ha a kábel nem jó, akkor sok hibát fogsz látni egyszerre. -
MrSealRD
veterán
Sziasztok!
Mi a vélemény a lapos ethernet kábelekről? Kicsit gondban vagyok. Van egy Yetteles Otthonnet előfizetésem. A jelenlegi helyén nagyon gatya sebességet produkál. Áthelyezve egy megfelelőbb helyre 200/14 Mbps megvan. Amivel már reálisan át tudná hidalni azokat az eseteket amikor kiesik a UPC/Vodafone/One kábeles vonal. (Sajnos többször van rá példa mint szeretném, ezért van backupnak a Yettel)
A lényeg, hogy az áthelyezés következtében egy kicsit kanyargós útvonalon, de a szegényléc mentén el tudnám vezetni a kábelt, és 5m-es hosszúsággal pont kijön a matek. De jelenleg csak S/FTP kábeleim vannak itthon... Korbácsolni meg ugrálókötélnek tökéletes, de ide most valami hajlékony formátum kellene... Ráadásul vékony, vagy lehetőleg lapos, hogy minél kevésbé legyen feltűnő. Ezért lesz fehér a színe. Fontos lenne, hogy kevésbé legyen alkalmas arra, hogy ingerelje a 2 éves kisfiam... Szóval több oka van, hogy a lapos és/vagy vékony kábel megoldást keresem. Ugyanakkor azt sem szeretném ha érzékeny lenne a zavarokra és nem lenne megfelelő minőségű a kapcsolat emiatt.
Mit gondoltok?
-
#13001
Balinov
titán
MasterMark
#13000
Balinov
titán
válasz
MasterMark
#13000
üzenetére
Valszeg igaz, bár nekem ilyen tudásom nincs, remélem a 10eves kisfiamnak sem
![;]](http://cdn.rios.hu/dl/s/v1.gif)
és még az asszonyt se zavarja 
Új hozzászólás Aktív témák
krealon- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- AMD Catalyst™ driverek topikja
- Viccrovat
- Milyen légkondit a lakásba?
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Elden Ring
- Autós topik
- One otthoni szolgáltatások (TV, internet, telefon)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Egyéni arckép 2. lépés: ARCKÉPSZERKESZTŐ
- További aktív témák...
- Kèszen állsz a játèkra? 0% THM rèszletre is!
- BESZÁMÍTÁS! MSI B450M R5 5600X 32GB DDR4 512GB SSD RTX 3060 12GB Rampage SHIVA Zalman 600W
- Gyors, Precíz, Megbízható TELEFONSZERVIZ, amire számíthatsz! Akár 1 órán belül
- LG K61 128GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! Dell Vostro 15 3558 - i5-5GEN I 4GB I 500GB I 15,6" HD I HDMI I Cam I W10 I Garancia!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest