A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
A finalidade deste documento é demonstrar o comportamento do Open Shortest Path First (OSPF) quando o V-bit (link virtual mordido) esta presente em uma área sem backbone. O V-bit está sinalizado no tipo-1 LSA somente se o roteador é o valor-limite de uns ou vários enlaces virtuais inteiramente adjacentes. Quando o V-bit é ajustado este poderia mudar a preferência do cálculo do trajeto entre o intra-area e as rotas inter-área.
Refira o diagrama da rede em figura 1 como você usa este documento:
Figura 1
No diagrama da rede acima, nós temos a área Backbone 0 e o r1 da área sem backbone 1. é uma área de conexão 0 do roteador de borda de área (ABR) e a área 1, R4 e R3 tem um papel similar nesta rede. Nesta área de topologia 0 são discontiguous desde que o R3 e o R4 não são conectados através da área 0.
Todas as áreas em um sistema autônomo OSPF devem ser conectadas à área Backbone (área 0). Em alguns casos onde você tem uma área sem backbone entre sua área Backbone, isto poderia fazer com que algumas áreas do sistema autônomo tornem-se inacessíveis e de resultados em sua rede que é discontiguous. Quando não é possível ter uma área Backbone contígua, você pode usar um enlace virtual para conectar seu backbone com uma área sem backbone. A área com que você configura o enlace virtual é sabida como uma área de trânsito.
Figura 2
Nesta encenação, nós estaremos indo sobre o cálculo previsto do trajeto na topologia de rede acima. Nós estaremos investigando que trajeto é preferido ao distribuir do r1 para R6 o laço de retorno 100 que tem um endereço IP de Um ou Mais Servidores Cisco ICM NT de 192.0.2.100/32
Lets tem um olhar na base de dados do OSPF no r1 a um undestand mais adicional a topologia:
R1#show ip ospf database OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 1.1.1.1 1.1.1.1 22 0x8000000C 0x00CD7A 2 4.4.4.4 4.4.4.4 289 0x8000000F 0x00434E 4 6.6.6.6 6.6.6.6 374 0x80000009 0x00630A 3 Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 192.168.13.0 1.1.1.1 18 0x80000001 0x00348D 192.168.13.0 4.4.4.4 207 0x80000001 0x00E3D0 192.168.34.0 1.1.1.1 8 0x80000001 0x005655 192.168.34.0 4.4.4.4 683 0x80000001 0x00F1AE Router Link States (Area 1) Link ID ADV Router Age Seq# Checksum Link count 1.1.1.1 1.1.1.1 17 0x80000009 0x00EC2B 2 3.3.3.3 3.3.3.3 18 0x8000000E 0x005A64 4 4.4.4.4 4.4.4.4 544 0x80000005 0x0007CF 2 Summary Net Link States (Area 1) Link ID ADV Router Age Seq# Checksum 155.1.37.0 3.3.3.3 1558 0x80000004 0x00A7C3 192.0.2.100 1.1.1.1 23 0x80000001 0x009F0C <- R6 Loopback 192.0.2.100 4.4.4.4 370 0x80000001 0x0059AA <- R6 Loopback 192.168.14.0 1.1.1.1 23 0x80000001 0x000B52 192.168.14.0 4.4.4.4 331 0x80000001 0x00CEE5 192.168.34.0 1.1.1.1 3608 0x80000002 0x00406C 192.168.46.0 1.1.1.1 23 0x80000001 0x00B388 192.168.46.0 4.4.4.4 484 0x80000001 0x006D27
Da saída que acima nós podemos ver que o r1 aprende R6 Lo100:192.0.2.100 através do R4 como um LSA sumário Type-3, r1 igualmente está originando-se um LSA sumário Type-3 desde que conhece R6 Lo100:192.0.2.100 através do backbone do intra-area. Na saída abaixo nós podemos ver que o R6 tem 192.0.2.100 conectado diretamente.
R1#show ip ospf da router 6.6.6.6 OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) LS age: 614 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 6.6.6.6 Advertising Router: 6.6.6.6 LS Seq Number: 8000000D Checksum: 0x5B0E Length: 60 Number of Links: 3 Link connected to: a Stub Network (Link ID) Network/subnet number: 192.0.2.100 <-- Loopback 100 directly connected (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 4.4.4.4 (Link Data) Router Interface address: 192.168.46.6 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 192.168.46.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1
16.2. Calculating the inter-area routes (5) Next, look up the routing table entry for the destination N. (If N is an AS boundary router, look up the "router" routing table entry associated with Area A). If no entry exists for N or if the entry's path type is "type 1 external" or "type 2 external", then install the inter-area path to N, with associated area Area A, cost IAC, next hop equal to the list of next hops to router BR, and Advertising router equal to BR. (6) Else, if the paths present in the table are intra-area paths, do nothing with the LSA (intra-area paths are always preferred). (7) Else, the paths present in the routing table are also inter-area paths. Install the new path through BR if it is cheaper, overriding the paths in the routing table. Otherwise, if the new path is the same cost, add it to the list of paths that appear in the routing table entry.
Na saída acima nós podemos ver que se indica que as rotas intra-áreas estão preferidas sobre rotas inter-área. Assim em nossa encenação o r1 deve preferir ir através do backbone do intra-area pelo RFC 2328.
Deixa a verificação se este comportamento é observado em nossa topologia:
R1#show ip ospf rib 192.0.2.100 OSPF Router with ID (1.1.1.1) (Process ID 1) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB LSA: type/LSID/originator *> 192.0.2.100/32, Intra, cost 102, area 0 SPF Instance 9, age 02:19:34 Flags: RIB, HiPrio via 192.168.14.4, GigabitEthernet3 label 1048578 Flags: RIB LSA: 1/6.6.6.6/6.6.6.6 R1#show ip route 192.0.2.100 Routing entry for 192.0.2.100/32 Known via "ospf 1", distance 110, metric 102, type intra area Last update from 192.168.14.4 on GigabitEthernet3, 02:26:29 ago Routing Descriptor Blocks: * 192.168.14.4, from 6.6.6.6, 02:26:29 ago, via GigabitEthernet3 Route metric is 102, traffic share count is 1
Como você pode ver das saídas acima nós preferimos ir sobre a área Backbone 0 para R6 loopback100. Em nosso base de dados do estado do link nós estamos igualmente cientes de um trajeto do inter-area com R3 então R4. O LSA sumário que é instruído através do R4 com um custo de 2 pode ser visto abaixo:
R1#show ip ospf database summary 192.0.2.100 OSPF Router with ID (1.1.1.1) (Process ID 1) Summary Net Link States (Area 1) LS age: 523 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 192.0.2.100 (summary Network Number) Advertising Router: 1.1.1.1 LS Seq Number: 80000005 Checksum: 0x9710 Length: 28 Network Mask: /32 MTID: 0 Metric: 102 LS age: 973 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 192.0.2.100 (summary Network Number) Advertising Router: 4.4.4.4 <- This is Type-3 LSA injected by ABR R4 LS Seq Number: 80000005 Checksum: 0x51AE Length: 28 Network Mask: /32 MTID: 0 Metric: 2
Leve em consideração por favor que este custo de 2 reflete o custo que o ABR tem para o prefixo de destino. Type-3 LSA são inundados da área 0 em áreas sem backbone e vice-versa, ele descrevem a alcançabilidade do ABR para os links em outras áreas. Inclui o custo da perspectiva ABR que enjected o Type-3 LSA, mas o custo completo dos couros crus do roteador que recebeu o Type-3 LSA.
Da saída acima nós sabemos agora que nós temos dois trajetos que nós poderíamos tomar para alcançar o laço de retorno R6 do r1:
1. Intra-area que tem um custo de 102
2. O inter-area que tem um custo de 2 conhecidos através de Type-3 LSA + r1 custa para o R4 que é igualmente 2. Isto dá-nos uns custos total de 4
Nesta encenação nós temos observado já que nós estamos preferindo um trajeto mais alto do intra-area do custo desde que se define no RFC 2328 que o intra-area está preferido sobre o inter-area.
Antes de continuar com encenação 2 está aqui um exemplo de como o OSPF interpreta Type-3 LSA:
• O ABR R4 pode alcançar o intra-area do link A com custo de X
• O r1 pode alcançar ABR R4 com um custo Y
• Implica o r1 pode alcançar o link A através do SPT com um custo de X + Y
Figura 3
Eis porque o roteamento inter-área é comparado geralmente com os protocolos de vetor de distância, desde que a informação entre áreas é hidden.
Porque o inter-area OSPF é vetor de distância, é vulnerável aos loop de roteamento. Evita laços encarregando uma topologia sem loop do inter-area, em que o tráfego de uma área pode somente alcançar uma outra área com a área 0.
Figura 4
Nesta encenação nós ajustamos o V-bit no R3 e no R4 assim que nós poderíamos verificar a preferência do trajeto quando este bit esta presente no tipo-1 LSA da área sem backbone 1.
6. The Area Data Structure TransitCapability This parameter indicates whether the area can carry data traffic that neither originates nor terminates in the area itself. This parameter is calculated when the area's shortest-path tree is built (see Section 16.1, where TransitCapability is set to TRUE if and only if there are one or more fully adjacent virtual links using the area as Transit area), and is used as an input to a subsequent step of the routing table build process (see Section 16.3). When an area's TransitCapability is set to TRUE, the area is said to be a "transit area".
16.1 Calculating the shortest-path tree for an area (2) Call the vertex just added to the tree vertex V. Examine the LSA associated with vertex V. This is a lookup in the Area A's link state database based on the Vertex ID. If this is a router-LSA, and bit V of the router-LSA (see Section A.4.2) is set, set Area A's TransitCapability to TRUE. In any case, each link described by the LSA gives the cost to an adjacent vertex. For each described link, (say it joins vertex V to vertex W):
Da indicação acima no RFC nós podemos ver que quando o V-bit é ajustado no LSA de roteador, nós conhecemos essa área em que o bit é ajustado para ser trânsito capaz ou em outras palavras ao executar o algoritmo de Dijkstra o TransitCapability é verdadeiro para essa área.
Uma vez que nós sabemos que uma área poderia ser considerada para o trânsito da capacidade se há um grupo do V-bit, nós devemos verificar se esta funcionalidade é configurada: A característica da capacidade do trânsito da área do OSPF é permitida à revelia.
R1#show run all | sec ospf router ospf 1 capability opaque capability lls capability transit
Para ajustar o V-bit na área 1 nós criaremos um link virtual do R3 para o R4. Quando o enlace virtual é trazido acima, nós devemos ver o V-bit ajustar-se no tipo-1 LSA.
R3(config)#router ospf 1 R3(config-router)#area 1 virtual-link 4.4.4.4 R3#show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C VL0 1 0 192.168.34.3/24 1 P2P 1/1 <-- Here we have Virtual-link present and 1 neighborship over VLO Gi3 1 0 192.168.80.3/24 1 DR 0/0 Gi2 1 1 192.168.13.3/24 1 P2P 1/1 Gi1 1 1 192.168.34.3/24 1 P2P 1/1 R3#
Deixa agora o tipo-1 LSA da verificação para R3 a área 1.
R3#show ip ospf 1 1 database router 3.3.3.3 OSPF Router with ID (3.3.3.3) (Process ID 1) Router Link States (Area 1) LS age: 189 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 3.3.3.3 Advertising Router: 3.3.3.3 LS Seq Number: 80000018 Checksum: 0x525E Length: 72 Area Border Router Virtual Link Endpoint <- V-bit set Number of Links: 4 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 1.1.1.1 (Link Data) Router Interface address: 192.168.13.3 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 192.168.13.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 4.4.4.4 (Link Data) Router Interface address: 192.168.34.3 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 192.168.34.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1
Como nós podemos ver na saída acima, o R3 agora tem o V-bit ajustado em seu tipo-1 LSA para a área 1 e tem o trânsito da capacidade permitido no nível do processo de roteamento.
Nós podemos igualmente ver que o r1 tem o trânsito cababilty permitido para a área 1 na saída abaixo:
R1#show ip ospf Routing Process "ospf 1" with ID 1.1.1.1 Start time: 00:02:48.412, Time elapsed: 01:27:00.690 Supports only single TOS(TOS0) routes Supports opaque LSA Supports Link-local Signaling (LLS) Supports area transit capability Supports NSSA (compatible with RFC 3101) Supports Database Exchange Summary List Optimization (RFC 5243) Event-log enabled, Maximum number of events: 1000, Mode: cyclic It is an area border router Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Incremental-SPF disabled Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs EXCHANGE/LOADING adjacency limit: initial 300, process maximum 300 Number of external LSA 0. Checksum Sum 0x000000 Number of opaque AS LSA 0. Checksum Sum 0x000000 Number of DCbitless external and opaque AS LSA 0 Number of DoNotAge external and opaque AS LSA 0 Number of areas in this router is 2. 2 normal 0 stub 0 nssa Number of areas transit capable is 1 External flood list length 0 IETF NSF helper support enabled Cisco NSF helper support enabled Reference bandwidth unit is 100 mbps Area BACKBONE(0) Number of interfaces in this area is 1 Area has no authentication SPF algorithm last executed 00:00:33.554 ago SPF algorithm executed 11 times Area ranges are Number of LSA 10. Checksum Sum 0x05EB7B Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 3 Flood list length 0 Area 1 Number of interfaces in this area is 1 This area has transit capability <-- This area is transit capabile Area has no authentication SPF algorithm last executed 00:00:04.259 ago SPF algorithm executed 8 times Area ranges are Number of LSA 10. Checksum Sum 0x0517AA Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0
Desde que a área 1 passa agora todos os critérios para se transformar uma área de trânsito nós devemos agora observar um cálculo/preferência diferentes do trajeto vistos então antes em nossa primeira encenação.
É RFC 2328 indicado se uma área é considerada como a área de trânsito que deva examinded diferentemente do que áreas do NON-trânsito
16.3. Examining transit areas' summary-LSAs This step is only performed by area border routers attached to one or more non-backbone areas that are capable of carrying transit traffic (i.e., "transit areas", or those areas whose TransitCapability parameter has been set to TRUE in Step 2 of the Dijkstra algorithm (see Section 16.1). The purpose of the calculation below is to examine the transit areas to see whether they provide any better (shorter) paths than the paths previously calculated in Sections 16.1 and 16.2. Any paths found that are better than or equal to previously discovered paths are installed in the routing table.
De acordo com o RFC, se a área é trânsito-capaz, é sujeita ao cálculo do trajeto descrito na seção 16.3 do RFC 2328
Note: que neste exemplo o enlace virtual permite o tráfego de dados de trânsito de ser enviado com a área 1, mas o trajeto real as tomadas do tráfego de dados de trânsito não precisa de seguir o enlace virtual. Ou seja os enlaces virtuais permitem que o tráfego de trânsito seja enviado com uma área, mas não ditam o trajeto preciso que o tráfego tomará.
Deixe-nos supor o trânsito da capacidade foi desabilitado no r1. Deixe-nos verificar o trajeto para o destino R6 loopback:100 192.0.2.100 com um traceroute.
R1#traceroute 192.0.2.100 Tracing the route to 192.0.2.100 VRF info: (vrf in name/id, vrf out name/id) 1 192.168.14.4 2 msec 2 msec 2 msec <--R4 2 192.168.46.6 3 msec 3 msec * <--R6
Uma vez que nós gerenciemos esta funcionalidade sobre com o grupo do V-bit na área 1 nós observamos os seguintes logs:
R1#debug ip ospf spf intra OSPF SPF intra debugging is on
R1#debug ip ospf spf inter OSPF SPF inter debugging is on R1#conf Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router ospf 1 R1(config-router)#capability transit R1(config-router)# *Aug 14 15:28:07.934: OSPF-1 INTER: Running spf for summaries in transit area 1 *Aug 14 15:28:07.934: OSPF-1 INTER: Summary transit processing lsid 192.0.2.100 adv_rtr 4.4.4.4 type 3 seq 0x8000000B *Aug 14 15:28:07.934: OSPF-1 INTER: Summary metric 2 *Aug 14 15:28:07.934: OSPF-1 INTER: found best path to adv_rtr: i,ABR [2] via 192.168.13.3, GigabitEthernet1, Area 1 orp_txit_adv_rtr 0.0.0.0 pathflag 0x0 *Aug 14 15:28:07.934: OSPF-1 INTER: Add transit path via area 1 *Aug 14 15:28:07.934: OSPF-1 SPF : Exist path: next-hop 192.168.13.3, interface GigabitEthernet1 *Aug 14 15:28:07.934: OSPF-1 INTRA: Route update succeeded for 192.0.2.100/255.255.255.255, metric 4, Next Hop: GigabitEthernet1/192.168.13.3 area 0
Deixa agora a verificação como rotas do r1 para R6 loopback100
R1#show ip ospf rib 192.0.2.100 OSPF Router with ID (1.1.1.1) (Process ID 1) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB LSA: type/LSID/originator *> 192.0.2.100/32, Intra, cost 4, area 0 SPF Instance 14, age 00:12:28 Flags: RIB, HiPrio, Transit via 192.168.13.3, GigabitEthernet1 label 1048578 Flags: RIB LSA: 1/6.6.6.6/6.6.6.6
R1#show ip route 192.0.2.100
Routing entry for 192.0.2.100/32
Known via "ospf 1", distance 110, metric 4, type intra area
Last update from 192.168.13.3 on GigabitEthernet1, 00:01:26 ago
Routing Descriptor Blocks:
* 192.168.13.3, from 6.6.6.6, 00:01:26 ago, via GigabitEthernet1
Route metric is 4, traffic share count is 1
Por que nós vemos o intra-area em vez do inter-area? Na seção 16.3 do RFC 2328 menciona-se que quando fazer o calulcation do trajeto se nós temos uma rota que seja dos custos mais baixos sobre a área de trânsito (Type-3) nós deve atualizar o salto seguinte do prefixo. Este é certamente o comportamento que nós estamos vendo na saída acima. O salto seguinte mencionado está correto, mas o tipo é enganador.
16.3. Examining transit areas' summary-LSAs
(4) Look up the routing table entry for the advertising router
BR associated with the Area A. If it is unreachable, examine
the next LSA. Otherwise, the cost to destination N is the
sum of the cost in BR's Area A routing table entry and the
cost advertised in the LSA. Call this cost IAC.
(5) If this cost is less than the cost occurring in N's routing table entry, overwrite N's list of next hops with those used for BR, and set N's routing table cost to IAC. Else, if IAC is the same as N's current cost, add BR's list of next hops to N's list of next hops. In any case, the area associated with N's routing table entry must remain the backbone area, and the path type (either intra-area or inter-area) must also remain the same.
O r1 está preferindo o inter-area Type-3 sobre o tipo-1 rota intra-área, embora se indique como o intra-area na saída. Nós vemos claramente que o salto seguinte não assosiated à área 0
R1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 4.4.4.4 0 FULL/ - 00:00:39 192.168.14.4 GigabitEthernet3 3.3.3.3 0 FULL/ - 00:00:32 192.168.13.3 GigabitEthernet1
R1#show ip ospf neighbor detail Neighbor 4.4.4.4, interface address 192.168.14.4 In the area 0 via interface GigabitEthernet3 Neighbor priority is 0, State is FULL, 6 state changes DR is 0.0.0.0 BDR is 0.0.0.0 Options is 0x12 in Hello (E-bit, L-bit) Options is 0x52 in DBD (E-bit, L-bit, O-bit) LLS Options is 0x1 (LR) Dead timer due in 00:00:36 Neighbor is up for 00:30:20 Index 1/1/1, retransmission queue length 0, number of retransmission 3 First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0) Last retransmission scan length is 1, maximum is 2 Last retransmission scan time is 135 msec, maximum is 135 msec Neighbor 3.3.3.3, interface address 192.168.13.3 In the area 1 via interface GigabitEthernet1 Neighbor priority is 0, State is FULL, 6 state changes DR is 0.0.0.0 BDR is 0.0.0.0 Options is 0x12 in Hello (E-bit, L-bit) Options is 0x52 in DBD (E-bit, L-bit, O-bit) LLS Options is 0x1 (LR) Dead timer due in 00:00:39 Neighbor is up for 00:30:20 Index 1/1/2, retransmission queue length 0, number of retransmission 3 First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0) Last retransmission scan length is 4, maximum is 4 Last retransmission scan time is 126 msec, maximum is 126 msec
Deixe-nos igualmente traceroute para o destino de R6 loopback100:
R1#traceroute 192.0.2.100 Tracing the route to 192.0.2.100 VRF info: (vrf in name/id, vrf out name/id) 1 192.168.13.3 2 msec 4 msec 3 msec <-- R3 2 192.168.34.4 5 msec 3 msec 3 msec <-- R4 3 192.168.46.6 5 msec 6 msec * <-- R6 R1#
Daqui na saída acima nós vemos que a área sem backbone 1 está preferida sobre a área Backbone 0 alcançar R6 o laço de retorno 100.
É igualmente possível ter ECMP (custos iguais Multipath) que usa o intra-area e as rotas inter-área se o custo entre eles é igual. Isto podia ser feito em nossa topologia diminuindo o link R1s para o R4 de 100 a 2.
Quando isto é feito nós temos a seguinte saída no RIB e no RIB OSPF:
R1#show ip ospf rib 192.0.2.100 OSPF Router with ID (1.1.1.1) (Process ID 1) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB LSA: type/LSID/originator *> 192.0.2.100/32, Intra, cost 4, area 0 SPF Instance 14, age 00:13:08 Flags: RIB, HiPrio, Transit, OldTrans via 192.168.13.3, GigabitEthernet1 label 1048578 Flags: RIB LSA: 1/6.6.6.6/6.6.6.6 via 192.168.14.4, GigabitEthernet3 label 1048578 Flags: RIB LSA: 1/6.6.6.6/6.6.6.6
R1#show ip route 192.0.2.100
Routing entry for 192.0.2.100/32
Known via "ospf 1", distance 110, metric 4, type intra area
Last update from 192.168.14.4 on GigabitEthernet3, 00:12:44 ago
Routing Descriptor Blocks:
192.168.14.4, from 6.6.6.6, 00:12:44 ago, via GigabitEthernet3
Route metric is 4, traffic share count is 1
* 192.168.13.3, from 6.6.6.6, 00:12:44 ago, via GigabitEthernet1
Route metric is 4, traffic share count is 1