Fredrik's CCNP thread

fredrikjj

Two years of work experience, mostly switching, and I passed the CCNA three months ago. I'm currently unemployed so I have plenty of time to study. I'm three weeks into my Route studies, with the FLG and GNS3 being the main tools. Target is mid December. So far I've done a first pass of EIGRP, OSPF, Redist. and Path Control by reading the FLG and doing the labs in that free Cisco lab manual*. My strength is probably that I pick up how to configure things fairly quickly, but have a harder time memorizing things from books. I also don't mind a 5-6 hour lab session, but I really struggle with reading for that amount of time. So far, the hardest topic has been Route Maps, and the easiest probably EIGRP, but I'm predicting that my actual weak area will end up being IPv6.

I'm currently working on BGP and will use the rest of the week to get to know that protocol before moving on to the next chapter. On a high level it totally makes sense to me but I'm struggling with some of the details.


*This would actually be my first question to the community. Is that book really enough? The EIGRP and OSPF labs feel a bit too easy to me.

Ismaeljrp

I've been up to date with a lot of CCNP threads. As far as I can tell, you can probably get by with just the FLG and lots of labbing, you would have to get better at studying from the book though, especially consider taking really good notes that way you don't have to re-read chapters.

Now, most people use 2 books from what I've seen. I think it's more of a repetition thing, it helps reinforce the knowledge, but even better, you might find things the FLG missed or you might begin to understand some topics better from a different style of writing.

CCNP Route Simplified is a good book, I got it on kindle for $5. I have the FLG also. But I'm still doing CCNA Sec before I get into ccnp studies.

Dieg0M

I went through a similar path then you. I don't know what you mean by "that free Cisco lab manual" but I would highly suggest the CCNP Route SLM, it helped me a lot by practicing concepts in a lab environment. Just google CCNP Route SLM to find it. Also, it's important that you identify what type of learner you are to be efficient in your studies. From what you've indicated in your post, I believe you are a Kinesthetic Learner and would benefit the most from doing labs several times.

Good luck in your studies and remember to check in with us on your progress.

fredrikjj

Ismaeljrp wrote: »

I've been up to date with a lot of CCNP threads. As far as I can tell, you can probably get by with just the FLG and lots of labbing, you would have to get better at studying from the book though, especially consider taking really good notes that way you don't have to re-read chapters.

Yes I definitely need to get better at straight up learning from books. My CCNA strategy was basically to read Lammle's book over and over (and lab with freeccnaworkbook.com). I might have read it 4 or 5 times total and that was a fairly painful experience. I heard later that it wasn't really the best book out there, but it was apparently enough to pass.

DiegoM wrote:

I went through a similar path then you. I don't know what you mean by "that free Cisco lab manual" but I would highly suggest the CCNP Route SLM, it helped me a lot by practicing concepts in a lab environment. Just google CCNP Route SLM to find it. Also, it's important that you identify what type of learner you are to be efficient in your studies. From what you've indicated in your post, I believe you are a Kinesthetic Learner and would benefit the most from doing labs several times.

Good luck in your studies and remember to check in with us on your progress.

Route SLM is the book I meant. I guess it's fine, but I would prefer to use one larger topology and continually build on that instead of working on each technology in isolation. If there is such a book, I'll certainly get it. I have a feeling that I would enjoy some of the CCIE material out there since it's tailored towards doing one large lab, but it's obviously too in depth.

fredrikjj

Day 21

I had a very good session last night and put in a good 5 hours or so of BGP. I read most of the FLG chapter up until the configuration examples started, and then built what I imagined a multihomed enterprise topology would look like. I then applied all the configuration examples to that toplogy. Everything worked, except that I failed to prevent routes learned from ISP1 from being propagated to ISP2. This turned my little enterpise into a transit path for those ISPs, something the book warned me about. A sidenot here is that although these Cisco press books aren't known for their humour, I actually laughed a bit when they explicitly told you that a reason not to use BGP was "if you don't know what you are doing".

Anyway, I thought that I knew how to prevent this from happening and created a standard deny access-list and applied it with the "distribute-list out interface" command on the edge routers of the enterprise. Routes still flowed from ISP1 to ISP2 so I must have messed up somewhere. I'll have to look into this today. I'm assuming that I only want to advertise routes originating inside the enterprise, and deny everything else.

FloOz

Goodluck in your studies!

fredrikjj

FloOz wrote: »

Goodluck in your studies!

Thanks!

fredrikjj

Day 22

Before I start, if anything sounds dumb, call me on it because
I need to know if I have misunderstood something.

I labbed my way through the rest of the
BGP chapter and configured local preference and the MED and some
other things. I managed to fix the route filtering issue from
yesterday. Instead of using the neighbor x.x.x.x distribute-list
command I had used just distribute-list without a neighbor statement.

