What does “event none” in an EEM applet mean
A member of the cisco-nsp mailing list asked an interesting question a while ago: he tried to test his EEM applet with the event manager run command and got the “Embedded Event Manager policy not registered with event none Event Detector” message.
An EEM applet (until EEM 3.02.4) can be triggered only by a single condition. If you want to trigger the applet from the command line (with the "event man run" command), it cannot be triggered by anything else. Such an applet must have "event none" pseudo-trigger.
The event none is used to indicate that "no trigger" is actually what you want to do (as opposed to "I forgot to specify the trigger").
This article is part of You've asked for it series.
Follow my links on Facebook
I’ve decided to keep the stuff I find interesting separate from the IOS Hints blog (which has evolved into a purely network engineering site). If you’re interested in the links I’m publishing, check them on my Facebook page (or follow the Links item in the More to explore section of the right sidebar). Facebook can also show you a list of the links I’ve published.
You don’t have to be a Facebook user to access the page or view the links, but if you’re already using Facebook and become a fan of my page, new links will automatically appear on your wall.
Blurt from the past: ATM LANE module for Catalyst 3000
I've found the following "gem" in the Catalyst 3000 LANE module data sheet:
The module "provides legacy LANs with access to ATM-based services in an ATM campus backbone".
The legacy LAN was switched Ethernet (which is still around after 15 years) and ATM campus backbones have joined the dinosaurs.
In case you've never seen a Catalyst 3000: it was a switch that Cisco got through one of its first acquisitions and although it was a good Ethernet switch, it was a nightmare to configure and the later additions (for example, the LANE module) were a disaster. Luckily, it was allowed to die a quiet death a few years later.
VPLS Is Not Aspirin
If you’re old enough to remember the days when switches were still called bridges and were used to connect multiple sites over WAN links, you’ve probably experienced interesting network meltdowns caused by a single malfunctioning network interface card. Some of you might have had the “privilege” of encountering another somewhat failed attempt at WAN bridging: ATM LAN Emulation (LANE) service (not to mention the “famous” Catalyst 3000 switches with LANE uplink).
It looks like some people decided not to learn from others’ mistakes: years later the bridging-over-WAN idea has resurfaced in the VPLS clothes. While there are legitimate reasons why you’d want to have a bridged connection across the Service Provider network, VPLS should not be used to connect regular remote sites to a central site without on-site routers, as I explained in the VPLS: A secure LAN cloud solution for some, not all article I wrote in 2009 (republished below).
Zone-based Traffic Policing
The zone-based firewall uses security policy-maps to specify how the flows between zones should be handled based on their traffic classes. The obvious actions that you can use in the security policy are pass, drop and inspect, but there’s also the police action and one of the readers sent me an interesting question: “why would you need the police action in the security policy if you already have QoS policing”.
Why Is OSPF (Or IS-IS) Afraid of Unequal-Cost Load Balancing
You might have wondered why no link-state routing protocols support unequal-cost load balancing (UCLB). Petr Lapukhov provides part of the answer in his Understanding Unequal-Cost Load-Balancing article: EIGRP is one of those few protocols that can ensure a neighbor is not using the current router as its next-hop.
However, one has to wonder: with OSPF and IS-IS having the entire network topology (or at least the intra-area part of it) in the SPF tree, how hard would it be to detect that sending a packet to a device that is not on the shortest path results in a forwarding loop? Is the lack of OSPF or IS-IS UCLB in Cisco IOS the result of lip service to the standards (at least the OSPF one is way too prescriptive) or a shoddy implementation? What are your thoughts?
Quick tip: limit SNMP traps sent to a SNMP server
If you use multiple SNMP servers in your network, you might want to limit the traps each server receives. Configuring this functionality is easy: just list the traps you want a server to receive at the end of the snmp-server host configuration command.
When you specify the list of SNMP trap types a server should receive, a trap is sent to the server only if it’s listed in the snmp-server host command and enabled with the snmp-server enable traps command.
… updated on Wednesday, November 18, 2020 13:37 UTC
OSPF Router ID Selection: the Gory Details
After I wrote the OSPF router ID selection trivia post, I wanted to figure out all the details of the OSPF router ID selection algorithm. As I’ve expected, the common wisdoms are mostly correct, but they fail to cover the interesting border cases.
Here’s the complete algorithm (as observed on Cisco IOS in 2009):
… updated on Tuesday, December 29, 2020 09:23 UTC
SPF Events in OSPF and IS-IS
Link-state algorithms select the best routes through a two-step process:
- The topology of the area is analyzed using SPF algorithm, resulting in a shortest-path tree. This tree contains the shortest paths from the current router to any other node (router or transit LAN) in the current area. This step performed with the Shortest Path First (SPF) algorithm.
- The best routes are selected based on the advertisements from all routers in the area (including inter-area and external routes in case of OSPF). The route selection is a simple distance-vector operation where the router selects the minimum-cost IP prefixes from the set of all advertised IP prefixes.
OSPF Router ID Selection Trivia
True or false: If you have an (enabled) loopback interface configured on the router, its IP address will always be used as the OSPF router ID.
Quick tip: Enable SNMP traps
IOS can generate numerous SNMP traps, but you have to enable most of them manually. Configuring a server that receives SNMP traps with the snmp-server host address community traps is not enough; you have to enable individual trap categories with the snmp-server enable traps group [ trap ] command.
In older releases, the standard SNMP traps (for example, link up/down traps) are enabled by default and cannot be disabled with the snmp-server enable traps command. Newer IOS releases have added the snmp-server enable traps snmp [ authentication | coldstart | linkdown | linkup | warmstart ] global configuration command. These releases require you to enable standard SNMP traps manually; otherwise the router will not generate them.
If you want to see the whole list, configure snmp-server enable traps and execute show running | include snmp-server enable. IOS 12.4T network management reference guide also includes a comprehensive list of all options.
Carrier Ethernet: the big picture
My regular readers are probably not surprised to learn that I dislike buzzwords and marketectures. I’ve heard so much about Carrier Ethernet in the last few years (not including confusing definitions of what it’s supposed to be) that I decided to write an article about it. It was recently published by SearchTelecom as “Carrier Ethernet: Big picture issues for carrier deployment”.
Why are there no Untagged entries in my LFIB?
One of the readers of my “When would an MPLS LSR have Untagged output label?” post made an interesting comment:
When a loopback network is advertised as 1.1.0.0/16, it's seen as »pop tag« on the neighboring router and I can't see it in the »show mpls forwarding« printout on the local router. What's going on?
As explained in the “When would an MPLS LSR have Untagged output label?” post, the Untagged (also displayed as No label in recent IOS releases) value means that the Label Switch Router (LSR) cannot use the inbound label to decide what to do with the packet and has to perform layer-3 lookup.
True or false: MPLS VPNs offer equivalent security to Frame Relay
Years ago when vendors were pushing the MPLS story to Service Providers, an “independent analyst” wrote a report claiming that MPLS-based VPNs offer security equivalent to Frame Relay networks (to find those reports, ask Google about “MPLS security equivalent to Frame Relay”). This might be true from the functional perspective (and it’s absolutely true that using IP does not make MPLS-based VPNs inherently insecure), but anyone believing these reports might become mightily upset when learning about BGP and MPLS security issues.
Before going any further, please note that exploiting the MPLS architecture as described in All your packets are belong to us presentation requires access to the core SP network, which means that the network (or network management station) has already been successfully penetrated.
I hope you knew this already: Backbone-hacking tools
A few days ago (the) Steve Bellowin sent an e-mail to the NANOG mailing list pointing to a FUD-full article describing upcoming release of MPLS hacking tools. Christian Koch quickly pointed out a similar presentation given by the same group @ Schmoocon and numerous respondents correctly stated these are old issues … if you’re interested in BGP and MPLS security, of course. Nicolas Fischbach even provided link to a 7 year old presentation describing numerous BGP/IGP/MPLS risks and attack vectors.