Data Domain: Direkte tilkobling av nettverk mellom databeskyttelsessystemer

• Direkte tilkoblede systemer kan ikke pinge hverandre.
• Replikeringsrapporter "No route to host", connection failedEller destination unreachable ERROR:
• Grensesnitttilstand viser DOWN, DisconnectedEller Not Connected.
• Interface Connectivity Down Varsler genereres.
• Koblingshastigheten forhandler lavere enn forventet.
• Gjennomstrømningen er lavere enn forventet under testing.
• Grensesnitt klapper eller mister tilkoblingen med jevne mellomrom.
• MTree-replikering, innsamlingsreplikering, sikkerhetskopiering, gjenoppretting, migrering eller hvelvoperasjoner mislykkes over direct connect-nettverket.
• Direct Connect-porter kobles bare til nettet under bestemte vinduer i Cyber Recovery-miljøer.
• Nylig installerte direkte tilkoblingskoblinger forblir frakoblet etter konfigurasjonen.

• Problemer med nettverkskonfigurasjon
  • Direkte tilkoblede grensesnitt er konfigurert på forskjellige delnett.
  • Feil nettverksmasker skaper rutingsproblemer.
  • Statiske ruter mangler når det finnes flere nettverksbaner.
  • Trafikk rutes gjennom et annet grensesnitt i stedet for den direkte tilkoblingsbanen.
  • Connection-host eller destinasjonskonfigurasjon refererer til feil IP-adresse.
• Fysiske tilkoblingsproblemer
  • Feil fysiske porter er koblet til.
  • Defekte kabler, optikk, DAC-kabler eller SFP/QSFP-moduler.
  • Transceivere som ikke støttes eller ikke samsvarer.
  • Feil ved automatisk forhandling av koblingshastighet.
  • Feil på NIC-fastvare eller maskinvare.
• Problemer med grensesnittkonfigurasjon
  • Grensesnittet er administrativt deaktivert.
  • Manglende samsvar mellom bindingskonfigurasjoner.
  • MTU-uoverensstemmelse mellom endepunkter.
  • Feil veth-konfigurasjon.
  • Feil LACP-innstillinger.
• Atferd for cybergjenoppretting
  • Hvelvgrensesnitt kan med hensikt være deaktivert mellom synkroniseringsvinduer.
  • Replikeringskontekster kan deaktiveres av Cyber Recovery-automatisering.
  • Nedkoblingsvarsler kan være forventet atferd når hvelvet er låst.
• Plattformspesifikke problemer
  • Visse 25 Gb NIC- og SFP-kombinasjoner har vist ustabilitet eller grensesnittflapping i direkte tilkoblingsdistribusjoner.
  • FC Direct-Connect-konfigurasjoner kan oppleve problemer med topologi eller initiatoroppdagelse.
  • Feil vertsnavn eller replikeringskonfigurasjon kan hindre at flere baner for direkte tilkobling brukes som tiltenkt.

1. Validering av lag 1

Start alltid feilsøking på det fysiske laget.

Bekreft

• • Link-LED-lampene lyser på begge systemene.
  • Riktige grensesnitt er kablet sammen.
  • Kabelen er sertifisert for forhandlet hastighet.
  • SFP/QSFP-moduler matcher i begge ender.
  • Problemet følger kabelen eller forblir med porten under testing.

2. Validere fysisk porttilordning

Ved direkte tilkobling-implementeringer er det ikke alltid åpenbart hvilken fysisk NIC-port på baksiden av apparatet som tilsvarer grensesnittet som konfigureres i DDOS. Dette er spesielt vanlig på systemer med flere NIC-er, ekspansjonskort, limte grensesnitt eller etter maskinvareoppgraderinger.

Et ofte problem oppstår når administratoren mener at kabelen er koblet til ett grensesnitt mens den faktisk er koblet til en annen fysisk port.

Feilsøkingstrinn