I then found a cisco document called
”bgp case studies”. I read through most of that document and
ended up at a seven router lab with 4 or 5 different ASes. I fired up
GNS3 and used the initial configurations that the article supplied.
Instead of working as expected, I spent the next hour troubleshooting
this thing.

I realized that they hadn't used a mask
statement when advertising their networks. The result of this was
that only the networks that were in the routing table with their
classful mask were actually advertised. For example, one router had
loopback0 with 205.102.50.0/24 and the network statement
205.102.50.0. This route was advertised. Another router had a /26
loopback, but no mask command which made it fail. On the routers
where the loopbacks weren't /24s, I had to create ip routes pointing
to null0 to propagate them throughout the topology.


Another issue I ran into was that they
wanted you to redistribute BGP into the IGP. From everything else
I've read, this isn't a good idea because you risk overloading the
IGP with routes. I'm also speculating that it's not the
smartest thing to make your IGP do a reconvergence because a network
in a different AS is flapping, which I assume would happen if that
route is redistributed into your IGP, and your eBGP router gets
notified by its peer that the network is gone.

The FLG solution is to use iBGP peering between the
internal routers so I did that instead of redistributing. I'm a bit
confused though because unless you want to run iBGP on every router,
you'll eventually lose the bgp routes. How does some random router
deep in your topology, that isn't running iBGP, know the optimal path
out of your network? I'm guessing that it simply doesn't. I'm also
assuming that this is where the route reflector concept comes into
the picture; to get bgp routes to everyone without this iBGP full
mesh thing.

powmia

Regarding your last paragraph:

When running eBGP on routers at the edge of your network, you need iBGP on any routers that are in the path between your edge routers (to prevent loops). Other routers in your network don't need and shouldn't have the internet routing table. They only need to be able to get to a device that does know how to properly exit the network; hence, edge devices originating default routes into the IGP.

fredrikjj

Day 23

I did the 5 BGP labs in the Route SLM book. I only really struggled with the as-path configuration since I've never worked with regular expression before. My confidence reached an all time high when I crushed the last one, the "Challenge Lab". At that point I couldn't stop myself from going online and finding a way bigger and harder ccie style BGP lab, and that one demoralized me completely and made me realize that I really don't know what I'm doing. "Do this" it said and I thought "very well, I know that", but don't use "x, y or z to accomplish it" and I was like damn I'm screwed. My session started at 4 PM and didn't stop until 1 AM or so.

Probably not the wisest investment of time to try such a hard lab (just the ip and igp configuration took way too long), but it did expose me to a clever way of not readvertising routes coming from outside the AS. One of the SLM labs makes you use an access-list that matches your internal networks and applying this list with the neighbor distribute-list command. Applying an as-path list with permit ^$ (i.e. no "path") feels much cleaner. I can see the distribute-list method becoming clumsy if you have many networks.

At this point I feel finished with my first review of BGP and will move on to the next chapter.

fredrikjj

powmia wrote: »

Regarding your last paragraph:

When running eBGP on routers at the edge of your network, you need iBGP on any routers that are in the path between your edge routers (to prevent loops). Other routers in your network don't need and shouldn't have the internet routing table. They only need to be able to get to a device that does know how to properly exit the network; hence, edge devices originating default routes into the IGP.

That makes sense. I think I got hung up on the idea of every router needing to know what BGP knows. As long as it somehow gets to something running BGP that router will apply the policy. The lab I did yesterday had 2 edge routers running eBGP, multihomed with 2 ISPs. They peered with 2 iBGP routers that just used a default route to those edge routers (or to their hsrp ip actually). In that case, traffic will get to either of those edge routers and then sent on its way.

