Journal

I'm not sure that I'm not going to regret doing this, but following in the footsteps of making a thread for my progress towards the IE.

Last night I grabbed a pdf for the routing & switching cert guide (I don't feel guilty about doing this, as the actual book has been purchased and is in transit. I may get it tomorrow or Monday at the latest - I just wanted to get started).

Read for about 3 hours last night and made it through Chapter 1 and most of Chapter 2. Everything seemed pretty easy / review until I came to a screeching halt at the end of Chapter 2 with the sudden introduction of PPPoE. Tried making sense of it for a while but gave up on it. I'll be looking at it more tonight, but may just make a note and move on. I'm hoping it'll make more sense on the re-read. That worked pretty well for a few areas in the Route studies.

To me learning is kindof like putting together a puzzle. It's much easier to do if you're adding to something you already know/have done. This surprise PPPoE felt like I was suddenly working on a totally new area of a puzzle where I didn't even have 2 pieces together yet.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

My DIGI CM32 came in today ($55+S&H). Got it hooked up and working without any major issues. Now I can lab with my existing switches without worrying about losing connectivity as STP reconverges and breaks.

Well... except 1 of my 4 switches is my "production" switch. I'll have to think up a way around the risk of breaking the connectivity to the CM32 itself.

Doing a bit of light labbing today to get in the swing of things. Basic layer 2 stuff - nothing complicated.

Rather than trying to get GNS3 working or attempting to wire up my hardware, I've got a tabbed notepad-like program open and am putting the commands there.

So far I'm doing ... not all that well. Not that I'm doing stuff WRONG, but I'm making assumptions and getting stuff wrong because of those assumptions. I need to stop doing that I guess! While doing this on live (or virtual) hardware might prevent some of these mistakes (due to various messages and verification failures), I'd rather configure it right in the first place.

Going through my (old) copy of Routing TCP/IP Volume 1 while waiting for my 2nd edition of it to arrive. I haven't encountered anything 'new' so far, but I understand the older edition's early chapters assume you don't know anything while the newer edition floors it right out of the gate.

UPDATE
I just realize and am now wondering if the CCNP-levels of knowledge for RIP, OSPF, EIGRP, all the layer 2 technologies are sufficient for the "core" knowledge. That might explain why reading on the layer 2 technologies and the standard IGP protocols are so worrisome: I'm not getting anything NEW, then freak out because I'm not getting anything new. I don't think I'll change my current "reviewing" though, since it serves as a refresher (and you never know when an area I never understood fully will make more sense, or when some new aspect of the protocol is discovered).

ON TO RIP!

And YE GODS, am I rusty with it. Authentication via key chains (ok, not bad - it's like EIGRPs) and v1/v2 compatibility via the interface commands.

Well ok, there's not that much to RIP when you get down to it, but one thing has be slightly confused. I made up a quick 2-router lab with loopbacks just to run the commands at, and the authentication is doing something I didn't expect.

On one side I created the key chain and applied it (using cleartext) on the appropriate interface. At that point the other router stopped accepting updates (invalid authentication), but the device with authentication configured is still accepting updates that have no authentication just fine.

That threw me off: I could have sworn that while authentication was unidirectional, having it configured on only one end still broke it in both directions. I added EIGRP to the lab with near-duplicate configuration (same key chain, etc) and it does there, but apparently not with RIP.

This seems like something that might be useful to remember (or verify, because it still seems WEIRD, or at least backwards)

Got the correct (2nd edition) of Routing TCP/IP Vol 1 today. I was able to find (to the word) where I was in my reviewing of the 1st edition so I could seamlessly switch books. I paid $46 for this? Eek.

I got stuck all day trying to parse through EIGRP's DUAL state machine example 2 (pages 280 through 287) before giving up and moving on.

Finished reviewing EIGRP in Doyle's book and have gone back to Chapter2: IPV6 since that chapter wasn't in the first edition.

Still working on the IPv6 chapter, which just feels like a massive infodump.

Some thoughts:
Anycast seems like a bad idea, in that it breaks one of IPv6's big focuses: the hierarchical model to provide highly efficient route summarization.
Privacy addresses don't seem like they'd actually ... well, work, considering the global address can be calculated from the "private" address.

Worked on some labbing today (and will continue to after lunch).

I find so far my main problems are two-fold: First I have some difficulty understanding what is being requested sometimes, and secondly my speed at gathering the information needed to perform the task. Once I have the information I haven't had problems configuring the requested task (so far, but I'm doing basic stuff still)

More labbing today, although technically it was spent researching Reliable Policy Routing, as that hung me up quite a bit yesterday (and was where I ended up giving up for the day). I had a lot of confusion on the command syntax, but figured it out while typing out a question to post here regarding it.

As a bonus I reviewed local policy routing, since it was a logical extension of PBR.

Didn't do a whole lot over the weekend (family time). Took the Multicast book home with me and read it as time permitted. Back to labbing RIP today hopefully.

Didn't really make any progress today. Had troubles setting up the lab - unexpected results in the routing table, then trying to visualize the topology with little luck.

I'm curious how others have figured out how to do this. With multiple subnets partially "overlapping" on the switches so you end up with complicated data paths across subnets.

I don't know whether to be embarassed or not when I figure something out that I was confused about.

I was looking at logical topologies last night and realized they provide the exact information I was having trouble visualizing: At what points one subnet "touches" another subnet (and therefore the logical path between subnets 'A' and 'G').

Back to labs!

AAnd once again I have spent significant amounts of time trying to figure out something that's not even on the v5 lab. I guess there's no such thing as bad learning though.

I still haven't figured out why this isn't working, but it's RIPv1, so I'm moving on.

In case anyone's wondering or wants to chime in, the problem was thus:
A ripv1 update is received, but one of the advertised networks is not being installed in the routing table. A subnet of the received update is configured locally. I THOUGHT I would end up with the /24 connected route as well as the /16 via RIP.

... I'm going to lab some variations to see if I can make sense of it. I can't let go of a puzzle sometimes haha.

Update:
No real information from my labs except to verify it happening. When I think about it though, it kindof makes sense, since you'd end up with a routing loop.

R1 sends 10.0.0.0 to R2, with a loopback of say 10.1.1.1/24. R2 sends 10.0.0.0 to R1 with a loopback of 10.2.1.1/24. You end up with any 10.x address besides the 2 /24's being bounced back and forth between them.

FINALLY finished the RIP section of INE wb1. I was going really slow, trying for solve each sub-section without referring to the answers. I realized today how dumb that was and allowed myself to use the workbook itself to learn from (especially considering my luck with the below)

I'm also attempting to switch over to using DOC-CD to look things up rather than google, figuring the sooner I get comfortable and proficient at navigating it, the better). Sadly, so far I'm about 0 for 4 trying to find what I'm looking for there (even if I verify it's there first via a google search).