• • Konfigurer midlertidige (dummy) IP-adresser på flere kandidatgrensesnitt på begge systemene.
  • Aktiver grensesnittene administrativt.
  • Observer hvilke grensesnitt som etablerer transportør og overgang til en UP-tilstand.
  • Verifiser de fysiske LED-lampene på begge enhetene.
  • Bruk grensesnitt- og maskinvarestatuskommandoer til å identifisere riktig porttilordning.
  • Når de riktige portene er identifisert, fjerner du den midlertidige konfigurasjonen og bruker de tiltenkte produksjonsinnstillingene.

Denne tilnærmingen kan raskt eliminere usikkerhet rundt fysisk portvalg og forhindre unødvendige undersøkelser av ruting, replikering, ytelse eller programvarerelaterte problemer når det faktiske problemet ganske enkelt er feil kabel-til-grensesnitt-tilordning.

Hvorfor dette hjelper

Mange problemer med direkte tilkobling spores etter hvert tilbake til:

• • Kabelen er koblet til feil NIC.
  • Feil antagelser om tilordning fra grensesnitt til havn.
  • Flere NIC-kort med lignende portmerking.
  • Grensesnittet som er konfigurert i DDOS, samsvarer ikke med porten som ble brukt av installasjonsprogrammet.
  • Bonded medlemmer koblet annerledes enn forventet.

Bekreftelse av fysisk porttilordning før du fortsetter med feilsøking på høyere lag, kan redusere tiden det tar å undersøke ruting, delnett, replikering eller Cyber Recovery-atferd betydelig når dette ikke er den faktiske årsaken.

3. Bekreft nettverkskonfigurasjonen

Det vanligste problemet med direkte tilkobling er feil delnett.

For kommunikasjon med direkte tilkobling:

• • Begge grensesnittene må ligge på samme delnett.
  • Dedikerte direkte tilkoblingsgrensesnitt bør bruke et delnett atskilt fra alle andre grensesnitt.
  • A /30-nettverk (255.255.255.252) anbefales fordi det bare gir de to nødvendige vertsadressene og forenkler ruting.

Eksempel:

System A: 192.168.100.1/30
System B: 192.168.100.2/30

Fordeler med en /30:

• • • Forenklet feilsøking.
    • Minimal ARP-trafikk.
    • Ingen krav til standard gateway.
    • Tydelig punkt-til-punkt-ruting.

Hvis et dedikert delnett ikke kan brukes:

• • • Konfigurere passende statiske ruter.
    • Kontroller at trafikken bruker det tiltenkte grensesnittet for direkte tilkobling.

4. Valider grensesnitttilstand

Sjekk at grensesnittene er:

• • Aktivert på begge systemene.
  • Tilordnet riktig IP-adresse.
  • Opererer med forventet hastighet.
  • Konfigurert med samsvarende MTU-verdier.

Et grensesnitt for direkte tilkobling kan ikke kommunisere hvis:

• • Det eksterne grensesnittet er deaktivert.
  • Koblingen har ikke etablert transportør.
  • Ett endepunkt er konfigurert på feil måte.

5. Bekreft bindingskonfigurasjon

Når flere Direct Connect-kabler brukes:

• • Kontroller at jordingsinnstillingene samsvarer på begge systemene.
  • Kontroller at medlemsgrensesnittene tilhører riktig binding.
  • Validere belastningsfordeling og aggregeringskonfigurasjon.

Felterfaring har vist at noen miljøer som forhandlet om lavere koblingshastigheter enn forventet ved bruk av Round Robin-binding, ble løst etter migrering til LACP.

LACP er vanligvis den foretrukne bindingsmetoden når den støttes på begge endepunktene.

6. Forstå atferd for cybergjenoppretting

Distribusjoner for Cyber Recovery genererer ofte noe som tilsynelatende er et nettverksproblem, men som faktisk er forventet atferd.

Cyber Recovery-applikasjonen kan:

• • Deaktiver hvelvgrensesnittet.
  • Aktiver grensesnittet bare i synkroniseringsvinduer.
  • Deaktiver replikeringskontekster etter at synkroniseringen er fullført.

Som et resultat:

• • Produksjonssystemer kan rapportere InterfaceConnectivityDown Varsel:
  • Ping-feil kan oppstå utenfor synkroniseringsvinduer.
  • Replikering kan rapportere "No route to host."

Før du eskalerer:

