Jul
09

"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.

ZBF Transparent VRF R2

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?
Here is the relevant output:

R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 1 FULL/DR 00:00:39 10.123.0.3 FastEthernet0/0
10.123.0.2 1 FULL/BDR 00:00:32 10.123.0.2 FastEthernet0/0
R1#show ip route ospf
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2] via 10.123.0.3, 00:01:33, FastEthernet0/0

R1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/88/172 ms
R1#ssh -l admin 3.3.3.3
Password: <password>

R3#show ssh
Connection Version Mode Encryption Hmac State Username
0 1.99 IN aes128-cbc hmac-sha1 Session started admin
0 1.99 OUT aes128-cbc hmac-sha1 Session started admin
%No SSHv1 server connections running.
R3#exit

[Connection to 3.3.3.3 closed by foreign host]
R1#

Now for R2:

R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DROTHER 00:00:37 10.123.0.1 BVI1
3.3.3.3 1 FULL/DR 00:00:35 10.123.0.3 BVI1

R2#show ip route ospf

R2#show policy-map type inspect zone-pair
Zone-pair: zp-in-to-out

Service-policy inspect : p-in-to-out

Class-map: c-in-to-out (match-any)
Match: protocol icmp
4 packets, 320 bytes
30 second rate 0 bps
Match: protocol ssh
3 packets, 72 bytes
30 second rate 0 bps
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [4:390]
icmp packets: [0:50]

Session creations since subsystem startup or last reset 8
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [2:1:1]
Last session created 00:02:23
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 3
Last half-open session total 0

Class-map: class-default (match-any)
Match: any
Drop (default action)
0 packets, 0 bytes
Zone-pair: zp-out-to-in

Service-policy inspect : p-out-to-in

Class-map: c-out-to-in (match-all)
Match: protocol icmp
Inspect
Packet inspection statistics [process switch:fast switch]
icmp packets: [0:20]

Session creations since subsystem startup or last reset 2
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:0]
Last session created 00:25:24
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 1
Last half-open session total 0

Class-map: class-default (match-any)
Match: any
Drop (default action)
4 packets, 96 bytes

R2#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2# show run
version 12.4
hostname R2
!
ip vrf myvrf
!
class-map type inspect match-any c-in-to-out
match protocol icmp
match protocol ssh
class-map type inspect match-all c-out-to-in
match protocol icmp
!
policy-map type inspect p-in-to-out
class type inspect c-in-to-out
inspect
class class-default
policy-map type inspect p-out-to-in
class type inspect c-out-to-in
inspect
class class-default
!
zone security inside
zone security outside
zone-pair security zp-in-to-out source inside destination outside
service-policy type inspect p-in-to-out
zone-pair security zp-out-to-in source outside destination inside
service-policy type inspect p-out-to-in
bridge irb
!
interface FastEthernet0/0
ip vrf forwarding myvrf
no ip address
zone-member security inside
bridge-group 1
!
interface FastEthernet0/1
ip vrf forwarding myvrf
no ip address
zone-member security outside
bridge-group 1
!
interface BVI1
ip vrf forwarding myvrf
ip address 10.123.0.2 255.255.255.0
!
router ospf 1 vrf myvrf
router-id 10.123.0.2
network 0.0.0.0 255.255.255.255 area 0
!
bridge 1 protocol ieee
bridge 1 route ip
end

Here is R3:

R3#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DROTHER 00:00:32 10.123.0.1 FastEthernet0/1
10.123.0.2 1 FULL/BDR 00:00:31 10.123.0.2 FastEthernet0/1

R3#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 10.123.0.1, 00:29:36, FastEthernet0/1

R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/117/176 ms
R3#

Similar configuration scenarios are included in both our RS and SC workbooks at INE.

Take a moment, and post your ideas on why the PING from R2 is failing, and thanks for taking the time to assist!

Best wishes.

Jul
07

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.


There are a variety of status classifications. These include, but are not limited to: standards, informational, best current practices. Some are very serious discussions of the deep inner workings, where others are just there for entertainment, such as RFC 1149 and 2549.

If you aren't sure whether a RFC is intended to be serious or entertainment, check the date. If it was one from 1 April of any year, most likely it falls into the category of entertainment.

http://www.rfc-archive.org/1+april+rfc.php