Learning the Doc-CD just takes practice. It's a pain to begin with but you soon learn to get the feel for it - I could even look up the DMVPN configuration without any real difficulty earlier.

That's definitely an understatement. So far I've only managed to find 1 thing.

I also managed to spend well over an hour on INE's "eigrp unequal cost load balancing" bit. It's STILL not bloody working correctly, but since 'show ip route' shows a correct 1:5 ratio, I'm considering it completed. (The access-lists show an 84:16 ratio instead of an 80/20).... err nevermind - my ratio was correct. 1:5 is not 20%/80%... oops. Still, my time on this one was ... excessive.

[EDIT1]
I also found out the hard way that apparently doing a "write mem" and then reloading in GNS3 still wipes the config. I don't remember it doing that before, but it's happened twice today so far.

[EDIT2]
Also, I'm finding myself labbing more and reading less because TCP/IP Volume 1 didn't cover about half of the tasks I've encountered (for RIP & EIGRP so far). It seemed to either be something I already knew (and was in TCP/IP Vol 1) or something I did not (but wasn't in the book either). Can I expect this trend to continue? (I expect my weak areas: QoS, multicast, BGP, all things ipv6 to be exceptions)

BGP = Internet Routing Architectures ~ 300 pages ish, good read
Multicast = Developing IP Multicast Networks
QoS = The old certification guide is quite handy for this, though I think QoS has been simplified a great deal now that all the legacy FR QoS methods are gone (I assume you are heading for a v5 lab at this point in time)

