Section 2: IPv4 IGP Protocols
Section 2.1: OSPF
We can the Hello timer, if there is a mismatch timers by using the command below:
■ All Loopback networks should not be advertised as host routes.
Loopback interfaces within OSPF will by default be advertised as host routes. To manipulate this behavior you need to override the network type that the IOS associates with the Loopback interface. The output below shows that the host routes learned from R2. Note that 120.100.123.3/32 is actually a host route generated by OSPF for the Frame Relay connection, so this is expected behavior and acceptable in the routing table.
R2#sh ip route | inc /32
O 120.100.1.1/32 [110/10417] via 120.100.123.3, 00:24:51, Serial6/0
L 120.100.2.1/32 is directly connected, Loopback0
O 120.100.3.1/32 [110/5209] via 120.100.123.3, 00:25:06, Serial6/0
O 120.100.5.1/32 [110/5209] via 120.100.25.5, 00:25:06, Serial6/1
L 120.100.25.2/32 is directly connected, Serial6/1
O 120.100.25.5/32 [110/5208] via 120.100.25.5, 00:25:06, Serial6/1
O 120.100.123.1/32 [110/10416] via 120.100.123.3, 00:24:51, Serial6/0
L 120.100.123.2/32 is directly connected, Serial6/0
O 120.100.123.3/32 [110/5208] via 120.100.123.3, 00:25:06, Serial6/0
L 150.100.2.1/32 is directly connected, FastEthernet3/1
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int l0
R1(config-if)#ip ospf network point-to-point
Requirements:
■ Use a process ID of 1; all OSPF configuration where possible should not be configured under the process ID. Do not change the preconfigured interface types where applicable, The Loopback interfaces of Routers R1, R2, and R3 should be configured to be in Area 0. R4 should be in Area 34 and R5 in Area 5.
■ All Loopback networks should not be advertised as host routes.
■ Ensure that R1 does not advertise the preconfigured secondary address under interface Gigabit 1/0 of 120.100.100.1/24 to the OSPF network. Do not use any filtering techniques to achieve this.
■ R5 should use the Frame Relay link within Area 5 for its primary communication to the OSPF network. If this network should fail either at Layer 1 or Layer 2, R5 should form a neighbor relationship with R4 under Area 5 to maintain connectivity. Your solution should be dynamic ensuring that while the Area 5 Frame Relay link is operational there is no neighbor relationship between R4 and R5; however, the Ethernet interfaces of R4 and R5 must remain up. To confirm the operational status of the Frame Relay network, you should ensure that the serial interface of R5 is reachable by configuration of R5. You are permitted to define neighbor statements between R5 and R4.
Configuration:
■ Use a process ID of 1; all OSPF configuration where possible should not be configured under the process ID. Do not change the preconfigured interface types where applicable, The Loopback interfaces of Routers R1, R2, and R3 should be configured to be in Area 0. R4 should be in Area 34 and R5 in Area 5.
Recent advances in OSPF have enabled configuration of the network area directly under the interface as opposed to within the OSPF process.
R1(config)# interface GigabitEthernet 1/0
R1(config-if)# ip ospf 1 area 100
R1(config)# interface Serial 6/0
R1(config-if)# ip ospf 1 area 0
R1(config-if)# interface Loopback 0
R1(config-if)# ip ospf 1 area 0
R2(config)# interface Loopback 0
R2(config-if)# ip ospf 1 area 0
R2(config-if)# interface Serial 6/0
R2(config-if)# ip ospf 1 area 0
R2(config-if)# interface Serial 6/1
R2(config-if)# ip ospf 1 area 5
R2(config-if)# interface FastEthernet 3/1
R2(config-if)# ip ospf 1 area 200
R3(config)# interface loopback 0
R3(config-if)# ip ospf 1 area 0
R3(config-if)# interface Serial 6/0
R3(config-if)# ip ospf 1 area 0
R3(config-if)# interface GigabitEthernet 0/0
R3(config-if)# ip ospf 1 area 34
R4(config)# interface Loopback 0
R4(config-if)# ip ospf 1 area 34
R4(config-if)# interface GigabitEthernet 0/0
R4(config-if)# ip ospf 1 area 34
R4(config-if)# interface GigabitEthernet 1/0.45
R4(config-if)# ip ospf 1 area 5
R5(config)# interface Loopback 0
R5(config-if)# ip ospf 1 area 5
R5(config-if)# interface GigabitEthernet 0/0
R5(config-if)# ip ospf 1 area 5
R5(config-if)# interface Serial 6/1
R5(config-if)# ip ospf 1 area 5.
Since Frame Relay NBMA networks won’t allow broadcasts or multicasts, an OSPF router will not attempt to dynamically discover any OSPF neighbors on the Frame Relay interface. Also, since this means that elections won’t be allowed, you’d have to statically confgure OSPF neighbors, plus the R2 router would need to be configured as a DR. Even though these are serial links, an NBMA network behaves like Ethernet and a DR is needed to exchange routing information. Only the R2 router can act as a DR because it would have the PVCs for all other routers. But the easiest way to fix this problem is to use the command ip ospf network point-to-multipoint on all router Frame Relay interfaces—not just the R2 router, but all branches too! Moreover, if the neighbor relationship is not formed, we also need to check the Hello and the Dead interval timers.
R1#show ip ospf int s6/0
Serial6/0 is up, line protocol is up
Internet Address 120.100.123.1/24, Area 0, Attached via Interface Enable
Process ID 1, Router ID 120.100.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 5208
Topology-MTID Cost Disabled Shutdown Topology Name
0 5208 no no Base
Enabled by interface config, including secondary ip addresses
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
oob-resync timeout 120
Hello due in 00:00:18
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 2/3, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 120.100.3.1
Suppress hello for 0 neighbor(s)
R3#show ip ospf int s6/0
Serial6/0 is up, line protocol is up
Internet Address 120.100.123.3/24, Area 0, Attached via Interface Enable
Process ID 1, Router ID 120.100.3.1, Network Type POINT_TO_MULTIPOINT, Cost: 5208
Topology-MTID Cost Disabled Shutdown Topology Name
0 5208 no no Base
Enabled by interface config, including secondary ip addresses
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
oob-resync timeout 120
Hello due in 00:00:10
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 2/3, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 2, Adjacent neighbor count is 2
Adjacent with neighbor 120.100.1.1
Adjacent with neighbor 120.100.2.1
Suppress hello for 0 neighbor(s)
We can the Hello timer, if there is a mismatch timers by using the command below:
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int 6/0
R3(config-if)#ip ospf hello-interval 30
R3(config-if)#^Z
R3#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
120.100.2.1 0 FULL/ - 00:01:59 120.100.123.2 Serial6/0
120.100.1.1 0 FULL/ - 00:01:58 120.100.123.1 Serial6/0
120.100.4.1 1 FULL/DR 00:00:38 120.100.34.4 GigabitEthernet0/0
■ All Loopback networks should not be advertised as host routes.
Loopback interfaces within OSPF will by default be advertised as host routes. To manipulate this behavior you need to override the network type that the IOS associates with the Loopback interface. The output below shows that the host routes learned from R2. Note that 120.100.123.3/32 is actually a host route generated by OSPF for the Frame Relay connection, so this is expected behavior and acceptable in the routing table.
R2#sh ip route | inc /32
O 120.100.1.1/32 [110/10417] via 120.100.123.3, 00:24:51, Serial6/0
L 120.100.2.1/32 is directly connected, Loopback0
O 120.100.3.1/32 [110/5209] via 120.100.123.3, 00:25:06, Serial6/0
O 120.100.5.1/32 [110/5209] via 120.100.25.5, 00:25:06, Serial6/1
L 120.100.25.2/32 is directly connected, Serial6/1
O 120.100.25.5/32 [110/5208] via 120.100.25.5, 00:25:06, Serial6/1
O 120.100.123.1/32 [110/10416] via 120.100.123.3, 00:24:51, Serial6/0
L 120.100.123.2/32 is directly connected, Serial6/0
O 120.100.123.3/32 [110/5208] via 120.100.123.3, 00:25:06, Serial6/0
L 150.100.2.1/32 is directly connected, FastEthernet3/1
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int l0
R1(config-if)#ip ospf network point-to-point
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int l0
R2(config-if)#ip ospf network point-to-point
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int l0
R3(config-if)#ip ospf network point-to-point
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#int l0
R4(config-if)#ip ospf network point-to-point
R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#int l0
R5(config-if)#ip ospf network point-to-point
R2#sh ip route ospf 1 | include /24
O 120.100.1.0/24 [110/10417] via 120.100.123.3, 01:31:32, Serial6/0
O 120.100.3.0/24 [110/5209] via 120.100.123.3, 01:33:36, Serial6/0
O IA 120.100.4.0/24 [110/5219] via 120.100.123.3, 00:15:18, Serial6/0
O 120.100.5.0/24 [110/5209] via 120.100.25.5, 01:31:47, Serial6/1
O IA 120.100.34.0/24 [110/5218] via 120.100.123.3, 01:33:36, Serial6/0
O 120.100.45.0/24 [110/5209] via 120.100.25.5, 01:31:47, Serial6/1
O IA 150.100.1.0/24 [110/10426] via 120.100.123.3, 01:31:32, Serial6/0
■ Ensure that R1 does not advertise the preconfigured secondary address under interface Gigabit 1/0 of 120.100.100.1/24 to the OSPF network. Do not use any filtering techniques to achieve this.
The associated behavior with configuring OSPF directly under the interface is that it will by default advertise any secondary addresses assigned to the interface. R1 has a preconfigured secondary address on interface Gigabit 1/0 that is therefore advertised. Because you cannot filter this advertisement, you need to inform OSPF not to include the secondary addresses under the interface command.
Adding a secondary address on g1/0 interface of R1
R1(config)#int g1/0
R1(config-if)#ip address 120.100.100.1 255.255.255.0 secondary
R1(config-if)#^Z
R1#sh ip ospf int g1/0
GigabitEthernet1/0 is up, line protocol is up
Internet Address 150.100.1.1/24, Area 100, Attached via Interface Enable
Process ID 1, Router ID 120.100.1.1, Network Type BROADCAST, Cost: 10
Topology-MTID Cost Disabled Shutdown Topology Name
0 10 no no Base
Enabled by interface config, including secondary ip addresses
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 120.100.1.1, Interface address 150.100.1.1
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:01
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Check the routing table on R2:
R2#sh ip route ospf | include /24
O 120.100.1.0/24 [110/10417] via 120.100.123.3, 01:31:32, Serial6/0
O 120.100.3.0/24 [110/5209] via 120.100.123.3, 01:33:36, Serial6/0
O IA 120.100.4.0/24 [110/5219] via 120.100.123.3, 00:15:18, Serial6/0
O 120.100.5.0/24 [110/5209] via 120.100.25.5, 01:31:47, Serial6/1
O IA 120.100.34.0/24 [110/5218] via 120.100.123.3, 01:33:36, Serial6/0
O 120.100.45.0/24 [110/5209] via 120.100.25.5, 01:31:47, Serial6/1
O IA 120.100.100.0/24 [110/10426] via 120.100.123.3, 00:01:52, Serial6/0
O IA 150.100.1.0/24 [110/10426] via 120.100.123.3, 01:31:32, Serial6/0
In order to inform OSPF not to include the secondary addresses under the interface command on R1, we can do:
R1(config)#int g1/0
R1(config-if)#ip ospf 1 area 100 secondaries none
Check the 120.100.100.0 network on R2's routing table to see whether R1 stops advertising it or not.
R2#sh ip route 120.100.100.0
% Subnet not in table
■
R5 should use the Frame Relay link within Area 5 for its primary communication to the OSPF
network. If this network should fail either at Layer
1 or Layer 2, R5 should form a
neighbor relationship with R4 under Area 5 to maintain connectivity. Your solution
should be dynamic, ensuring
that while the Area 5 Frame Relay
link is operational, there is no neighbor relationship between R4 and R5; however, the Ethernet
interfaces of R4 and R5 must
remain up. To confirm the
operational status of the Frame
Relay network, you should
ensure that the serial interface of R5 is reachable by configuration of R5. You are permitted to define neighbor statements between R5 and R4.
This is a complex scenario that can consume your time, but all the clues are in the question, so some lateral thinking is required. You can rule out a backup interface solution because the Ethernet needs to remain up, and the solution must cater for Layer 1 and Layer 2 rather than purely Layer 1. Similarly, a demand scenario is also out because this would involve a neighbor relationship being formed. You are also requested to confirm operational status of the Frame Relay interface on R5 with your overall solution being dynamic. This would take a great deal of effort and trial and error, but you will find that you can use the IP SLA feature to monitor the IP address of the Frame Relay interface on R5 by R5 itself. If this responds to the automatic polling with ICMP, you know the frame relay is up at Layers 1 and 2. (Layer 2 would also need to be up for a valid response because the ICMP packet would be sent over the Frame Relay network, and a local map to R5’s own IP address is required for this.) If the polling fails, you know the interface is down. IP SLA can then be used to inform the router, and a forwarding decision can be manipulated; this feature is known as Policy-Based Routing (PBR) support with multiple Tracking Options. This gives PBR access to all the objects that are available through the tracking process.
The tracking process provides the ability to track individual objects, such as ICMP ping reachability, and inform the required PBR process when an object state changes. In summary, if the object status changes, R5 can simply manipulate the way it sends traffic by policy routing. The traffic it manipulates needs to be OSPF that should be directed to R4 to form the adjacency over the Ethernet network (VLAN45), so when R5 Frame Relay is up and running, we just need to break the adjacency between R5 and R4. When the Frame Relay fails, we need to allow the adjacency between R5 and R4 to form. The first step in this solution is to configure the IP SLA object tracking on R5. Remember the additional map is needed locally, so it can ping its own serial interface;
This is a complex scenario that can consume your time, but all the clues are in the question, so some lateral thinking is required. You can rule out a backup interface solution because the Ethernet needs to remain up, and the solution must cater for Layer 1 and Layer 2 rather than purely Layer 1. Similarly, a demand scenario is also out because this would involve a neighbor relationship being formed. You are also requested to confirm operational status of the Frame Relay interface on R5 with your overall solution being dynamic. This would take a great deal of effort and trial and error, but you will find that you can use the IP SLA feature to monitor the IP address of the Frame Relay interface on R5 by R5 itself. If this responds to the automatic polling with ICMP, you know the frame relay is up at Layers 1 and 2. (Layer 2 would also need to be up for a valid response because the ICMP packet would be sent over the Frame Relay network, and a local map to R5’s own IP address is required for this.) If the polling fails, you know the interface is down. IP SLA can then be used to inform the router, and a forwarding decision can be manipulated; this feature is known as Policy-Based Routing (PBR) support with multiple Tracking Options. This gives PBR access to all the objects that are available through the tracking process.
The tracking process provides the ability to track individual objects, such as ICMP ping reachability, and inform the required PBR process when an object state changes. In summary, if the object status changes, R5 can simply manipulate the way it sends traffic by policy routing. The traffic it manipulates needs to be OSPF that should be directed to R4 to form the adjacency over the Ethernet network (VLAN45), so when R5 Frame Relay is up and running, we just need to break the adjacency between R5 and R4. When the Frame Relay fails, we need to allow the adjacency between R5 and R4 to form. The first step in this solution is to configure the IP SLA object tracking on R5. Remember the additional map is needed locally, so it can ping its own serial interface;
R5(config)# interface
s6/1
R5(config-if)# frame-relay
map ip 120.100.25.5 512 broadcast
R5(config-if)# exit
R5(config)# ip sla 1
R5(config-ip-sla)# icmp-echo 120.100.25.5
R5(config-ip-sla-echo)# ip sla schedule 1 life forever start-time now
R5(config)#track 1 rtr 1 reachability
OSPF needs to be configured between R4 and R5 with manual neighbor statements as directed in the question, which ensures the routers unicast traffic to each other. To do this you need to change the network type to nonbroadcast. The unicast traffic between neighbors can be identified by an ACL that the PBR process can match, and then instead of allowing normal traffic flow between R5 and R4 to form the neighbor relationship, the next hop can be modified and as the OSPF TTL is set to 1 by default, the traffic will effectively be dropped by the next hop and the OSPF between R5 and R4 will never establish. Similarly, when the object tracking fails, the PBR process will be overridden and traffic can flow as normal. This will then allow R5 and R4 to form an OSPF adjacency. So by using the PBR command set ip next- hop verify-availability 120.100.25.2 10 track 1, R5 can forward normal OSPF traffic to 120.100.25.2 (R2 Frame Relay to effectively discard the traffic) if the tracked object (1) is up. If the object status changes to down, the PBR process is informed, and the OPSF traffic to 120.100.25.2 would follow the usual next hop. R5 must be configured to locally policy route traffic because normal PBR behavior is for traffic manipulation for traffic that flows through the router rather than traffic generated by the router itself. The following configuration shows the required OSPF configuration on R4 and R5, the PBR on R5, a debug of R2 sending TTL expired to R5 after the OSPF traffic is sent to R2 instead of R5, and the resulting neighbor partial adjacency that is formed between R4 and R5.
OSPF needs to be configured between R4 and R5 with manual neighbor statements as directed in the question, which ensures the routers unicast traffic to each other. To do this you need to change the network type to nonbroadcast. The unicast traffic between neighbors can be identified by an ACL that the PBR process can match, and then instead of allowing normal traffic flow between R5 and R4 to form the neighbor relationship, the next hop can be modified and as the OSPF TTL is set to 1 by default, the traffic will effectively be dropped by the next hop and the OSPF between R5 and R4 will never establish. Similarly, when the object tracking fails, the PBR process will be overridden and traffic can flow as normal. This will then allow R5 and R4 to form an OSPF adjacency. So by using the PBR command set ip next- hop verify-availability 120.100.25.2 10 track 1, R5 can forward normal OSPF traffic to 120.100.25.2 (R2 Frame Relay to effectively discard the traffic) if the tracked object (1) is up. If the object status changes to down, the PBR process is informed, and the OPSF traffic to 120.100.25.2 would follow the usual next hop. R5 must be configured to locally policy route traffic because normal PBR behavior is for traffic manipulation for traffic that flows through the router rather than traffic generated by the router itself. The following configuration shows the required OSPF configuration on R4 and R5, the PBR on R5, a debug of R2 sending TTL expired to R5 after the OSPF traffic is sent to R2 instead of R5, and the resulting neighbor partial adjacency that is formed between R4 and R5.
R4(config)#int g1/0.45
R4(config-subif)#ip ospf network non-broadcast
R4(config-subif)#router ospf 1
R4(config-router)#neighbor 120.100.45.5
R5(config)#int g0/0
R5(config-if)#ip ospf network non-broadcast
R5(config-if)#router ospf 1
R5(config-router)#neighbor 120.100.45.4
R5(config-router)#exit
R5(config)#access-list 100 permit ospf host 120.100.45.5 host 120.100.45.4
R5(config)#route-map TEST permit 10
R5(config-route-map)#match ip address 100
R5(config-route-map)#set ip next-hop verify-availability 120.100.25.2 10 track 1
R5(config-route-map)#int g0/0
R5(config-if)#ip policy route-map TEST
R5(config-if)#exit
R5(config)#ip local policy route-map TEST
R2#debug ip icmp
ICMP packet debugging is on
R5#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
120.100.2.1 0 FULL/ - 00:01:55 120.100.25.2 Serial6/1
N/A 0 ATTEMPT/DROTHER - 120.100.45.4 GigabitEthernet0/0
The following configuration shows the OSPF adjacency formed when the Frame Relay between R2 and R5 is shut down on R5. The PBR is overridden and normal routing occurs because the next hop is not verified by the object tracking. Your routing table needs to be an exact replica as below. You must remember that when an OSPF adjacency forms between R5 and R2, you are joining Area 5 into Area 34 and a virtual-link between R3 and R4 is required to extend area 0. If you hadn’t configured a virtual-link it would have been an easy mistake that would take your points away.
R3(config)#router ospf 1
R3(config-router)#area 34 virtual-link 120.100.4.1
R4(config)#router ospf 1
R4(config-router)#area 34 virtual-link 120.100.3.1
R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#int s6/1
R5(config-if)#shut
R5(config-if)#
*Aug 19 20:14:46.067: %OSPF-5-ADJCHG: Process 1, Nbr 120.100.2.1 on Serial6/1 from FULL to DOWN, Neighbor Down: Interface down or detached
R5(config-if)#
*Aug 19 20:14:48.031: %LINK-5-CHANGED: Interface Serial6/1, changed state to administratively down
*Aug 19 20:14:49.031: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial6/1, changed state to down
R5(config-if)#do show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
N/A 0 ATTEMPT/DROTHER - 120.100.45.4 GigabitEthernet0/0
R5(config-if)#
R5#sh ip route ospf
Codes: L - local, 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, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
120.0.0.0/8 is variably subnetted, 15 subnets, 2 masks
O IA 120.100.1.0/24 [110/10481] via 120.100.25.2, 00:00:34, Serial6/1
O IA 120.100.2.0/24 [110/65] via 120.100.25.2, 00:00:34, Serial6/1
O IA 120.100.3.0/24 [110/5273] via 120.100.25.2, 00:00:34, Serial6/1
O IA 120.100.4.0/24 [110/5283] via 120.100.25.2, 00:00:34, Serial6/1
O 120.100.25.2/32 [110/64] via 120.100.25.2, 00:00:34, Serial6/1
O IA 120.100.34.0/24 [110/5282] via 120.100.25.2, 00:00:34, Serial6/1
O IA 120.100.123.1/32 [110/10480] via 120.100.25.2, 00:00:34, Serial6/1
O IA 120.100.123.2/32 [110/64] via 120.100.25.2, 00:00:34, Serial6/1
O IA 120.100.123.3/32 [110/5272] via 120.100.25.2, 00:00:34, Serial6/1
150.100.0.0/16 is variably subnetted, 4 subnets, 2 masks
O IA 150.100.1.0/24 [110/10490] via 120.100.25.2, 00:00:34, Serial6/1
O IA 150.100.2.0/24 [110/74] via 120.100.25.2, 00:00:34, Serial6/1
Section 2.2: EIGRP
No comments:
Post a Comment