Language is included to define how an item is intended to behave. RFC 2119 lists some of these requirements. Requirements are shown capitalized, and include the following: MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, RECOMMENDED, NOT RECOMMENDED, OPTIONAL.

RFCs are not a "magic bullet" for lab preparation. Most students that are familiar with RFCs tend to be more comfortable with the technologies discussed.

RFCs can be viewed online at a number of sites, including the following:

http://www.ietf.org/rfc.html

http://www.rfc-editor.org/

Most search engines will also give you results for RFCs by number or topic.

Quick quiz.

Four questions on RFCs that most people are generally familiar with. Questions are True or False, and the answers can be found fairly quickly, if you know where to look.

T or F
RFC 3330, which describes Special Use IPv4 Addresses, is obsolete.

T or F
RFC 1812, which discusses requirements for IPv4 Routers, states that subnet bits MUST be contiguous.

T or F
RFC 2827 discusses ingress filtering mechanisms, including the effects of multihoming.

T or F
RFC 1918 does not address security issues.

How did you do? Two of these are true and two are false. If you got all four correct, congratulations. If you've never heard of these RFCs, perhaps it is time to do some additional reading.

Bonus Question:

True or False:
Neither Cisco nor Juniper devices are compliant with RFC 5841.

Sep
22

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.

access-list 199 permit ip any object-group TEST

What just happened here?  Can you really match those in a single line?  The answer deals with object groups, which allow grouping of other items.  The object group still needs to be configured, but the question just asked for a short access list.

You can enter in either /x notation for mask, or with subnet mask information, as shown in the following examples:

object-group network TEST
10.0.0.0 /8
172.16.0.0 /12
192.168.0.0 /16
169.254.0.0 /16

The router will convert syntax, and the following will be what remains in your config for the group:

object-group network TEST
10.0.0.0 255.0.0.0
172.16.0.0 255.240.0.0
192.168.0.0 255.255.0.0
169.254.0.0 255.255.0.0

You can also nest object groups.  You could configure the individual groups as follows:

object-group network A
10.0.0.0 /8
object-group network B
172.16.0.0 /12
object-group network C
192.168.0.0 /16

object-group network RFC1918
group-object A
group-object B
group-object C

object-group network APIPA
169.254.0.0 /16

object-group network TEST
group-object RFC1918
group-object APIPA

Here, we took a brief look at network object groups.  Object groups on the router also have a "service" option, which can be used to group protocols and ports. For those of you with a background configuring PIX / ASA, you may already be very familiar with configuring object groups.  For the rest of you, it may be something that you want to practice before your next scheduled lab date.

For more reading:
Cisco - Object Groups for ACLs

Object groups were added in 12.4(20)T.

Feb
15

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/

