Learning Red Hat Directory Server
Posted by juecker in Red Hat Directory, Systems on February 28th, 2010
I’ve decided to take on a new technical challenge, at least start one. I had a lot of fun recently playing in servers recently and decided to follow that a ways. I’m going to start studying Red Hat Directory Server, in effort to take the accompanying class. Eventually, I might be able to accomplish the fantastic RHCA, but that’s ambitious at this point, with the little one on the way. I’m also hoping to blog a little more about it, something I’ve been terrible at.
Update
Posted by juecker in Uncategorized on January 24th, 2010
Whew, it sure has been a long time since my last post. So what’s kept me away? Laziness mostly but here’s a list of some new developments. 1) Finished up CCBOOTCAMP projects. That wasn’t a fun process, but I won’t say too much more. I wouldn’t keep your eyes peeled for anything with my name on it in Cisco Press. 2) Doing baby things! My wife and I are expecting our first baby (it’s a boy) in July. So we’ve been going to doctor’s offices, ultrasound appointments, buying cute little outfits and furniture, all the great things you do when expecting your first child. 3) Most recently, I’ve started teaching at the College of Southern Nevada. It’s a regional Cisco Networking Academy located here in Las Vegas. The first class was a bit rocky but I’m confident it’ll be a great experience all around.
Lots going on
Posted by juecker in Uncategorized on September 29th, 2009
I haven’t posted in awhile, obviously. I’ve been involved in a project with CCBOOTCAMP which required a lot more time than I thought. Something that I need to get better at: estimating the amount of time required for a particular project. In any case, here’s a link to the project I worked on. Just when I finished that, I got involved doing a writing project, which I’m really enjoying. I’ll talk more about it when it’s closer to being completed. I don’t want to put a hex on it
EEM Event Detectors
In my previous post, I stated that EEM has these Event Detectors which are used to catch the events and then trigger policies which you have created. So the ability to do anything with EEM relies greatly upon the detectors themselves. After all, if you want to be able to do something (with a policy), you have to be able to detect the trigger. It would be a little like having a policy to open the door for someone when they arrived at your doorstep. The policy would be opening the door but without the ability to detect whether or not someone was at your door, you’d have a hard time. The detector in this case, determining whether or not someone was at your door, is critical to the entire operation. Such is the case with the EEM event detectors. So what are they? These are the list of event detectors supported by the various versions of Cisco IOS.
| Event Detector | EEM v2.2/2.3 | EEM v2.4 | EEM v3.0 |
| Syslog | x | ||
| SNMP | x | ||
| Watchdog | x | ||
| Counter | x | ||
| Interface | x | ||
| Timer | x | ||
| Application Specific | x | ||
| OIR | x | ||
| CLI | x | ||
| GOLD | x | ||
| Resource | x | ||
| Redundancy Framework | x | ||
| Enhanced Object Tracking | x | ||
| None | x | ||
| EEM-RPC | x | ||
| SNMP Proxy | x | ||
| NetFlow | x | ||
| IP SLAs | x | ||
| Routing | x | ||
| Custom CLI | x |
So what are these and what can they do? Here’s a brief comment about each one but I’ll talk about each one in depth in future posts. Some of them are more common than others. For example, I done think that many people use the GOLD ED but Syslog and CLI are extremely popular.
Syslog – Monitors the syslog messages sent by the device. You can use this to match using a regular expression and act accordingly.
CLI – This ED is used everytime a CLI command is issued by a user. What’s great about this ED is that you can configure it so that you can suspend the CLI command that the user issued until the completion of the policy. This means that you can use your policy to disallow access to that CLI command.
Timer – This ED is used to setup a countdown (and stop) timer, a countdown (and restart counting down) timer, a specific time, or a recurring interval timer. The coundown (and stop) timer acts like a kitchen egg timer. After a specific number of seconds, the EEM server fires off the associated policy. The timer is NOT restarted with this timer. There is atimer that does support that type of functionality. In essence, it counts down, fires off the policy and starts counting down again. So the end result is, you can have something fire every 42 seconds, for example. Third, there is a specific time timer which fires off at a specific time, say, August 23, 2009 at 9:03am. The fun with this one is that you have to configure the time in number of seconds past midnight January 1, 1970. (Use an online conversion utility like this one). Finally, there’s a timer which behaves just like the UNIX cron utility (or Cisco’s Kron).
None – This ED is not triggered by any event that happens within IOS. It is used to be triggered by hand or by another script.
SNMP – This ED polls a specific OID. The value can then be processed and a policy can act accordingly.
Interface – This ED is used to process the interface counters which can be seen when you type ’show interface’. There are 22 some odd counters that can be monitored with this ED.
Counter – Along with the None ED, this is another detector that can be used to trigger another policy. The counter is a value that can be manipulated from within the policies and referenced by other policies. For instance, you can have one policy update the counter and have another policy (which uses the counter ED) rely upon the counter value set previously to trigger.
Watchdog/WD System Monitor - These two EDs monitor the CPU and memory within the device. The Watchdog ED is used for non-modular code and the WD System Monitor is used on the new modular code. This is handy when you are concerned about processes using too much CPU or memory.
OIR (Online Insertion and Removal) – This ED triggers upon the insertion and removal of cards. For example, if a line card in a 6500 chassis was removed and replaced, this ED would trigger.
Application Specific – This ED is used by a policy to publish an event which can then be used to trigger another event.
Generic Online Diagnostic (GOLD) - The Generic Online Diagnostic (GOLD) is a framework for diagnotics which is currently implemented in some Cisco IOS products. It is designed to help detect hardware problems that can occur on devices. The results of these tests can be captured using the GOLD ED.
Resource – Cisco has a feature which allows a more in-depth view of the allocation of resources such as CPU, memory and buffers called the Embedded Resource Manager. This utility is able to generate events such that they can be captured by the Resource ED.
Redundancy Framework -The Redundancy Framework is a feature which provides high availablity to various Cisco devices, such as the Cisco 6500 series switches. It is one of the elements that allows the device to support NSF/SSO functionality. The redundancy framework generates events which can be detected by the redundancy framework ED.
Enhanced Object Tracking – Yes, the vary same feature that allows you to track IP SLA statistics, routes, track lists, etc. These events can be detected by the Enhanced Object Tracking ED.
EEM-RPC – This event detector can accept SOAP commands over SSHv2. The commands are formatted as XML code which tell the event detector to fire off an EEM policy.
SNMP Notification – This event detector can detect SNMP trap messages which are sent to the device. This allows the ability to peform an action (through a policy) in response to an SNMP trap detected from another system
NetFlow – Supports Flexible NetFlow which allows the detection of various flow attributes such as the destination IP address or port number. It also allows the detection of flow rate so the ED can trigger if the flow rate exceeds a specific threshold.
IP SLAs – This event detector supports the IP SLA functionality that is available within IOS. It allows the detection of changes in the failing or meeting of a programmed SLA.
Routing – Allows the detection of Routing Information Base (RIB) events such as the addition, remove or modification of a route.
Custom CLI – Allows the creation of custom CLI commands which allow the addtion of special characters such as ‘?’ or ‘Enter’.
TFTP with GNS3
In order to do all this fun Tcl and EEM stuff, I needed to be able to access a TFTP (could have been FTP or SCP, I suppose) server to the virtual routers in GNS3. GNS3 (through dynagen/dynamips) supports the use of a cloud which can attach to real interfaces on the host computer. I just didn’t know how to do it. So I Google’d it and found this joshatterbury.com page with some great explanation. Check out his site for more details. He has some verification stuff that I’m going to skip over. I pretty much followed his directions which are below:
I use my wireless interface (wlan0) for everything so I decided to bind the GNS3 tap0 interface to my eth0 interface so it wouldn’t affect my blogging. Additionally, I wouldn’t be opening up my TFTP server to the Internet (also controlled through iptables).
Create the bridge interface called br0
brctl addbr br0
and activate it with
ip l s dev br0 up
Now is time to create the tap interface. To do this, I needed to install uml-utilities which was a simple (I love linux)
yum install uml-utilities
To create the tap interface using the username of the logged in user after the -u
tunctl -t tap0 -u username!
I bound the tap0 and eth0 interfaces to the br0 bridge interface
brctl addif br0 tap0 brctl addif br0 eth0
That’s pretty much it! I had to give the br0 an IP address so it could talk to the interface that is connected to the router. So I bound 192.168.1.1/24 to the br0 interface. After starting up GNS3 (as root), throwing in a router and a cloud, I configured a tap interface named tap0 and connected the cloud to a router.

