Fredrik's CCNP thread

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.

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

Day 35

More OSPF. After a few hours though I started to feel like there were some very steep diminishing returns so I decided to answer the 40 review questions in the FLG instead. I messed up on two questions, and only because they tricked me. At this point, any additional information I manage to memorize about OSPF is probably going to be forgotten by December anyway so I'm I'm moving on to EIGRP.

Day 36

I had a job interview that fell flat. Demoralized, I spent the rest of the day catching up on on my favorite podcasts instead of studying EIGRP.

Sorry to hear that man. I'm sure something will come up. Don't kick yourself around for catching up on podcasts. I do that all the time.

TBickle wrote: »

Sorry to hear that man. I'm sure something will come up. Don't kick yourself around for catching up on podcasts. I do that all the time.

Day 37

I reviewed the FLG chapter on EIGRP and took notes whenever I felt that it was a productive thing to do. The goal was to identify strengths and weaknesses.

My focus was on how DUAL works, the EIGRP packets, some configuration, and the section about query scoping at the end of the chapter, which I'm not quite done with. This process took seven hours or so and resulted in a substantial number of pages of handwritten notes. I consistently can't sleep for several hours after studying for that amount of time though which is quite annoying. Maybe I'm STUCK IN ACTIVE... haha.

Today I'm going to finish up the query scoping section and do some experiments with those features. The SLM doesn't have anything related to it so I guess I'll just have to build something myself.

Bonus tech question:
I'm been thinking a bit about the supposed advantage of the "hybrid metric", and if someone wants to defend delay as a valid metric feel free to educate me. My logic is basically that if your network is local, you'll have super low latency everywhere unless you are totally screwed by congestion, in which case you have bigger problems.

If you route on a worldwide scale where delay starts to matter due to physics, wouldn't you care a lot more about using the _right_ link. I.e. manual policy becomes more important than trusting some routing protocol to make the right decision. And, wouldn't two links to the same destination have roughly the same latency anyway unless you literally go opposite directions around the world?

That leaves us with bandwidth basically, and it starts looking like a worse version of OSPF's link costs because EIGRP uses the lowest bandwidth along the path, and while you probably can create topologies where that would makes sense, I can see it making suboptimal decisions as well.

If a device is connected to 1 gig, and you move to 10 or 40 gig down the path, the metric will not take the difference between those 10 and 40 gig pipes into account unless you manually configure the 1 gig to the same BW as the 40 gig in which case the 10 gig will seem worse. OSPF solves that problem by default without trickery. And generally, don't end users and servers generally have their lowest bandwidth at their closest layer 3 device, always creating this problem? You wouldn't connect a server to 10 gig if the next hop is 1 gig, would you. My ideas here aren't based on any kind of pratical experience so feel free to school me.

Day 38-40

I finished up the Query stuff on Friday, reviewed my notes, and then more or less took the weekend off. I've also decided to get the 101 CCNP Labs book because I've heard that that it has some difficult material, and difficulty motivates me.

Day 41

Read the short path control chapter, took notes and labbed up some of the stuff on Offset lists, IP SLA and PBR. I struggled a bit with PBR because I tried to do it with prefix lists and for the life of me I couldn't get it to work. Standard access lists worked fine, but I had no luck with specific source-desitination extended lists like "permit ip host <source ip> host <destination ip>". It's supposed to work, right, so I must have made some kind of mistake somewhere. I put set interface null0 at the end of the route-map for all these tests as an easy way to gauge if traffic was matched or not (and debug ip policy).

With prefix lists the problem was that despite having a specific network in the list, it matched all IPs and policy routed them according to that match/set combination. With extended access lists debug ip policy told me that the packets came in with the specific src and dst I had put in my extended ACL, but they still weren't matched, got bumped down to the null0 statement and got dropped. I found it very frustrating.

I've also taken a first look at the BGP labs in "101 CCNP Labs" at http://www.##########.net/public/department601.cfm and they seem pretty brutal. My goal this week will be to refresh and learn BGP to the point where I can solve most of those. It's by far my weakest area right now after the recent work I've done on EIGRP, OSPF and redistribution, but 30-40 hours of studying should take care of that.

