Gbit ethernet signaal omschakelen tussen 2 uitgangen

Hi allen,

Ik heb een toepassing waarvoor ik meerdere ethernetkabels met 1 druk op de knop fysiek wil kunnen ompatchen tussen twee poorten.
De toepassing is dat als de actieve switch het niet meer goed doet ik eenvoudig en heel snel kan omschakelen door op 1 knop te drukken.

Daarom denk ik zelf aan meerdere relais die omschakelen. Het probleem wat ik voorzie is dat de HF signalen niet fijn door relais gaan, hooguit door hele dure HF relais en dat is niet de bedoeling want ik moet maar liefst 24 poorten in 1 x kunnen omschakelen.
Relais zijn mijns inziens ook fijn omdat er, als de spanning volledig afvalt, nog altijd signaal zal worden doorgeschakeld naar de in ruststand aangesloten output.

Het doel is dat ik 24 RJ-45 op 1 rij op een print heb zitten waarin patchkabels zitten en aan de andere kant 48 RJ-45 connectoren heb met daarin een uitsplitsing van de kabels die zowel naar Switch A als Switch B lopen.

Heeft iemand ideeën / ervaring hierin?

Sine

Moderator

Dat is een aparte manier van aanpak.

Normaalgezien als je zoiets redundant wilt bouwen neem je twee (of meer) switchen die je al dan niet in een ringetje hangt.

De hosts hebben dan twee ethernet interfaces waarvan elke koppelt met een andere switch.

-edit-

Maar dat wist je al zo te zien, waarom hardwarematig omschakelen?

[Bericht gewijzigd door Sine op 13 februari 2017 15:24:51 (13%)]

Als je een nette print maakt, en geen al te lange kabels aan de connectoren hebt hangen kun je prima wegkomen met gewone relais in een 1000BASE-T verbinding.

Ik vraag me wel af welk probleem je hiermee denkt op te lossen...

Ik ben helemaal akkoord met @Sine: natuurlijk willen we SPOF's (single point of failure) vermijden, maar jij wilt er juist eentje toevoegen. Niet goed bezig! Inderdaad veel beter om aan elke kritische deelnemer twee netwerkinterfaces te geven, die elk naar een aparte switch connecteren. Spanning tree wordt dan misschien wel spannend...

Wat zeg je? Heb je deelnemers die maar één interface kunnen hebben? Die zijn dan sowieso niet geschikt voor in een superkritische omgeving. Dumpen. Geen compromissen, vroeg of laat ga je je die beklagen.

hoe beter de vraag geschreven, zoveel te meer kans op goed antwoord

Er is een reden dat zoiets niet bestaat. Het is namelijk minder bedrijfszeker dan het probleem dat je ermee denkt op te lossen.

Mijn echte naam: Joris | Mijn elektronica website: Fuzzcraft.com

Ik zou het niet met mechanische relays opbouwen, voor dit soort toepassingen maakt TI een IC TS3L501E

Mechanische relays introduceren SI problemen.

[Bericht gewijzigd door Blackfin op 13 februari 2017 17:09:05 (14%)]

This is the world we know best, the world of madness

Niet doen, je creeert gewoon een heel onzekere situatie op blijkbaar een belangrijk punt in je netwerk. Niet alleen na weken testen kan je problemen krijgen, maar denk ook aan corrosie, stof, condens etcetera.

Managed switchen hebben hier allerlei truukjes voor ingebouwd, bijvoorbeeld 'EtherChannel' waarbij je 2 gigabit kabels gebruikt om twee switches te koppelen met dus 2 Gbit. Bij een kabelbreuk of interface storing zak je van 2 naar 1 Gigabit maar blijft de verbinding verder in stand. Verder is er nog Resilient Ethernet Protocol (REP), Parallel Redundancy Protocol (PRP) e.d.

Overigens, mijn ervaring: hoe complexer je de oplossing maakt hoe eerder en groter het probleem wordt.