Then I had to install the TFTP server with
yum install tftp-server
and configure it by changing the /etc/xinet.d/tftp file so it was enabled, and restarting xinetd. Then UDP/69 traffic had to be allowed through iptables over interface br0.
Thanks Josh!
I’ve upload a copy of my .net file for reference (and for me when I bork mine). Click here to download it. (MD5: 12ec565963cabd436a669bd3cc53f803)
I also created a very very basic script to setup the bridged interface on my linux box. Click here to download it (MD5: 9476bd4953fab7c7a296d26b392d7cde)
Tcl Example
Tcl is an interpreted programming language like Perl and Python (although there’s some big differences). To give you an idea of what a Tcl program looks like, I’ve written this little program which can be run using your friendly Tcl interpreter.
#
# Fun with TCL at Cisco Live 2009
# Jacob Uecker
# juecker.net
#
# Outputs the string to the screen
puts "Enter a number:"
# Gets input from the user and stores into variable 'num'
gets stdin num
# Loop
# Sets the for loop variable 'i' to the value that the user entered
# Runs as long as the variable is greater than zero
# Decrements the value by one each time
for { set i $num } { $i >= 0 } { set i [expr {$i - 1}] } {
# Outputs the current value of i
puts "The variable \$i is currently: $i"
# If the value of i is zero output a special message
if { $i == 0 } {
puts "Learning Tcl is fun when \$i is zero."
#end if
}
# End for loop
}
Embedded Event Manager Beginnings
Cisco’s Embedded Event Manager is probably the most under-utilized ability of the Cisco IOS. It has been available for sometime time and is built into almost all modern IOS based products. Notice that I stated IOS based, this excludes ASA, PIX, and some of the more esoteric Cisco products. But it is available on switches and routers (including the XR line). Here’s how it works:
In the normal operations of the switch or router, events happen all the time. These events can be someone issuing a CLI command, a syslog message, an SNMP trap, etc. As these things happen, they can be detected by the EEM Event Detectors, which are running all the time in the background. The Event Detectors send their information to the EEM server. Here’s a picture from the Cisco website


