Posts from ‘General’
Transparent ZBF, IRB, and VRF troubleshooting.
“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
Tags: ccie, troubleshooting
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.
Continue Reading
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.
http://blog.internetworkexpert.com/2008/01/04/using-extended-access-lists-in-a-distribute-list/
Tags: advanced, extended, kron, redistribution, time-based, tricks
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
III. BGP
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
Tags: cisco, doc-cd, documentation
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!
Tags: access-list, ACL, answers, binary-math, contest, evil, summarization
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!
Answers…
1. Start picking a few and finding similarities again…
0 00000000
4 00000100
8 00001000
12 00001100
16 00010000
20 00010100
etc.
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 131.102.0.0 0.0.252.255
2. Our differences here are in the third octet.
128 10000000
130 10000010
132 10000100
134 10000110
136 10001000
138 10001010
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.
Method 1:
access-list 17 permit 200.100.128.0 0.0.6.0
access-list 17 permit 200.100.136.0 0.0.2.0
Method 2:
access-list 17 deny 200.100.140.0 0.0.2.0
access-list 17 permit 200.100.128.0 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 158.1.100.0 0.0.0.63
access-list 18 permit 158.1.100.64 0.0.0.15
access-list 18 permit 158.1.100.80 0.0.0.7
access-list 18 permit 158.1.100.88 0.0.0.3
access-list 18 permit 158.1.100.92 0.0.0.0
access-list 18 permit 158.1.100.107 0.0.0.0
access-list 18 permit 158.1.100.108 0.0.0.3
access-list 18 permit 158.1.100.112 0.0.0.15
access-list 18 permit 158.1.100.128 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:
172.16.31.0/24
172.16.32.0/24
172.16.33.0/24
172.16.34.0/24
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.
31 00011111
32 00100000
33 00100001
34 00100010
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
or
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:
172.16.31.0/24
172.16.32.0/24
172.16.33.0/24
172.16.34.0/24
172.16.35.0/24
172.16.36.0/24
172.16.37.0/24
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.
31 00011111
32 00100000
33 00100001
34 00100010
35 00100011
36 00100100
37 00100101
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:
000
001
010
011
100
101
110
111
The “110″ and “111″ matches are not in our list. That would be 38 and 39.
38 00100110
39 00100111
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.
0 00000000
2 00000010
4 00000100
6 00000110
8 00001000
10 00001010
12 00001100
14 00001110
16 00010000
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 131.102.0.0/16
2. In as few lines as possible, permit only the following networks (assume it will be a distribute-list):
200.100.128.0/24
200.100.130.0/24
200.100.132.0/24
200.100.134.0/24
200.100.136.0/24
200.100.138.0/243. In as few lines as possible, allow access from all hosts in the 158.1.100.0/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!
Look at the diagram above. Both router links are clocked at 128Kbps, and the test packet flow has packet size of 1000 bytes each, being sent at a sustained rate of 16 packets per second, effectively saturating the 128Kbps link. Consider what happens when we shape the flow down to 64Kbps. Egress packets are also serialized at 128Kbps – therefore the shaper needs to buffer and delay packets to obtain the target average rate of 64Kbps. Shaper performs that by delaying every burst each Tc interval. For this example, the Bc value (shaper burst) equals to packet size, so effectively every 1/16s interval egress link is busy and the next 1/16s interval it is idle. The average bps rate is total volume of (4*1000) divided by 1/2s (time to send) and multiplied by 8 (to get bps) yielding the result of 64000bps.
The summary points about shaping are as follows:
I) Shaper send Bc amount of data every Tc interval at physical port speed
II) Since shaper delays packets, it uses a queue to store them
III) Shaper queue may use different scheduling algorithms, e.g. WFQ, CBWFQ, FIFO
IV) Shaper unifies traffic flow and introduces delay, which may affect end-to-end QoS characteristics
V) Shaping is generally a WAN technology, used to share a multipoint interface bandwidth and/or compensate for speed differences between sites
On the other hand, policer behaves in a much simpler manner. It achieves the same average traffic rate by dropping a packet that could exceed the policed rate. The policer algorithm is simple: remember the last packet arrival time (“T0”), the current credit (“Cr0”) and “PolicerRate” constant (64Kpbs in our example). (There is also the “Bc” – burst size, but we will ignore it for a moment). When a new packet of size “S” arrives at a moment of time “T” the policer performs the following:
a) Calculate accumulated credit: Cr = Cr0 + (T-T0)*PolicerRate (note: Bc ignored here).
b) If (S <= Cr) than Cr0 = Cr – S and packet is admitted, since we have enough credit
c) Else packet is denied and credit remains the same: Cr0 = Cr.
d) Store the last packet arrival time: T0=T
This simple admission procedure allows for very efficient hardware implementations. Look at the above diagram again. For a sustained packet flow, policer drops every next packet, for it can’t accumulate 1000 bytes of credit during 1/16s (the packet arriving rate) since the “PolicerRate” is just 64000bps. Therefore, every 1/16s the policer is only able to accumulate 500 bytes of credit, and it takes 1/8 of a second to get enough credit to admit a packet.
Now, for the policer burst size. As we remember, with shaping Bc effectively defines the amount of data sent every Tc. With policing it’s purpose is different, however. Look at the diagram below:
The flow no longer sustains. At one moment, the source is paused and then resumed. Policers were designed to take advantage of such irregular behavior. The long pause allows the policer to accumulate more credit and then use it to accept a “large” packet train at once. However, it can’t be allowed for the credit to grow in unbounded manner (e.g. 1 hours of pause between packets yielding very large credit). Therefore, a committed burst size is used by policers as follows:
a) Calculate new credit: Cr = Cr0 + (T-T0)*PolicerRate
b) If (Cr > Bc) then Cr = Bc
c) If (S <= Cr) then Cr0 = Cr – S and packet is admitted.
d) Else packet is denied and Cr0 = Cr.
e) Store the last packet arrival time: T0=T
The Bc constant limits the amount of credit a policer is allowed to accumulate during the idle periods. Obviously, you will never want to set up Bc lower than a network MTU, for this will prohibit any packet from passing admission. Note the following interesting relation: Tc=Bc/PolicerRate. This is sometimes called “averaging interval”. By the policer design, if you observe the policer traffic flow for “Tc” amount of time, you will never see average bitrate to go above “PolicerRate”. Note that policer “Tc” has nothing to do with “shaping” Tc, as they have very different purpose and meaning.
In summary, the key points about policing:
I) Policer uses a simple, credit based admission model
II) Policer never delays packets and never “absorbs” or smoothes packet bursts
III) Policers are usually used at the edge of a network to control packet admission
IV) Policers could be used in either ingress or egress direction
The last question – how would one calculate a Bc value for a policer? As you’ve seen, for a sustained traffic flow it does not matter what size of Bc to pick up – it does not affect the average packet rate. However, in real life, traffic flows are very irregular. If you pick Bc value too small, you may end up dropping too much packets. Obviously, this is bad for protocols like TCP, which consider a dropped packet to be a signal of congestion. Therefore, there exist some general rules of thumb to pick up Bc values based on policer rate. Generally, Bc should be no less than 1,5s*PolicerRate, but you should calculate the optimal value empirically, by running application tests.
Further Reading:
Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting
Tags: comparsion, illustration, policing, shaping, visual, wfq
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!
Loading ...