I guess my issue with this is that while that might work fine with that basic enterprise style multihoming, what happens if you have say 5 exits and rely on your IGP/defaults to get to the border routers? If certain traffic is supposed to go out a specific exit (let's call it "right"), but your IGP sends it "left". Left applies the bgp policy, and sends it across the network again to reach Right. If you ran iBGP, the traffic would know to go Right, and not Left. Unless you tinkered with the internal routing to align the traffic flow with the BGP policy? But if you need to actively make traffic reach a certain BGP peer, wouldn't you just run iBGP?

This is how confused a brain gets after 5 days of BGP.

fredrikjj

Day 24 & 25

I read and configured most of the concepts in chapter 7, "The Branch Office". The text started out with a ton of techno babble about cable and dsl that I'm not going to remember. Hopefully, you are not required to know that sdsl is discontinued in favor of shdsl or that upstream is handled by this or that frequency range. Not a fan of that kind of trivia. But, just as I had decided that this was the worst chapter in the book, there was a long (the rest of the chapter actually) case study on migrating a branch office from a private line (I used a frame relay link) to an IPsec VPN with a GRE tunnel. They maintained the same topology throughout the chapter and simply added or removed features as the case progressed. I really wish all chapters were constructed this way because it makes it very easy to lab along with GNS, or real hardware for that matter.

There were some problems however. Primarily the fact that they didn't supply complete configurations on certain aspects of this migration to VPN/GRE while simultaneously saying that how to actually configuring it was outside of the scope of this text. If it's outside the scope, you need to actually give me the complete configs. After nailing the NAT configuration, I got stuck because they only supplied the VPN commands for one of the routers. After cursing a lot I realized that the chapter 7 lab in the Route SLM book is the exact same case, and they gave you the configuration for both sides. With everything in place I could finally get my GRE tunnel going, which seemed like a very neat thing indeed.

Despite the dreadful first 10 or 15 pages, an enjoyable chapter. My plan for the next week is to go as deep as I can with IPv6.

fredrikjj

I'm thinking about booking a practice exam in early November. It will motivate me to study harder in hopes of somehow passing (unlikely), but more importantly, it might calm my nerves in anticipation of December when I had actually planned to make my first attempt. I feel like I really need to have more to go on than that useless exam blueprint. Is this a good or bad idea?

Another thing I'm going to do is to switch to a US keyboard layout to emulate the exam experience as much as possible. During the CCNA I felt so slow on the sims because I had no idea about the keyboard.

MrBrian

Great work just keep reading and labbing!

fredrikjj

Day 26, Sunday 29/9

I started on the IPv6 chapter and I seem to have built up a higher work capacity because the four or five hours I spent didn't feel like that much. If I can maintain this pace I feel like I'm in a very good place. Anyway, I managed to read and lab my way up until the BGP section. The chapter is actually very clever in the way it's set up, with each section being a smaller v6 version of the other chapters. It'll make it easy to simply incorporate each of those sections into the study of the corresponding v4 chapters instead of looking at it in isolation.

As I'm approaching the end of this initial review, I'll need to figure out what my approach is going to be moving forward. One thing that's on the agenda is building a single topology that's compatible with all the topics. There's simply no reason for me spend time on labbing things from blank configs, assigning ip addresses or enabling routing protocols on interfaces. And since I'm using GNS3 on a decent computer I'm not really limited when it comes to the number of routers. If someone already has a suitable topology, let me know.

powmia

fredrikjj wrote: »

That makes sense. I think I got hung up on the idea of every router needing to know what BGP knows. As long as it somehow gets to something running BGP that router will apply the policy. The lab I did yesterday had 2 edge routers running eBGP, multihomed with 2 ISPs. They peered with 2 iBGP routers that just used a default route to those edge routers (or to their hsrp ip actually). In that case, traffic will get to either of those edge routers and then sent on its way.

I guess my issue with this is that while that might work fine with that basic enterprise style multihoming, what happens if you have say 5 exits and rely on your IGP/defaults to get to the border routers? If certain traffic is supposed to go out a specific exit (let's call it "right"), but your IGP sends it "left". Left applies the bgp policy, and sends it across the network again to reach Right. If you ran iBGP, the traffic would know to go Right, and not Left. Unless you tinkered with the internal routing to align the traffic flow with the BGP policy? But if you need to actively make traffic reach a certain BGP peer, wouldn't you just run iBGP?

This is how confused a brain gets after 5 days of BGP.

If you have a specific destination that you want to have a preferred exit point, the easiest way is to leak the more specific prefix into your IGP at that point, then rely on the default for everything else.

fredrikjj

powmia wrote: »

If you have a specific destination that you want to have a preferred exit point, the easiest way is to leak the more specific prefix into your IGP at that point, then rely on the default for everything else.

Again, that makes sense. Thanks.

MrBrian wrote: »

Great work just keep reading and labbing!

fredrikjj

Day 27, tunnels tunnels tunnels tunnels

I continued my adventure in IPv6 land, reading and labbing policy based routing, some redistribution and all the 5 (!) different tunnel types. I struggled with redistribution because my v4 redistribution knowledge is weak. So weak in fact that I should probably make it priority number one once I've finished off the rest of the IPv6 chapter later today.

Tangentially speaking, my first thought when I realized that ipv6 routing protocols used the link local addresses to communicate, and that those were installed in the routing table was like "holy crap those are ugly". A full ip6 address with a mac based host portion is f***ing dreadful to look at. So, I've developed a method for dealing with this madness. If the global address is say 2001:10::1/64 I manually assign the link local fe80:10::1, and 2001:2::4 becomes fe80:2::4 - you get the picture. This is extra configuration, but it makes debug output legible and removes "via FE80:T#":TAA3F:GA#"ATAG:ASTAGHAO" crap from the routing table. I have no idea how "real world" this solution is, but at this point it makes a ton of sense to me. Ultimately though (see next point) I don't know if people even assign a global address on the physical interfaces, but they sure do in the book.

I like that the addresses used for protocol communication is separated from the routed networks. It feels very clean because once you leave a segment, you have no reason to be able to communicate directly with a physical interface, right, so why do we have all those things in the routing table in ospv2? Because ipv4 doesn't have link-local. The question that it raises in me is if you could just emulate this in v2 by filtering the routes to the physical interfaces at each router. Or... you could run IPv4 on OSPFv3 mind = blown.

PS.
Another thing that's been on my mind lately is how badly I would fail certain switch specific topics if I had a job interview right now. Spanning-tree was a weak area for me during the CCNA, and I think they expect junior guys to not be completely lost in a basic spanning-tree topology. I have worked with switching, but it was a 0 STP environment (diff. vendor proprietary protocol). With that in mind, it would probably be a good idea to review the CCNP Switch material for a month right now before going truly deep into Route. But I don't have switches or the means to buy them, nor the motivation to learn how to set up the "evil" way to do switch.

I'm just going to continue with Route, and if they ask me about STP stuff I guess I'll have to say "sorry, I don't know" followed by "but I could set up a nice layer 3 access layer for you, how about that?". And "oh, you need layer 2 connectivity? I guess I would just extend a L2 MPLS VPN to the desktop". Don't worry, I wouldn't actually say that... or would I?

In all seriousness, I'm the worst at job interviews.

fredrikjj

Day 28, ipv6 lab day

I did the 5 ipv6 labs in the Route SLM book and took some notes

ipv6 lab 1, OSPFv3

-configure a static ipv6 address on an interface
router(config-if)#ipv6 address FEC0::12:0/112

-Change the default link-local address on an interface
router(config-if)#ipv6 address FE80:12::1 link-local

-configure an eu-64 ipv6 address on an interface
router(config-if)#ipv6 address prefix/64 eu-64

-enable ipv6 routing and cef
router(config)#ipv6 cef
router(config)#ipv6 uni

-single area ospfv3
router(config-rtr)#router-id 0.0.0.1
router(config-if)#ipv6 ospf 1 area 0

Walkthrough needed? no. easy lab.

ipv6 lab 2, Manual Tunnel

-configure EIGRP for ipv4
network 0.0.0.0 <- im lazy

-create a manual ipv6 tunnel
int tun0
tunnel mode ipv6ip
tunnel dest <remote loopback>
tunnel source <local loopback>
ipv6 address fec0::13:1/112

-eigrp ipv6 over the tunnel
ipv6 router eigrp 1
no shut (no shut by default on my ios ver though)
int tun0
ipv6 eigrp 1
walkthrough need: no. I remembered this tunnel type well from yesterday.

ipv6 lab 3, 6to4 tunnel

A 6to4 tunnel doesn't have a link-local address. this makes dynamic routing protocols fail (except bgp) and the lab wants you to configure static routing to overcome this.

-configure eigrp for v4
this lab reuses the topology of lab 2

-create a 6to4 tunnel
tunnel mode ipv6ip 6to4
ipv6 add <2002 ipv6 version of ip4 address>
tunnel source <exit ip4 interface>

Around here is where I started failing.

Walkthrough needed? Yes. I found this one much more confusing than the manual tunnel. I'm confused because the FLG has two seemingly conflicting quotes on what ip4 address is actually used to convert into the 2002 adress.

"Each 6to4 edge router, which is a dual-stacked device, has an IPv6 address with a /48 prefix, which is the concatenation of 2002::/16 and the hexadecimal representation of the IPv4 address of that edge router."

"Notice that the configuration is similar to the manual and GRE tunnel configurations. One difference is that the tunnel destination is not specified, because the destination IPv4 address is embedded in the IPv6 address."

The lab walkthrough says that the ipv6 address in the tunnel configuration is a transformation of the ip4 on the LOCAL device. That begs the question of how the tunnel finds its other end.

I basically just copied the commands in the walkthrough and it worked.

IPv6 lab 4, Challenge Lab

1. Configure all interfaces in the topology diagram with the IPv4 or IPv6 addresses shown.
self explanatory

2. Use EUI-64 addresses on the link between R3 and R4.
ipv6 address fec0:34::/64 eui-64

3. Configure EIGRP AS 1 on R1, R2, and R3 to route all IPv4 networks.
router eigrp 1
network 0.0.0.0

4. Disable EIGRP automatic summarization.
no auto - off by default in modern ios.

5. Configure a manual IPv6 tunnel between R1 and R3.
R1
int tun0
tunnel mode ipv6ip
tunnel destination 172.16.23.3
tunnel source s1/0
ipv6 add FEC0::13:1/112
R2
int tun0
tunnel mode ipv6ip
tunnel destination 172.16.12.1
tunnel source s1/0
ipv6 add FEC0::13:3/112

6. Include all IPv6 networks in OSPF area 0 on R1, R3, and R4.
ipv6 unicast-routing
int tun0
ipv6 ospf 1 area 0
etc
ping R1 lo0 -> R4 lo0 successful.

7. Manually configure a router ID of 172.16.4.1 on R4 (this address does not need to be reachable).
ipv6 router ospf 1
router-id 172.16.4.1

8. Remove the OSPFv3 configuration commands from R1, R3, and R4 and configure RIPng to run on
these routers using RIP1 as the process name.
router(config)#no ipv6 router ospf 1. This removes all the interface specific configuration automagically.
router(config-if)#ipv6 rip RIP1 enable

Walkthrough needed?
There is no walkthrough, but I found this one very straightforward. I assumed that there would be some kind of trickery going on with the tunnel and RIP but it seemed to work. R1 learned routes from R4 through the tunnel interface. It would have been a bit more interesting if they had used an ISATAP tunnel, which doesn't support multicast. In that scenario, RIP would have failed, but it would have possible to configure unicast OSPF.

IPv6 lab 5, troubleshooting lab

R1.
OSPF not enabled on Lo0

R4.
s1/0 running in ospf process 100

Found nothing in R2/3. I made a tcl script and pinged everything successfully from everywhere.

fredrikjj

How I Passed the CCIE Data Center Lab Exam

The methodology is a basic four step process as follows:

• Gain a basic understanding of the technologies
• Gain basic hands-on experience to reinforce and expand your understanding
• Gain an expert level of understanding
• Gain an expert level of hands-on experience

It might seem self-explanatory that you need to start at the bottom and work your way up, i.e. A then B then C then D, however over the years we’ve seen so many CCIE candidates try to shortcut this process and try to go from A directly to D.

I'm at B now, having read 95% of the FLG and done all the labs in the SLM. My hunch is that C will be the most challenging for me. Reading, rereading and taking extensive handwritten notes is going to be my approach. It's painful, but it's ultimately going to be worth it.

That mid December target that I mentioned in the first post leaves me with around 10 weeks (and a nice even 100 days of studying). I don't know how slow this reading and note taking is going to be so before creating any kind of elaborate schedule I'm going to attempt to do the EIGRP chapter this week (5 days).

fredrikjj

Day 29

I totally failed to get going and ended up doing other things.

PS.
I've decided that going into a lot of detail on EIGRP this far out isn't as important as working on the really weak areas like redistribution. I'm also going to make an honest attempt at improving my resume.

fredrikjj

Day 30

Made up for yesterday with a 6-7 hour session on redistribution. I've also started using a US keyboard layout, and it's not bad at all actually. Stictly for configuring IOS it's vastly better because "/" is much more accessable and, as you all know, you use it constantly when going into interface mode. The Swedish layout has forward slash at shift+7 which is pretty much the worst possible location.

TBickle

Fredrikjj,


Are you using actual equipment or GNS3? If actual, what routers are you using?

fredrikjj

TBickle wrote: »

Fredrikjj,


Are you using actual equipment or GNS3? If actual, what routers are you using?

100% GNS3. Last time I saw real cisco gear was when we cleaned out some ancient 100 mbit stuff at work... in 2009. I figure I'll have to actually get some switches for the switch exam, but itseems like the supply is severely limited (and very expensive) on Swedish sites. Our most popular auction site seems to have 1 3560 with an opening bid of 1,600 SEK which is like $250. To me that's pretty damn expensive for something that's pretty much 100% useless outside of labbing.

If I was a vendor I'd make sure people could train on my equipment for free because it literally has zero downside. I read Ethan Bank's blog post on that Juniper solution (junosphere), and it's mindboggling that they've created some elaborate cloud solution and then charges for it when they could have just released the OS and let the community handle everything else. The same goes for Cisco. They have this product in the pipeline called "VIRL" which seems to be GNS3, more or less, but with support for the newer OSes, and I'll be EXTREMELY suprised if it's just a free download for anyone. It seems to be in the nature of these companies to make it more complicated than it has to be.

fredrikjj

Day 31

Spent another four hours or so on redistribution.

fredrikjj

Exam:

642-902 Implementing Cisco IP Routing - English - (ENU)






Candidate:

.-



Candidate ID:

-



Registration ID:

-



Date:

02 December 2013



Time: ^*

11:00 AM



Appointment Length:

170 Minutes





Accommodations You have been approved for the following accommodations:


Accommodation

Time Extension (Minutes) ^*



Automatic English Time Extension

30




jelly?


It was significantly cheaper than the CCNA (€182.5 vs. €286.5) which was a very pleasant surprise.

gorebrush

I assume that the was the combined (802) CCNA cost you are comparing? Yes, it is more expensive as it is effectively two exams in one.

fredrikjj

gorebrush wrote: »

I assume that the was the combined (802) CCNA cost you are comparing? Yes, it is more expensive as it is effectively two exams in one.

Indeed it was.

fredrikjj

Day 32

Put in my daily 5-6 hours. Mostly worked on redistribution. Towards the end of the day I started looking at OSPF because while I can configure it just fine, I'm fairly weak on the details. Btw, can you use the ip ospf x area y interface command on the exam?

fredrikjj

Day 33

My main objective was to determine what my weak areas (no pun intended!) were in OSPF.
The first 5 hours or so I spent reading most of the FLG chapter, taking notes whenever I felt that it was warranted, and skimming sections that I knew that I knew. These are the things that I identified as more difficult:

OSPF packet types
The adjacency states (init,exstart,exchange etc..)
the network types
the LSA types
special area types

I created 10 pages of handwritten notes on these topics. I'm a bit confused about the network types. There are 5 if we include the two cisco ones, and I've put them in three categories:

1. point-to-point

2. broadcast and point-to-multipoint
Both of these work over multicast capable networks, but broadcast selects DR/BDR while point-to-multi doesn't. I get that in a hub-and-spoke topology, you need to either use multipoint, or, set priority 0 on the spokes to force the hub to be the DR if you use broadcast. But, beyond that, I don't get why you would use one over the other.

3. non-broadcast and point-to-multipoint non-broadcast
I have the same kind of questions about these two. On the surface they seem to offer roughly the same things, but the multipoint one doesn't use a DR. Both require static neighbors.

I took a one hour break at this point to get some fresh air. I mainly rode around on my bike, listening to Prince (Purple Rain is an all time classic!).

I read cisco's "OSPF Design Guide", a 50 page document that's probably kind of old, but I had it printed so why not. When I was done with the Design Guide I didn't want to do more reading so I turned to the labs in the Cisco SLM. I decided to just skip the first 4 because they seemed easy

Here are my notes. I felt fairly confident doing these but it's possible that there are mistakes (google ccnp route slm if you want to check out the topologies).

OSPF Lab 5 "Challenge Lab"

Configuration Requirements
1. Configure the interfaces in the diagram with the IP addresses shown.
2. Configure the bandwidth to reflect the actual bandwidth of all serial links.
3. Configure OSPF with interfaces in the areas shown in the diagram.
4. Configure R2 to summarize area 20 with the most specific mask possible.
R2(config-rtr)#area 20 range 172.16.2.0 255.255.255.128
5. Make the link between R1 and R2 have the OSPF network type of broadcast, with R1 as the DR.
R2(config-if)#ip ospf network broadcast
#ip ospf priority lower than R1, or priority 0 to make inelgible.
6. Configure R1 to always originate a default route.
R1(config-rtr)#default-information originate always. always keyword creates a default route even if one isn't already in the routing table? drawback of this is that you might force traffic to a router that doesn't have a way out of the AS.
7. Modify the link between R2 and R3 to have hello timers and dead timers that are double the default
values.
default on point-to-point: hello 10 dead 40
interface
ip ospf hello-intervall 20
ip ospf dead-intervall 80
8. Make the link between R2 and R3 have a cost of 500.
R2(config-if)#ip ospf cost 500
Only needed on one side of the link?
Should probably actually read up on how link costs work, if you need to set them on both sides or if the higher one decides.
9. Configure area 34 to be a totally stubby area.
R3(config-rtr)#area 34 stub no-summary
R4(config-rtr)#area 34 stub
10. Use MD5 authentication with the keyword “cisco” over the link between R3 and R4.
R3(config-if)#ip ospf authentication message-digest
#ip ospf message-digest key 1 md5 cisco
R4(config-if)#ip ospf authentication message-digest
#ip ospf message-digest key 1 md5 cisco
11. Figure out the hidden issue in the topology that you need to address to have full connectivity.
Virtual link needed to connect area 34 to area 0
R3(config-rtr)#area 23 virtual-link 0.0.0.2 (R2's router-id)
R2(config-rtr)#area 23 virtual-link 0.0.0.3
authentication message-digest message-digest-key X md5 password can also be added on the same line.
12. Run a Tcl script on all routers to verify that there is connectivity between the IP addresses in the topology.
I'm too lazy to write that script, but a few strategically placed pings tells me that everything is in order.

OSPF Lab 6, Troubleshooting Lab

My first step will be to verify basic IP reachability.
Using show ip int brief to compare the addresses with the topology map, and using ping.
Everything seems reachable within their own segments.
R1
Looking at the OSPF configuration on R1, they've used an incorrect network statement for its serial interface. This is why you use the ip ospf process-id area interface command. Fixing this established the R1-R2 link.
R2
network type is nonbroadcast on the interface to R3. Adding the neighbor 172.16.23.3 command to the router process.
R3
mirror of R2.
The virtual link is potentially faulty. checking it.
It turns out I was right. They've used the wrong router-id on R4's virtual link statement. The fact that they haven't configured explicit router ids that make more sense than the loopbacks makes it harder to troubleshoot. Virtual link now works. Virtual links should show up in show ip ospf neighbor.

OSPF Lab 7, OSPF Case Study

I'm too tired to actually load GNS3 so I'm just going to write commands in Notepad.
1. Use the addressing scheme shown in the diagram.
2. Configure OSPF with the networks shown in the diagram.
3. Configure the OSPF backbone area to be on Loopback0 on HQ.
int lo0
ip ospf 1 area 0
4. Configure the Frame Relay subnets as point-to-point subinterfaces, with the link between HQ and
East in area 100, and the link between HQ and West in area 300.
int s0/0/1
encap frame-relay - the encapsulation on the physical interface, right?
int s0/0/1.102 point
ip add 10.1.1.1 255.255.255.252
frame-relay interface-dlci 102
ip ospf 1 area 100
int s0/0/1.103 point
ip add 10.1.1.5 255.255.255.252
frame-relay interface-dlci 103
ip ospf 1 area 300
No need to turn off inverse arp because it's off by default on point-to-point subinterfaces, I think
5. Configure area 300 as an NSSA.
R1(config-rtr)#area 300 nssa
R4(config-rtr)#area 300 nssa
Routers must agree on the area type flag or they can't form relationships.
6. Configure the router East loopback interfaces to be in area 200. Summarize this area with the most
efficient summary.
R2(config-rtr)#area 200 range 10.1.1. damn... /28 16 increment 0 16 32 48 64 80 96 112. 10.1.1.96/28 misses the last loopback I guess so we could either accept that or increase to a /27.
area 200 10.1.1.96 mask? 255.255.255.224
7. Redistribute the loopback network on router West into OSPF.
R4(config-rtr)#redistribute connected subnets.
8. Create virtual links as necessary for full connectivity.
R1(config-rtr)#area 100 virtual-link 0.0.0.2
R2(config-rtr)#area 100 virtual-link 0.0.0.1
9. Make sure that all loopback interfaces are advertised with the correct subnet mask.
int lo0
ip ospf network point-to-point

Tomorrow I'll probably review my notes on OSPF, and working on memorizing all the LSAs and stuff. I also need to look at the ip ospf cost command.

fredrikjj

Day 34

Re: the talk about network types yesterday. I've now figured out the purpose of point-to-multipoint. In a full mesh topology, having a DR isn't a good idea because if a router loses it's direct layer 2 connection to the DR, it loses its ability to send LSAs to that DR despite still having an indirect path to it via other routers. You would still be able to ping the DR in that scenario, but OSPF won't function properly.

In a hub-and-spoke this doesn't matter because if the connection to the DR is lost, there's no other paths anyway, but If you are paying extra for a full mesh you want the network to still be functional even if one specific circuit goes down. Point-to-multipoint creates the magic sauce that makes that happen.

I also did some debugging on the adjacency process, trying to break it in various ways.

How the adjacency process works:
(debug output is from 'debug ip ospf adj')

1. The router sends hello packets out the interface when OSPF is enabled. Before the router has received a hello packet from another router it's in the DOWN state.

2. When the router receives a hello packet from another router it goes into 'INIT'
OSPF: Rcv DBD from 0.0.0.2 on FastEthernet1/0 seq 0x20B opt 0x52 flag 0x7 len 32 mtu 1500 state INIT

The FLG says a hello packet makes a router go into INIT, but this output clearly says DBD which must stand for database descriptor, packet type 2. The DBD describes the LSAs in a router's database. Now, this could mean that the debug output says DBD but it was actually a hello packet that was received. Or, it was an actual DBD packet. Either way, it's mildly confusing.

3. When the router receives a hello from another router it adds that router's router-id to its own hello packets. Once a router receives a packet with its own router-id it knows that it has established communication with another router and goes into the two-way state.

OSPF: 2 Way Communication to 0.0.0.2 on FastEthernet1/0, state 2WAY

4. At this point, if the network type is broadcast, there's a DR/BDR election according to priority settings, or highest router-id if the same priorities.

OSPF: Elect BDR 0.0.0.1
OSPF: Elect DR 0.0.0.2

5. The routers now want to synchronize their databases.

FastEthernet1/0 Nbr 0.0.0.2: Prepare dbase exchange
OSPF: Send DBD to 0.0.0.2 on FastEthernet1/0 seq 0x10B7 opt 0x52 flag 0x7 len 32
OSPF: Rcv DBD from 0.0.0.2 on FastEthernet1/0 seq 0x1103 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
NBR Negotiation Done. We are the SLAVE

The router on the other side has become MASTER. The FLG doesn't go into specifics as to what the significance of this master/slave relationship is.

6. The actual exchange takes place

OSPF: Rcv DBD from 0.0.0.2 on FastEthernet1/0 seq 0x25E3 opt 0x52 flag 0x1 len 72 mtu 1500 state EXCHANGE
OSPF: Exchange Done with 0.0.0.2 on FastEthernet1/0
OSPF: Send LS REQ to 0.0.0.2 length 12 LSA count 1
OSPF: Send DBD to 0.0.0.2 on FastEthernet1/0 seq 0x25E3 opt 0x52 flag 0x0 len 32
OSPF: Rcv LS UPD from 0.0.0.2 on FastEthernet1/0 length 64 LSA count 1
OSPF: Synchronized with 0.0.0.2 on FastEthernet1/0, state FULL

7. The database is now in synch with the neighbor and they are both in the 'FULL' state.

//Mismatched timers
So why even care about this type of debugging? After all, as long as you double check that the variables that must match do in fact match (area, hello/dead intervall, authentication, stub flag), shouldn't things just work? Yes, but for example, what if you can't log in to the other device because it's managed by someone else. If all you got is show ip ospf neighbor, and that shows you nothing, what do you do? You could call that other administrator up and say "IT IS NOT WORKING!", or you could go deeper.

I configured a hello intervall of 9 seconds instead of 10 on the other router. debug ip ospf adj won't give you anything, and show ip ospf neighbor gives you this, incredibly useful output:

R1#show ip ospf neigh
<blank>
R1#
I
nstead, let's turn on debug ip ospf hello.

OSPF: Rcv hello from 0.0.0.2 area 0 from FastEthernet1/0 1.1.1.2
OSPF: Mismatched hello parameters from 1.1.1.2
OSPF: Dead R 36 C 40, Hello R 9 C 10 Mask R 255.255.255.0 C 255.255.255.0

We're able to determine that the remote hello timer of 9 doesn't match ours (and dead the timer of 36 - it defaults to 4 times the hello). Now, instead of calling and saying "It's not working" you'd be able to say "it seems like the hello timers you guys told us to use don't match what you are actually running on your end". You'll sound like you know what you are talking about and the issue will probably be resolved faster. And even if you had access to the other device, this would probably be quicker than actually double checking all the parameters manually.

Another interesting thing I found when I tried to deliberately break the adjaceny process is that a point-to-point interface will play with a broadcast interface. At least on the point-to-point ethernet segment I'm using for testing. I suppose I shouldn't be surprised since it's not mentioned that those need to match. Don't ask me if this has any implications.

//Area mismatch

Next I messed around with area mismatches. OSPF won't be able to form an adjaceny if the area # doesn't match. The problem is that the debug ip ospf hello command we used previously is insufficient.

R3(config-if)#
*Oct 24 04:41:55.639: OSPF: Send hello to 224.0.0.5 area 2 on Serial1/0 from 10.0.0.2
R2(config-if)#
*Oct 24 04:43:34.359: OSPF: Send hello to 224.0.0.5 area 1 on Serial2/0 from 10.0.0.1
No hellos are received according to this output, which I find suspect to be honest.
If we go back to debug ip ospf adj, we're informed of the problem immediately:

R3#debug ip ospf adj
OSPF adjacency events debugging is on
R3# OSPF: Rcv pkt from 10.0.0.1, Serial1/0, area 0.0.0.2 mismatch area 0.0.0.1 in the header

Another failure scenario in the adjacancy process that I came up with is if one side of the link is non-broadcast and they forgot to tell you. How would you troubleshoot this? You probably won't beacause it'll still work. Presumably because the broadcast side of the link will multicast its IP address, and then the other side will unicast the response. But, if you configure both sides of the link to non-broadcast, they won't become adjacent even if you can ping 224.0.0.5 just fine.

//Mismatched stub flag

Seen with debug ip ospf hello
OSPF: Rcv hello from 0.0.0.2 area 2 from Serial1/0 10.0.0.1
OSPF: Hello from 10.0.0.1 with mismatched Stub/Transit area option bit
debug adjaceny won't show anything.

Why is there such inconsistency in what debug commands show what when it comes to the adjaceny process?

//authentication.

debug ip ospf adj will show you mismatched authentication
OSPF: Rcv pkt from 10.0.0.1, Serial1/0 : Mismatch Authentication type. Input packet specified type 2, we use type 0
type 0: null
type 1: simple
type 2: md5
If we have the right type, but the wrong key we get:
OSPF: Rcv pkt from 10.0.0.1, Serial1/0 : Mismatch Authentication Key - No message digest key 1 on interface

//LSA
I've pretty much memorized the LSAs by repeatedly drawing diagrams of their propagation. I'm a little bit confused about type 2 LSAs though. Why do we need them when we have type 1s? The FLG is fairly sparse on details, but from what little information is there, I've imagined that type 1 LSAs don't actually contain the full information about transit networks, and only point to the DR. The type 2 LSA then informs the router about the actual full details about that network, should it be required. Is this how it works?