Day 42

A day of BGP. I basically read and took notes on the first 40 pages of the chapter. Nothing really suprised me since I've read this material before and done labs, but I went into more detail. Today I plan to move into the configuration and verification sections. I've also realized that the very first lab in the "101.." requires communities which is covered in the appendix. I guess this means that I'll work my way through all the text before I start labbing.

Keep up the good work. Use various materials - then the pieces will fall into place.

Goodspeed wrote: »

Keep up the good work. Use various materials - then the pieces will fall into place.

I appreciate the support.

Day 43

Did some more BGP and got into the meat and poatoes of the configuration. That leaves me with configuration of the attributes and the appendix. I also read this sentence about the "network" command:

If the mask is not specified, this command announces only the classful network number; at
least one subnet of the specified major network must be present in the IP
routing table to allow BGP to start announcing the classful network as a BGP
route. However, if you specify the network-mask, an exact match to the network
(both address and mask) must exist in the routing table for the network to be
advertised.

Verification:

R1 and R2 are directly connected on 10.1.12.0/24.

R1#show run | s router bgp
router bgp 1
neighbor 10.1.12.2 remote-as 2

R1#show ip bgp neighbors
BGP neighbor is10.1.12.2, remote AS 2, external link

R2show run | s router bgp
router bgp 2
neighbor 10.1.12.1 remote-as 1

R2#show ip bgp neighbors
BGP neighbor is10.1.12.1, remote AS 1, external link

I create a subnet of the major network 20.0.0.0/8 as a loopback interface on R1.

R1(config-router)#int lo0
R1(config-if)#ip add 20.0.0.1 255.255.255.0

It shows up in therouting table:

R1#show ip route
C 20.0.0.0/24 is directly connected,Loopback0

Now, according to the text I quoted above I should be able to advertise 20.0.0.0/8 with network 20.0.0.0 since “at least one subnet of the specified major network must bepresent in the IP routing table to allow BGP to start announcing the classfulnetwork as a BGP route”

R1#show run | s router bgp
router bgp 1
network 20.0.0.0

But,

R2#show ip bgp
<blank>
R2#

However, if I change the mask of the loopback to /8 the network is advertised.

R1(config)#int lo0
R1(config-if)#ip add 20.0.0.1 255.0.0.0

R2#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 20.0.0.0 10.1.12.1 0 0 1 i

Conclusion: the FLG is wrong and/or they've changed this behavior in more recent releases of IOS.Clearly, even a major network requires an exact match in the routing table. Am I missing something?

Day 44

I finished my notes on the BGP chapter. I ended up with significantly more pages compared to the IGP chapters which reflects the fact that I'm much less confident with this protocol. I also solved the first BGP lab out of the 11 in the '101 CCNP Labs' book. When that final ping came back, I got the biggest grin on my face. Easily the best “I can't believe that actually worked” moments so far. These labs are supposed to be harder than the exam so my rules are basically that I can't look at the answers, but I can use my notes, the FLG, etc.

All this stuff is freely available on their website that I can't link to due to some kind of filter.

Task 1
Configure hostnames and IP addressing on all routers as illustrated in the network topology.

Thankfully, this wasn't a problem.

Task 2
Without using peer groups, configure internal BGP on R1, R2, R3, and R4 as follows:
1. Statically configure a BGP router ID using the router number, e.g. 1.1.1.1 for R1, etc.

router(config-router)#bgp router-id 1.1.1.1

2. All routers should peer using their physical interface addresses
3. R1 should peer to R2 and R3
4. R2 should peer to R1
5. R3 should peer to R1 and R4
6. R4 should peer to R3

router(config-router)#neighbor 10.0.0.2 remote-as 254
repeat

7. All routers should use the TCP MD5 authentication password 'CCNP'

router(config-router)#neighbor 10.0.0.2 password CCNP

