Dec
31

Benjamin Franklin was quoted as saying "You may delay but time will not".  We may also say that "Email may tolerate delay, but VOIP will not".  Performance Routing (PfR), previously called Optimized Edge Routing (OER), is designed to solve network performance issues, such as delay, that vanilla IP routing can’t.  In this blog, we will use the term OER as that is still the command set used.

Petr and the team have created some awesome new labs on OER, including Volume 1, v5 in the IP Routing section. Our workbook content is extensive, has great explanations for everything and is highly recommended it to anyone preparing for the v4 CCIE RS lab.

One of the big challenges for the OER newcomer is knowing what to expect after configuring OER, and how to see measurable results. My intention in this blog post, is to assist the learner by providing a jump start into OER/PfR, by walking you through a solid configuration, and sharing a few critical show and debug commands to verify that OER is working. For you dynamips/GNS3 fans, the configuration may be replicated using (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T10, RELEASE SOFTWARE (fc3).

So, how does it work?   It is actually very simple.  In the world of OER, there are 2 roles. The brains of the operation, called the master controller, and the border router who owns the exit interfaces. There may be multiple border routers. The key is there needs to be at least 2 or more exit points across the borders being managed by a single controller. Although the controller and border can actually run on the same router, I broke it up into separate devices for this blog post. R1 will be the OER Master Controller, and R2 will be the OER Border. Here is the topology.

Single Border, with 2 exit interfaces.

First we will create key chain on the controller R1.  The key is used for communications between the controller and the border.

R1(config)# key chain cisco
R1(config-keychain)# key 1
R1(config-keychain-key)# key-string cisco

Next, on R1 we will configure the master controller portion. About 98 % of all the configuration for OER is done on the controller. Here we will enable logging, and specify who the border(s) are, along with which interfaces on the border are exit interfaces to the outside world.

R1(config)#oer master
R1(config-oer-mc)#logging
R1(config-oer-mc)#border 136.1.12.2 key-chain cisco
R1(config-oer-mc-br)#interface Tunnel1 external
R1(config-oer-mc-br-if)#interface Tunnel2 external
R1(config-oer-mc-br-if)#interface FastEthernet0/0 internal
R1(config-oer-mc-br)#exit

Next on the controller, we  specify that we will learn prefixes based on throughput and delay, set time periods regarding learning, and tell the controller the network lengths to learn. In this example, due to the small network, we are going to have the controller learn /32 routes. We could also specify a maximum number of prefixes to learn as well. (Note: In a production network, you would not want thousands of static routes for sites visited by users. There is a default maximum, and the default aggregation is /24).

R1(config-oer-mc)#learn
R1(config-oer-mc-learn)#throughput
R1(config-oer-mc-learn)#delay
R1(config-oer-mc-learn)#periodic-interval 1
R1(config-oer-mc-learn)#monitor-period 2
R1(config-oer-mc-learn)#expire after time 30
R1(config-oer-mc-learn)#aggregation-type prefix-length 32
R1(config-oer-mc-learn)#exit

Next, now that we have exited out of “learn mode”, we can configure some of the other properties of the controller, such as how often to make prefix decisions (the backoff period), allow it to put routes in the routing table (mode route control), and choose the best exit interface (mode select-exit best). OER will create /32 static routes that use that use the “best” interface to reach the destination network.

R1(config-oer-mc)#backoff 180 360
R1(config-oer-mc)#mode route control
R1(config-oer-mc)#mode select-exit best

A few additional options include how often to make policy decisions, (periodic command), and which policy items are the most important regarding making those policy decisions (resolve commands).  Highest priority is 1, and lowest is 10.

R1(config-oer-mc)#periodic 90
R1(config-oer-mc)#resolve loss priority 1 variance 1
R1(config-oer-mc)#resolve delay priority 2 variance 1
R1(config-oer-mc)#resolve utilization priority 3 variance 1
R1(config-oer-mc)#resolve range priority 4

That is it for now on the controller. Let’s visit the border router R2 next. We’ll create the key chain, and tell R2 who the controller is. We will also tell R2 which interface to use for sending an active probe, (in the event the controller requests one).  Active probes are one method (from many available within OER) to determine delay.

R2(config)# key chain cisco
R2(config-keychain)# key 1
R2(config-keychain-key)# key-string cisco

R2(config)#oer border
R2(config-oer-br)#local FastEthernet0/0
R2(config-oer-br)#master 136.1.12.1 key-chain cisco
R2(config-oer-br)#active-probe address source interface Loopback0

So, how do we verify this? Since we are at R2, let’s start by issuing a show oer border on R2.

R2#show oer border
OER BR 136.1.12.2 ACTIVE, MC 136.1.12.1 UP/DOWN: UP 00:00:03,
Auth Failures: 0
Conn Status: SUCCESS, PORT: 3949
Version: 2.1 MC Version: 2.1
Exits
Fa0/0 INTERNAL Tu1 EXTERNAL Tu2 EXTERNAL
R2#

From this we see that we have successfully connected with the controller (R1), and that the controller has told R2 which interfaces are internal and which are external, based on what we configured on R1.

On R1, we can issue a few commands to confirm our configuration and connectivity to our border as well. Any elements shown in the output that we didn’t configure are based on the default settings.   Lets jump over to R1 and take a look.

R1#show oer master
OER state: ENABLED and ACTIVE
Conn Status: SUCCESS, PORT: 3949
Version: 2.1
Number of Border routers: 1 Number of Exits: 2
Number of monitored prefixes: 0 (max 5000)
Max prefixes: total 5000 learn 2500
Prefix count: total 0, learn 0, cfg 0

Border Status UP/DOWN AuthFail Version 136.1.12.2 ACTIVE UP 00:00:12 0 2.1
! Note: Below, items in bold are derived from our configuration.
Global Settings:
max-range-utilization percent 0 recv 0
mode route metric bgp local-pref 5000
mode route metric static tag 5000
trace probe delay 1000
logging

Default Policy Settings:
backoff 180 360 180
delay relative 50
holddown 300
periodic 90
probe frequency 56
mode route control
mode monitor both
mode select-exit best
loss relative 10
jitter threshold 20
mos threshold 3.60 percent 30
unreachable relative 50
resolve loss priority 1 variance 1 resolve delay priority 2 variance 1 resolve utilization priority 3 variance 1 resolve range priority 4 variance 0

Learn Settings:
current state : RETRY
time remaining in current state : 26 seconds
throughput delay
no inside bgp
no protocol
monitor-period 2 periodic-interval 1
aggregation-type prefix-length 32
prefixes 200
expire after time 30
R1#

As a reference below, on R2, here are the IP addresses and Interfaces in use.   Note, that Serial 0/0 is used only as a transport for the GRE tunnels.

R2#show ip int brief | ex una
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 136.1.12.2 YES NVRAM up up
Serial0/0 136.1.23.2 YES NVRAM up up
Loopback0 150.1.2.2 YES NVRAM up up
Tunnel1 10.0.0.2 YES NVRAM up up
Tunnel2 20.0.0.2 YES NVRAM up up
R2#

Here is the initial routing table on R2, (before OER has dynamically learned routes). We have only 2 static routes, which originated from the startup configuration.

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 20.0.0.3 to network 0.0.0.0

136.1.0.0/24 is subnetted, 2 subnets
C 136.1.12.0 is directly connected, FastEthernet0/0
C 136.1.23.0 is directly connected, Serial0/0

20.0.0.0/24 is subnetted, 1 subnets
C 20.0.0.0 is directly connected, Tunnel2

10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Tunnel1

150.1.0.0/24 is subnetted, 1 subnets
C 150.1.2.0 is directly connected, Loopback0

S* 0.0.0.0/0 [1/0] via 20.0.0.3 [1/0] via 10.0.0.3
R2#

R2#show run | inc route
ip route 0.0.0.0 0.0.0.0 10.0.0.3 ip route 0.0.0.0 0.0.0.0 20.0.0.3

Now for the fun part. (Really!:) Lets generate some traffic in the background, and allow OER to dynamically learn the specific routes, as well as learn the best path to those routes and watch those routes be added to the routing table on R2. We’ll create two SLAs from R1 directed to the loopbacks of R4 and R5.

R1

R1(config)#ip sla 1
R1(config-ip-sla)#tcp-connect 150.1.4.4 4000
R1(config-ip-sla-tcp)#timeout 100
R1(config-ip-sla-tcp)#frequency 1
R1(config-ip-sla-tcp)#exit
R1(config)#ip sla schedule 1 life forever start-time now
R1(config)#
R1(config)#ip sla 2
R1(config-ip-sla)#tcp-connect 150.1.5.5 5000
R1(config-ip-sla-tcp)#timeout 100
R1(config-ip-sla-tcp)#frequency 1
R1(config-ip-sla-tcp)#exit
R1(config)#ip sla schedule 2 life forever start-time now

On R4 and R5, we need to set up the SLA responder, so they will respond correctly to the tcp-connect requests sourced from R1.

R4 and R5

R4(config)#ip sla responder
R5(config)#ip sla responder

On R2, lets see what networks have been learned. (Note: Based on the timers, it may take a ~minute or so for the /32 networks of 150.1.4.4 and 150.1.5.5 to be learned.   I waited at least a couple minutes before issuing the commands below.   You may want to verify that your SLA traffic is reaching R4 and R5 if you need to troubleshoot).

R2#show oer border passive cache prefix

OER Passive Prefix Cache, State: enabled, 278544 bytes
4 active, 4092 inactive, 1222 added
67316 ager polls, 0 flow alloc failures
Active flows timeout in 1 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 25800 bytes
12 active, 1012 inactive, 3666 added, 1222 added to flow
0 alloc failures, 0 force free
1 chunk, 30 chunks added
0 flows not aggregated due to main subcache starvation

Prefix NextHop Src If Dst If Flows
Pkts B/Pk Active sDly #Dly PktLos #UnRch
------------------------------------------------------------------------
150.1.4.4/32 0.0.0.0 Tu1 Fa0/0 24
34 38 18.5 0 0 0 0
150.1.5.5/32 0.0.0.0 Tu1 Fa0/0 24
34 38 18.1 0 0 0 0
150.1.4.4/32 20.0.0.3 Fa0/0 Tu2 23
35 62 18.5 64 5 0 0
150.1.5.5/32 20.0.0.3 Fa0/0 Tu2 23
35 62 18.1 84 5 0 0
R2#

Now, lets turn on a debug of active probes on the border, and see what we can learn from it.

R2#debug oer border active-probes detail
<snip>
OER BR APE detail: Completed retrieving Probe Statistics.
probeType = echo, probeTarget = 150.1.4.4, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 10.0.0.3
probeIfIndex = 10, SAA index = 339 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 2, Sum of rtt 40, Max rtt 24, Min rtt 16
<snip>
OER BR APE detail: Completed retrieving Probe Statistics.
probeType = echo, probeTarget = 150.1.4.4, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 20.0.0.3
probeIfIndex = 11, SAA index = 340 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 2, Sum of rtt 52, Max rtt 28, Min rtt 24

Based on this, the rtt values from Tunnel 1 (using 10.0.0.3 as the next hop to reach 150.1.4.4) are lower than Tunnel 2 (which is using 20.0.0.3 as the next hop). As a result, OER believes that Tunnel 1 is the best path and will inject a static /32 route for destination 150.1.4.4, using Tunnel 1 as the exit interface and 10.0.0.3 as the next hop. A similar result was discovered for 150.1.5.5 as well. As a result, both /32 routes are dynamically added to the routing table on R2.

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 20.0.0.3 to network 0.0.0.0

136.1.0.0/24 is subnetted, 2 subnets
C 136.1.12.0 is directly connected, FastEthernet0/0
C 136.1.23.0 is directly connected, Serial0/0
20.0.0.0/24 is subnetted, 1 subnets
C 20.0.0.0 is directly connected, Tunnel2
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Tunnel1
150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 150.1.2.0/24 is directly connected, Loopback0
! OER dynamically added the 2 static routes below
S 150.1.5.5/32 [1/0] via 10.0.0.3 S 150.1.4.4/32 [1/0] via 10.0.0.3
S* 0.0.0.0/0 [1/0] via 20.0.0.3
[1/0] via 10.0.0.3
R2#

Also, on R1, the controller, there were a couple messages logged:

%OER_MC-5-NOTICE: Route changed Prefix 150.1.5.5/32, BR 136.1.12.2, i/f Tu1, Reason Delay, OOP Reason Timer Expired
%OER_MC-5-NOTICE: Route changed Prefix 150.1.4.4/32, BR 136.1.12.2, i/f Tu1, Reason Delay, OOP Reason Timer Expired

So now that OER has decided that Tunnel 1, using 10.0.0.3 is the best path for those 2 networks, lets tip the scale in the other direction by using generic  traffic shaping on Tunnel 1, so that the delay there will be worse than Tunnel 2, and watch the results. (Note: in addition to the generic traffic shaping on R2 Tunnel 1, I also ran an extended ping sourced from 150.1.4.4 and 150.1.5.5 to increase the overall delay).

R2(config-if)#traffic-shape rate 8000 1000 0
R2(config-if)#do show traffic-shape

Interface Tu1
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
- 8000 125 1000 0 125 125 -

R2#
! Below is debug output showing Tunnel 2 with next hop of 20.0.0.3 ! as having the least delay for destination 150.1.4.4 ...

OER BR APE detail: Completed retrieving Probe Statistics.
probeType = echo, probeTarget = 150.1.4.4, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 10.0.0.3
probeIfIndex = 10, SAA index = 363 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 1, Sum of rtt 88, Max rtt 88, Min rtt 88
OER BR APE detail: Completed retrieving Probe Statistics.
probeType = echo, probeTarget = 150.1.4.4, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 20.0.0.3
probeIfIndex = 11, SAA index = 364 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 1, Sum of rtt 8, Max rtt 8, Min rtt 8
OER BR APE detail: Completed retrieving Probe Statistics.

! Now the debug output for the destination 150.1.5.5 showing ! that Tunnel 2 with next hop of 20.0.0.3 has the least delay ....
probeType = echo, probeTarget = 150.1.5.5, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 10.0.0.3
probeIfIndex = 10, SAA index = 365 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 1, Sum of rtt 72, Max rtt 72, Min rtt 72
OER BR APE detail: Completed retrieving Probe Statistics.
probeType = echo, probeTarget = 150.1.5.5, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 20.0.0.3
probeIfIndex = 11, SAA index = 366 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 1, Sum of rtt 12, Max rtt 12, Min rtt 12

Back on the master controller (R1), we notice the messages:

%OER_MC-5-NOTICE: Route changed Prefix 150.1.4.4/32, BR 136.1.12.2, i/f Tu2, Reason Delay, OOP Reason Timer Expired
%OER_MC-5-NOTICE: Route changed Prefix 150.1.5.5/32, BR 136.1.12.2, i/f Tu2, Reason Delay, OOP Reason Timer Expired

On R2 (the border), here is the updated routing table:

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 20.0.0.3 to network 0.0.0.0

136.1.0.0/24 is subnetted, 2 subnets
C 136.1.12.0 is directly connected, FastEthernet0/0
C 136.1.23.0 is directly connected, Serial0/0

20.0.0.0/24 is subnetted, 1 subnets
C 20.0.0.0 is directly connected, Tunnel2

10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Tunnel1

150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 150.1.2.0/24 is directly connected, Loopback0

! Note: the next hop has changed, and will use Tunnel 2 as the exit
S 150.1.5.5/32 [1/0] via 20.0.0.3
S 150.1.4.4/32 [1/0] via 20.0.0.3

S* 0.0.0.0/0 [1/0] via 20.0.0.3
[1/0] via 10.0.0.3
R2#

For detailed information regarding OER and the hundreds of options available with it, please leverage the content in our updated V5 RS content.

OER is very fun, and very important. Enjoy your studies, and good luck!

 

Dec
28

What does RITE and the v4 CCIE blueprint have in common? Section 10.04 :) If you are new to RITE, or would like to know more about it, read on.

