710 Words. Plan about 3 minute(s) to read this.
I think I got in maybe 4 or 5 decent lab rack hours today. I spent part of the morning helping a friend move a piano, plus an hour this afternoon dealing with an unexpected phone call about one of my other web sites. Had those events not happened, I could have gotten in a bit more time. As things stand right now, I’m pretty fried. I ran into lots of new stuff today, all of which I was paying close attention to.
Today I completed OSPF, RIP, EIGRP and BGP configuration, with lots of mutual redistribution. I did a bit of reading to review basic concepts and brush up on syntax. For instance, it’s been a long time since I’d cranked up RIP on a router. This scenario requires RIP v2 only, and that’s a VLSM protocol. So I was thinking I’d be able to specify the mask in network statements for RIP. Nope, no can do. So stuff like that were stumblingblocks throughout the afternoon.
I’m finding that I really need to pay attention to what is being asked of me, a skill I’d best have nailed down before the real lab. In one step, I was told to set up BGP on a couple of routers in specific AS’s. Which I did. And then I proceeded to peer the 2 routers as eBGP peers, which so happened to require multihop. And I got that all done, and was checking out my established neighbor relationship, and doing some traceroutes. I was trying to figure out exactly the minimum number of hops to put into the ebgp-multihop. I was getting a little impatient, so I popped over to the SHOWiT engine, to see what NMC thought the right setting was. And SHOWiT didn’t have those routers peered. Duh – I didn’t need to peer those routers at all…when I looked back at the instructions, the scenario didn’t specify that the routers were to be peered. I was doing more than I should have been, and burned 10 or so minutes in the process. Doing things like that in that real lab would be bad. So, lesson learned.
There were 2 major challenges in the scenario thus far.
- Multipoint mutual redistribution. In this case, there were 2 routers sitting at the edge of the same OSPF and RIP domains, and both routers were mutually redistributing between OSPF and RIP. The issue is that RIP routes redistributed into OSPF would be redistributed BACK into RIP by the other router. And that could cause a convergence issue – OSPF has an AD of 110 and RIP has an AD of 120. Meaning that native RIP routes would end up heading towards the OSPF cloud. Solution? Use the distance command in the router rip paragraphs to set the AD of RIP routes to 105 (some number lower than 110) so that RIP routes learned from RIP neighbors would stay in the routing table, and not get shoved out by redistributed RIP routes showing up in OSPF.
- Setting up an iBGP transit AS with the fewest number of peers. The scenario layered a number of external BGP AS’s, with a central AS meant to be used as a transit AS. Since the requirement was for the least number of peers, that meant you couldn’t use the default iBGP full-mesh in the transit AS. Therefore, using route-reflectors or confederations was the answer to reduce peer count. The answer key recommended confederations in this particular scenario, because route-reflectors would have been difficult to layer over the underlying OSPF network. The reason for that difficulty had to do with Router IDs, and I didn’t quite grasp all the issues tied up in that. Something I need to go back and read.
So, I made a lot of progress today, but I am already behind schedule. I should have had lab #1 done today. That’s okay – I expected the first batch to go a bit slower, since I’m pretty much a rookie. There’s so many things that won’t be a problem, going forward. Like IPv6. I have that section next. I’m completely green with IPv6. So, it’s going to take me a while to plow through that section. But next scenario, it shouldn’t be nearly so bad.
about | subscribe | @ecbanks