Posts from ‘General’
“Why doesn’t this PING work!?!”
Here is a simple 3 router configuration, well at least it is simple on 2 of the 3 routers. R1 and R3 are configured quite traditionally, but R2 is a bit more involved.
Here is the diagram.
Here are the details.
R2 is using a VRF which includes both LAN interfaces. R2 is also acting as a Zone Based Firewall in transparent mode, allowing all ICMP traffic in both directions, as well as SSH from the inside to the outside networks. R2 has a bridged virtual interface in the 10.123.0.0/24 network. All are running OSPF, but pings issued from R2 to the loopbacks of R1 and R3 are failing.
Can you identify why? Continue Reading
RFC, or Request for Comments, are documents published that describe various items surrounding computer networking. Generally, these are memorandums published by the Internet Engineering Task Force.
RFCs can be a great resource. For some unknown reason, most candidates preparing for the CCIE don’t take the time to review these documents, which can be very helpful in assisting with understanding the how and why of various networking components. Perhaps the language is a bit dry, or they prefer books with shiny covers.
You have just been given a shiny, new router to configure. As part of the configuration, you are asked to configure an outbound access list which will only permit traffic through to specific destinations. Here are the requirements that you are given for your access-list:
Match (and permit) the following destinations using an access-list. Your access list should use the fewest number of lines, and should not overlap any other address space.
Anything within the 10.0.0.0/8 address space.
Anything within the 172.16.0.0/12 address space.
Anything within the 192.168.0.0/16 address space.
Anything within the 169.254.0.0/16 address space.
Be warned, it is estimated that a very high percentage of readers will NOT have the correct answer.
The leading question:
“Is it possible (and if so, how) to redistribute or originate a default route based on time of day?”
The short answer is “Sure, why not?”… But the longer answer has to do with how do we warp the forces of the universe to make that happen???
Well, start with what we know. We know we can do time-ranges in access-lists, right? Can we do them in standard access-lists (what we see used for redistribution all the time)?
Rack1R1(config-if)#exit Rack1R1(config)#access-list 1 permit 172.16.0.0 0.15.255.255 ? log Log matches against this entry <cr> Rack1R1(config)#
Nope. There’s a bummer. So we will need to use EXTENDED ACL’s in order to make this work. So now we are reaching the point of “Yes, it can be done, but it will make my head hurt.” as the answer.
First, as a little review, check out a blog we did last year providing some information on that sort of thing in conjunction with a distribute-list in different routing protocols.
Hello faithful blog readers. We all know there are some real treasures in the DOC-CD that can assist dramatically in the lab exam. Here are some of our reader’s favorites. Thanks to my friend Ruhann over in South Africa for the post idea!
All navigation begins from http://www.cisco.com/cisco/web/psa/configure.html?mode=prod
I. Bridging and Switching
a. Integrated and Concurrent Routing and Bridging
Cisco IOS Software – 12.4 Family – 12.4 Mainline – C.G. – Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.4 – Part 1: Bridging – Configuring Transparent Bridging
II. IP IGP Routing
a. Best Path Selection
Cisco IOS Software – 12.2 Family- 12.2 Mainline - C.G. – Cisco IOS IP Configuration Guide, Release 12.2 – Part 2: IP Routing Protocols – Configuring BGP – How BGP Selects Paths
Answers for Part II
So the answers to the exciting tasks at hand….
There was a good amount of activity surrounding answers submitted for the contest! It was good to see that many people interested in them! Now, it’s time to go through the answers and stretch the imagination a bit! Be prepared for some stretching as well!
One quick thing to point out before we get started, there was a question asked about why /24 routes won’t have a “.255″ as the fourth octet. This really depends on how we are using the ACL. If we are doing traffic filtering, where packets will obviously come from hosts INSIDE the /24, then yes, I’d use a “.255″ mask.
However, when the entry is being used for a routing filter, and it’s a /24 route… The fourth octet will, by definition, always be “.0″ and shouldn’t be changed. So the mask of “.0″ prevents anything from changing!
Now… On to the answers!
Thank you to everyone who participated… It was my first time running a little contest on the blog, and I’m sorry to say it didn’t quite work as I expected! The comments were not supposed to be seen until a day later, but I think I forgot to share that with the other folks here! My bad!
Anyway, there are a variety of answers that we received in the commentary, and remember that I said all three must be correct. That was the catchy part, as even the first few people were almost there. Almost, but not quite! It’s a good learning curve though!
Andrew Dempsey was the first person to actually get all three of them correct! Congratulations! Andrew, pop me an e-mail and we’ll figure out how to get the tokens to you.
To everyone else, I promise to have all the kinks worked out by tomorrow when I post Part II with a much more exciting set of things to think about!
1. Start picking a few and finding similarities again…
Just like with our even/odd example, we look at the constants. The last two bits will ALWAYS be “00″. So a mask of 11111100 would fit.
access-list 16 permit 184.108.40.206 0.0.252.255
2. Our differences here are in the third octet.
There are three bits of difference between the six values there. The 2-bit, 4-bit and 8-bit positions. But 2^3 would yield eight matches.
140 and 142 are missing there. So we have two ways of looking at this.
access-list 17 permit 220.127.116.11 0.0.6.0
access-list 17 permit 18.104.22.168 0.0.2.0
access-list 17 deny 22.214.171.124 0.0.2.0
access-list 17 permit 126.96.36.199 0.0.14.0
Either way, two lines is our best bet!
3. This is a little more complicated than it looks! Namely because there’s a gap in the middle and we aren’t allowed to use any “deny” statements! Go figure!
This exercise is just like creating subnets though. How well did you know your bit boundaries?
So let’s make as many major blocks as we can.
access-list 18 permit 188.8.131.52 0.0.0.63
access-list 18 permit 184.108.40.206 0.0.0.15
access-list 18 permit 220.127.116.11 0.0.0.7
access-list 18 permit 18.104.22.168 0.0.0.3
access-list 18 permit 22.214.171.124 0.0.0.0
access-list 18 permit 126.96.36.199 0.0.0.0
access-list 18 permit 188.8.131.52 0.0.0.3
access-list 18 permit 184.108.40.206 0.0.0.15
access-list 18 permit 220.127.116.11 0.0.0.127
After a while you have to think about all the different bit boundaries. On the bright side, Windows Calculator available to help if necessary!
Back in a day’ish!
As CCIE candidates, we are asked to do all sorts of things with access lists. We have them in lots of different places, and use them in lots of different ways. So many, sometimes, that it becomes very confusing to follow things!
Access-lists themselves aren’t really that bad. Or are they? When we use them with route-maps, occasionally we see permits in an access-list that are really used to deny the packet/route/whatever. What’s up with that?
Remember that ACLs are simply a matching mechanism. Something either DOES (permit) or DOES NOT (deny) match the list. Now, what we do with that matching status depends on how we use the ACL. As an interface-based packet filter, it truly is a permit or deny of the packet! In a route-map, it would depend on whether the route-map clause is a permit one or a deny one, in which case anything MATCHING the ACL would follow that route-map permit or deny ability.
Now, within an access-list, we also have some difficult things to grasp. I like to consider that lesson in binary math. That may oversimplify it, because really all we are doing is counting a 0 or a 1. How difficult can it be to count to one???
All by itself, it’s not that difficult. But the we’ll get some really obnoxious words thrown in like “in as few lines as possible” or “minimal configuration”. That means we have to start thinking about how the router sees things.
Let’s start with some groupings or summaries, and get the ball rolling.
In as few lines as possible (which translates to “no overlap”) summarize:
There’s only four networks, so it should be a /22, right? We learned that back in CCNA! Well, not quite so fast, because there’s a bit-boundary in our way. The best way to start with any of these tasks is to work with the binary and start to see the patterns.
Now, we may have seen some documents about performing an XOR function between the different entries. This is kinda-sorta true. From a pure logical construct, XOR measures between two different things. Here we have four. So would it be an XXXOR or an XOROROR? Either way, the point is we are beyond the basic logical formula!
But it really isn’t as bad as it may sound! Think about it in very simplistic terms! Next, we look at what things are the same and which are different. Well, between 31 and 32 we see LOTS of things that are different. 6 bits, in particular, have different values. When we create an ACL binary mask, the 0-bit means “stay the same” while a 1-bit means “different” or “don’t care”.
So just on two values with 6 bits of difference, we could come up with a mask of 00111111 and it would work. The problem we create, though, is the over-matching. If you take 2 to the power of the total number of 1-bits in your mask, you’ll find the total number of matches for the mask.
In this case, 2^6 yields 64 matches to that mask. We only have four things to group, so that’s not cool. So we won’t be able to get our summary in one line!! Leave 31 by itself then. Look at 32, 33 and 34.
There are two bits (the 1-position and 2-position) that are different. Here with a mask of 00000011 and two bits set to the 1-bit value, there will be a total of four matches to the mask (2^2). Still more than we want, as there’s only three lines left after setting aside “31″!
But, here’s where we start to look at multiple ways to accomplish the task!
access-list 10 permit 172.16.31.0 0.0.0.255
access-list 10 permit 172.16.32.0 0.0.1.255
access-list 10 permit 172.16.34.0 0.0.0.255
access-list 10 permit 172.16.31.0 0.0.0.255
access-list 10 deny 172.16.35.0 0.0.0.255
access-list 10 permit 172.16.32.0 0.0.3.255
Both results give us a total of three lines as the tightest configuration we can get. The difference is that one of them over-permits, but we deny those non-listed things first! So if your lab task says there “must be at least one ‘deny’ statement” then this is it.
The bottom line is no more, no less though! So let’s add to that list.
In as few lines as possible (which translates to “no overlap”) summarize:
We know we’ll run into the same basic quandary with “31″ and the others as we did before. But what about the rest? Back to binary.
Counting 31 off on its own, we notice there are three bits that have varying values from 32 through 37. The 1-bit, 2-bit and 4-bit positions. So if we used a mask of 00000111, that would cover all of those three bits.
2^3 to check the mask though tells us there would be eight matches. There’s only six values listed to match. We want no more, no less! Notice that 32 through 35 has two bits varying between them. A mask of 00000011 would match ONLY those four. And a mask of 00000001 would match ONLY the 36 and 37.
So we can use:
access-list 11 permit 172.16.31.0 0.0.0.255
access-list 11 permit 172.16.32.0 0.0.3.255
access-list 11 permit 172.16.36.0 0.0.1.255
What if we were told that we must have at least one DENY statement in the ACL?
Oh, those obnoxious requirements! Think like we did with the first one with the over-permitting. Let’s go back to the 00000111 mask. What extra values come into play there?
With a mask, we are saying we permit any and all of the variants with the bits. No matter where they fall in the mask, we should substitute values in to see them!
With three bits, we need:
The “110″ and “111″ matches are not in our list. That would be 38 and 39.
Those can be summarized as well, so here’s a list with a deny:
access-list 11 permit 172.16.31.0 0.0.0.255
access-list 11 deny 172.16.38.0 0.0.1.255
access-list 11 permit 172.16.32.0 0.0.7.255
Exactly the same list is being permitted as before. With no more or no less.
Now, let’s start talking about non-contiguous matching! Because that’s where life becomes more interesting. We’re following the same rules though.
What if we are instructed to pick only the even /24 networks from 192.168.0.0/16?
As I said, the rules don’t change here, it’s just “different” than we may be used to building masks for. We just aren’t drawing a “line” to separate network from host. That’s the CCNA version of access-lists. While it’s technically true, it’s not the entire truth! As a CCIE we are expected to know more!
So we can go back and start breaking all the even numbers up into binary to start to see our patterns.
Blah, blah, blah… You get the idea. Keep going if you want, but you should already get the pattern. The ONLY bit that WILL NEVER change is the 1-bit position, which will always be a zero.
Our mask will consist of seven “don’t care” bits and one “must be the same” bit. 11111110 will work perfectly fine. Now, here’s the catchy part. What do you put as the ‘network’ portion of the ACL?
Well, let’s expand on that “network” name…. Again, very CCNA explanation. What really is happening is that your ACL has a “binary starting point” and a “binary mask” to go with it.
So we need to SET our values, then provide the rules for what can change or what cannot.
access-list 12 permit 192.168.0.0 0.0.254.0 will permit all of the EVEN /24′s there.
Why did we put “.0″ as the fourth octet? Because the question asked for /24′s, which implies this will be used in a routing protocol. All /24 network advertisements must have “.0″ as the fourth octet and it cannot change. If it were a security question asking for hosts in the even numbered networks, then we would use a 0.0.254.255 mask.
What if we wanted the ODD networks out of the same range?
You can work out the binary if you want, but you will find that the mask will actually be the same thing. The only difference here is that our STARTING POINT changes.
access-list 13 permit 192.168.1.0 0.0.254.0 will permit all of the ODD /24′s!!!
So our big lessons here are:
- All bits are treated individually (no “line” to draw)
- The logical least number of lines may include over-permission with a deny first
- It’s not a “network”, but rather a binary starting point.
- Don’t forget to check the mask using 2^(# of 1-bits in the mask) forumla!
Some extra ones to think about, and we’ll see who gets the answers first.
1. Allow packets from all hosts in every fourth /24 network from 18.104.22.168/16
2. In as few lines as possible, permit only the following networks (assume it will be a distribute-list):
3. In as few lines as possible, allow access from all hosts in the 22.214.171.124/24 network except .93 through .106. You are not allowed to use any “deny” statements.
Be sure to comment with your answers, no comments will show up until the contest ends. The first person with all three answers correct will win 60 tokens!!! Whether you are renting racks of equipment for any track or working on graded Mock Labs, those tokens sure come in handy!
Stay tuned for the answers, and for Part II in a few days! Good Luck!!!
This may seem to be a basic topic, but it looks like many people are still confused by the difference between those two concepts. Let us clear this confusion at once!
Brian,First off, thanks for this great website and the great effort. One question about the CCIR R&S. Is grading effected by executing show or debug commands? Many cases I configure elements and I’m pretty sure that it will work, and omit the verification stage. In other words, does the proctor/script look at monitoring commands I executed, and if not, he marks me down because of simply not monitoring even though the configuration is fully functional?Kind regards,M. Khonji
The proctors don’t monitor your progress during the day for grading purposes. I.e if you configure OSPF and don’t issue the “show ip ospf neighbor” output it’s not going to make a difference as long as your configuration is functional. Now on the other hand grading itself can be based on either the configuration or the result. By this I mean that simple feature configurations, such as IP Accounting or SNMP or RMON would most likely be graded by looking at your running configuration, as there is usually only one way to accomplish a particular goal with features such as that. However more complex configurations like BGP or redistribution may be graded not based on your configurations but based on their results. I.e if you are asked to modify the BGP bestpath selection process, the easiest way to check this is to view the “show ip bgp” output and then to send traffic through the network with traceroute and see where it actually goes. Based o n this fact I would highly recommend to try to verify as much of the results of your configurations as possible in the real lab before leaving at the end of the day.Good luck in your preparation!