Situatie 1: Een goede switch met bijvoorbeeld dubbele voeding, temperatuuralarm e.d. gaat één keer in de tientallen jaren kapot en kan door iedereen met simpele beschrijving worden vervangen (door een simpele reserve switch die al klaar staat).

Situatie 2: Een complexe clusteroplossing geeft vroeg of laat problemen bij het upgraden of configureren, niemand snapt het en onder de streep veel meer storingen / problemen dan de simpele situatie.

Techies en netwerkverkopers (!!) zijn natuurlijk veel meer geïnteresseerd in situatie 2. Soms ben je echter veel beter af met twee simpele gedegen switches van de lokale computerwinkel voor een tiende van de prijs.

Edit: Deze wou ik nog toevoegen, de simpelste 'oudste' oplossing:

https://en.wikipedia.org/wiki/Spanning_Tree_Protocol

Als je een redundant netwerk wilt maken ga dan niet het wiel opnieuw uitvinden.

Hoe belangrijk is een redundant netwerk?
Wat zijn de kosten bij uitval. (budget)?
Wat zijn de meest voorkomende storingen?

Zelf iets met relais gaan maken is lastig.

Zonder verdere info te hebben klink het idd als een onlogische keuze. Maar misschien kan TS dat toelichten?

Normaliter heb je meerdere switches, redundant aangesloten met LACP of STP, via verschillende voedingscircuits. Naar een server (oid) ga je met meerdere touwtjes, immers, ook een nic kan defect.

Alles is een afweging van voor- en tegens. 100% redundant blijft lastig te realiseren. Hoe ingewikkelder je de techniek maakt, hoe kleiner de kans, maar in de praktijk verschuiven de storingen dan naar dingen die het net ff niet doen zoals bedacht en/of een grotere speurtocht.

Een dode switch geeft 15min downtime (swappen + config overzetten). Een cluster met storage nodes die wegvallen randmon en file locks heeft of whatever duurt langer om stabiel te krijgen als je pech hebt.

Gebruik gewoon fatsoenlijke hardware, voedingen dubbel en op langere lengtes galvanische scheidingen. (glas, ipv 80m utp door de grond)

Buiten alle normale oplossingen voor in een productieomgeving; ik begrijp dat het daar om enige reden niet om gaat.

Een managed switch kun je remote omconfigureren om zo te schakelen. Iets oudere modellen zonder support zijn waardeloos voor productietoepassingen en dus "gratis".

Voor een timer op de internetverbinding naar de kinderkamer heb ik wel eens voorgesteld een klein switchje er tussen te zetten nemen en de voeding daarvan in- en uit te schakelen.
Zo kun je ook een kruisschakelaar maken met zes switchjes lijkt me, het wordt wel steeds interessanter qua betrouwbaarheid ;-)

Het is juist bedoeld als "redundantie" voor devices die slechts 1 ethernet aansluiting hebben. In dit specifieke geval om allemaal VoIp telefoons. Maar soms gaat het ook om "gewone" werkplekken zoals thin clients of PC's.
De oplossing die ik zoek moet vanzeflsprekend geen extra single point of failure worden en daarom denk ik in de eerste instantie aan mechanische relais, bij uitval blijft de primaire connectie gewoon staan.
De reden waarom ik toch een soort van omschakelapparaat er tussen had bedacht is omdat de wens is om niet alleen sneller te kunnen ompatchen, maar dit ook op afstand te kunnen doen. Dit scheelt heel veel aanrijtijd en daarmee downtime van een flinke groep bellers.
Vanzelfsprekend heb ik nagedacht over de gangbare oploddingen in de markt, maar voor veel clients met maar 1 aansluiting kan ik zo snel geen andere oplossing bedenken.
Alle goede bedoelingen van reageerders die met switches met redundante voedingen aankomen ten spijt, zelfs deze switches gaan zo nu en dan stuk, en dat hoeft lang niet altijd de voeding te zijn. Sterker: ik merk vaker (met name met cisco) dat bijvoorbeeld ARP tabellen vollopen waardoor de switch gaat haperen en een herstart nodig heeft.
Een omschakelapparaat zou ook daar een oplossing kunnen zijn: met 1 druk op de knop omschakelen naar de reserve switch, reboot de primaire switch en weer terugschakelen zodra die weer gestart is.
Met het geld wat ik bespaar op de redundante voedingen en hogere type switches heb ik al een aardig budget voor dergelijke omschakelswitch.
Een robotarm die de de RJ-connectoren er een voor een uittrekt en omprikt is ook een oplossing, maar dat is me echt te complex en te duur :)

