300-115 Progress Thread

FullofBit

I think it's finally time to commit to the 300-115. I have been reading everyone's "I passed" threads (thanks for the advice btw) for the past few months. Based on what I've read, here's my plan and the materials I'll be using:

First Pass (Introduction/Overview) ~ 1 Month
I've selected the following materials to get an overview of the materials based on everyone's feedback. I'm not going to worry about getting too in depth.
CBT Nuggets 300-115 course
Chris Bryant 300-115 course
Cisco E-Learning:

Implementing Cisco IP Switched Networks (SWITCH) v2.0


Second Pass (Depth) ~ 1.5 months
INE 300-115 Technologies
Kevin Wallace Live Lessons

Cisco E-Learning: Implementing Cisco IP Switched Networks (SWITCH) v2.0 Review
3750 Configuration Guide

Practice Test
Boson

Labs
INE Switch Bootcamp VoD & Workbook (going to use VIRL whenever possible to save my tokens)
CBT Nuggets 300-115 Hands On Labs Course (going to use VIRL to follow along)

Cisco E-Learning Labs


My strategy is going to be watch the video first, then read, then lab. I'm hoping to take my first attempt within 2.5 - 3 months.

snokerpoker

Looks like very solid prep work.

When you sit the exam make sure you understand and do the sims 100% correctly. I failed the first time due to basically bombing one sim.

Good luck!

kloppyo

Hi - I've not yet completed my CCNA but wanted to take this opportunity to ask a question as it may save me some time later on.

I noticed you are not planning on using any of the course books (OCG or FLG). I was wondering is because the e-learning contains all the same material as those books and is a comprehensive overview of the info required to help pass the exam?

The reason I ask is I've seen lots of reports of FLG vs OCG and some have even said read both. I feel this is a bit of a grey area. But if for a cost I can guarantee a good source which covers all the exam topics then I'm willing to pay as for me the end goal justified the outlay.

Thanks

kloppyo

Sorry forgot to ask could a similar approach be taken for the ROUTE exam (I.e use the E learning product) as I plan to do that one first.

MustafaIT

Good Luck Bro . I am studying for 300-115 right now . I Started a week ago using Cisco book and cbt nuggets with my GNS3 and real lap .
I hope we can pass after 3 months. Good luck

FullofBit

kloppyo wrote: »

I noticed you are not planning on using any of the course books (OCG or FLG). I was wondering is because the e-learning contains all the same material as those books and is a comprehensive overview of the info required to help pass the exam?

Thanks

Hey. I've used Cisco's E-learning product for CCNA Security and it was WAY better than all other materials out there. I wouldn't have been able to pass CCNA Security without it. I haven't seen a lot of posts about the quality of their E-learning products for CCNP though. I'm hoping that it will be just as good as their E-learning for CCNA:S.

I'm also going to be going through the 3750 Configuration Guide on my second pass just to make sure that everything is covered. I'll let you know if it's enough after my first attempt. Also, I suggest you check out this page regularly: learningnetworkstore.cisco.com/promotions. I got 25% off the E-learning

MustafaIT wrote: »

I hope we can pass after 3 months. Good luck

Good luck to you too.

FullofBit

Just completed Section 1: Analyzing Campus Network Structure of the E-learning course. It was basically a review of the three-tier hierarchical design that was mentioned in the CCNA.

A few of takeaways/reminders from this module:
1. Make sure your devices can handle the increased load in the event that redundancy fails
2. Learned about some device models and their placement in the hierarchy. Also learned about the placement of modular/fixed configuration switches in the hierarchy.
3. Learned about the advantages/disadvantages of extending L3 to the access layer. You should use Local VLANs when extending L3 to the Access Layer

I also watched this video from Cisco Live about extending L3 to the Access Layer because I wanted to learn more about it: https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/campover.html

The course is good so far. However, there is one video where the presenter can't stop saying "uh". The video was less than 2 minutes long and I swear he said "uh" a dozen times. I actually had to watch the video multiple times to piece together what was said between the "uhs" lol.