Router IP Traffic Export, (RITE), allows the forwarding of unaltered IP packets from a router interface to memory or to a specific MAC address on a locally attached network. A likely candidate being the MAC address of a network analyzer or Intrusion Detection System.

As an example, lets configure RITE on R2. Setting it up is simple. We first create a profile, and apply that profile to an interface. But what if we don't want to export all of the traffic? No problem. We can also filter to specify exactly which traffic should be captured and exported, and we can even specify a smaller sample of the overall traffic flow if desired.

In this example, we will create an access-list that only matches if the source traffic is from R5’s loopback 0 address of 150.1.5.5

R2:

ip access-list extended FROM-R5
permit ip host 150.1.5.5 any

Next lets create a simple profile, (we will call this one “R5”), and specify the interface where we will export the packets to, as well as the MAC address that is reachable locally by R2. We will also leverage the access-list to filter on what may be captured, as well as a sampling rate of 1 in every 5 packets, (20%).

R2:

ip traffic-export profile R5
interface FastEthernet0/0
incoming access-list FROM-R5
mac-address 0123.4567.89ab
incoming sample one-in-every 5
exit

Next we will apply the profile to the interface which will be receiving the packets sourced from R5 loopback 0.

R2

interface Serial0/0
ip traffic-export apply R5

Turning on debugging will assist in seeing the activity behind the scene.