TCP/IP Vol 1 and 2 are great reference guides but probably don't go "all the way" in terms of depth. The ultimate resource for that will probably be the RFC. I haven't started reading those for the finer points yet, but I intend to, and shortly.

Yeah, I have all those books, and I've been glancing through them when I'm out somewhere waiting in the car or something.

MAN, I'm finding a lot of bugs in the later parts of the INE section.

I'm starting to have a BIT better luck with doc-cd, but only if I already know what I'm looking for (command), and just need to look up options (such as leak maps). Still no luck if it's a concept and I need to find what commands to execute it.

Yeah some of them ticked me off as well, I think I will just be trying to emulate the same thing on the newer layout.

Hello OSPF, my old enemy.

I managed to get through the first 13 topics of WB1 but am stuck on topic 14 ("OSPF Path selection with virtual links").

Still having troubles finding information in doc-cd unless I already know what I'm looking for or there's a key word in the topic title (like 6.13: "OSPF Path selection with non-backbone transit areas" matching the "area transit capability" from the ospf configuration guide). Neither of those apply here.

I don't really WANT to just scroll down to the "configuration" section to get my answer -- I want to FIND it. It's easier to remember that way. GRRRR.

Also: Anyone have tips on how to get better at interpreting the ospf database? I've never been all that good (or quick) at doing it, and while I know just doing it builds the ability, it's a lot easier to do it to solve a problem than just for kicks. (Neither section 6.9 nor 6.10 required me to do thise, as it was obvious from the topology diagram where the change needed made, and 'show ip route' gave me enough to know what to change)

How do you mean interpreting the database?

What questions are you asking it? I know you can do

Show IP ospf database [LSA type] [prefix]

That should help you see the info about a particular prefix, where lsa-type could be external (for example)

What are you after exactly?

I think just being able to look through it and quickly being able to go step by step through the LSAs to trace a path from point A to point B.

I'm doing a webinar tomorrow on the Cisco Learning Network on OSPF, unfortunately this round will be for premium members only. I will demonstrate how to calculate the SPF tree and the purpose of all the LSAs.

Maybe I should do a blog post series on it. People often get confused by looking for prefixes in the LSDB but the LSDB is used to build the SPF tree, the prefixes are just leaves on that tree. Let's say that you have a router in area 1 and you want to reach a prefix in area 0. Then you first must find the cost to the ABR. This is done by looking at the type-1 router LSAs. A shortcut to find the cost is 'show ip ospf border-routers'. The ABR will advertise the type-3 summary LSA with the cost that it has to reach that prefix. Your cost is then the cost to the ABR + the cost of that summary LSA. The ABR calculates that cost by looking at the router LSAs in area 0.

bermovick wrote: »

I think just being able to look through it and quickly being able to go step by step through the LSAs to trace a path from point A to point B.

I could create some topologies in GNS3 if you want to play around with drawing a topology diagram from the LSDB with no prior knowledge. I imagine that I could just stack all the router icons on top one another or something to make it hard (well, as long as you restrict yourself to database commands) to "****". Would you like that?

I understand the LSAs and generally how everything fits together in theory, and the command to pull up the database (or a section of it). Just in practice I'm not great at reading the output and getting the information I need (especially when that leads to reviewing another section of the database to get THAT -- and even more especially when you build on the previous information 5 or 6 times to get a full path).

Thanks fredrikjj, but I don't want you to have to do what I can just as easily do. I was just curious if there was anything out there on the interwebs that would make good practice. (like subnettingquestions.com was for subnetting)

I think today I'll take a break from labbing and instead use the v4 INE topology to draw the topology using nothing but the ospf database to guide me. Maybe by the end I'll be doing a bit better.

