Its happening! CCNP here I go...

After a discussion with some regulars here and some people on Linkedin I have decided to begin CCNP work despite having only 18 months of work experience.

I am familiar with the arguments against CCNP with that little experience. I am prepared to battle my way through the interview hell that this may bring on me. But that is all for a later date & time.

For right now, I am focusing on 300-115 (SWITCH) first since it is what I have the most experience with and will provide the most benefit to me in my current role. I am enrolled full time in school (BS in Info Sec), typically work about 50 hours a week and have a family that comes first. With that said...

Here is the plan for SWITCH:

Read FLG / build lab / familiarize myself with the objectives
Watch Chris Bryants videos on Udemy / Lab along / makes notes
Read OCG / More labbing / make notes
Combine notes into study guide / find weak spots, reaserch/lab them
Crush exam
???
profit

Lab setup:
2x 3750
2x 2950 (for STP participation)
2x 1841s (unknown use at this point)

I think this style lab will get me through everything on the objectives, does anyone have some ideas or criticism? I plan on setting up QinQ with GNS3 for the ROUTE exam when I finish up SWITCH.

I have finished chapters 1,2 & 3 in the FLG. So far a lot of review that I needed and some new ideas that I can actually use in my day-to-day work already. I can tell the exam content is going to teach me some things I really need to know.

I will be posting here with questions and looking for advice from others as I move through the material. The timeline is a long one, about 12 months for all three exams.

Find more posts tagged with

Comments

First question: Looking over the ROUTE objectives I ran across something I had never seen before, so I googled it.

VRF-lite
Catalyst 4500 Series Switch Cisco IOS Software Configuration Guide, 12.2(25)EW - Configuring VRF-lite [Cisco Catalyst 4500 Series Switches] - Cisco

In the description it says, "A VPN is a collection of sites sharing a common routing table".

The word VPN is being used differently than I am familiar with. When I think VPN, I think IPsec and SSL...this doesn't appear to be that. Is VPN being used to mean something completely different here?

--chris-- wrote: »

Is VPN being used to mean something completely different here?

Yes, but it'll make sense once you get to VRFs so don't worry about it. A VRF's basically a separate routing table that only certain interfaces belong to, and using various techniques, that can be used to create VPNs. It's "private" in the sense that forwarding from one VPN to another is prevented. It doesn't have anything to do with encryption.

Get it man! You will knock it out of the park. Good luck

Welcome onboard!

Good luck! I just passed my CCNP: SWITCH exam last night (2nd attempt), and it's a good feeling to have that accomplished. It was tougher than I was expecting, but looking over my notes and what topics I studied, it's not as broad as the CCNA was. It's much, much more focused on the details of spanning tree (STP, RSTP, MST), HSRP, Etherchannel, AAA, and VACLs.

I think you and I are at similar experience/skill levels. I've only been officially on my company's network team for less than a year, but I was handling a lot of Layer 2 and server issues before I got promoted. I don't think it's such a big deal to have limited experience + your CCNP. All having the CCNP proves is that you know and understand the topics on the CCNP exams (hopefully); it doesn't mean you are automatically some sort of network wizard. If you have limited experience, just be honest about that in interviews.

I think your plan and equipment list looks good. I managed with 2 x 2950's, 3 x 3550's, 1 x 3750G, 1 x 1841, and 2 x 2621's (didn't really need those routers, though). Also highly recommend the Chris Bryant videos...I used those as well.

I'm gonna take a few days off, then start on ROUTE.

You got this Chris. I'm about to finish my CCNA. I'll try to keep up with you.

stylezunknown wrote: »

You got this Chris. I'm about to finish my CCNA. I'll try to keep up with you.

This is something I would recommend if you know ccnp is in your future. This feels like it picks up right where CCNA left off.

The 3750 24fs-s i just picked up is pure 100base fx. Will this sfp work with the sfp slots I have in this switch? I'll get two if this will work.

New Cisco Compatible 10/100/1000BASE-T Gigabit Ethernet Auto Negotiation Copper SFP Optical Transceiver Module -Fiberstore

fredrikjj wrote: »

Yes, but it'll make sense once you get to VRFs so don't worry about it. A VRF's basically a separate routing table that only certain interfaces belong to, and using various techniques, that can be used to create VPNs. It's "private" in the sense that forwarding from one VPN to another is prevented. It doesn't have anything to do with encryption.