R2:

debug ip traffic-export events

Next, we generate some traffic, sourced from R5 loopback 0. This traffic does pass through the serial 0/0 interface of R2.

R5:

R5#show ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM up up
Serial0/0 unassigned YES NVRAM administratively down down
FastEthernet0/1 136.1.45.5 YES NVRAM up up
Serial0/1 unassigned YES NVRAM administratively down down
Loopback0 150.1.5.5 YES NVRAM up up

R5#
R5#ping 150.1.2.2 repeat 50 source loopback 0

Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
Packet sent with a source address of 150.1.5.5
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 4/12/32 ms
R5#

Back to R2, to see the results of the debug.

R2#RITE: exported input packet # 1
RITE: exported input packet # 2
RITE: exported input packet # 3
RITE: exported input packet # 4
RITE: exported input packet # 5
RITE: exported input packet # 6
RITE: exported input packet # 7
RITE: exported input packet # 8
RITE: exported input packet # 9
RITE: exported input packet # 10

R2#

Now lets look at some of the statistics.

R2#show ip traffic-export
Router IP Traffic Export Parameters
Monitored Interface Serial0/0
Export Interface FastEthernet0/0
Destination MAC address 0123.4567.89ab
bi-directional traffic export is off
Input IP Traffic Export Information Packets/Bytes Exported 10/1000
Packets Dropped 43
Sampling Rate one-in-every 5 packets
Access List FROM-R5 [named extended IP]
Profile R5 is Active
R2#