Jochem

Golden Member

Met mechanische relais ga je absoluut een onbetrouwbare hobby-bob oplossing maken. Je wilt dat echter niet horen, zo is wel duidelijk.

Op 13 februari 2017 17:08:25 schreef Blackfin:
Ik zou het niet met mechanische relays opbouwen, voor dit soort toepassingen maakt TI een IC TS3L501E

Mechanische relays introduceren SI problemen.

Dit dus. SI staat hierbij trouwens voor Signal Integrity.

Heb geduld: alle dingen zijn moeilijk voordat ze gemakkelijk worden.

Voor 10Mbit/s lukt je dat.
Maar voor hogere snelheden wordt dat lastig.
Er zit o.a. een verschil in impedantie tussen kabel en relais.

EricP

mét CE

Een dubbele power supply is niet (alleen) bedoeld om de PSU redundant te maken, maar ook de feed. Het zal niet de eerste keer zijn dan een voeding die opstijgt de feed mee trekt (waarschijnlijk toch ff een forse piekstroom voordat de rook er definitief uit is). Toch handig als de rest van je rack dan niet mee onderuit gaat...

Een 2de switch willen omdat je de eerste moet rebooten omdat die software rammelt, dat klinkt als een microsoft oplossing. Je zou ook het probleem op kunnen lossen: een switch neerzetten die wel gewoon werkt...

En ja, met relais in een signaalweg knoeien kan. Ik heb het voor 100Mbit gedaan. Dat werkte vlekkeloos (al zal het wel niet helemaal volgens spec geweest zijn). De reden was daar meer om fysiek om te kunnen schakelen naar een ander netwerk. Iets met netwerk scheiding (beveiliging) en managed switches zijn zou eenmaal te complex om de boel echt 'dicht' te krijgen. Hobby-Bob? Wellicht. Maar niemand had een beter idee. En het draait inmiddels 10 jaar zonder mankeren. Maar nogmaals, dat was 100MBit. En het zou zomaar kunnen dat ik gewoon mazzel heb gehad en het per ongeluk zo gemaakt heb dat het 'goed genoeg' is om te werken.

@EricP
Inderdaad, geluk gehad.
(En vermoedelijk aan snelheid verloren)

met een 2 tal 5 poorts gbit switches is dit betrouwbaarder te maken als met relais. kabel die nu in de grote switch zit op een 5 poorts gbit switch zetten. vanuit die switch naar 1 grote voip centrale, en hetzelfde met de andere. de switch die voeding krijgt bepaalt welke voip centrale de boel draait.

de 12V van die switch of de 230V kun je met elke gsm schakelmodule of zelfs via eternet actoren schakelen.

waar rook was, werkt nu iets niet meer
EricP

mét CE

@EricP
Inderdaad, geluk gehad.
(En vermoedelijk aan snelheid verloren)

Niet eens. Ik had een fall-back naar 10Mbit verwacht. Maar het ding bleef 100Mbit doen. En haalde dat ook (dedicated netwerk, lag iets anders dan een stapel windhoos ellende, testen was makkelijk...). De relais waren dood ordinaire klein signaal relais. Niks shielded, geen HF specs. Natuurlijk wel ff nagedacht over layout - tracks even lang gehouden, overal ground er omheen. Meer dan een (bijzonder goed) geslaagde noodoplossing was het niet... En uiteraard moest het verleden week af, dus de PCB is gewoon hier thuis in de keuken gemaakt...