[UPDATE]
This link is kindof useful. While I already knew what each piece individually does, tying it all together and seeing it as "a whole" is the tricky part.

https://supportforums.cisco.com/document/133976/reading-and-understanding-ospf-database

My work today has been a failure so far. By the time I got 3 routers & their links drawn out I'd filled 1/2 a page of circles, lines and notes to the point it was nearly unreadable -- with 7 routers left to go. I'm going to try following the steps of the link to see if that makes it easier to organize.

OK, I have to correct myself. I'm not bad at it, just slow. I managed to get a topological(?) map of SW4, SW2 and R1-R5's FR links (using the INE v4 topology which is easily findable online for anyone who doesn't have it). I stopped at that point because every one of the R1-R4 routers is an ABR into a separate area, and I didn't feel like doing all of that.

I swear, this is turning into a complain-fest by me right now, but I get annoyed at this:
(from the workbook, showing how because of a previously configured virtual-link, traffic between area 2 will use the R6 ABR)

Rack1SW3#traceroute 51.51.51.51
(omitted)
1 155.1.79.7
2 155.1.67.6
3 155.1.146.1
4 155.1.0.5
5 155.1.0.2
6 192.10.1.254

and when I run it, despite having followed the workbook, I get

Rack1SW3#traceroute 51.51.51.51
(omitted)
1 155.1.79.7
2 155.1.37.3
3 155.1.0.5
4 155.1.0.2
5 192.10.1.254

Note a whole lot of labbing today. After feeling stupid while reading fredrik's thread, I spent some time trying to understand that topic. Once I got the gist of it I grabbed TCP/IP Vol 1, planning on reading the OSPF chapter since I'd forgotten how an ABR won't use a type 3 LSA it learned through a non-backbone area (unless it has no adjacencies in area 0 apparently), but after a handful of pages of nothing new, I went back to labbing, starting with BGP... I didn't get far due to time constraints, but am set up for a busy BGP day tomorrow.

Hopefully doing the labs and working my way up to the larger, deeper ones will expose my rusty areas and let me get back to speed on them naturally.

BGP section of wb1 today. Surprisingly I remembered nearly everything covered. I had to double-check confederations but otherwise it was a good day!

I have the "advantage" of having the VAST majority of my working hours available for studying. It's a BIG double-bladed sword though since i'm stagnating otherwise.

Finished the bgp part today (following the 12-month INE plan as close as I can) and started on the ipv6 section, with some modifications (skipping ripNG and doing the eigrpv6 section instead). I find I'm liking ipv6 more than I ever have before, but GOSH I love this workbook! </sarcasm>

Task 13-1: allow eigrpv6 to do unequal-cost load balancing for unequal metrics up to 3x the optimal metric.
Part of their solution adjusts the k values.
Task 13-2: configure R4's serial link to have a delay twice as good as R4's frame-relay link
Their solution adjusts BOTH links delay values.

BAH.

[UPDATE]

Also ran into another GNS3 bug. I'd encountered it early but since it was during a very basic task, I ignored it. Basically a DAD failure:

(config-if)# do show ipv6 int f0/0 | i link-local
IPv6 is stalled, link-local address if FE80::C08E:1DFF:FEA4:0 [DUP]
No Virtual link-local address(es):

(config-if)# ipv6 address FE80::3 link-local
%IPV6-4-DUPLICATE: Duplicate address FE80:3 on FastEthernet0/0
(config-if)# ipv6 address FE80::33 link-local
%IPV6-4-DUPLICATE: Duplicate address FE80:33 on FastEthernet0/0
(config-if)# ipv6 address FE80::666 link-local
%IPV6-4-DUPLICATE: Duplicate address FE80:666 on FastEthernet0/0

On a point-to-point ethernet link.

Finished up poking through the IPv6 sections and moved on (back?) to multicast. I hate multicast. Nothing seems to work how it should.

I know GNS3 has some multicast ... 'issues' as well, so that's another wrench in the works trying to follow along.

Quick Links