Out of the 50 pings, 10 of them were exported, due to the profile we created. The packets dropped reflect packets that were not exported, including 40 from R5, and 3 other packets that did not match the ACL in the profile.

Keep up the great studies, and good luck!

Dec
17

Using an IPS Sensor, we can dynamically apply rate limiting/policing on a router interface, based on a signature match or an event action over-ride, which is generated on the sensor appliance.   Ok, I know there is no Sensor Appliance in the RS lab, but what if we need to trigger a rate limit of specific traffic, destined to a router, based on current conditions on that router, such as transmit or receive loads on an interface.

This is a job for, da dada dahhh: Embedded Event Manager (EEM).  In this example we will create a service policy which we will apply to the control plane based on a interface threshold being exceeded.  Full labs on Embedded Event Manager can be found in our RS v5 Vol1 workbook in  "System Management".  Let's break down the individual steps, first for the control plane policing policy, and then the EEM to apply it.

We will first create a policy map, which calls on a class map, which calls on an ACL. In this class map, we are going to identify ICMP, by referencing an access list. So first we create the access list, and we will name it ICMP.

ip access-list extended ICMP
permit icmp any any

Now that the access list is created, we will create the class map called ICMP which will be referencing the access list of the same name.

class-map match-all ICMP
match access-group name ICMP
exit

Next we will create the policy map, and for convenience we will name it ICMP (as well). This policy map will reference the class map, and specify  policing at 8000 bits per second with a burst rate of 1000 bytes.

policy-map ICMP
class ICMP
police 8000 1000

Ok, so now for the EEM part of the configuration.  First, we will create our event manager applet. In this applet we will be referencing serial 0/0, and we will be looking for the received load to be greater than 25. The 25 refers to 25 out of a possible 255 as reported by the interface. Once the ~10% is exceeded, the CLI commands implemented in our applet will be executed. The CLI commands will simply apply the service policy to the logical control plane host interface on the router. By doing this, any ICMP traffic destined TO the router, will be policed, regardless of which interface the traffic is received on.   The EEM policy will also generate a syslog message. There are additional options which we could include, such as sending SNMP traps, e-mail messages and so forth.

event manager applet LOAD
event interface name Serial0/0 parameter rxload entry-val 25 entry-op gt entry-val-is-increment false poll-interval 60
action 0.0 cli command "enable"
action 1.0 cli command "configure terminal"
action 2.0 cli command "control-plane host"
action 3.0 cli command "service-policy input ICMP"
action 4.0 syslog msg "Just Applied Control Plane Policy to Limit ICMP"
exit

At the interface level we will specify a bandwidth statement of 64, which will allow us to trigger the 25/255 much quicker. We will also set the load interval to a lower value than the default of five minutes so that the average will increase faster.

interface ser 0/0
bandwidth 64
load-interval 30
end

The following debug, will give us the Howard Cosell play-by-play of exactly what's happening.

R2#debug event manager action cli
Debug EEM action cli debugging is on

To view the details of the interfaces that are registered with an event manager policy, we would use the following show command.