8. BGP Hellos should be sent out every 5 seconds
9. All of the BGP speakers should advertise a Hold Time of 15 seconds

router(config-router)#neighbor 10.0.0.2 timers 5 15

10. The COMMUNITIES attribute (standard) should be supported

This feature needs to be manually activated or the router won't pass the community information along to peers
router(config-router)#neighbor x.x.x.x send-community standard
This needs to be added to all neighbor statements.

Task 3
Advertise the 150.1.1.0/24, 150.2.2.0, and 150.3.3.0/24 subnets on R1, R2, and R3 via BGP. These
prefixes must be advertised with the standard community values listed below. You are NOT allowed to
redistribute these prefixes into BGP. Additionally, you are NOT allowed to use outbound or inbound route-
maps when completing this task. Ensure that the community values are displayed in ASN:nn (RFC 1997 -
BGP Communities Attribute) format. Verify your configuration using the appropriate commands.
1. The 150.1.1.0/24: community value of 254:111
2. The 150.2.2.0/24: community value of 254:222
3. The 150.3.3.0/24: community value of 254:333

You activate the RFC1997 standard with the command router(config)#ip bgp-community new-format because the Cisco default is NN:AS instead of AS:NN. Assigning the community values is done with a route-map on the network statement.
#route-map COMMUNITY permit 10
set community 254:111
#network 150.1.1.0 mask 255.255.255.0 route-map COMMUNITY

Task 4
Configure your network so that all 150.x.x.x/24 subnets can reach each other. You are NOT allowed to
use any static routes in your solution. Additionally, you are NOT allowed to advertise or redistribute the
150.4.4.0/24 subnet into BGP on R4. Instead, consider other BGP features to complete this task. You are
NOT allowed to configure R2 or R4. Additionally, you are NOT allowed to configure a dynamic routing
protocol to complete this task.

Next, verify your configuration using the appropriate commands as well as the extended ping function.
For example, on R1 use the extended ping function to send a ping to 150.2.2.2 sourced from 150.1.1.1,
etc, etc. All pings should work when the task is completed correctly .

This is where things got interesting and where I spent most of my time. If you think that my solution is crude and demonstrating a lack of knowledge of BGP, you are probably right. Anyway. The first problem is that since R3 and R2 aren't peering, they'll never learn each other's 150 segments due to the rule that routers don't send updates learned from IBGP to other IBGP peers.

Configuring R3 as a route reflector client on R1 solves this problem.
R1(config-router)#neighbor 10.0.0.6 route-reflector-client

At this point R1,R2 and R3 all know about the 150.1, 150.2 and 150.3 networks, but since the next-hop is maintained, R2 and R3 have a next-hop to their respective LAN segments that they can't reach. Next-hop-self on R1? No, that is for EBGP. I wasted time at this point searching for some BGP command to fix the problem. I fixed R2 by sending a default BGP route from R1 with:

R1(config-router)#neighbor 10.0.0.2 default-originate

Now when R2 tries to find the next hop 10.0.0.6 to reach 150.3.3.0/24, it uses the default route. On R3 I resolved this issue by advertising the network 10.0.0.0/30 from R1.

R1(config-router)#network 10.0.0.0 mask 255.255.255.252

R3 is able to find the next hop 10.0.0.2 to 150.2.2.0/24 by looking at this route. We now have full connectivity between R1,R2,R3. The remaining problem is R4 and the 150.4.4.0/24 network. I sent a default route to R4 from R3:

R3(config-router)#neighbor 10.0.0.14 default-originate

R1,2,3 have no knowledge of 150.4.4.0/24. R2 will send traffic to R1 through the default, but it won't go beyond that. The only way I manage to solve this was to create an extended ACL on R1 and R3

R1(config)#access-list 100 permit ip any 150.4.4.0 0.0.0.255

It permits any traffic with a destination of 150.4.4.0/24.

I then created a route map on R1 and R3

R1
route-map MAGIC permit 10
match ip address 100
set ip next-hop 10.0.0.6
!
route-map MAGIC permit 20

