IEWB-DYN Lab 5 – IGP Highlights

The IGP section again, was quite straight forward, with the usual OSPF over FR shenanigans going on, where by not being able to change one of the interface types, so have to match the others accordingly.

OSPF

This was a simple hub and spoke setup, with a NON_BROADCAST interface at the hub that couldn’t be changed. All other spoke interface were using the physical interfaces, so didn’t need to be changed, apart from R2 that was a point-to-point sub interface that needed to be changed to OSPF interface NON_BROADCAST. Always remember to set the spokes to priority 0 when on a NON_BROADCAST network so they don’t try to become the DR for the segment – and remember to manually specify the neighbors under the OSPF process on the DR (hub).

R3 (HUB)

router ospf 1
router-id 150.1.3.3
neighbor 162.1.0.2
neighbor 162.1.0.4
neighbor 162.1.0.5

Rack1R3#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
Internet Address 162.1.0.3/24, Area 0
Process ID 1, Router ID 150.1.3.3, Network Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DR, Priority 1

R2 (SPOKE)

interface Serial1/0.1 point-to-point
ip address 162.1.0.2 255.255.255.0
ip ospf network non-broadcast
ip ospf priority 0
frame-relay interface-dlci 203

Rack1R2#sh ip ospf int s1/0.1
Serial1/0.1 is up, line protocol is up
Internet Address 162.1.0.2/24, Area 0
Process ID 1, Router ID 150.1.2.2, Network Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DROTHER, Priority 0

EIGRP Metrics

There was a task to tweak EIGRP to use bandwidth, delay and load as part of the metric calculation. An additional task was to make sure the bandwidth value is 3 times more significant than delay and load.

Rack1R3#sh run | s eigrp
router eigrp 200
metric weights 0 3 1 1 0 0

The K values need to match on each device within the EIGRP AS, in order for the neighbor adjacency to form, so this needed to be applied to all routers within AS 200.

Routing Redundancy

Task to ensure R5 remains available when its FR connection goes down to the OSPF domain. There is a PP link configured between R4 and R5 (R4 is in the OSPF domain). This task stated that static routes were allowed, so this hinted at floating static routes.

Create routes on R4 pointing to R5 networks via the PPP link, but set them with an AD higher than the OSPF routes that are in the table.

ip route 150.1.5.0 255.255.255.0 162.1.45.5 111
ip route 162.1.5.0 255.255.255.0 162.1.45.5 111
ip route 162.1.55.0 255.255.255.0 162.1.45.5 111

Redistribute these statics into OSPF (they will only be distributed when the routes are actually in the table)

router ospf 1
router-id 150.1.4.4
redistribute static subnets

On R5 make sure there is a route out the the rest of the network when the FR (OSPF) link is down

ip route 0.0.0.0 0.0.0.0 162.1.45.4 111

As these routes have a manually configured AD of 111 which is higher than OSPF’s AD of 110 they don’t appear in the routing table when OSPF learned routes are present. Once the OSPF routes are removed the statics with the AD of 111 come into effect.

IGP Redistribution

The redistribution on this lab was quite easy, no multiple redistribution points, so no need for any filtering. There were a couple of differences between my solution and the SG, but it appeared to me that they had some additional configuration that wasn’t asked for (or needed) to get reachability across the network. A quick check on the IE forum showed that a few people had the same issue, so I decided to leave my solution as it was. Seeing as my ping scripts worked just fine.