R2#show event manager policy registered event-type interface
No. Class Type Event Type Trap Time Registered Name
1 applet user interface Off Thu Feb 28 18:51:41 2002 LOAD
name {Serial0/0} parameter {rxload} entry_op gt entry_val 25 entry_val_is_increment FALSE poll_interval 60.000
maxrun 20.000
action 0.0 cli command "enable"
action 1.0 cli command "configure terminal"
action 2.0 cli command "control-plane host"
action 3.0 cli command "service-policy input ICMP"
action 4.0 syslog msg "Just Applied Control Plane Policy to Limit ICMP"

To verify what the current load is on the interface, we can use the command below.

R2#show int ser 0/0 | inc rxload
reliability 255/255, txload 1/255, rxload 1/255

Once the control plane policy has been applied, the actual details of how many packets have been permitted and denied by that policy will be shown by the command below.

R2#show policy-map control-plane host
R2#

From the commands above, you'll notice that the current load is at one, and there is no policy currently applied to the control plane. Let's go to the neighboring router and generate some traffic to trigger event manager and the applet that we just created.

Neighbor-R3#ping 150.1.2.2 size 500 repeat 1000 timeout 0

Type escape sequence to abort.
Sending 1000, 500-byte ICMP Echos to 150.1.2.2, timeout is 0 seconds:
......................................................................
......................................................................
......................................................................
.......................................................!.!............
......................................................................
.............................................!........................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
....................
Success rate is 0 percent (3/1000), round-trip min/avg/max = 4/6/8 ms
Neighbor-R3#

Cool, we got 3 back, even with a timeout of 0 seconds.  Now lets go back to R2, and look at some results.

R2#show int ser 0/0 | inc rxload
reliability 255/255, txload 58/255, rxload 58/255
R2#
! Note: It may take a few moments for the policy as polling occurs every 60 seconds ! ! Patience is a virtue, and I want mine NOW ;-) !

%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : CTL : cli_open called.
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : R2#
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : IN : R2#enable
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : R2#
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : IN : R2#configure terminal
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : Enter configuration commands, one per line. End with CNTL/Z.
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : R2(config)#
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : IN : R2(config)#control-plane host
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : R2(config-cp-host)#
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : IN : R2(config-cp-host)#service-policy input ICMP
%CP-5-FEATURE: Control-plane Policing feature enabled on Control plane host path

%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : R2(config-cp-host)#
%HA_EM-6-LOG: LOAD: Just Applied Control Plane Policy to Limit ICMP
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : CTL : cli_close called.
R2#
%SYS-5-CONFIG_I: Configured from console by vty0
R2#

Back to the neighbor router, R3 to see how the policing of ICMP looks from the outside.

Neighbor-R3#ping 150.1.2.2 size 500 repeat 20         

Type escape sequence to abort.
Sending 20, 500-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
!!.!!.!!.!!.!!.!!.!.
Success rate is 65 percent (13/20), round-trip min/avg/max = 4/12/24 ms
Neighbor-R3#

Back to R2 to view the output of the service policy.

R2#show policy-map control-plane host
Control Plane Host

Service-policy input: ICMP

Class-map: ICMP (match-all)
20 packets, 10080 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: access-group name ICMP
police:
cir 8000 bps, bc 1000 bytes
conformed 13 packets, 6552 bytes; actions:
transmit
exceeded 7 packets, 3528 bytes; actions:
drop
conformed 0 bps, exceed 0 bps

Class-map: class-default (match-any)
3 packets, 268 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
R2#

Based on results, the service policy is now applied to the control-plane host sub-interface, and is limiting ICMP.  This example of EEM is like a single ice-cube, compared to a titanic sized iceberg of possibilities.   My intention is to introduce the topic, and encourage you to study it further.

I configured this demonstration using IOS Version 12.4(15)T10

Enjoy your studies, and have fun exploring the world of EEM.

Nov
13

The CCNP Workbook accompanying the CCNP Bootcamp Class-on-Demand has been updated. Current customers can access the new updates by visiting the IE Member's Site. The workbook now includes the following topics:


1.1 VLANs
1.2 Access Ports
1.3 ISL Trunk Ports
1.4 802.1Q Trunk Ports
1.5 Controlling Traffic over Trunk Ports
1.6 VLAN Trunk Protocol (VTP)
1.7 VTP Pruning
1.8 VTP Transparent Mode
1.9 Spanning-Tree Protocol
1.10 Rapid PVST+
1.11 Multiple Spanning-Tree Protocol
1.12 Spanning-Tree Protocol Features
1.13 EtherChannel
1.14 Inter-VLAN Routing
1.15 Port Security
1.16 802.1X Authentication
1.17 VLAN Access Lists
1.18 DHCP Snooping & DAI
1.19 Private VLANs
1.20 HSRP
1.21 VRRP
1.22 GLBP
2.1 Basic EIGRP
2.2 EIGRP Security
2.3 EIGRP Convergence Optimization
2.4 EIGRP Load Balancing
2.5 EIGRP Summarization
2.6 EIGRP Default Routing
2.7 EIGRP Stub Routing
3.1 Single Area OSPF
3.2 Multi-Area OSPF
3.3 OSPF Optimization
3.4 OSPF Security
3.5 OSPF Redundancy
3.6 OSPF Path Selection
3.7 OSPF Summarization
3.8 OSPF Stub Areas
4.1 Level-2 IS-IS
4.2 Level-1 IS-IS
4.3 IS-IS Optimization
4.4 IS-IS Security
4.5 IS-IS Path Selection
4.6 IS-IS Summarization
5.1 iBGP Peerings
5.2 EBGP Peerings
5.3 BGP NLRI Advertisements
5.4 BGP Aggregation
5.5 Outbound BGP Path Selection
5.6 Inbound BGP Path Selection
6.1 PIM
6.2 Multicast Testing
7.1 IPv6 Addressing
7.2 IPv6 OSPFv3 Routing
8.1 Site-to-Site VPN
8.2 Site-to-Site GRE over IPsec VPN
8.3 Easy VPN
8.4 One-Step Lockdown
8.5 IOS Firewall
9.1 Layer 2 AutoQoS
9.2 Layer 3 AutoQoS