R3
route-map MAGIC permit 10
match ip address 100
set ip next-hop 10.0.0.14
!
route-map MAGIC permit 20

This route-map is applied to the incoming interfaces and locally. If it isn't activated locally, traffic sourced from the router itself won't have its next-hop modified.

R1(config-if)#ip policy route-map MAGIC
R1(config)#ip local policy route-map MAGIC

R3(config-if)#ip policy route-map MAGIC
R3(config)#ip local policy route-map MAGIC

Once traffic actually gets to R4, it's returned to R3 through the default route, and R3 can handle the return traffic just fine since that router has normal reachability to the other LAN segments.

The requirements are now met without touching R2 or R4 or using an IGP or static routes, but I get the feeling that the actual solution looks different. BGP gurus, feel free to chime in.

Day 45

Finished two more BGP labs. Hard as ****, but I did it. I made similar write ups like the one above, but I doubt anyone wants to read a 3,000 page post.

Day 46

Did 3 more bgp labs. These were less painful than the three I did before so I think it's starting to click. I have identified 2 very specific weak points; using as-path and regular expression, and those ge/le keywords in prefix-lists. I know what they do, but when it comes down to crafting a very specific as-path list or prefix list, I often fail. I found this post on INE's blog http://blog.ine.com/2008/01/06/understanding-bgp-regular-expressions/ that I haven't read yet, but I have a feeling that it's exactly what I need. I do find it strange that it isn't covered in the FLG when it's something that you obviously need to know when configuring BGP.

PS.
I wish I could go live in Brian McGahan's basement.

fredrikjj wrote: »

Bonus tech question:
I'm been thinking a bit about the supposed advantage of the "hybrid metric", and if someone wants to defend delay as a valid metric feel free to educate me. My logic is basically that if your network is local, you'll have super low latency everywhere unless you are totally screwed by congestion, in which case you have bigger problems.

If you route on a worldwide scale where delay starts to matter due to physics, wouldn't you care a lot more about using the _right_ link. I.e. manual policy becomes more important than trusting some routing protocol to make the right decision. And, wouldn't two links to the same destination have roughly the same latency anyway unless you literally go opposite directions around the world?

That leaves us with bandwidth basically, and it starts looking like a worse version of OSPF's link costs because EIGRP uses the lowest bandwidth along the path, and while you probably can create topologies where that would makes sense, I can see it making suboptimal decisions as well.

If a device is connected to 1 gig, and you move to 10 or 40 gig down the path, the metric will not take the difference between those 10 and 40 gig pipes into account unless you manually configure the 1 gig to the same BW as the 40 gig in which case the 10 gig will seem worse. OSPF solves that problem by default without trickery. And generally, don't end users and servers generally have their lowest bandwidth at their closest layer 3 device, always creating this problem? You wouldn't connect a server to 10 gig if the next hop is 1 gig, would you. My ideas here aren't based on any kind of pratical experience so feel free to school me.

Just, saw this and thought i'd comment.
On Eigrp both delay and bandwidth are configurable per interface, the delay can be used in the same way as ospf uses cost.Bandwidth can be used as an extra knob to fine tune. So the hybrid metric gives you more flexibility.

Ed: Thanks

Day 47 - BGP week post mortem

Sunday night I finally finished the last of the 10 BGP labs I had planned to do this week, save one or two tasks that I simply can't solve with those restrictions in place. I learned I a lot, I think, and at some points I even felt like I knew what I was doing. No points for speed though, and occasionally I got stuck for hours going over notes and the BGP command reference. While the conceptual knowledge you need is in the FLG for the most part, some of the actual commands definitely are not.

I'm about half way through the 3 months I've allowed myself to study for this thing and I'm satisified with my rate of progress. My main concern is that I won't be able to memorize enough stuff to pass the exam.

First of all, I want to commend you for your effort and determination to get this CCNP under your belt. If you continue like this I have no doubt you will pass with flying colours, and also have a long and prosperous career in IT.