• • Kontroller at hvelvet er låst opp.
  • Kontroller at synkroniseringsvinduet er aktivt.
  • Bekreft at grensesnittet ikke ble deaktivert med hensikt av Cyber Recovery-automatisering.

7. Feilsøke koblingshastigheter som er lavere enn forventet

Hvis en 100 GB-kobling forhandler om 25 GB eller en annen redusert hastighet:

Bekreft

• • Samsvarende optiske typer.
  • Kabellengder som støttes.
  • Kompatible sendere/mottakere.
  • Bindingskonfigurasjon.
  • Fastvarenivåer for NIC.

En binding eller forhandlingskonflikt kan forhindre at grensesnitt fungerer med den tiltenkte hastigheten.

8. Feilsøke lav gjennomstrømning

Lavere gjennomstrømning indikerer ikke alltid et nettverksproblem.

Tenk på:

• • CPU-begrensninger på testverktøy som iPerf.
  • Flaskehalser med én kjerne.
  • Øktfordeling på tvers av prosessorkjerner.
  • Kilde- og målsystemutnyttelse.

Ved evaluering av ytelse:

• • Se gjennom applikasjons- eller replikeringsstatistikk.
  • Se etter faktisk etterslep eller forsinkelse.
  • Sammenlign workloadytelse med syntetiske testresultater.

Ikke stol utelukkende på iPerf-resultater når du bestemmer den generelle ytelsen for dataoverføring.

9. Maskinvarespesifikke problemer

Feltsaker har identifisert problemer som involverer:

• • 25 GB NIC-ustabilitet.
  • SFP-kompatibilitetsproblemer.
  • Grensesnittflapping som krever tilbakestilling av porter.
  • Direkte tilkobling-koblinger som krever grensesnittreturoperasjoner før gjenoppretting.

Hvis programvarekonfigurasjonen ser riktig ut:

• • Gjennomgå maskinvarekompatibilitet.
  • Sjekk kjente feil og produktmerknader.
  • Bytt ut utvalgt optikk eller kabler.
  • Valider fastvare- og DDOS-versjoner.

Tilleggsinformasjon

Direct-connect-nettverk kan brukes til følgende:

• MTree-replikering
• Replikering av samling
• Tilkobling til hvelv for cybergjenoppretting
• IDPA-til-IDPA-kommunikasjon
• Kommunikasjon mellom IDPA og datadomene
• Datamigrering
• Sikkerhetskopiering og gjenoppretting av isolasjon
• Ytelsestesting
• Feilsøking for nettverk
• Midlertidig implementeringstilkobling

MRepl og CRepl kan operere over et direkte tilkoblet nettverk. Fra Data Domain-perspektivet trenger ikke den tilkoblede enheten å være en svitsj, ruter eller et annet nettverksapparat. Så lenge transportøren er etablert og grensesnittene er riktig konfigurert, kan kommunikasjon skje direkte mellom de tilkoblede endepunktene.

For direkte tilkoblede grensesnitt:

• Begge endepunktene må konfigureres i samme delnett med mindre ruting er innført med hensikt.
• Et dedikert subnett bør brukes når det er mulig.
• Hvis det direkte tilkoblingsnettverket overlapper med andre grensesnitt, kan det være nødvendig med statiske ruter for å sikre at trafikken bruker den tiltenkte banen.
• Feilsøking for direkte tilkobling brukes ofte til å isolere eksterne nettverksenheter som en potensiell kilde til tilkoblings- eller ytelsesproblemer.

Relatert artikkel:

• Data Domain: Feilsøking av grensesnitt nede eller uregelmessig for brukere
  
• Data Domain - Konfigurere fysiske grensesnitt med grafisk brukergrensesnitt)
  
• Data Domain – konfigurere fysiske grensesnitt via kommandolinjegrensesnitt)
• Data Domain: Intel X710 NIC kan mislykkes i å VLAN-merke riktig hvis det går inn i gjenopprettingsmodus.

Se denne artikkelen hvis VLAN-trafikk ikke sendes riktig gjennom et Intel X710-grensesnitt. Artikkelen forklarer hvordan NIC-gjenopprettingsmodus kan påvirke VLAN-merking, og inneholder fremgangsmåter for å identifisere og løse problemet.