Good luck in your continued preparation!

Nov
11

Change is in the air. I've noticed that over the last several weeks, we've had at least five security CCIE candidates pass who used INE's security products as part of their study plan. What these students have done is use a combination of our version 3 and version 5 products. Congratulations to all those who passed!

The rumor on the street is, that "IF" there were issues in the past with Cisco’s security lab, whether they were Java issues, or wording issues, etc. it seems that well-prepared candidates can now, based on results, pass this exam.  Better yet, with the update of our Vol 1 products, studying will be easier than ever.

As Brian mentioned, the roll-out of our updated volume 1 products is underway. Marvin and I would like to thank a handful of beta testers, who have done an outstanding job testing a few of our latest modules. Thank you very much for your assistance!

So you might ask, what's new and exciting about the updates for security volume 1? I'm glad you asked!

Each of the new modules in volume 1 matches up identically with the sections from the current blueprint from Cisco. This means if you just want to focus on VPN technology, you can go to section 3 and have the entire VPN section to work with.  The same is true for ASA (module 1), IOS firewall (module 2) and the rest of the sections.

The ASA module is now complete and will be posted to the member’s area this afternoon, along with the startup configuration files for all of the individual racks.  The IOS firewall module, which I know sounds like a piece of hardware, (forgive my chuckle), is finishing beta testing today and will be posted in the members area shortly. As the other modules complete beta testing they will be posted to the members area, and will begin shipping the week of November 23.

Thank you, and good luck with your studies.

Oct
22

As promised I have begun posting new updates to the CCNP Lab Workbook, for customers of the CCNP Bootcamp Class-on-Demand. In addition to the previously available BCMSN section, the EIGRP portion of the BSCI section is now posted. I should be posting another batch of updates tomorrow which include OSPF and possibly IS-IS, along with the rest of the topics to soon follow. Current customers can find these updates on the members site.

Stay tuned for more!

Oct
07

The first beta release of our CCNP Lab Workbook is now posted for all customers of the CCNP Bootcamp Class-on-Demand.  A sample of it can be viewed here. Current customers can find the workbook on the CCNP Bootcamp Class-on-Demand page of the INE Members Site.

Currently the workbook covers BCMSN.  Within the coming week it will be incrementally updated with the lab content for BSCI, ISCW, and ONT.  There is a timestamp on the members site page that you use to access the workbook, so make sure to take note of this as there will be a large amount of updates in a small amount of time coming shortly.  The current outline of the BCMSN section is as follows:

  • VLANs
  • Access Ports
  • ISL Trunk Ports
  • 802.1Q Trunk Ports
  • Controlling Traffic over Trunk Ports
  • VLAN Trunk Protocol (VTP)
  • VTP Pruning
  • VTP Transparent Mode
  • Spanning-Tree Protocol
  • Rapid PVST+
  • Multiple Spanning-Tree Protocol
  • Spanning-Tree Protocol Features
  • EtherChannel
  • Inter-VLAN Routing
  • Port Security
  • 802.1X Authentication
  • VLAN Access Lists
  • DHCP Snooping & DAI
  • Private VLANs
  • HSRP
  • VRRP
  • GLBP

For all technical questions on the lab workbook please visit the Internetwork Expert Online Community at http://www.IEOC.com

Happy Labbing!

Sep
18

INE is proud to announce that our CCNP Class-on-Demand is now completed and available for viewing! Taught by yours truly, the class includes more than 45 hours of videos covering the latest BSCI, BCMSN, ISCW, and ONT exams for the CCNP. Whether your are preparing for the CCNP, or brushing up for the new Core Technologies section of the CCIE R&S Lab Exam, this series will exceed all your expectations.

Using our tried and true hands-on learning approach, by using this series you will not only learn how these networking technologies work in real-world design scenarios, but you will also see live IOS command line and SDM GUI examples of how to configure, verify, and troubleshoot them.

For more info visit http://www.ine.com/ccnp.htm or email sales@ine.com

The current topic outline can be found below, along with some sample videos. More details will be posted next week about the CCNP Lab Workbook that is included for no extra charge, hardware recommendations, along with more samples video and workbook content.

Content Outline

