Ethan Banks On productivity.

NMC DOiT Vol.2 Scenario 4 Day 2 – General Redistribution & BGP Comments


I got through Catalyst configuration, RIP, EIGRP, OSPF and route redistribution tonight. I also designed the BGP piece, although I’m out of time this evening to actually put the code on the routers.

The route redistribution was totally mind-blowing. I was way out of my league with that piece, and I knew it. I knew that they wanted me to use route tagging to meet all of the requirements, but I just couldn’t wrap my brain around how to make it all happen. So I decided that section would benefit me more if I worked through it with the answer key. That was definitely the right way to go. Working through this section with the answer key taught me a lot more than hacking and slashing my way through it like a Vogon writing poetry.

The redistribution section wanted me to do mutual redistribution between 3 different protocols: RIP, OSPF and EIGRP. Native protocols were always to be the preferred path to prefixes originated in that protocol. For example, a route originated in RIP was to be accessed via the RIP domain, not OSPF or EIGRP. That meant tweaking a lot of administrative distances, mostly to work around OSPF AD of 110 clobbering RIP AD of 120 and EIGRP external AD of 170. The scenario also said that you couldn’t filter routes on the redistribution process with a prefix-list or access-list…which left tagging the routes, and then making decisions about whether or not to redistribute a route based on the tag. So NMC’s solution was to create a tagging system using a 3 position binary number. If the tag was a “1”, that route was originated in RIP. If the tag was “10”, then it was originated in OSPF. “100” = EIGRP. “101” was an EIGRP route redistributed into RIP, and so on. There was a long route-map to then define the redistribution logic. Deny routes with this tag…deny tags with this other tag…permit this tag, but set the tag to this new value…permit the route with no tag, but set the tag to this value. And so on. It made for some long (although easy to read) route-maps.

What they were doing and why made sense. Back as a total geek 8th grader on my Commodore 64 programming in C-64 BASIC, I fooled around for a while with storing object values using bits to describe the object. I could describe an object with a decimal number, then perform a binary “and” operation to determine if the object was opened, closed, hot, cold, whatever. (I was working on my own Infocom-style game.) I had a whole long list of attributes I could keep in a number. So NMC’s technique immediately made sense, even if they were not strictly using binary numbers to make the tags happen. Would I have wanted to concoct that whole scheme sitting under the gun in the actual lab? Man…that’d be tough. Sit there and figure out all the dependencies for administrative distances and route tags to get the network to stably converge like the scenario required? Ugh. Ask me after about 20 more practice labs.

The BGP scenario doesn’t look too bad. As I said above, I haven’t actually implemented it. But it’s all designed on paper. One of the requirements states that 3 routers which are in one AS will need to be members of different AS’s…meaning a confederation. Okay, got that. There’s another tweak requiring a summary route. I don’t remember the syntax, but that should be easy to find. There’s a requirement for one path to be 3 times longer than another…which I can do with an AS prepend. There’s another requirement for one specific AS to be preferred as the path to routes originated in another AS. I haven’t nailed that down exactly yet, but I think setting metric is probably the easiest way to do that. I just don’t remember if metric is carried in eBGP advertisements. I’ll sort it out.

By Ethan Banks
Ethan Banks On productivity.

You probably know Ethan Banks because he writes & podcasts about IT. For example, he co-authored "Computer Networks Problems & Solutions" with Russ White.

This site is Ethan on productivity--not tech so much.

Find out more on his about page.