In regards to remembering stuff, make sure you understand what you are reading, therefore you will not need to remember any of it. It will be stuck in your head and there is nothing you can do about it (sort of like getting a song stuck in your head for the whole day)

I know that Cisco makes you learn some annoying and trivial stuff like STP/RSTP timers, phases, metrics, troubleshooting steps, some Cisco marketing BS etc.., I always found flash cards to be very helpful for that.

I am about to start my CCNP study with the Switch OCG. I have gone through the whole CCNP course twice at college and university, so i think its time for me to demolish it.

Good luck

lincis_aus wrote: »

First of all, I want to commend you for your effort and determination to get this CCNP under your belt. If you continue like this I have no doubt you will pass with flying colours, and also have a long and prosperous career in IT.

What's funny is that doesn't really require much effort. Getting started can be a bit rough some days, but lab work especially I find very enjoyable. I've actually put some cycles into trying to figure out why; for me, the constant feedback you get from tinkering with the CLI induces a state of flow that rivals the best of video games. The very obvious connection between theory and practice is something that I love as well, and this field is pretty much an ideal match for me as far as I'm concerned.

In regards to remembering stuff, make sure you understand what you are reading, therefore you will not need to remember any of it. It will be stuck in your head and there is nothing you can do about it (sort of like getting a song stuck in your head for the whole day)
I know that Cisco makes you learn some annoying and trivial stuff like STP/RSTP timers, phases, metrics, troubleshooting steps, some Cisco marketing BS etc.., I always found flash cards to be very helpful for that.

Certainly. When I studied for the CCNA I remember having trouble remembering ADs for different routing protocols and things of that nature. I think it was a case of that material being so shallow that it actually made it harder to remember. Except for Frame Relay. I can configure FR like it's nobody's business.

The CCNP seems to be in this weird middle ground where you don't need to know everything, but enough to make you think that you do. I have a feeling that more than one CCNP has messed stuff up because he thought he was the ****, and applied his "expertise" to a real network, lol.

I am about to start my CCNP study with the Switch OCG. I have gone through the whole CCNP course twice at college and university, so i think its time for me to demolish it.

Good luck

It makes me kind of jealous that people get to take actual college classes on this stuff. I even heard about some Master's program in the US that was basically a CCIE prep thing. How cool is that.

IPv6 and GRE tunnels are my main weak areas remaining, and I'll probably spend the rest of this month on it. The FLG seems to be very heavily focused on the implementation side of things with a significant number of pages on how to configure the IPv6 routing protocols which, to be perfectly honest, is very straight forward if you know how their IP counterparts work. With that in mind I might check out some additional online sources.

Day 49

Read and took notes on IPv6 and managed to get through the first 25 pages of the FLG chapter.

Day 50

Did some more reading on IPv6, and then solved the first IPv6 lab which tested my RIPng skills more than anything else. I also did my first v6 summarization, and by applying fundamentals (going to binary etc) I managed to solve it. I got started on the second lab where I ran into trouble when one task called for "the most effecient and simple" redistribution plan between RIPng and OSPv3. A question like that is way out of my league so I just redistributed best I could to get reachability. The depth these labs go into with the v6 versions of the routing protocols is way beyond the FLG so I guess it's time to download some command references...

Day 51

Not a good day. I think that I got food poisoned by my dinner and I gave up after, at most, 2 hours of reading.

Day 52

Did the IPv6 redistribution section. The typical route-map for preventing feedback seems to be to set a tag for each of the routing procols, and denying that tag when redistributing back into it. Like this:

RIP tag = 10
OSPF tag = 20

route-map OSPF_TO_RIP deny 10
match tag 10
route-map OSPF_TO_RIP permit 20
set tag 20

route-map RIP_TO_OSPF deny 10
match tag 20
route-map RIP_TO_OSPF permit 20
set tag 10

But, am I correct in assuming that if you just have two routing processes to redistribute between, you could save major time with:

route-map ROUTE_TAG deny 10
match tag 10
route-map ROUTE_TAG permit 20
set tag 10

And use this on both protocols?