Week 1 - BCMSN & BSCI

  • Introduction    0:55:08
  • BCMSN - Hierarchical Campus Design    1:04:07
  • BCMSN - VLANs & Trunking    1:00:17
  • BCMSN - Dynamic Trunking Protocol (DTP) & VLAN Trunk Protocol (VTP)    1:09:37
  • BCMSN - Spanning-Tree Protocol (STP)    0:42:32
  • BCMSN - STP (cont.)    0:53:45
  • BCMSN - Advanced STP    1:00:07
  • BCMSN - Rapid Spanning-Tree Protocol (RSTP)    0:46:04
  • BCMSN - Advanced STP Features & EtherChannel    0:47:45
  • BCMSN - Inter-VLAN Routing    0:53:31
  • BCMSN - Gateway Redundancy    0:49:25
  • BCMSN - HSRP (cont.) & Layer 2 Security    1:00:18
  • BSCI - IP Routing Overview    0:28:15
  • BSCI - EIGRP Overview    0:57:19
  • BSCI - EIGRP Configuration    1:01:24
  • BSCI - Advanced EIGRP    0:44:10
  • BSCI - Basic OSPF    1:07:43
  • BSCI - Basic OSPF (cont.)    0:39:53
  • BSCI - Multi-Area OSPF    0:58:14
  • BSCI - OSPF Virtual-Links & Summarization    0:52:45
  • BSCI - OSPF Stub Areas & Advanced OSPF    0:52:46
  • BSCI - IS-IS    1:17:21
  • BSCI - BGP    1:17:37
  • BSCI - BGP (cont.)    0:48:01
  • BSCI - BGP Configuration    1:14:41
  • BSCI - IP Routing Features    0:47:51
  • BSCI - Redistribution    1:02:42
  • BSCI - IPv4 Multicast    1:25:55
  • BSCI - IPv4 Multicast Configuration    0:46:40
  • BSCI - IPv6    0:57:10
  • BSCI - IPv6 Configuration    0:09:46

Week 2 - ISCW & ONT

  • Introduction    0:20:19
  • ISCW - Basic Teleworker Services    0:55:22
  • ISCW - MPLS Overview    0:49:52
  • ISCW - MPLS LDP Configuration    0:54:48
  • ISCW - MPLS VPNs Overview    0:31:50
  • ISCW - MPLS VPNs Configuration    0:42:12
  • ISCW - IPsec Overview    0:58:04
  • ISCW - IPsec Configuration    1:06:32
  • ISCW - IPsec Troubleshooting & Remote Access IPsec    1:06:06
  • ISCW - GRE over IPsec    0:59:47
  • ISCW - Device Hardening    1:08:54
  • ISCW - Device Hardening (cont.) & AAA    0:57:00
  • ISCW - Firewall Overview    0:44:28
  • ISCW - Stateless Packet Filters    0:43:05
  • ISCW - IOS Firewall (CBAC)    0:39:16
  • ISCW - IOS Firewall (ZBPF)    0:57:48
  • ISCW - IOS IPS    0:45:52
  • ISCW - IOS IPS (cont.)    0:10:13
  • ONT - VoIP Overview    1:02:29
  • ONT - QoS Overview    0:35:45
  • ONT - DiffServ QoS    1:11:03
  • ONT- QoS Configuration
  • BCMSN - Layer 2 QoS
  • BCMSN - Wireless Client Access
  • ONT - Wireless Security
  • ONT - Wireless Configuration
  • ONT - Wireless QoS

Content Samples

CCNP BCMSN STP Overview Part 1/2

CCNP BCMSN STP Overview Part 2/2

CCNP BSCI EIGRP Part 1/3

CCNP BSCI EIGRP Part 2/3

CCNP BSCI EIGRP Part 3/3

CCNP ISCW IPsec Part 1/4

CCNP ISCW IPsec Part 2/4

CCNP ISCW IPsec Part 3/4

CCNP ISCW IPsec Part 4/4

For more info visit http://www.ine.com/ccnp.htm or email sales@ine.com

Section

Description

Duration

BCMSN & BSCI Day 1 Part 1

BCMSN & BSCI - Introduction

0:55:08

BCMSN Day 1 Part 2

BCMSN - Hierarchical Campus Design

1:04:07

BCMSN Day 1 Part 3

BCMSN - VLANs & Trunking

1:00:17

BCMSN Day 1 Part 4

BCMSN - Dynamic Trunking Protocol (DTP) & VLAN Trunk Protocol (VTP)

1:09:37

BCMSN Day 1 Part 5

BCMSN - Spanning-Tree Protocol (STP)

0:42:32

BCMSN Day 1 Part 6

BCMSN - STP (cont.)

0:53:45

BCMSN Day 2 Part 1

BCMSN - Advanced STP

1:00:07

BCMSN Day 2 Part 2

BCMSN - Rapid Spanning-Tree Protocol (RSTP)

0:46:04

BCMSN Day 2 Part 3

BCMSN - Advanced STP Features & EtherChannel

0:47:45

BCMSN Day 2 Part 4

BCMSN - Inter-VLAN Routing

0:53:31

BCMSN Day 2 Part 5

BCMSN - Gateway Redundancy

0:49:25

BCMSN Day 2 Part 6

BCMSN - HSRP (cont.) & Layer 2 Security

1:00:18

BSCI Day 3 Part 1

BSCI - IP Routing Overview

0:28:15

BSCI Day 3 Part 2

BSCI - EIGRP Overview

0:57:19

BSCI Day 3 Part 3

BSCI - EIGRP Configuration

1:01:24

BSCI Day 3 Part 4

BSCI - Advanced EIGRP

0:44:10

BSCI Day 3 Part 5

BSCI - Basic OSPF

1:07:43

BSCI Day 3 Part 6

BSCI - Basic OSPF (cont.)

0:39:53

BSCI Day 3 Part 7

BSCI - Multi-Area OSPF

0:58:14

BSCI Day 4 Part 1

BSCI - OSPF Virtual-Links & Summarization

0:52:45

BSCI Day 4 Part 2

BSCI - OSPF Stub Areas & Advanced OSPF

0:52:46

BSCI Day 4 Part 3

BSCI - IS-IS

1:17:21

BSCI Day 4 Part 4

BSCI - BGP

1:17:37

BSCI Day 4 Part 5

BSCI - BGP (cont.)

0:48:01