After you've had a little time to review that stuff, let's move on with the testing! I have nabbed my routers in a configured state already. I just recently finished with creating more detailed solutions for Mock Lab 4 (it's a fun one!), so that's the topology that I have going right now. Specifics should really matter, I was just hunting for any particular spot of redistribution in order to see what we could accomplish here.

On R3 I happen to have found some redistribution between OSPF and RIP that looks like fun.

R3 Starting:

Rack1R3(config)#do sh run | s router
router ospf 1
log-adjacency-changes
area 0 authentication message-digest
area 123 virtual-link 150.1.1.1 message-digest-key 1 md5 CISCO
redistribute rip metric-type 1 subnets route-map Red-RIP
network 145.1.3.3 0.0.0.0 area 0
network 145.1.13.3 0.0.0.0 area 123
network 145.1.23.3 0.0.0.0 area 123
network 150.1.3.3 0.0.0.0 area 0
router rip
version 2
redistribute ospf 1 metric 7 route-map RIP-R6
passive-interface default
no passive-interface FastEthernet0/0
network 145.1.0.0
distribute-list 11 out FastEthernet0/0
no auto-summary
Rack1R3(config)#

Rack1R3(config)#do sh run | s route-map
redistribute rip metric-type 1 subnets route-map Red-RIP
redistribute ospf 1 metric 7 route-map RIP-R6
route-map RIP-R6 permit 10
match ip address prefix-list R4-R5-Link
set metric 2
route-map RIP-R6 permit 20
set metric 10
route-map Red-RIP deny 10
match ip address prefix-list NAT-Route
route-map Red-RIP permit 20
set metric-type type-1
Rack1R3(config)#

All devices have "debug ip routing" turned on.

Rack1R3(config)#do sh clock
*02:02:28.984 UTC Sun Feb 15 2009
Rack1R3(config)#

No NTP is running, so we can deal with the current clock settings.   So let's look at our route-maps...  The one called RIP-R6 is going from OSPF to RIP.

Rack1R3(config)#do sh ip ro os
51.0.0.0/32 is subnetted, 1 subnets
O E2    51.51.51.51 [110/20] via 145.1.23.2, 3w2d, Serial1/3.23
O E1 204.12.1.0/24 [110/865] via 145.1.23.2, 1w6d, Serial1/3.23
[110/865] via 145.1.13.1, 1w6d, Serial1/2.13
145.1.0.0/16 is variably subnetted, 20 subnets, 2 masks
O IA    145.1.17.0/24 [110/782] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.5.0/24 [110/865] via 145.1.23.2, 1w6d, Serial1/3.23
[110/865] via 145.1.13.1, 1w6d, Serial1/2.13
O       145.1.7.0/24 [110/783] via 145.1.13.1, 3w2d, Serial1/2.13
O       145.1.12.0/24 [110/845] via 145.1.23.2, 3w2d, Serial1/3.23
[110/845] via 145.1.13.1, 3w2d, Serial1/2.13
O       145.1.48.0/24 [110/847] via 145.1.23.2, 3w2d, Serial1/3.23
[110/847] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    145.1.58.0/24 [110/846] via 145.1.23.2, 3w2d, Serial1/3.23
[110/846] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.45.5/32 [110/867] via 145.1.23.2, 3w2d, Serial1/3.23
[110/867] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.45.4/32 [110/865] via 145.1.23.2, 3w2d, Serial1/3.23
[110/865] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.45.0/24 [110/865] via 145.1.23.2, 3w2d, Serial1/3.23
[110/865] via 145.1.13.1, 3w2d, Serial1/2.13
O       145.1.47.0/24 [110/1782] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    145.1.125.5/32 [110/845] via 145.1.23.2, 3w2d, Serial1/3.23
[110/845] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    145.1.125.1/32 [110/781] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.125.0/24 [110/867] via 145.1.23.2, 1w6d, Serial1/3.23
[110/867] via 145.1.13.1, 1w6d, Serial1/2.13
O IA    145.1.125.2/32 [110/781] via 145.1.23.2, 3w2d, Serial1/3.23
O IA 192.10.1.0/24 [110/782] via 145.1.23.2, 3w2d, Serial1/3.23
150.1.0.0/16 is variably subnetted, 7 subnets, 3 masks
O       150.1.7.7/32 [110/783] via 145.1.13.1, 3w2d, Serial1/2.13
O       150.1.4.4/32 [110/848] via 145.1.23.2, 3w2d, Serial1/3.23
[110/848] via 145.1.13.1, 3w2d, Serial1/2.13
O       150.1.2.2/32 [110/782] via 145.1.23.2, 3w2d, Serial1/3.23
O       150.1.1.1/32 [110/782] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    150.1.0.0/20 [110/846] via 145.1.23.2, 3w2d, Serial1/3.23
[110/846] via 145.1.13.1, 3w2d, Serial1/2.13
Rack1R3(config)#

We have quite a few OSPF routes, so we can always pick on a few others just to play.   But let's change things around momentarily.

Rack1R3(config)#do sh run | in prefix-list
ip prefix-list NAT-Route seq 5 permit 145.1.133.0/24
ip prefix-list R4-R5-Link seq 5 permit 145.1.45.0/24
match ip address prefix-list R4-R5-Link
match ip address prefix-list NAT-Route
Rack1R3(config)#

Right now, we're matching a Prefix List...  That will need to change.  Let's create a time-range as well.

R3

time-range First12
periodic daily 0:00 to 11:59
exit

access-list 101 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12

route-map RIP-R6 permit 10
no match ip address prefix-list R4-R5-Link
match ip address 101
set metric 2

Rack1R3(config)#do sh access-list 101
Extended IP access list 101
10 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12 (active) (2 matches)
Rack1R3(config)#

So we're active now.  This is good.   We'll see this route via other paths in this lab, but the metric here is the key.  And we'll notice this change as well.  Since we started re-advertising the route:

Rack1R6(config-router)#
*Feb 15 03:17:13.656: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/10] to [120/2]
*Feb 15 03:17:13.656: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

