Przerabiam część EIGRP z: CCNP v6 ROUTE i na stronie 26 zaczyna się: Chapter 2 Lab 2-2, EIGRP Load Balancing. Taka sama topologia w GNS3, z tym, że połączenia serialowe są:
R1
Serial0/0 connected to R2 on port Serial0/0
Serial2/0 connected to R3 on port Serial2/0
R2
Serial0/0 connected to R1 on port Serial0/0
Serial0/1 connected to R3 on port Serial0/1
R3
Serial0/1 connected to R2 on port Serial0/1
Serial2/0 connected to R1 on port Serial2/0
Podpunkt f. z Step 5 na str. 37 to ćwiczenie, w którym należy pingować 10.1.102.1 z R3, wszystko wykonane zgodnie z instrukcjami, poza tym, że wyłączone jest w obliczaniu metryki K1.
Kod: Zaznacz cały
R3#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
C 10.1.3.8/30 is directly connected, Loopback39
D 10.1.2.8/30 [90/640000] via 10.1.203.2, 00:14:23, Serial0/1
D 10.1.1.8/30 [90/640000] via 10.1.103.1, 00:14:23, Serial2/0
C 10.1.3.0/30 is directly connected, Loopback31
D 10.1.2.0/30 [90/640000] via 10.1.203.2, 00:14:23, Serial0/1
D 10.1.1.0/30 [90/640000] via 10.1.103.1, 00:14:23, Serial2/0
C 10.1.3.4/30 is directly connected, Loopback35
D 10.1.2.4/30 [90/640000] via 10.1.203.2, 00:14:25, Serial0/1
D 10.1.1.4/30 [90/640000] via 10.1.103.1, 00:14:25, Serial2/0
C 10.1.103.0/29 is directly connected, Serial2/0
D 10.1.102.0/29 [90/1024000] via 10.1.203.2, 00:14:25, Serial0/1
[90/1024000] via 10.1.103.1, 00:14:25, Serial2/0
C 10.1.203.0/29 is directly connected, Serial0/1
Kod: Zaznacz cały
R3#show ip route 10.1.102.1
Routing entry for 10.1.102.0/29
Known via "eigrp 100", distance 90, metric 1024000, type internal
Redistributing via eigrp 100
Last update from 10.1.203.2 on Serial0/1, 00:15:14 ago
Routing Descriptor Blocks:
10.1.203.2, from 10.1.203.2, 00:15:14 ago, via Serial0/1
Route metric is 1024000, traffic share count is 1
Total delay is 40000 microseconds, minimum bandwidth is 64 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 11/255, Hops 1
* 10.1.103.1, from 10.1.103.1, 00:15:14 ago, via Serial2/0
Route metric is 1024000, traffic share count is 1
Total delay is 40000 microseconds, minimum bandwidth is 64 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Kod: Zaznacz cały
*Mar 1 01:38:32.743: IP: tableid=0, s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), routed via RIB
*Mar 1 01:38:32.743: IP: s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), len 100, sending
*Mar 1 01:38:32.747: IP: tableid=0, s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), routed via RIB
*Mar 1 01:38:32.747: IP: s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), len 100, sending
*Mar 1 01:38:32.787: IP: tableid=0, s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), routed via RIB
*Mar 1 01:38:32.787: IP: s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), len 100, sending
*Mar 1 01:38:32.795: IP: tableid=0, s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), routed via RIB
*Mar 1 01:38:32.799: IP: s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), len 100, sending
Dlaczego tak się dzieje? skoro są 2 trasy do 10.1.102.1 i wyłączony CEF to czy R3 w przypadku padu połączenia z R1 nie powinien od razu pchać całości ruchu przez R2?