BSCI Day 4 Part 6

BSCI - BGP Configuration

1:14:41

BSCI Day 5 Part 1

BSCI - IP Routing Features

0:47:51

BSCI Day 5 Part 2

BSCI - Redistribution

1:02:42

BSCI Day 5 Part 3

BSCI - IPv4 Multicast

1:25:55

BSCI Day 5 Part 4

BSCI - IPv4 Multicast Configuration

0:46:40

BSCI Day 5 Part 5

BSCI - IPv6

0:57:10

BSCI Day 5 Part 6

BSCI - IPv6 Configuration

0:09:46

ISCW & ONT Day 1 Part 1

ISCW & ONT Introduction

0:20:19

ISCW Day 1 Part 2

ISCW - Basic Teleworker Services

0:55:22

ISCW Day 1 Part 3

ISCW - MPLS Overview

0:49:52

ISCW Day 1 Part 4

ISCW - MPLS LDP Configuration

0:54:48

ISCW Day 1 Part 5

ISCW - MPLS VPNs Overview

0:31:50

ISCW Day 1 Part 6

ISCW - MPLS VPNs Configuration

0:42:12

ISCW Day 2 Part 1

ISCW - IPsec Overview

0:58:04

ISCW Day 2 Part 2

ISCW - IPsec Configuration

1:06:32

ISCW Day 2 Part 3

ISCW - IPsec Troubleshooting & Remote Access IPsec

1:06:06

ISCW Day 2 Part 4

ISCW - GRE over IPsec

0:59:47

ISCW Day 2 Part 5

ISCW - Device Hardening

1:08:54

ISCW Day 2 Part 6

ISCW - Device Hardening (cont.) & AAA

0:57:00

ISCW Day 3 Part 1

ISCW - Firewall Overview

0:44:28

ISCW Day 3 Part 2

ISCW - Stateless Packet Filters

0:43:05

ISCW Day 3 Part 3

ISCW - IOS Firewall (CBAC)

0:39:16

ISCW Day 3 Part 4

ISCW - IOS Firewall (ZBPF)

0:57:48

ISCW Day 3 Part 5

ISCW - IOS IPS

0:45:52

ISCW Day 3 Part 6

ISCW - IOS IPS (cont.)

0:10:13

ONT Day 4 Part 1

ONT - VoIP Overview

1:02:29

ONT Day 4 Part 2

ONT - QoS Overview

0:35:45

ONT Day 4 Part 3

ONT - DiffServ QoS

1:11:03

ONT Day 4 Part 4

ONT- QoS Configuration

BCMSN Day 4 Part 5

BCMSN - Layer 2 QoS

BCMSN Day 5 Part 1

BCMSN - Wireless Client Access

ONT Day 5 Part 2

ONT - Wireless Security

ONT Day 5 Part 3

ONT - Wireless Configuration

ONT Day 5 Part 4

ONT - Wireless QoS

Jul
30

In preparation for the upcoming CCIE R&S v4.0 Blueprint, new topics are being added to the CCIE R&S Open Lecture Series.  For those of you that have been unable to attend the live sessions, Class-on-Demand recordings are now available for MPLS and Zone Based Policy Firewall.  Currently there are 4 sessions on MPLS, totalling about 5 hours of class, that cover theory, implementation, and verification.  Zone Based Policy Firewall has been added from today's session, and covers the evolution from standard/extended ACLs to Reflexive ACLs to CBAC to Zone Based Policy Firewall.

If you have any topics that you would like to see covered in upcoming sessions please email me at bmcgahan@ine.com with the subject "Open Lecture Topic Request".

Happy Labbing!

May
31

Hi everyone!

We are excited to announce our newest release of IEWB-VO VOL1 labs covering the new CCIE Voice blueprint, which becomes effective as of July this year. The first of the CCIE Voice v3.0 labs are now out in beta format, in addition to new Voice Racks available to rent covering the new topology! All current customers who have purchased IEWB-VO VOL1 will automatically receive the new updates in their members account at no additional cost. Each section of the new VOL1 includes technology-focused labs with explanations, verifications, further reading links, and dedicated troubleshooting sections.

The initial release covers Cisco Unified Communications Manager Express (CUCME, formally known as Call Manager Express or CME). We will continue releasing new voice content covering all new blueprint topics, with a new section being released each week. The next release will include more CUCME labs, as well as Unity Express tasks, followed by the first of the new Unified Communications Manager Labs! The initial VOL1 release covers the following topics:

CUCME Basic Configuration
Phone Registration & Number Assignment (SCCP Phones)
SIP Phones
ISDN PRI
IOS Call Routing
Voice Translation Rules
Shared Line
Night Service
After-Hours Setup
Single Number Reach
Softkey Customization - SCCP
Softkey Customization - SIP
Octo-Line
Conference Resources
Transcoding Resources
B-ACD
Voice Hunt Groups
Ephone Hunt groups
Dynamic Hunt groups

The new voice racks are fully compliant with the CCIE Voice hardware specification posted at Cisco’s website: CCIE Voice Hardware Specification. To many folks out there, the new hardware lists is a huge relief, as the many old and expensive devices including the 6500 switch and the VG248 are now gone. Plus, the addition of SIP phones allows for more flexible choice of softphone software, not limited to the small set of SCCP-compatible products available on the market.

As for the people preparing using the old blueprint, our rack rentals support the old CCIE Voice hardware specification as well. Nothing will change until the lasts days the old blueprint remains valid.

Thank you, and be sure to check back often for more updates!

Subscribe to INE Blog Updates

New Blog Posts!