Notice the metric change.   Now let's go back to R3 and change the time!

Rack1R3#clock set 15:00:00 feb 15 2009
Rack1R3#
*Feb 15 15:00:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 02:22:08 UTC Sun Feb 15 2009 to 15:00:00 UTC Sun Feb 15 2009, configured from console by console.
Rack1R3#

Rack1R3(config)#do sh access-list 101
Extended IP access list 101
10 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12 (inactive) (2 matches)
Rack1R3(config)#

Notice that now we are inactive on our time.     **Time Passes**

Well, 20 minutes later and still no update.   Our problem with this is that change IN THE ROUTING TABLE trigger changes to redistribution.  We still learn this route via OSPF and therefore nothing has changed.  If we were to trigger a change in OSPF that would lead to a status change, we would see the route withdrawn.

How do you trigger a status change?  Clear it.

Rack1R3(config)#do clear ip route 145.1.45.0
Rack1R3(config)#
Feb 15 15:12:28.719: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 15:12:28.719: RT: del 145.1.45.0/24 via 145.1.13.1, ospf metric [110/865]
Feb 15 15:12:28.719: RT: delete subnet route to 145.1.45.0/24
Feb 15 15:12:28.719: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT: SET_LAST_RDB for 145.1.45.0/24
NEW rdb: via 145.1.13.1

Feb 15 15:12:28.723: RT: add 145.1.45.0/24 via 145.1.13.1, ospf metric [110/867]
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT:ospf's 145.1.45.0/24 (via 145.1.13.1) metric changed from distance/metric [110/867] to [110/865]
Feb 15 15:12:28.723: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.727: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 15:12:28.727: RT: NET-RED 145.1.45.0/24
Rack1R3(config)#

From R3's perspective, notice that it comes back just as it was before.

Rack1R6(config-router)#
*Feb 15 03:32:27.576: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/2] to [120/10]
*Feb 15 03:32:27.576: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

On R6 though, it changed because the criteria changed.   What if we change the clock and do it again?  (By the way, subsequent 'clear ip route' commands on R3 make no difference on R6 as long as the time range is still inactive)

Rack1R3(config)#do clock set 3:00:00 feb 15 2009
Rack1R3(config)#
Rack1R3(config)#
Feb 15 03:00:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 15:14:57 UTC Sun Feb 15 2009 to 03:00:00 UTC Sun Feb 15 2009, configured from console by console.
Rack1R3(config)#
Rack1R3(config)#do sh access-list 101
Extended IP access list 101
10 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12 (active) (2 matches)
Rack1R3(config)#

Back to active now.  Clearing....

Rack1R6(config-router)#
*Feb 15 03:35:24.672: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/10] to [120/2]
*Feb 15 03:35:24.672: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

Back to a metric of 2 on R6.  So the redistribution is happening again...  So....  Can the router trigger itself?  Do we have mechanisms to do so?  You betchya!  But it's not perfectly simple!   But then again, you would be a CCIE if everything were always simple!  Or more importantly, EVERYONE would be a CCIE if it were simple!

We can use EEM (Embedded Event Manager, complicated) or KRON (time scheduler, easier) to trigger things.   My vote is kron!  In the unix world you'd know this as cron.

R3

kron policy-list ChgRedist
cli clear ip route 145.1.45.0
exit

kron occurrence Midnight at 0:00 recurring
policy-list ChgRedist
kron occurrence Noon at 12:00 recurring
policy-list ChgRedist
exit

Rack1R3(config)#do sh kron schedule
Kron Occurrence Schedule
Midnight inactive, will run again in 0 days 20:55:41 at 0 :00 on
Noon inactive, will run again in 0 days 08:55:41 at 12:00 on

Rack1R3(config)#