I then did two IPv6 labs. One was about OSPFv3 over Frame Relay and the other my first MBGP lab. I honestly didn't struggle nearly as much as I had expected. The OSPv3 lab called for the point-to-multipoint non-broadcast network type by asking for something that didn't use DR/BDR and used unicast. It also demonstrated the fact that the transport is disconnected from the payload by not configuring global addresses on the FR interfaces. And I summarized correctly again which pleased me.

The 10 BGP labs I did last week helped a lot and I confidently used the no-export community, as-path lists, local pref, weight and so on while doing the MBGP lab. The only issue I ran into was some minor confusion with when to configure directly under the router process and when to use the address-family.

Today I'm going to try to create some kind of system that will let me to memorize the 5 different IPv6 tunnels.

I don't know what you mean by FLG, but I am using the books from The Online CCNP Guide. I have a safari account so I can read any material, but these books "cut the BS" out. I made it through about 200 pages of Wendall Odom's book before I quit. It's too dry, and I would have to reread the pages multiple times. The ccnpguide+INE+Networking Academy Lab Manual is how I am studying.

Day 53

I worked on the fifth IPv6 lab which covered MBGP and OSPFv3. I say worked on because I couldn't get it fully operational. Conceptually I didn't struggle, but I had multiple issues with the actual configuration, which isn't exactly surprising considering the very basic coverage of MBGP in the FLG. I couldn't get peering over link locals going because the IOS refused the input, complaining about scope something. I wasted way too much time on feeble attempts to get that fixed, but eventually I decided to use the global addresses instead and move on.

The next issue, which killed my chances of getting the thing working, was that the neighbor next-hop-self command didn't seem to work. In retrospect I might have been able to fix it with an incoming route-map, manually adjusting the next-hop address. In these IBGP scenarios with no IGP running, controlling your next hops is obviously crucial since a router has no clue about anything not directly connected.

I didn't really get to the IPv6 tunnels like I thought I would, but the next lab introduces them so I guess I better prepare.

Day 54

I spent most of the day at my parents place, but I felt inspired when I got home and repeated that lab from yesterday, and also quickly did the first lab on IPv6 tunnels.

Day 55

I finished up the remainder of the IPv6 chapter and did the last 3 or 4 IPv6 labs. With that I've reached a point where I'm not quite sure what my weak areas are, and I have more than a month left until the exam. I'd like to think that I'm weak on theory and strong on configuration, but my CCNA results tell a different story. I scored an embarrassing 64% on configuration there and only passed because I had several 100% categories. I really don't want that to happen again so I guess I should create some kind of plan at this point. Any suggestions on how to approach this final month are appreciated.

Day 56

I had a long session where I did most of the EIGRP labs. I figured that it made sense because it was a few weeks since I worked with that protocol. Anyway, compared to the BGP labs, these were significantly easier which probably reflects the fact that an EIGRP lab with 4 routers can only be made so hard. I did work with some commands that weren't in the FLG like next-hop-self and summary-address leak map. I also engineered FD/AD and variance to install multiple routes in the routing table, while still only using the cheapest one with traffic-share min across. A lot of off-set list usage as well. All in all, a very enjoyable six hours with labs that were at just the right level of difficulty to create that fuzzy feeling of flow.

Day 57

I basically mirrored the day before, but this time with OSPF. I managed to get through 7 out of the 10 labs, and I did feel like these were a tad bit harder than the EIGRP labs. When I got stuck though it was mostly because of the requirement to use some command that I had never even heard of, and restrictions, all these restrictions. The main thing I got out of it was probably getting better at verification since I was required to look into the ospf database on many occasions.

Day 58

Finished up the last 3 OSPF labs. I got into some of the more obscure features and it was probably more or less useless in terms of exam prep, but it was certainly a good reminder that I pretty much don't know anything in the grand scheme of things. I've also realized that I know the ospf packet types, the adjaceny states, the network types and the LSAs by heart which is good because I thought I would have major issues remembering that stuff. I'll focus on redistribution over the weekened because I doubt you could study that enough.

Quick Links