Nogmaals: het verbaasde mij ook. Aan de andere kant... Als je soms ziet hoe kabels op patch panels afgewerkt worden door 'erkende' of 'gecertificeerde' bedrijven... En dat werkt ook allemaal. Je maakt mij niet wijs dat daar geen rare impedantiesprongen plaats vinden. 10cm ongetwist bijvoorbeeld... Maar het WERKT... (mooi spul, dat Ethernet :) ).

@testman: ik weet niet of dat betrouwbaarder is. Je single point of failure blijft dat relais. En het blijft symptoomonderdrukking van brakke firmware op een switch - de enige juiste oplossing is die switch 'retour afzender' met 'doet het niet' en stuur maar iets wat wel werkt. Tenzij TS natuurlijk de afzender is :+

@rbeckers, Blackfin:

Gigabit over mechanische relais kan gewoon. Ik heb het gedaan, in een fabrieksopstelling. Welliswaar met korte kabels (DUT->relais->ethernettester) maar dus met 1000'den DUTS.
Heeft altijd op gigabit snelheid gewerkt, en zonder bitfouten (daar was immers de tester voor).
Het enige probleem was slijtage van de connectors die op de DUT contact maakten :-)

Of dit voor OP een oplossing is betwijfel ik, inmiddels blijkt uit zijn posts dat hij wel degelijk enige kabellengte heeft, en dan kan je marge snel op zijn.

Jochem

Golden Member

Er zijn redenen te bedenken om ethernet met relais te switchen, maar verhogen van betrouwbaarheid is daar niet een voorbeeld van. Zoals EricP al zei: neem een switch die werkt. Als je een switch hebt waarvan ARP-tabellen vollopen, dan denk ik gelijk aan mijn huis-tuin-en-keuken switchje vroeger (die had dat ook). Switches voor professioneel gebruik mag je gewoon retour-afzender sturen als zoiets zich voor zou doen.

Gigabit heeft trouwens meer kans dan slagen over relais dan 100 Mbit vanwege de bak aan extra eisen/features die in een Gbit PHY zitten waarmee allerlei kabel-ellende gecompenseerd wordt. En in beide gevallen is de symboolsnelheid gelijk: 125 Mbaud.

Heb geduld: alle dingen zijn moeilijk voordat ze gemakkelijk worden.

Op 14 februari 2017 09:32:31 schreef Mark Stoopman:
Het is juist bedoeld als "redundantie" voor devices die slechts 1 ethernet aansluiting hebben. In dit specifieke geval om allemaal VoIp telefoons. Maar soms gaat het ook om "gewone" werkplekken zoals thin clients of PC's.

Ik begrijp hem niet helemaal. Ik snap dat je thinclients en voip telefoons hebt met 1 aansluiting. En dan wil je onder het bureau een kastje maken dat die telefoon naar een andere switch schakelt? Is het dan niet veel robuuster en nóg sneller opgelost door de gebruikers instructies te geven om zelf het kabeltje van outlet A naar B te pluggen?

Als het helemaal mission critical, stock exchange speeds moet: Twee voip telefoons en twee thinclients per werkplek. Een scherm of keyboard kan het ook begeven, nog waarschijnlijker ook omdat je op de werkplek meer stof, vloeistoffen, lompe gebruikers, schoonmakers e.d. hebt.

Vanzelfsprekend heb ik nagedacht over de gangbare oploddingen in de markt, maar voor veel clients met maar 1 aansluiting kan ik zo snel geen andere oplossing bedenken.
Alle goede bedoelingen van reageerders die met switches met redundante voedingen aankomen ten spijt, zelfs deze switches gaan zo nu en dan stuk, en dat hoeft lang niet altijd de voeding te zijn. Sterker: ik merk vaker (met name met cisco) dat bijvoorbeeld ARP tabellen vollopen waardoor de switch gaat haperen en een herstart nodig heeft...

