De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft een overzicht van Resilient Ethernet Protocol (REP).
Opmerking: gebruik Cisco Feature Navigator om informatie te vinden over platformondersteuning en ondersteuning voor Cisco-softwareafbeeldingen.
REP is een protocol dat wordt gebruikt om het Spanning Tree Protocol (STP) te vervangen in bepaalde specifieke Layer 2-netwerkontwerpen. De meest recente STP-specificatie is Multiple Spanning Trees (MST), gedefinieerd in 802.1Q-2005. Gebruikers die een alternatief voor MST willen, maken zich terecht zorgen:
Hier zijn enkele van de voordelen van REP:
Hier zijn enkele van de beperkingen van REP:
REP gebruikt een segment als minimale netwerkbouwsteen. Een segment is simpelweg een verzameling havens die aan elkaar zijn geketend. Slechts twee havens kunnen tot een bepaald segment op een brug behoren, en elke segmenthaven kan een maximum van één externe buur hebben. De definitie van het segment wordt volledig bereikt door de configuratie van de gebruiker. Het segment wordt afgesloten door twee randpoorten die ook door de gebruiker worden bepaald. Het REP-protocol dat op segmenten wordt uitgevoerd, is zo minimaal mogelijk en garandeert alleen deze eigenschappen:
Afbeelding 1 toont een voorbeeld van een segment dat zes poorten omvat, verspreid over vier bruggen. De geconfigureerde randpoorten E1 en E2 worden weergegeven met een driehoek in het diagram en de logisch geblokkeerde poort wordt weergegeven door een balk. Wanneer alle poorten operationeel zijn, zoals in de linkerzijde wordt weergegeven, wordt één poort geblokkeerd. Wanneer er een mislukking in het netwerk is, zoals in het diagram rechts, gaat de logisch gezien geblokkeerde poort terug naar een doorsturen staat.
Wanneer het segment open is, zoals weergegeven in afbeelding 1, biedt het nooit verbinding tussen de twee randpoorten. Er wordt aangenomen dat de connectiviteit tussen REP-switches buiten het segment (via STP) aanwezig is. Met optionele configuratie wordt een STP Topology Change Notification (TCN) gegenereerd als er een storing optreedt in het REP-segment om de convergentie te versnellen.
Wanneer de twee randpoorten zich op dezelfde switch bevinden, zoals in afbeelding 2, wordt het segment in een ring gewikkeld. In dit geval is er connectiviteit tussen de randpoorten door het segment. In feite kunt u met deze configuratie een redundante verbinding tot stand brengen tussen twee switches in het segment.
Als u combinaties van open en gesloten segmenten gebruikt, zoals weergegeven in Afbeelding 1 en Afbeelding 2, kunt u een verscheidenheid aan verschillende netwerkontwerpen bereiken.
Wanneer een poort is geconfigureerd voor REP, ondergaat het deze toestanden:
Een haven wordt onder deze omstandigheden niet operationeel:
In de standaardinstelling wordt met REP een hello-pakket naar een BPDU-klasse (Bridge Protocol Data Unit) gestuurd met MAC-adres op het native VLAN (untagged), zodat de pakketten worden gedropt door apparaten die de functie niet uitvoeren. Elke Link Status Layer (LSL) PDU bevat zowel een volgnummer van de PDU die wordt verzonden als het externe volgnummer van de laatst ontvangen PDU. Dit zorgt voor een betrouwbare transmissie tussen de havens. Elke buur houdt een kopie bij van elke PDU die wordt verstuurd totdat een ACK wordt ontvangen. Als geen ACK wordt ontvangen, wordt het opnieuw verstuurd nadat een timer verloopt.
De eigenlijke LSL PDU bevat:
LSL-pakketten worden verzonden met elk hello-interval, of wanneer een protocol op een hogere laag om deze pakketten verzoekt. Wanneer de LSL PDU wordt gebouwd, bevolkt het eerst zijn eigen velden, zoals SegmentID en LocalPortID. Vervolgens kijkt het in de hoger-laag protocolwachtrijen, zoals Block Port Advertisement (BPA) of End Port Advertisement (EPA), om te zien of extra gegevens moeten worden gevraagd.
De HFL is de REP-module die snelle convergentie na koppelingsstoringen vergemakkelijkt. Het verzendt geen PDU's naar het BPDU MAC-adres zoals LSL, maar het verzendt multicast PDU's naar een speciaal MAC-adres (0100.0cc.ccce) op het REP-beheerVLAN. Op deze manier wordt het overstroomd in hardware naar alle switches in het segment.
De HFL-pakketindeling is eenvoudig:
Op dit moment zijn de enige TLV's die via HFL worden verstuurd BPA's.
BPA’s worden door AP’s verzonden om de VLAN’s die zij blokkeren te adverteren met hun poortprioriteit. Dit helpt het segment op de hoogte te stellen van koppelingsfouten en zorgt ervoor dat er slechts één AP per segment per VLAN is. Dit is niet gemakkelijk te verwezenlijken.
In een stabiele topologie zijn AP-verkiezingen eenvoudig. Een poort die online komt, begint als een AP voor alle VLAN’s (blokkering). Wanneer het een BPA van een andere haven met een hogere prioriteit ontvangt, weet het veilig kan deblokkeren. Wanneer een poort op het segment faalt, wordt dit zelfde proces gebruikt om de andere poorten te deblokkeren. Alle mislukte poorten genereren een hogere poortprioriteit (met een mislukt bit in de prioriteit) dan de huidige AP's, waardoor de huidige AP deblokkeert.
Problemen doen zich echter voor wanneer deze link weer opduikt. Wanneer dit gebeurt, wordt de mislukte bit op de prioriteit gewist en keert de prioriteit terug naar normaal. Hoewel deze haven zijn nieuwe prioriteit kent, kunnen andere delen van het segment verouderde BPA-informatie van deze haven hebben. Dit diagram illustreert dit scenario:
Aan het begin van dit scenario blokkeert haven 7 en adverteert de prioriteit als 7. Vervolgens het verband tussen 11 en 12 onderbrekingen, waardoor 12 een BPA verzenden die aangeeft dat het blokkeert met een prioriteit van 12. Voordat deze blokkerende havens de BPA van de andere haven ontvangen, komt haven 12 terug en is operationeel. Spoedig daarna ontvangt haven 12 de BPA van haven 7 met prioriteit 7, zodat het deblokkeert. Port 7 krijgt dan de verouderde BPA van poort 12 met prioriteit 12, dus het ontgrendelt. Dit veroorzaakt een lus. Deze racevoorwaarde is de reden dat BPA sleutels gebruikt.
Elke poort berekent een poortprioriteit met deze informatie:
Het is nu duidelijk waarom mislukte poorten altijd worden verkozen AP's in het segment. Wanneer een poort beweegt van Mislukt naar Alternatief, genereert het een unieke sleutel op basis van zijn poort-ID en een willekeurig nummer, en adverteert het samen met zijn poort-ID. AP deblokkeert alleen als het een bericht ontvangt van een geblokkeerde poort die de lokale sleutel bevat. Dit mechanisme helpt voorkomen dat het race conditiescenario beschreven in de vorige paragraaf. Dit zijn diagrammen die laten zien wat er gebeurt als havens omhoog en omlaag gaan:
Wanneer een koppelingsfout optreedt op een segment, wordt een BPA overstroomd naar de rest van het segment via HFL. Om dit volledig effectief te laten zijn, moet het administratieve VLAN worden uitgevoerd op alle segmentpoorten en moet het worden vervoerd tussen randpoorten buiten het segment. BPA stuurt deze informatie ook via LSL, omdat HFL geen betrouwbaar transport kan garanderen. Als er problemen zijn met de levering van HFL, zorgt LSL ervoor dat er reconvergentie optreedt.
Een eindpoort is een randpoort of een mislukte poort. Wanneer een segment aan beide kanten door een randhaven wordt geëindigd, wordt het als volledig beschouwd en de lastverdeling van VLAN is mogelijk. Wanneer een segment wordt afgesloten door een mislukte poort, is geen taakverdeling mogelijk omdat alle poorten open zijn.
De eindhavens sturen periodiek EPO's die via LSL worden doorgegeven. Deze berichten:
Elke eindpoort verstuurt een periodieke EPA die informatie over zichzelf bevat via LSL. Elke tussenpoort voegt zijn eigen informatie toe en geeft de EPA door. Aangezien deze berichten in beide richtingen bewegen, heeft elke REP-deelnemende switch kennis van het gehele REP-segment. De EPO bevat onder meer de volgende informatie:
Elke randpoort verstuurt een speciale verkiezingspositie met een eigen randprioriteit en een speciale sleutel (niet gerelateerd aan de BPA-sleutel). De eerste haven die dit ontvangt, stelt zijn eigen havenprioriteit in dit bericht en geeft het door aan de volgende switch. Elke switch op het pad vergelijkt zijn eigen havenprioriteit met die in de EPO en vervangt deze door zijn eigen havenprioriteit als die hoger is. Wanneer de edge port een EPA ontvangt, vergelijkt het de edge-prioriteit met zijn eigen. Als de ontvangen EPO een hogere prioriteit heeft, stuurt de randpoort zijn volgende EPO-bericht met de sleutel naar de primaire rand. Dit mechanisme helpt twee dingen te bereiken:
VLAN-taakverdeling wordt bereikt met twee verschillende AP’s die verschillende VLAN’s blokkeren. De primaire rand is en is verantwoordelijk voor het toegangspunt op ten minste een subset van de VLAN’s en het verstuurt een EPA-bericht dat de poort met de hoogste prioriteit vertelt de rest te blokkeren. De informatie over de tussenhaven met de hoogste prioriteit was al meegenomen in de verkiezingsboodschap van de EPO. Het type bericht dat hiervoor wordt gegenereerd is een EPA-opdracht TLV die een bitmap van de VLAN’s bevat die de poort met de hoogste prioriteit moet blokkeren.
EPA-header:
Verkiezing TLV:
Opdracht TLV:
Informatie over TLV:
Hier is een voorbeeld van een goede topologie:
SwitchA#show rep topology
REP Segment 1
BridgeName PortName edge Role
---------------- ---------- ---- ----
SwitchA Fa0/2 Pri Alt
SwitchC Fa1/0/23 Open
SwitchC Fa1/0/2 Open
SwitchD Fa0/23 Open
SwitchD Fa0/2 Open
SwitchB Fa1/0/23 Sec Open
Hier is een voorbeeld waar iets gebroken is:
SwitchA#show rep topology
REP Segment 1
Warning: REP detects a segment failure, topology may be incomplete
BridgeName PortName edge Role
---------------- ---------- ---- ----
SwitchA Fa0/2 Sec Open
SwitchC Fa1/0/23 Open
SwitchC Fa1/0/2 Fail
Zo zag het er vroeger uit:
SwitchA#show rep topology archive
REP Segment 1
BridgeName PortName edge Role
---------------- ---------- ---- ----
SwitchA Fa0/2 Pri Open
SwitchC Fa1/0/23 Open
SwitchC Fa1/0/2 Open
SwitchD Fa0/23 Open
SwitchD Fa0/2 Open
SwitchB Fa1/0/23 Sec Alt
Voer deze opdracht in om meer informatie te krijgen over de koppeling tussen SwitchC en SwitchD die is mislukt:
SwitchA#show rep topology archive detail
REP Segment 1
<snip>
SwitchC, Fa1/0/2 (Intermediate)
Open Port, all vlans forwarding
Bridge MAC: 0017.5959.c680
Port Number: 004
Port Priority: 010
Neighbor Number: 3 / [-4]
SwitchD, Fa0/23 (Intermediate)
Open Port, all vlans forwarding
Bridge MAC: 0019.e73c.6f00
Port Number: 019
Port Priority: 000
Neighbor Number: 4 / [-3]
<snip>
Zo ziet het eruit nadat je de link weer naar boven hebt gebracht:
SwitchA#show rep topology
REP Segment 1
BridgeName PortName edge Role
---------------- ---------- ---- ----
SwitchA Fa0/2 Pri Open
SwitchC Fa1/0/23 Open
SwitchC Fa1/0/2 Alt
SwitchD Fa0/23 Open
SwitchD Fa0/2 Open
SwitchB Fa1/0/23 Sec Open
Bericht dat de eerder-ontbroken haven als AP blijft en blijft blokkeren. Dit komt doordat er alleen AP-verkiezingen plaatsvinden tussen geblokkeerde poorten. Toen deze verbinding ontbrak, openden alle andere havens in de topologie. Toen de link beschikbaar kwam, verstuurden zowel SwitchC als SwitchD BPA’s met hun prioriteiten. SwitchC F1/0/2 had een hogere prioriteit, dus werd het de AP. Dit blijft totdat een andere poort in de topologie mislukt, of totdat een voorschot wordt uitgevoerd.
Een ALT-poort blokkeert enkele of alle VLAN’s. Als er een storing in het REP-segment is, is er geen ALT-poort; alle poorten zijn open. Zo kan REP een actief pad voor het dataverkeer bieden als er een storing is.
In een volledig REP-segment (wanneer er geen storing is) is er één ALT-poort of zijn er twee ALT-poorten. Als VLAN-taakverdeling is ingeschakeld, zijn er twee ALT-poorten in het segment - een van de ALT-poorten blokkeert een gespecificeerde set VLAN’s en de andere ALT-poort, die altijd aan de primaire rand staat, blokkeert de complementaire set VLAN’s. Als VLAN-taakverdeling niet is ingeschakeld, is er één ALT-poort in het segment die alle VLAN’s blokkeert.
De volgorde waarin de poorten online komen en de ingebouwde poortprioriteiten bepalen welke poort in het segment een ALT-poort wordt. Als u wilt dat een bepaalde poort de ALT-poort is, configureer deze met het voorkeurssleutelwoord. Hierna volgt een voorbeeld:
interface gig3/10
rep segment 3 edge preferred
Stel dat gig3/1 de primaire rand is en u VLAN-taakverdeling wilt configureren:
interface gig3/1
rep segment 3 edge primary
rep block port preferred vlan 1-150
Met deze configuratie, na voorkoop, is port gig3/10 een ALT-poort die VLAN’s 1 tot en met 150 blokkeert, en is port gig3/1 een ALT-poort die VLAN’s 151 tot en met 4094 blokkeert.
Voorrang wordt gedaan of manueel met de opdracht Rep pre-empt segment 3, of automatisch als u Rep pre-empt-vertraging <seconden> onder de primaire randpoort configureren.
Wanneer een segment na een verbindingsmislukking geneest, komt één van de twee poorten naast de mislukking omhoog als de ALT-poort. Vervolgens wordt de locatie van de ALT-poorten, na voorrang, zoals gespecificeerd door de configuratie.
Voer deze opdracht in om te zien of er een nabijheid is:
SwitchC#show interface fa1/0/23 rep
Interface Seg-id Type LinkOp Role
---------------------- ------ -------------- ----------- ----
FastEthernet1/0/23 1 TWO_WAY Open
Voer deze opdracht in om meer informatie te verkrijgen:
SwitchC#show interface fa1/0/23 rep detail
FastEthernet1/0/23 REP enabled
Segment-id: 1 (Segment)
PortID: 001900175959C680
Preferred flag: No
Operational Link Status: TWO_WAY
Current Key: 000400175959C6808335
Port Role: Open
Blocked VLAN: <empty>
Admin-vlan: 1
Preempt Delay Timer: disabled
Configured Load-balancing Block Port: none
Configured Load-balancing Block VLAN: none
STCN Propagate to: none
LSL PDU rx: 255547, tx: 184557
HFL PDU rx: 3, tx: 2
BPA TLV rx: 176096, tx: 2649
BPA (STCN, LSL) TLV rx: 0, tx: 0
BPA (STCN, HFL) TLV rx: 0, tx: 0
EPA-ELECTION TLV rx: 870, tx: 109
EPA-COMMAND TLV rx: 2, tx: 2
EPA-INFO TLV rx: 45732, tx: 45733
De meeste debugs afdrukken teveel uitvoer om nuttig te zijn. Hier is de volledige lijst (sommige alleen beschikbaar bij interne service):
SwitchB#debug rep ?
all all debug options
bpa-event bpa events
bpasm BPA state machine
database protocol database
epasm EPA state machine
error protocol errors
failure-recovery switchover events
lslsm LSL state machine
misc miscellaneous
packet protocol PDU
prsm Port Role state machine
showcli show debug info
Hier zijn een paar handige debugs:
debug rep fout - Dit debug heeft het potentieel om zeer nuttig te zijn.
*Mar 5 05:01:11.530: REP LSL-OP Rx EXT Local (Fa0/23 seg:1, tc:1, frs:0) prio:
*Mar 5 05:01:11.530: 0x80 0x00 0x19 0x00 0x17 0x59 0x59 0xC6
*Mar 5 05:01:11.530: 0x80
*Mar 5 05:01:11.530: REP Flush from Fa0/23 to REP, sending msg
*Mar 5 05:01:11.530: REP LSL-OP Rx INT Local (Fa0/2 seg:1, tc:1, frs:0) prio:
*Mar 5 05:01:11.530: 0x80 0x00 0x19 0x00 0x17 0x59 0x59 0xC6
*Mar 5 05:01:11.530: 0x80
*Mar 5 05:01:11.530: REP Flush from Fa0/2 to REP, sending msg
4d05h: %LINK-3-UPDOWN: Interface FastEthernet0/2, changed state to up
4d05h: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/2,
changed state to up
*Mar 5 05:06:19.098: rep_pr Fa0/2 - pr: during state FAILED_PORT,
got event 5(no_ext_neighbor)
*Mar 5 05:06:19.098: @@@ rep_pr Fa0/2 - pr: FAILED_PORT ->
FAILED_PORT_NO_EXT_NEIGHBOR[Fa0/2]rep_pr_act_no_ext_neighbor@272:
PRSM->fp_no_ext_neighbor state
[Fa0/2]rep_pr_lsl_event_handler@448: REP_MSG_EXT_PEER_GONE rcvd
4d05h: %REP-4-LINKSTATUS: FastEthernet0/2 (segment 1) is operational
*Mar 5 05:06:22.236: rep_pr Fa0/2 - pr: during state FAILED_PORT_NO_EXT_
NEIGHBOR, got event 0(link_op)
*Mar 5 05:06:22.236: @@@ rep_pr Fa0/2 - pr:
FAILED_PORT_NO_EXT_NEIGHBOR ->
ALTERNATE_PORT[Fa0/2]rep_pr_act_ap@162: PRSM->alternate state
[Fa0/2]rep_pr_lsl_event_handler@431: REP_MSG_LINKOP_TRUE rcvd
*Mar 5 05:06:23.125: rep_pr Fa0/2 - pr: during state ALTERNATE_PORT,
got event 2(pre_empt_ind)
*Mar 5 05:06:23.133: @@@ rep_pr Fa0/2 - pr: ALTERNATE_PORT -> UNBLOCK_VLANS_ACT
*Mar 5 05:06:23.133: rep_pr Fa0/2 - pr: during state UNBLOCK_VLANS_ACT,
got event 3(no_local_block_vlan)
*Mar 5 05:06:23.133: @@@ rep_pr Fa0/2 - pr: UNBLOCK_VLANS_ACT ->
OPEN_PORT[Fa0/2]rep_pr_act_op@252: PRSM->active state
[Fa0/2]rep_pr_act_uva@222: PRSM unblock vlans
[Fa0/2]rep_pr_sm_prempt_ind@374: Posting pre empt indication
Hier is de output als een haven offline gaat:
*Mar 5 04:48:31.463: rep_epa_non_edge Fa0/2 - epa-non-edge: during state
INTERMEDIATE_PORT, got event 1(lr_eq_fp)*Mar 5 04:48:31.463: @@@ rep_epa_non_
edge Fa0/2 - epa-non-edge: INTERMEDIATE_PORT -> FAILED_PORT[Fa0/2]rep_epa_non_
edge_act_failed_port@164: Trigger archiving
[Fa0/23]rep_epa_set_peer_archive_flag@1084: set arch flag
[Fa0/2]rep_epa_non_edge_act_failed_port@171: no edge, failed port
*Mar 5 04:48:35.473: rep_epa_non_edge Fa0/2 - epa-non-edge: during state
FAILED_PORT, got event 0(epa_hello_tmo)
*Mar 5 04:48:35.473: @@@ rep_epa_non_edge Fa0/2 - epa-non-edge: FAILED_PORT ->
FAILED_PORT[Fa0/2]rep_epa_non_edge_act_periodic_tx@90: archiving on port down
[Fa0/2]rep_epa_copy_topology@913: deip=0x3396F18,pe=0,se=1,fp=0,ap=0,op=2
[Fa0/23]rep_epa_non_edge_handle_info_tlv@1560: archiving on internal flag
[Fa0/23]rep_epa_copy_topology@913: deip=0x33961F0,pe=1,se=0,fp=0,ap=1,op=3
[Fa0/2]rep_epa_non_edge_act_periodic_tx@102: epa non edge, send info tlv
[Fa0/23]rep_epa_set_peer_archive_flag@1084: set arch flag
[Fa0/2]rep_epa_non_edge_handle_election_tlv@325: archiving on seg cfg change
[Fa0/2]rep_epa_copy_topology@913: deip=0x3396F18,pe=0,se=1,fp=0,ap=0,op=2
[Fa0/2]rep_epa_set_peer_archive_flag@1084: set arch flag
[Fa0/23]rep_epa_non_edge_handle_election_tlv@325: archiving on seg cfg change
[Fa0/23]rep_epa_copy_topology@913: deip=0x33961F0,pe=1,se=0,fp=0,ap=1,op=3
[Fa0/2]rep_epa_non_edge_handle_info_tlv@1560: archiving on internal flag
[Fa0/2]rep_epa_copy_topology@913: deip=0x3396F18,pe=0,se=1,fp=0,ap=0,op=2
Hier is de output wanneer een haven online komt:
*Mar 5 04:49:39.982: rep_epa_non_edge Fa0/2 - epa-non-edge: during state FAILED_PORT,
got event 2(lr_neq_fp)
*Mar 5 04:49:39.982: @@@ rep_epa_non_edge Fa0/2 - epa-non-edge: FAILED_PORT ->
INTERMEDIATE_PORT[Fa0/2]rep_epa_non_edge_stop_timer@123: epa non edge, stop the timer
[Fa0/2]rep_epa_copy_topology@913: deip=0x32E2FA4,pe=0,se=1,fp=0,ap=1,op=1
[Fa0/2]rep_epa_copy_to_stable_topology@1040: copy to stbl
[Fa0/23]rep_epa_copy_topology@913: deip=0x3ACFFB8,pe=1,se=0,fp=0,ap=0,op=4
[Fa0/23]rep_epa_copy_to_stable_topology@1040: copy to stbl
[Fa0/23]: BPA: Sending ext pak to bparx
[Fa0/2]: BPA: Enqueued internal pak
[Fa0/2]: BPA: Sending int msg to bparx
[Fa0/2]: BPA: Relay pak
[Fa0/2]: BPA: Enqueue ext pak
*Mar 5 04:44:23.857: rep_bpa_rx BPA RX sm: during state BPA_RX_IDLE,
got event 0(bpa_rx_bpa_msg)
*Mar 5 04:44:23.857: @@@ rep_bpa_rx BPA RX sm: BPA_RX_IDLE -> BPA_RX_IDLE
[Fa0/23]: BPA Rx sm: Received bpa: <internal> 0, <vlan_detail> 0
[Fa0/23]: BPA Rx sm: Role 2: TC 0; Internal 0; Frm Remote Segment 0
*Mar 5 04:44:23.857: rep_bpa_rx BPA RX sm: during state BPA_RX_IDLE,
got event 0 (bpa_rx_bpa_msg)
*Mar 5 04:44:23.857: @@@ rep_bpa_rx BPA RX sm: BPA_RX_IDLE -> BPA_RX_IDLE
[Fa0/2]: BPA Rx sm: Received bpa: <internal> 1, <vlan_detail> 0
[Fa0/2]: BPA Rx sm: Role 2: TC 0; Internal 1; Frm Remote Segment 0
*Mar 5 05:03:10.564: REP Fa0/23 seq:4411 ACK'ed (ref: 1)
*Mar 5 05:03:10.564: REP Fa0/23 seq:4412 ACK'ed (ref: 1)
*Mar 5 05:03:10.564: REP LSL: Fa0/23 rx expected seq# (4744),
process it (TLV: 0).
*Mar 5 05:03:10.782: REP Fa0/2 seq:440 ACK'ed (ref: 1)
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
3.0 |
08-Mar-2024 |
Bijgewerkte afbeeldingen en onderschriften, SEO en opmaak. |
2.0 |
20-Jan-2023 |
Bijgewerkte opmaak en vaste CCW-waarschuwingen. Hercertificering. |
1.0 |
03-Jul-2013 |
Eerste vrijgave |