• Data Domain: Feil "SMS-kommandoen mislyktes: Finner ingen grensesnitt" fra DD CLI og UI

Bruk denne artikkelen når DD CLI eller UI rapporterer at ingen grensesnitt er funnet. Den bidrar til å identifisere problemer med oppdagelse av grensesnitt og skisserer feilsøkingstrinn for å gjenopprette normal synlighet for nettverksgrensesnittet.

• Data Domain: Feilsøke en "Net Set Up Flag Failure" -feil

Se denne artikkelen når endringer i nettverkskonfigurasjonen mislykkes med meldingen "Net Set Up Flag Failure". Den gir veiledning om diagnostisering av konfigurasjonsinkonsekvenser og gjenoppretting av grensesnittfunksjonalitet.

• PowerProtect DD og IDPA: Etter oppgradering kommuniserer ikke ethVX

Bruk denne artikkelen hvis ethVX-grensesnitt slutter å kommunisere etter en programvareoppgradering. Den skisserer vanlige årsaker, valideringstrinn og korrigerende tiltak for å gjenopprette tilkobling.

• Data Domain: Intel-grensesnitt kobler sammen med tx_timeout

Se denne artikkelen når Intel-baserte nettverksgrensesnitt uventet går ned og tx_timeout feil observeres. Artikkelen hjelper deg med å finne ut om problemet er driver-, fastvare- eller maskinvarerelatert, og inneholder gjenopprettingsprosedyrer.

• Data Domain: Cyber Recovery FEC-innstilling er ikke tillatt

Denne artikkelen gjelder når nettverkskonfigurasjoner for Cyber Recovery mislykkes fordi Forward Error Correction (FEC) er deaktivert. Den forklarer FEC-kravene og hvordan du konfigurerer støttede innstillinger.

• Data Domain: Intel X710-kortet oppdages ikke ved oppstart med tilkoblede nettverkskabler

Bruk denne artikkelen når en Intel X710-adapter mangler eller ikke oppdages under systemoppstart når nettverkskabler er tilkoblet. Artikkelen drøfter betingelsene som utløser problemet, og den anbefalte løsningen.

• Data Domain: Endre bindingstype med LACP-svitsjkonfigurasjon Deaktiverer grensesnitt

Se denne artikkelen når du endrer bindingsmodi på grensesnitt koblet til LACP-konfigurerte svitsjer. Den beskriver hvordan bindingstypeendringer kan føre til at grensesnitt blir utilgjengelige, og hvordan du trygt kan utføre overgangen.

• Data Domain: Ugyldig innstillingsfeil for nettverkskonfigurasjon forårsaket av QLogic-kort

Denne artikkelen er nyttig når endringer i nettverkskonfigurasjonen mislykkes på grunn av ugyldige innstillinger knyttet til QLogic-kort. Den inneholder feilsøkingstrinn og veiledning for korrigering av konfigurasjonen.

• Data Domain: Ugyldig MTU forårsaker feil på VLAN-grensesnittet etter omstart

Se denne artikkelen hvis VLAN-grensesnittene ikke kobles til etter en omstart på grunn av MTU-relaterte konfigurasjonsproblemer. Artikkelen forklarer symptomet, grunnårsaken og riktige MTU-valideringskrav.

• Data Domain: Varsel om limt grensesnitt på grunn av manglende samsvar mellom medlemsgrensesnitthastighet

Bruk denne artikkelen når limte grensesnitt genererer varsler fordi medlemsporter opererer med ulike hastigheter. Den skisserer hvordan hastighetsavvik påvirker bindingshelsen og trinnene som trengs for å løse tilstanden.

• Data Domain: Nettverksgrensesnittene kan gå ned på grunn av Intels midlertidige løsningskonfigurasjon

Se denne artikkelen når nettverksgrensesnitt uventet blir utilgjengelige etter bruk av Intel-relaterte midlertidige løsningsinnstillinger. Den forklarer atferden, berørte konfigurasjoner og anbefalinger for å opprettholde stabil nettverkstilkobling.