Chris.Mackenzie01

I've just started the Switch exam myself. I'm in a bit of a 2 way mind set about it, not sure how i sit as reading through some exmaple questions I got 100%.
I've got the official guide, Chris Bryant Videos. GNS3/Eve-ng have tried both and seem to blip between each..

I have previously watched quite a few of the cbt nugget videos for switch when I first passed my ccna and then was looking to dive into CCNP immediately..
Good luck!

FullofBit

Day 2: Completed Section 2: Exploring Switches

Most of it was a review on Switch operations such as: forwarding behavior (forward, filter, flood), switching methods (process switching, fast switching CEF), MAC learning, etc. There were a few topics in this section that went into more depth than what was covered in the CCNA, such as TCAM, SDM templates, and LLDP. I feel like I need to do some additional research on TCAM for sure.

Some takeaways/reminders from this section:

• Ternary CAM uses a mask in addition to binary values as a key to perform table lookups
• IPv4 uses one entry in the TCAM, but IPv6 uses more than one which means that you will have fewer entries that can be looked up in hardware
• Don't use the dual-ipv4-and-ipv6 SDM template if you are only using IPv4! because part of the TCAM will be allocated for IPv6 and that space therefore can't be used for IPv4 (you're basically wasting TCAM space)
• ACLs/QoS parameters are stored in TCAM
• Reminded me that STP port state affects forwarding decisions
• Not all packets can be forwarded by CEF such as ARP, Broadcast traffic sent as unicast, etc.
• What protocols operate at Data plane, Management plane, control plane
• CEF polarization can mess up your load balancing due to default dest-based load balancing
• Make sure that a feature that you are using has an appropriate amount of space in the TCAM. If the space for that feature becomes full, then all processing overflow is sent to the CPU.
  

I know I said that I wouldn't use Cisco Docs until the review phase, but I can't help it. Here are the links that I used for additional research:

• http://www.ciscopress.com/articles/article.asp?p=101629&seqNum=2 (Covers L2/L3 switch operation as well as CAM/TCAM)
• https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/15-0_2_se/configuration/guide/scg3750/swlldp.html(Covers LLDP)
• https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/15-0_2_se/configuration/guide/scg3750/swsdm.html (Covers SDM)

​
Lab Progress

There was one lab in this module, but it was a CAM table discovery lab. I wish they would have done an SDM lab and/or an LLDP lab instead. A few mistakes I made while labbing:

• Tried to enable IPv6 routing without changing the SDM template lol
• Forgot to reload after changing SDM template

clarson

hello every one,
I'm studying for the switch exam also. I came across a question about the implementation of where to place stp root guard. But I've gotten different answers. So, lets discuss it and get an answer for everyone.

What I've been able to find out is this:
1) enable root guard on all ports where the root bridge should not appear.

this would mean all access ports. And, access ports should set up with portfast and bpduguard.
This leaves all the links and that won't allow stp to reconverge if there is a root failure

2) enabled on all the designated interfaces.
again how does this effect reconvergance if there is a root failure

3) portfast/bpduguard on all access ports and root guard on ports towards the customer (other organization). no where else in your environment. inside your own network, using Root Guard is a questionable practice. Your network can be considered trustworthy and there is no rogue root switch to protect against. Using Root Guard in your own network could cause your network to be unable to converge on a new workable spanning tree if any of the primary links failed, and it would also prevent your network from converging to a secondary root switch if the primary root switch failed entirely.

4) at the distribution layer facing the access layer. no access layer switch can become the root bridge and only distribution and core layer switches can. and core switches probably aren't running stp.


if the links between the HSRP primary and standby fails. The access switches are sending superior BPDUs but the secondary distribution switch will block the link due to Root Guard being implemented. This means that any traffic arriving
at the secondary distribution switch destined for the access layer switches will be black holed.

so what are your thoughts on this?

negru_tudor

clarson wrote: »