Ik heb toch al heel wat uurtjes op MKB en Enterprise werkplekken gezeten. Bedrijven met soms duizenden werkplekken (per land) en ik kan het me niet herinneren dat ik ooit ook maar een hikje op ethernet niveau hebt gehad. Misschien 1 keer even dat 'disconnected' icoontje, misschien omdat de beheerder de switch even een duw gaf. Nooit dat de hele gang naar de koffieautomaat kwam omdat er een 24-48 poort switch begon te smeulen.

Arp tabellen op een switch? Een switch geeft niks om IP en doet dus ook geen ARP behalve om met z'n manager/monitor te verbinden, complexe Layer 3 toestanden uitgezonderd.

ken het probleem van ts wel, bij een voormalig werkgever was ict verhuisd naar een locatie 30 km verderop, met een netwerk van 10 jaar oud en veel rijgsystemen van utp naar glas heb je vaak storingen. veel kilometers kon ict schrijven bij storingen oplossen toen.

op afstand toestellen resetten kan dan behoorlijk schelen in downtime, elke schakel in de keten kan storing geven, zeker als het spul veroudert en smps voedingen, converters en de hitte icm falende ventilatoren in toestellen ellende gaan geven.

[Bericht gewijzigd door testman op 14 februari 2017 10:59:38 (25%)]

waar rook was, werkt nu iets niet meer

Het signaal is "maar" 125MHz, dus enige tolerantie voor een kort stuk waarbij impedantie matching mist zou nog kunnen werken. (8ns is 2.4m op lichtsnelheid. Dus als je 10cm aan impedantie matching mist is dat minder dan 10%).

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Op 14 februari 2017 10:57:52 schreef K7Jz:
[...]

Arp tabellen op een switch? Een switch geeft niks om IP en doet dus ook geen ARP behalve om met z'n manager/monitor te verbinden, complexe Layer 3 toestanden uitgezonderd.

Een switch doet L2.. en L2 is gebaseerd op... macadressen.

Een mactabel kan wel degelijk vollopen. Daarom zitten er bij WAN verbindingen ook limieten aan het aantal macadressen. Wil je meer? Ga maar routeren.

Als je ontwerp goed is en je niet alles in 1 groot plat netwerk gooit maar lokaties routeerd heb je daar echter niet snel last van. Beetje switch doet zonder problemen 8k macadressen. Daar zit je niet heel snel aan normaliter.

Op onze core haal ik de 3k nog nieteens, ding kan 64k. Terwijl er toch bijna 300 vlans op staan die ie grotendeels allemaal routeerd

Maar terugkomend op het probleem van TS: Ik zou eerder kijken of de toestellen om- en om aan te sluiten te zijn. Dan valt hoogstens de helft uit bij een defecte switch, de andere helft zit op een andere switch. Dat, ism redundant PSUs en uplinks, lijkt mij voldoende.

Kun je niet iets met wifi? Kabel preferren, fallback naar wifi als de kabel/switch wegvalt.
Een oplossing met relais en daarmee gaan schakelen (incl POE) klink mij als juist een groter risico introduceren dan hiermee oplossen.

[Bericht gewijzigd door DJSmiley op 14 februari 2017 11:16:25 (23%)]

@EricP
Dat ethernet in combinatie met tcp/ip werkt met jouw methode zegt weinig over hoe goed en hoe betrouwbaar dat werkt.
Aangezien relais en UTP, of STP, niet dezelfde impedantie hebben krijg je reflecties. Dat vermindert de signaal kwaliteit. Als eerste bij slechtte, of o.a. langere, kabels heeft de hardware dan minder marge om goed te werken. Zowel hardware als software hebben manieren om fouten te detecteren en te corrigeren. Maar niet zonder problemen.

Tussen allerlei meningen door lees ik ook handige praktijkervaringen. Dank daarvoor!
Vooralsnog is mijn conclusie dat het schakelen van ethernet signalen op een mechanische manier een hobby-oplossing is die misschien kan werken.
Dat het geen gecertificeerde oplossing zou worden had ik wel verwacht, anders hadden we een dergelijk apparaat wel ergens online kunnen bestellen lijkt me.
Allen heel hartelijk dank voor alle input. Wat een geweldig actief forum is dit!