The EEM server can then be programmed to fire off an EEM policy. The policy is what you can program. Currently there are two different types of polices: applets and Tool Command Language (Tcl) scripts. These applets and Tcl scripts can be programmed to do all sorts of fun things. They can send syslog messages, SNMP traps, fire off e-mails, even open raw sockets. That’s right, you read it right, you can open raw sockets! If you’re not familiar with Tcl, get familar. It’s a lot like Perl and Python just a new syntax but it has them same power. Let that soak it, you have a script interpreter built into your router!
Think about the power you have now. You can program your router to detect the user typing a specific CLI command, stop them, and fire off an e-mail in response. You can capture the MAC address table every five minutes, detect any changes, and syslog it off. To get a better feeling about what people are doing out there, check out the Cisco Beyond page.
I plan on writing a lot about this in the future so expect Tcl scripts, applets, discussions about how to all sorts of things. Let me know if there’s something you’d like to see.
Multicast Question #4 – Answered
Posted by juecker in Cisco, Multicast, Networking on July 1st, 2009
The fourth question was:
* What happens when the receiver decides it wants to bypass the RP for group 239.0.1.23 and receive the multicast stream directly from the host?
Answer: So this is a pretty easy one (which makes me feel dumb for not writing it sooner). By default, in sparse mode, a Cisco router with an attached listener will attempt to form a source-path tree (from the root-path tree) after receiving the first packet of data from the source. Essentially, this means that in sparse mode, the receivers rely upon the RP to be the root of a tree which sends the stream of data that it’s interested in. This is because it doesn’t really know where the sender is coming from (it could be unknown or from multiple places). Once the router attached to the receiver realizes where the source of the stream is coming from, it can get it directly from the source.
How does this work? Glad you asked. Take a look at the following diagram.