Rack1R3(config)#do clock set 11:58:00 feb 15 2009
Feb 15 11:58:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 03:05:50 UTC Sun Feb 15 2009 to 11:58:00 UTC Sun Feb 15 2009, configured from console by console.
Rack1R3(config)#do sh kron schedule
Kron Occurrence Schedule
Midnight inactive, will run again in 0 days 12:01:55 at 0 :00 on
Noon inactive, will run again in 0 days 00:01:55 at 12:00 on

Rack1R3(config)#

Rack1R3(config)#do deb kron all
All kron debug flags are on

Rack1R3(config)#

Now we just wait and see!  (Pretend you've been staring at this for two minutes now!)

Rack1R3(config)#
Feb 15 11:59:59.999: Major 1, Minor 0
Feb 15 11:59:59.999: Timer Event Noon
Feb 15 11:59:59.999: Kron delay for next Noon 60000
Feb 15 11:59:59.999: Call parse_cmd 'clear ip route 145.1.45.0'
Feb 15 11:59:59.999: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 11:59:59.999: RT: del 145.1.45.0/24 via 145.1.13.1, ospf metric [110/865]
Feb 15 11:59:59.999: RT: delete subnet route to 145.1.45.0/24
Feb 15 11:59:59.999: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.003: Kron CLI return 0
''
Feb 15 12:00:00.003: Major 4, Minor 7
Feb 15 12:00:00.003: Respond to end of CLI Process
Feb 15 12:00:00.003: RT: SET_LAST_RDB for 145.1.45.0/24
NEW rdb: via 145.1.13.1

Rack1R3(config)#
Feb 15 12:00:00.003: RT: add 145.1.45.0/24 via 145.1.13.1, ospf metric [110/867]
Feb 15 12:00:00.003: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.003: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 12:00:00.003: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.003: RT: ospf's 145.1.45.0/24 (via 145.1.13.1) metric changed from distance/metric [110/867] to [110/865]
Feb 15 12:00:00.007: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 12:00:00.007: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.007: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.007: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 12:00:00.007: RT: NET-RED 145.1.45.0/24
Rack1R3(config)#

That looks like the router magically did what we wanted it to on R3! And on R6:

Rack1R6(config-router)#
*Feb 15 03:43:46.695: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/2] to [120/10]
*Feb 15 03:43:46.695: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

Bingo!  Exactly what you wanted.

Rack1R3(config)#do sh kron sched
Kron Occurrence Schedule
Midnight inactive, will run again in 0 days 11:58:24 at 0 :00 on
Noon inactive, will run again in 0 days 23:59:24 at 12:00 on

Rack1R3(config)#

And in 12 hours'ish we'll see the process reverse itself.  So yes, you CAN have redistribution on a timed basis, it's just not necessarily a pretty thing!

Dec
08

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

b. Community Values

Cisco IOS Software - 12.4 Family - 12.4 Mainline - C.G. -  Cisco IOS IP Routing Protocols Configuration Guide, Release 12.4 - Part 1: BGP - Connecting to a Service Provider Using External BGP

c. Regular Expressions

Cisco IOS Software - 12.4 Family - 12.4 Mainline - C.G. - Cisco IOS Terminal Services Configuration Guide, Release 12.4 - Appendixes - Regular Expressions

d. Confederation Configuration

Cisco IOS Software - 12.4 Family - 12.4 Mainline - C.G. - Cisco IOS IP Routing Protocols Configuration Guide, Release 12.4 - Part 1:BGP - Configuring Internal BGP Features

IV. IP and IOS Features

a. NTP

Cisco IOS Software - 12.4 Family - 12.4 Mainline - C.G. - Cisco IOS Network Management Configuration Guide, Release 12.4 - Performing Basic System Management - Setting Time and Calendar Services

b. HSRP

Cisco IOS Software - 12.4 Family - 12.4 Mainline - C.G. - Cisco IOS IP Application Services Configuration Guide, Release 12.4 - Part 1: First Hop Redundancy Protocols

V. IP Multicast

a. Intermediate IP Multicast Helper

Cisco IOS Software - 12.4 Family - 12.4 Mainline - C.G. -Cisco IOS IP Multicast Configuration Guide, Release 12.4 - Configuring an Intermediate IP Multicast Helper Between Broadcast-Only Networks

VI. QoS

a. RTP Port Range

Cisco IOS Software - 12.4 Family - 12.4 Mainline - C.G. -Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4  - Part 2: Congestion Management - Congestion Management Overview - IP RTP Priority