So this is sort of like security through obscurity?

This makes sense, and will probably be a good summary of how a lot of ROUTE will go. New (to me) technologies with names I associate with other ideas.

--chris-- wrote: »

So this is sort of like security through obscurity?

No, if you get an MPLS VPN based connection you are prevented from sending packets into another customer's VPN, assuming correct configuration of course. Since the VRF your router is connected to only the SP side only has routes to your sites, there's no trick you can do to make the router forward packets to a different customer.

However, the service provider can see every customer's traffic since there's no encryption of the packets. Therefore you must either not care about the contents of the packets getting into the wrong hands, or trust your service provider, or add some form of encryption on top of the MPLS VPN service.

fredrikjj wrote: »

No, if you get an MPLS VPN based connection you are prevented from sending packets into another customer's VPN, assuming correct configuration of course. Since the VRF your router is connected to only the SP side only has routes to your sites, there's no trick you can do to make the router forward packets to a different customer.

However, the service provider can see every customer's traffic since there's no encryption of the packets. Therefore you must either not care about the contents of the packets getting into the wrong hands, or trust your service provider, or add some form of encryption on top of the MPLS VPN service.

Ahh I got it.

Whats the most common thing to do here? Trust the ISP or encrypt all data on MPLS?

1/3 of the way through the FLG, still feel like its 50% review and 50% building on things I have worked with or wondered "how exactly did that just happen on its own....?" Too be honest, the VLAN, VTP, Etherchannel and (R)STP sections feel almost identical to the CCNA material but with an added 20-30% of depth on certain topics (like tuning PVST+ & how MST works).

Main takeaway for anyone following along - I wish I would have started this sooner after passing the CCNA. I have some "rust" that would not have been there if I started this 6 months ago.

I ordered 2 of those SFP's above to make my cheap 3750 work in my lab. I will review them since they are about 1/5 the cost of Cisco branded SFPs.

--chris-- wrote: »

Too be honest, the VLAN, VTP, Etherchannel and (R)STP sections feel almost identical to the CCNA material but with an added 20-30% of depth on certain topics (like tuning PVST+ & how MST works).

This is how I feel, the later chapters in the book do go into more depth with DHCP snooping, SPAN etc. It's a pretty good read overall, I have about 1 chapter to go and my exam is booked in

!

The start is very samey.

Simrid wrote: »

This is how I feel, the later chapters in the book do go into more depth with DHCP snooping, SPAN etc. It's a pretty good read overall, I have about 1 chapter to go and my exam is booked in !

The start is very samey.