hello every one,
I'm studying for the switch exam also. I came across a question about the implementation of where to place stp root guard. But I've gotten different answers. So, lets discuss it and get an answer for everyone.

What I've been able to find out is this:
1) enable root guard on all ports where the root bridge should not appear.

this would mean all access ports. And, access ports should set up with portfast and bpduguard.
This leaves all the links and that won't allow stp to reconverge if there is a root failure

2) enabled on all the designated interfaces.
again how does this effect reconvergance if there is a root failure

3) portfast/bpduguard on all access ports and root guard on ports towards the customer (other organization). no where else in your environment. inside your own network, using Root Guard is a questionable practice. Your network can be considered trustworthy and there is no rogue root switch to protect against. Using Root Guard in your own network could cause your network to be unable to converge on a new workable spanning tree if any of the primary links failed, and it would also prevent your network from converging to a secondary root switch if the primary root switch failed entirely.

4) at the distribution layer facing the access layer. no access layer switch can become the root bridge and only distribution and core layer switches can. and core switches probably aren't running stp.


if the links between the HSRP primary and standby fails. The access switches are sending superior BPDUs but the secondary distribution switch will block the link due to Root Guard being implemented. This means that any traffic arriving
at the secondary distribution switch destined for the access layer switches will be black holed.

so what are your thoughts on this?

It all comes down to policy: what and how you want / need things implemented in your environment.

Points 3 and 4 are kind of accurate but also leave it up to you to make up your mind depending on the environment you're in.

From STP's perspective, one thing to note at point 4 is that even if the link between your HSRP nodes fails the topology can reconverge and redundant paths are put into forwarding state. Your topology would look like an N for example. Not sure why you would have those access switches even send out superior BPDUs. Usually you'd hardcode the priority on your root and backup root nodes to something low enough (4096 or 8192) that the access switches will not be able to beat by default (32768 ).

You wouldn't need Root Guard if you wouldn't have a trust boundary in your switched topology (ex. interconnect to another vendor or department's switched/L2 topology); working around wacky STP elections can be done if you're deliberately assigning STP priorities on your root/backup root nodes.

Root Guard as a concept in itself makes sense and can easily be labed / observed but the use cases really depend on what your requirements are and environment looks like.

Chris.Mackenzie01

negru_tudor wrote: »

It all comes down to policy: what and how you want / need things implemented in your environment.

Points 3 and 4 are kind of accurate but also leave it up to you to make up your mind depending on the environment you're in.

From STP's perspective, one thing to note at point 4 is that even if the link between your HSRP nodes fails the topology can reconverge and redundant paths are put into forwarding state. Your topology would look like an N for example. Not sure why you would have those access switches even send out superior BPDUs. Usually you'd hardcode the priority on your root and backup root nodes to something low enough (4096 or 8192) that the access switches will not be able to beat by default (32768 ).

You wouldn't need Root Guard if you wouldn't have a trust boundary in your switched topology (ex. interconnect to another vendor or department's switched/L2 topology); working around wacky STP elections can be done if you're deliberately assigning STP priorities on your root/backup root nodes.

Root Guard as a concept in itself makes sense and can easily be labed / observed but the use cases really depend on what your requirements are and environment looks like.

Agree with this, although must admit - every environment I've been in we have always had Root Guard enabled on all access ports. Just assumed it was best practice.

clarson

yes, it does seem to be very dependent on the topology. which makes it a good test question. there isn't just one answer. Your given a topology. now do you know what you are doing.

negru_tudor

clarson wrote: »

yes, it does seem to be very dependent on the topology. which makes it a good test question. there isn't just one answer. Your given a topology. now do you know what you are doing.

Correct. Know the concept, how it works, lab it up and roll it out if there's a need for it. Most times, interfaces that aren't in use go in shutdown state and on an isolated VLAN so that lowers the risk of a rogue switch. Rolling out BPDU Guard will also decrease chances of getting rogue switches on the LAN that could mess up your topology.