VII. Security

a. ACL Favorites

Security - Firewall Appliances - Cisco ASA 5500 Series Adaptive Security Appliances - C.G. - Cisco Security Appliance Command Line Configuration Guide, Version 8.0 - Reference - Addresses, Protocols, and Ports

b. Control Plane Policing (CoPP)

Cisco IOS Software - 12.4 Family - 12.4 Mainline - C.G. -Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4  - Part 4: Policing and Shaping - Configuring Traffic Policing - Control Plane Policing

c. Role-Based CLI Access

Cisco IOS Software - 12.4 Family - 12.4 Mainline - C.G. - Cisco IOS Security Configuration Guide: Securing User Services, Release 12.4 - RADIUS and TACACS+ Attributes - Secure Shell (SSH) - Role-Based CLI Access

Do you have a favorite resource location not shown here? Let me know immediately in the blog comments area!


Nov
05

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!

1.  Now, there are a total of 16 things we're trying to match.  So in the best of worlds, we can do this in a single line (because it's an exponent of two), but if and ONLY IF we find a total of four bits different across the entire 32-bit address.  So let's solve it.

Where do we have differences?  All over the place!  So let's isolate them.

2nd octet:

34    00100010
50    00110010

Only the 16-bit position is different here.  (mask of 00010000)  This could have been discovered by the subtraction method!

3rd octet:

80    01010000
208    11010000

Only the 128-bit position is different here.  (mask of 10000000)  This could have been discovered by the subtraction method!

4th octet:

133    10000101
165    10100101
197    11000101
229    11100101

It's a little more difficult to use the subtraction method here as well!   But we discover that there are only two bits of difference here, in the 64-bit position and the 32-bit position. (mask of 01100000)

So we DO have a total of four bits across these numbers.  Cool.  One line, right?

But go back to re-read the question.  There's more to it than that!  The even-numbered bits of the SECOND-HALF of a /24.  Now that's just plain evil!

So numbers from 128-254, and only the even ones.  Now we've done the even numbered thing before.  That's a mask of ".254" (11111110) with the starting point of .0...  But here we want only the second half.  So what else is consistent in even numbers OVER 128?  (hint:  the 128-bit position!)

access-list 101 deny ip 180.34.80.133 0.16.128.96 150.100.32.128 0.0.0.126
access-list 101 permit ip any any

And we'll assume that the access-list is either applied inbound on a WAN link, or outbound on our LAN link!

2.   Pure summarization now.  But there's only 12 lines listed.  That doesn't work out as nicely for single-line summarization!  The best we'll be able to do is two lines.  but let's work through the details.

First octet:

19 00010011
79 01001111
83 01010011

Second octet:

55 00110111
56 00111000

Third octet:

4 00000100
5 00000101
12 00001010
13 00001011
20 00010100

Yeah, now all of a sudden that two-line solution isn't looking nearly as possible!  So let's start isolating.  (Divide and conquer)

Really our consideration will be with the 19 and 83 address sets.  They each have 4, 5, 12 and 13 in the third octet.  The 79 addresses are completely different in the third octet.

First octet:

19    00010011
83    01010011

One bit of difference there in the 64-bit position.  (mask = 01000000)  This could be solved with subtraction.

Third octet:

4    00000100
5    00000101
12    00001100
13    00001101

While we can't really do the subtraction method here, at least there's only two bits of difference here.  (mask = 00001001)  These eight values can be summarized in a single line.  Three bits of difference (2^3 = 8 matches).

access-list 2 permit 19.55.4.0 64.0.9.0

Now, the 79-series of addresses.

Second octet:

55    00110111
56    00111000

Lots of differences here (four bits) so we'll be treating these separately.

Third octet:

4
20

Why bother with the math?  Just subtract!  :)  Only the 16-bit position changes.  (mask = 00010000)

access-list 2 permit 79.55.4.0 0.0.16.0

So our entire solution:

access-list 2 permit 19.55.4.0 64.0.9.0
access-list 2 permit 79.55.4.0 0.0.16.0
access-list 2 permit 79.56.4.0 0.0.16.0

Hey!  Look!  Two lines.   But it seemed so ugly for a while!  We use ".0" for the fourth octet because we were told this ACL is for routing updates.  /24's in a routing update will always have .0 as the fourth octet!