I wish I had more time to devote to this book, every time I pick it up I fill in apiece of knowledge I wish I knew previously (so that's why that failed at client Y...).

Good luck on SWITCH!

I come today with a question: SWITCHPORT AUTOSTATE EXCLUDE

The best explanation I have found for this is that you use this command when you need to keep an SVI up/up even after all participant ports in that vlan go down/down. Is this correct?

And if that is correct, what is the use case for this? I need to tie it to a purpose to help retain it...the only thing I can think of is if you wanted the SVI to participate in L3 routing protocol....if it were to go down, then the routing protocol would have to recalculate causing possible outages?

I have some ideas on a few STP/RSTP concepts, maybe someone here can let me know if I am on the right path with these...

BPDU Guard: Used only on access ports; protects against loops by shutting down the port if it receives a BPDU; can be enabled globally...if globally enabled instead of putting the port that received a BPDU into err disabled it removes the port-fast state from the interface and the interface will begin to work through the listening/learning stages
BPDU Filter: Should be used with caution; should only be used on access ports; keeps BPDUs from being sent & received from port - presents the opportunity for a loop because it will stay in a forwarding state
Root Guard: This protects the root bridge; discards superior BPDUs if received on the port with Root Guard enabled; not sure why this would be used if you can control root bridge through other methods..

I have other questions regarding this technologies, but my battery is about dead. I will post them later.

--chris-- wrote: »

I have some ideas on a few STP/RSTP concepts, maybe someone here can let me know if I am on the right path with these...
BPDU Guard: Used only on access ports; protects against loops by shutting down the port if it receives a BPDU; can be enabled globally...if globally enabled instead of putting the port that received a BPDU into err disabled it removes the port-fast state from the interface and the interface will begin to work through the listening/learning stages

BPDU Filter: Should be used with caution; should only be used on access ports; keeps BPDUs from being sent & received from port - presents the opportunity for a loop because it will stay in a forwarding state

Root Guard: This protects the root bridge; discards superior BPDUs if received on the port with Root Guard enabled; not sure why this would be used if you can control root bridge through other methods..

I have other questions regarding this technologies, but my battery is about dead. I will post them later.

Root Guard ensures that if an unauthorized switch has a priority of 0 that it can't become the root. You can't set what should be root to a lower priority than 0 so Root Guard must be used in that situation.

shortstop20 wrote: »

Root Guard ensures that if an unauthorized switch has a priority of 0 that it can't become the root. You can't set what should be root to a lower priority than 0 so Root Guard must be used in that situation.

So it protects from rogue switches with a priority of zero. This makes sense, thanks!

Just finished the HSRP chapter. I will have to go back and re-read the HSRP stuff from ICND2 but I feel like it was almost verbatim the same things...

The plan is to finish this book within the month, start OCG and crank up the labing portion of this adventure.

In other new, I was invited to interview for a Tier 2 or 3 NOC position. Tier 2 would be all switch & routers, Tier 3 would be fire-walling. I declined for two reasons; the commute would be about 1h 20m each way and the pay was pretty low for "tier 2/3" at $41000 and $46000 respectively.

That's a nightmare commute. I also bet they are constantly filling that position at that rate. Seems like an ideal place to get experience and get out as soon as you find something better.

I considered it, but I would be making quite a bit less once you factor the gas/commute/personal vehicle costs. I am buying a house right now...the last thing I need is to increase my DTI ratio.

I'm retaking SWITCH tomorrow and have started reading for ROUTE. I completely agree with you about SWITCh, it really felt like the CCNA with a little more detail. I do deal with vlans and L2 stuff in general at work, so I might not realize how much exposure I have to it. Route is feeling a bit more overwhelming because I don't have much experience with it.

daba wrote: »

I'm retaking SWITCH tomorrow and have started reading for ROUTE. I completely agree with you about SWITCh, it really felt like the CCNA with a little more detail. I do deal with vlans and L2 stuff in general at work, so I might not realize how much exposure I have to it. Route is feeling a bit more overwhelming because I don't have much experience with it.

That sounds like me in a nutshell. I feel like I don't get much L2 exposure at work, but I must get some because a lot of this are things I have worked with on client sites.

I too also fear ROUTE, I have no exposure to routing protocols in a prod environment.

Just about ready to finish up the FLG, working through its security section. I am struggling with understanding how/why the vlan access-map command is used. T think its used in the following way...but I really dont know.

Create the VLAN acl's. Then using the access-map command to combine ACL's into what you are trying to achieve. Then you apply the access-map to the ports you want to filter.

Am I on the right path?

I've just refreshed that after someone else asked the same thing.
In short: Yes you're on the right path. With a vlan filter/VACL you can permit/deny traffic inside the same vlan and couple it with Mac ACLs too.

I.e. you can deny all HTTP/tcp80 traffic just by making an acl like:
access-list 123 permit tcp any any eq www
and inside a vlan access-map you drop the matched acl:
match ip address 123
action drop

And a new sequence number with just an "action forward" to allow everything else inside the VLAN filter.
Something like:
access-list 123 permit tcp any any eq 80
vlan access-map Deny-http 5
match ip address 123
action drop
vlan access-map Deny-http 10
action forward
vlan filter Deny-http vlan-list 10 (apply the "Deny-http" access-map to vlan-list with vlan10)

All TCP/80 traffic inside vlan 10 is denied by matching all tcp/80 trafic in your ACL 123 after adding the vlan10 in the vlan filter command.
To clarify a bit more: They can control access for packets bridged/forwarded inside a vlan or routed across VLANs(think SVIs). They just don't have any control if its inbound or outbound - it's both.

joetest wrote: »

I've just refreshed that after someone else asked the same thing.
In short: Yes you're on the right path. With a vlan filter/VACL you can permit/deny traffic inside the same vlan and couple it with Mac ACLs too.

I.e. you can deny all HTTP/tcp80 traffic just by making an acl like:
access-list 123 permit tcp any any eq www
and inside a vlan access-map you drop the matched acl:
match ip address 123
action drop

And a new sequence number with just an "action forward" to allow everything else inside the VLAN filter.
Something like:
access-list 123 permit tcp any any eq 80
vlan access-map Deny-http 5
match ip address 123
action drop
vlan access-map Deny-http 10
action forward
vlan filter Deny-http vlan-list 10 (apply the "Deny-http" access-map to vlan-list with vlan10)

All TCP/80 traffic inside vlan 10 is denied by matching all tcp/80 trafic in your ACL 123 after adding the vlan10 in the vlan filter command.
To clarify a bit more: They can control access for packets bridged/forwarded inside a vlan or routed across VLANs(think SVIs). They just don't have any control if its inbound or outbound - it's both.

I appreciate the response, but I am still lost

It could be the head ache though. I finished the FLG tonight, starting to lab and re-read subjects that I feel weak on.

It's a bit like a route-map. Instead of setting some action(set ip next-hop bla bla), you're now telling to drop or forward whatever traffic it is you're permitting in your access-list(which can be a Mac acl).

I say match all traffic (any to any) using port tcp/80 aka http/www in access-list 123:
access-list 123 permit tcp any any eq 80
Then I start a vlan access-map "Deny-http" with sequence nr. 5 like a route map, using that name to make it descriptive:
vlan access-map Deny-http 5
Where I match IP addresses based on whatever is in the ACL 123(which was any to any on port tcp/80):
match ip address 123
Ok, so now I've told the access-map to match traffic on port 80 and If traffic inside whatever vlan is matched(packets to going to port 80 on server host) then drop/stop it:
action drop
Now all http traffic going from any to any will be dropped, but remember like ACLs there's an implicit deny ip any any at the bottom, so to circumvent that I make a new statement with a higher sequence in the same vlan access-map:
vlan access-map Deny-http 10
And I tell the next sequence number to just forward all traffic(if it's not http-traffic):
action forward

Now I've created my access-map(like a route-map) and just have to apply it to whatever Vlans I want to use this filter(deny all http traffic, but permit everything else):
vlan filter Deny-http vlan-list 10
You now drop all http traffic going from any to any INSIDE vlan 10. That's why you also can drop/forward based on Mac adresses if you use a mac acl to match them. It's inside the same Layer 2 domain which forwards based on... Mac adresses.

You'll get it once you lab it a bit.

Thanks again! I was over complicating the idea...I have a better grasp on it now. I need to lab it a bit before I feel comfortable with it though.

For anyone following along, I am still chugging away at the studies. I have decided to start posting on linkedin. Essentially what I do is I make 1 post for each objective, breaking the objective down into terms I understand than write about it as if I am trying to tech someone else what I just learned. So far its been great for retaining the knowledge. It also forces me to lab the objective so that I can verify my post is accurate.

It has the nice benefit of increasing profile views as well as showing potential employers I am not just looking for a job, I really do enjoy this stuff!

I realized yesterday my CCNA expires in Jan of 2017 (1/4/2017), so now I REALLY need to buck up and finish this.....picking up where I left off, reviewing the OCG for material as a refresher, reviewing my linkedin posts I made which are summaries of each section, then moving onto labbing.

Set the lab up in the new house (moved in late January of this year, new job in June, been busy) and now just need 3 more console cables to get everything connected all the way. Reset configs, erases vlan.dat's and did so wr mem....ready to go!

Also ordered the FLG and lab guide.

--chris-- wrote: »

I realized yesterday my CCNA expires in Jan of 2017 (1/4/2017), so now I REALLY need to buck up and finish this.....picking up where I left off, reviewing the OCG for material as a refresher, reviewing my linkedin posts I made which are summaries of each section, then moving onto labbing.

Set the lab up in the new house (moved in late January of this year, new job in June, been busy) and now just need 3 more console cables to get everything connected all the way. Reset configs, erases vlan.dat's and did so wr mem....ready to go!

Also ordered the FLG and lab guide.

Good luck man. Also going through a CCNA review at the moment & planning on tackling CCNP soon. Going to start ROUTE first though.

Quick Links