From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

IEWB Vol.3 Lab 6 – Connect 2 Separate OSPF Backbone Areas Via Redistribution + RIP v2 Without “version 2” Command + Multilink PPP over FR (MLPoFR)

575 Words. Plan about 3 minute(s) to read this.

I just finished off lab 6 in the InternetworkExpert.com volume 3 series. One odd problem was the creation of 2 physically separate OSPF backbone area. IE gave some rules stating that the backbone areas could not be joined via a virtual link on a couple of routers or a tunnel on yet a different router to resolve the problem. So I just created virtual links and a tunnel on other routers; everything worked fine. But that isn’t what IE was getting at. In the answer key, they really wanted the second OSPF backbone area to be created within a second OSPF process, and the routes redistributed back into the first OSPF process. Yes, my solution worked fine, but the way IE resolved the issue was not something I had considered.

One RIP detail was to configure version 2, but not use “version 2” in the “router rip” paragraph. They wanted “ip rip send version 2” and “ip rip receive version 2” on all the interfaces instead.

The BGP section was also strange. You know how IE tends to imply the way things are supposed to be, even if it’s not explicitly stated in the task? You get used to thinking that way. In the BGP section, they told me to configure a simple-to-build, but hopeless-to-put-traffic-through set of neighbors. I built the turd, and started looking at how in the world I was going to actually forward all the traffic. Then I paused for minute, and went back to the beginning of the lab. There was no requirement for BGP reachability. So I skipped it, and looked at the answer key, and sure enough – I was right. They just built the connectivity, showed the BGP advertisements showing up in everyone’s tables, and that was it. No reachability checks.

The “fun” part of this lab was building a multilink PPP over frame-relay. I’d never set one of these up before, but I was comfortable enough with it to make it go with little trouble. If you’re interested in this, here’s a diagram that I lifted from the IE lab, and then edited a bit. My code follows. The idea is to configure a hub-n-spoke, R4-R3-R5, using dual PVCs to each router, running PPP on top of the PVCs, and then bundling the PPPoFR links into multilink PPP. Note that on my IOS, the routers barked that they needed frame-relay traffic-shaping enabled for MLPoFR to work correctly. IE did not include FRTS in the answer key, although one of their outputs shows the same error as I was seeing. Something to keep in mind for the exam, as FRTS if left at defaults, could negatively impact other things in the frame cloud.

Multilink PPP over Frame Relay
©InternetworkExpert.com

!R3
interface Serial1/0
encap frame
frame-relay traffic-shaping
no shut

interface S1/0.34 p
frame-relay interface-dlci 304 ppp virtual-template1

interface S1/0.35 p
frame-relay interface-dlci 305 ppp virtual-template2

interface Serial1/1
encap frame
frame-relay traffic-shaping
no shut

interface S1/1.34 p
frame-relay interface-dlci 314 ppp virtual-template1

interface S1/1.35 p
frame-relay interface-dlci 315 ppp virtual-template2

interface virtual-template1
ppp multilink group 34

interface Multilink34
ip address 145.1.0.3 255.255.255.0

interface virtual-template2
ppp multilink group 35

interface Multilink35
ip address 145.1.0.3 255.255.255.0

!R4
interface Serial0/0/0
encap frame
frame-relay traffic-shaping
no shut

interface S0/0/0.341 p
frame-relay interface-dlci 403 ppp virtual-template1

interface S0/0/0.342 p
frame-relay interface-dlci 413 ppp virtual-template1

interface virtual-template1
ppp multilink group 34

interface Multilink34
ip address 145.1.0.4 255.255.255.0

!R5

interface Serial1/0
encap frame
frame-relay traffic-shaping
no shut

interface S1/0.351 p
frame-relay interface-dlci 503 ppp virtual-template1

interface S1/0.352 p
frame-relay interface-dlci 513 ppp virtual-template1

interface virtual-template1
ppp multilink group 35

interface Multilink35
ip address 145.1.0.5 255.255.255.0