3.  Ooooo..   A big, long, ugly looking one!  Well...  If we count them, there's only 28 lines.  That's definitely not going to solve in one line!  Best we can do there is three lines (16 + 8 + 4).  Hmmmmm.  Time to look at binary!

First octet:

124    01111100
132    10000100

Yeah...  That's not going to happen.  Five bits of difference will get 32 matches.  :)  Even though the subtraction method says "8" is the difference, since we cross a bit-boundary (128), all bets are off!

Second octet:

130    10000010
194    11000010

This is easier!  There's one bit of difference between these two.  (mask = 01000000)  This could be solved via subtraction.

The third octet is all ".1".  So that brings us to the fourth octet:

16    00010000
17    00010001
19    00010011
24    00011000
25    00011001
26    00011010
27    00011011

That's just plain ugly now.  There are actually three bits of difference in there, but one very important piece to note.  18 is missing from the list, so it's not all contiguous that way.

But wait...  The task actually says we need to include "18" as a deny specifically!  So therefore we CAN count it.  Once we do that, three bits of difference makes things work (2^3 = 8 matches).

So let's put it together now.

access-list 3 deny 124.130.1.18 0.64.0.0
access-list 3 deny 132.130.1.18 0.64.0.0
access-list 3 permit 124.130.1.16 0.64.0.11
access-list 3 permit 132.130.1.16 0.64.0.11

line vty 0 15  (optional for grading)
access-class 3 in (optional for grading)

4.  Now we need to first convert a prefix-list into an access-list.  THEN we need to look at the existing access-list and somehow integrate the two together.  Isn't this just pleasant.

This not only tests you on your knowledge of access-lists and binary functions, but also on your knowledge of BGP distribute-lists!  See, our issue is that the current distribute list only looks at /24 information.  And not necessarily very well, but that's the intent.  Our prefix-list looks at many mask lengths from /20, /21, /22, /23 and /24!

BGP distribute-lists can use an extended ACL to match the mask information as well!  Oh boy will this be fun.  Actually, it's not nearly as bad as it looks!

With the prefix list, our binary starting point is all the same.  192.168.0.0/15.  This is 192.168.0.0 0.1.255.255 in "regular ACL" masking.  The masks we are looking for are:

255.255.240.0
255.255.248.0
255.255.252.0
255.255.254.0
255.255.255.0

So really, we're matching on third octet values:

240    11110000
248    11111000
252    11111100
254    11111110
255    11111111

So the last four bits, I really don't care what the values are.  Wait.  If we come up with a mask of 00001111 (15), what happens when we're presented with a value of 247?  Wouldn't that match?

Sure, technically it would match the mask we create.  But fortunately for us, there's no way in reality we're going to ever see a mask like that!  Route masking can only be done on bit boundaries!   So reality versus technical possibility (e.g. fantasy) are two completely different ideas!

access-list 104 permit 192.168.0.0 0.1.255.255 255.255.240.0 0.0.15.0

Now, we have to look at the remaining values.  These should be easier as it's just a summarization question.

Third octet:

0    00000000
1    00000001
2    00000010
3    00000011
4    00000100
5    00000101
6    00000110
7    00000111
8    00001000
9    00001001
10    00001010
11    00001011
12    00001100
13    00001101
14    00001110
15    00001111

Again, the masking will be 00001111 (.15).

access-list 104 permit 150.100.0.0 0.0.15.0 255.255.255.0 0.0.0.0

So our whole ACL:

access-list 104 permit 192.168.0.0 0.1.255.255 255.255.240.0 0.0.15.0
access-list 104 permit 150.100.0.0 0.0.15.0 255.255.255.0 0.0.0.0

Well...  That was fun.  I will tell you, it was likely much more entertaining for me than it was for you.  But good stuff.  If nothing else, getting through these exercises, and having them actually make some semblance of sense to you, there's NOTHING that the CCIE Lab can come up with that will scare you!

It's good to be evil.  :)

See the Comments here for the list of winners!

Sep
16

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!

Sep
16

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/24

3. 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!!!

Jul
03

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!

Shaping vs Policing

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:

Policing Burst

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

Feb
18

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!

Subscribe to INE Blog Updates

New Blog Posts!