Router B is going to be sending the data from the Source to the RP. But look at the RP! The root path three is highlighted in red. It doesn’t make much sense for the Host to receive this data in this roundabout manner. Why can’t Router A just get the stream from Router B? That’s exactly what happens when Router A realizes that it received the data from an interface that isn’t consistent with it’s routing table. Imagine that you could view Router A’s routing table. It would show that the shortest path to get to the Source would be through Router B. So Router A sends a PIM Join message to Router B which allows it to bypass the RP. Now the flow follows the highlighted blue line. Much more efficient.
Can this behaviour be changed? Absolutely. The command (global) to use is:
ip pim spt-threshold <rate (in Kbps)>
When the configured rate is exceeded, the change to a SPT will be made. If you send it to 0, the change will never occur.
Multicast Question #3 – Answered
Posted by juecker in Cisco, Multicast, Networking on June 24th, 2009
The third question was:
* If the host is sending data for group 239.0.1.23 (and sparse-mode is being used), which router (A or B) is going to forward the stream to the RP?
Answer: If you take a look back at the answer to Multicast Question #1, the host will send an IGMP membership report using the destination address of the group (in this case, 239.0.1.23). If both router A and B are listening to these IGMP messages, they will both receive the same membership report. It is then the job of the router (A or B) to send the PIM Register message to the RP. Assuming that there are hosts out there somewhere who want to receive the stream, the RP will accept the PIM Register message and the stream will head toward the RP. Of course, the question was, WHICH router?! The answer is the same as it was in Question #1. The PIM DR for the segment will be the forwarder.
After firing up GNS3, we run a test:
R1#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.0.1.23), 00:03:23/stopped, RP 192.168.0.1, flags: SJPCF
Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.1
Outgoing interface list: Null
(10.0.1.110, 239.0.1.23), 00:03:23/00:02:57, flags: FT
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:00:07/00:02:52
Notice the flags that are set on the (*,G) entry. The ‘C’ flag is set which indicates that there is a device connected to the router which belongs to the group. In the (S,G) entry the RPF nbr of 0.0.0.0 means that it is connected to the sender. It looks like our PIM DR theory proved true!
Multicast Question #2 – Answered
Posted by juecker in Cisco, Multicast, Networking on June 21st, 2009
The second question was:
* Which router (A or B) is going to send the queries to the LAN to determine if there are any more active listeners?
Answer: Obviously, only one of the routers should query the LAN to determine if there are any listening hosts. IGMP determines which router should send the queries on to the segment using the IP addresses. If R2 sends it’s query first, R1 will hear the query and determine that R2 should be the active querier on the segment because R2’s IP address is lower. The opposite could happen, and R1 might be active first, send the query and then R2 could come alive. In this case, R2 would see that it has a lower IP address and send it’s query. R1 would then hear the query from a lower IP address and reliquesh it’s duties to R2. So what happens if R2 fails? R1 has a timer called the ‘query timeout’. If that time runs out and R1 hasn’t heard a query from R2, it takes control and starts to query.