Wednesday, August 31, 2016

CCNA Question of the Week 2

 on  with No comments 
In , ,  
In the following image, you'll see a network topology.  In this topology, the routers are running the RIP routing protocol.  As is traditional with these questions, I'm going to strip out all the irrelevant information.  We're not going to see any router configuration, IP addressing, or anything else that would distract from the question at hand.  The key thing we're going to focus on here is that there are 20 routers.  First, we'll start with a couple assumptions:
  • The RIP routing protocol is configured correctly on every router.  
  • Nothing in the routers configurations differ except for IP addresses and networks in the routing protocol.
  • The IP addressing scheme is correctly subnetted, and the routers are addressed correctly on every interface.
So this week's question is, can the RIP protocol function correctly in this topology?  And for a couple follow up questions:  Why or why not?  Does it make a difference if we're running RIPv1 or RIPv2?




The first thing that probably comes to mind is that the RIP protocol has a maximum hop count.  Most CCNA students go here first when something of this nature comes up.   Now let's consider the difference between hop count, and the number of routers in the topology.  The hop count refers to the number of hops between two routers.  It says nothing about the number of routers in the topology.  

So Let's look at the two routers that are furthest apart, R1 and R20.  In this particular topology, there is no path from R1 to R20 that is more than 7 hops.  And if there a path that exceeded the maximum hop count, it would be ignored by the routing protocol, not having any effect on a different route that didn't exceed 15 hops.  

So the answer to the question is yes, this is a valid RIP topology.  Now two routers exceed 15 hops apart, so there is no part of the topology that is unreachable by any other portion of the topology.  PC1 can reach PC2.

And for the final follow up question, it doesn't matter if we're running RIPv1 or RIPv2.  Neither version of RIP will balk at a hop count of 7.
Share:

Thursday, August 25, 2016

CCNA Question of the Week 1

 on  with No comments 
In , ,  
Group member Donovan Bone posted this question in a discussion, and I thought that it would be a great "Question of the Week" for the group.  So a new thread was started for just it, and a lot of members attempted to answer the question. I didn't expect the majority to get it right, but only one got it right in the three hours I watched the replies.  Not surprisingly, the one person who answered correctly is the only one who actually labbed it up.  So here is the question.

Share:

Wednesday, August 24, 2016

Private VLAN Edge

 on  with No comments 
In , ,  
A common switch feature to limit communications between hosts within a common VLAN is Private VLANs.  I'll talk about Private VLANs in a future post.  Private VLANs can be a bit complex to set up, and they're not supported on a number of older and low end switch models.  A similar technology, Private VLAN Edge is available on a wider range of platforms.  The integrated switch in the Cisco ASA 5505 supports Private VLAN Edge, as does the older 2950 and 3550 series switches.  Because it's simpler and more widely available, Private VLAN Edge is a good starting point.

Private VLAN Edge (also referred to as PVLAN Edge or protected switchport), is a technology which allows the blocking of certain inter-host communication within a VLAN.  It blocks all unicast, multicast and broadcast traffic among the protected ports within a switch, while not interfering with traffic between two unprotected ports, or between one protected and one unprotected port. There is one key exception however.  Control traffic, such as routing protocol updates will still be forwarded between such ports.

Private VLAN Edge differs from Private VLANs in a number of key ways. First, Private VLAN Edge is much simpler to set up.  You simply add the command switchport protected at the interface level, and that is it. Second, Private VLAN Edge is limited to a single switch, whereas Private VLANs can span multiple switches.

That in a nutshell is all there really is to it.  For completeness, let's look at a configuration example. As I said earlier, it's real basic.  I would be normally using an IOU switch in my GNS3 topology, however it would appear that the one place that Private VLAN Edge is not supported is in the L2 IOU devices.  Perhaps in a different image.  So instead I'll be falling back to one of my old trusty 2950s.

S1(config)# interface FastEthernet 0/1
S1(config-if)#  switchport protected
S1(config-if)#  end

And to verify, we have a single show command

S1# show interfaces Ethernet 0/1 switchport
Name-Fa0/1
Switchport: Enabled
Administrative Mode: static access
<<Omitted for brevity>>
Protected: true
Share:

Wednesday, August 17, 2016

Tracking Superseded Windows Patches

 on  with 1 comment 
In , ,  
Here's another short blurb, and I'm mostly posting it here for my own reference.  Part of my job requires analyzing the monthly vulnerability scan and remediating any findings.  On occasion, a patch is reported missing from systems, and it turns out that the patch has been superseded, it is no longer reported by the system as installed.  And occasionally you'll see one wrongly reported that has been superseded, and the superseding patch has also been superseded, making it difficult to track back whether or not the system is actually vulnerable.

I've searched and searched for this fabled spreadsheet provided by Microsoft that tracks which patches supersede which patches, but have come up short every time.  But yesterday, I was given this link, BulletinSearch.xlsx.  Enjoy!
Share:

Monday, August 15, 2016

Obligatory I'm Still Alive Post

 on  with No comments 
In ,  
We're coming up on two weeks since I've last posted. The break started with a family vacation the week of my last post on August 3, and I just haven't gotten back into the swing of writing. I'm still trying to prepare for the SENSS, though I've rescheduled it for the beginning of next month as I've had trouble focusing on the exam material. As always, I've been running in a dozen different directions, picking up where I left off on ESXi/VCenter and trying to learn ExtremeWare, Server 2016, SCCM 2012r2, Advanced Treat Analytics, and Cisco CDA.

Yes, I'm still alive.

Share:

Wednesday, August 3, 2016

How ACL's are Intrepreted

 on  with No comments 
In , ,  
A quick and dirty post as I'm taking a much needed vacation.

Often times, an explanation of an ACLs layout used very simple ACLs with only one or two ACEs.  However, in practice, ACLs can grow to lengths of hundreds of ACEs.  This makes the planning of their layout a very important and complex affair. An ACL is processed from top to bottom.  Each packet which flows through an interface in a direction with an ACL applied will be inspected.  Being processed from the top down means that each packet will be examined against the ACL until a match is made.  The packet will be compared against the first line of the ACL. If a match is made, it will take the action specified by the ACE.  If no match is made, it will then be compared against the second line of the ACL, and so on.  It will continue through the ACL until a match is made, it will take the action specified by that line, and then it will stop processing.  The packet will not be compared to any other ACE after the first match.
Share: