CCO documentation errors & the VTP v2 transparent issue

Dear Cisco Customer,

Thank you for your recent feedback on Cisco technical documentation submitted through
the embedded feedback form. Your feedback has highlighted a potential change to our
documentation and this has formally been raised as an error with the relevant
technical documentation organization.


We look forward to your continued participation on improving our product documentation.

Thank you,

The Cisco Documentation Team

I don't know how many times you have seen the above message in your email, but i'm getting around 1 or 2 of those per month.

I belong to the category of people that fill the feedback form for every small or big "error" they come through when reading a document on CCO. It usually doesn't take more than a minute, as long as there is a working feedback form somewhere on the page. I don't even remember every feedback i submit; that's why i believe Cisco should include the customer submitted form in the answer too.

In a previous post of mine i had talked about VTP v2 in transparent mode and how it should work according to the current CCO documentation (VTP is Cisco proprietary so it's difficult to find information elsewhere).

Version-Dependent Transparent Mode — In VTP Version 1, a VTP transparent switch
inspects VTP messages for the domain name and version and forwards a message only if
the version and domain name match. Because VTP Version 2 supports only one domain,
it forwards VTP messages in transparent mode without inspecting the version and domain name.

As it proved out (check the comments on my old post; thx to Antonie for making me search it deeper), this specific CCO documentation is totally wrong (switches with VTP v2 in Transparent mode should not forward VTP updates unless the domain name matches the locally configured domain name) and a bug (CSCsi65330) has been raised a long time ago about it. This bug has been opened to correct the documentation guides for VTP v2 transparent mode behavior due to another bug (CSCea40015).

In the meanwhile, the above CCO documentation is correct when using NM-16ESW as switches, so a new bug (CSCsr22106) has been opened in order to correct this behavior too.

The first bug is waiting for many months to be fixed (still in Assigned state), while all the new documentation pages that are being added to CCO, still include the wrong description. There should be around 100 pages right now that include the above wrong description.


The answer that i got from Cisco was:

Certainly the documents currently on CCO have not been updated and even the
new ones are reflecting the same info. I apologize if this caused any
inconveniences for you, and would like to ensure that our technical
documentation team is working to get this fixed, but as if now the documents
are reflecting incorrect information.
...

About the other documentation part, I am still waiting for an official note
that would be replacing the wrong one, however it should be replaced by
something like: "Switches running VTPv2 in transparent mode only forward VTP
frames if the domain name of the VTP frame matches the locally configured
VTP domain, or the switch has an un-configured NULL VTP domain".

To be honest, i don't expect this documentation to be corrected soon. It stayed there for many months and it keeps on reproducing itself.

I also have another issue with the 802.1q tunneling documentation on CatOS, but i have a feeling that this one is going to be harder to be fixed.

What's your own experience?

Update 1 Aug 2008 : I have added a poll to the right, so you choose whether you submit feedback for documentation errors on CCO or not. If YES what is the result? If NO, why?

Update 1 Sep 2008 : These are the results of the above poll:

Minor blog redesign & advertisements addition

During the last months i have been experimenting with and doing small changes in the design of my blog, ranging from the addition of a custom Google search to the addition of today's advertisement.

Here is a summary of all of them:

• Profile details have been moved inside the profile, so they are not viewable from the main page. You have to click on "View my complete profile" in order to view them.
• A picture of me and John (Chambers, who else?) from Cisco Live 2008 has been added as a profile photo. I hope it's blurred enough, so i cannot be recognized easily. You wouldn't believe how friendly the CEO of a network giant can be.
• A custom Google search engine has been added, which includes all the blogs links shown at the right sidebar. Everyone interested can add his/her own links to this custom search engine by following the appropriate links.
• A blog list has been added, which displays the latest news/posts for each one of the blog links at the right sidebar. I'm thinking of removing the blog links at some time in the future if the blog list satisfies both needs.
• An advertisement area has been added, something different than the adsense area which is at the bottom of the right sidebar. This started when some days ago i was contacted by Mike Down of IP Expert, regarding a mutual "cooperation". I was offered some free "gifts" from IP Expert's training material in exchange of a banner of his company on my blog. I'm not generally a fan of training products that teach you the technologies, especially in a non-interactive way (that goes for all vendors), because i have the bad habit of focusing mostly on my own strengths in order to understand them, to get into them, to mess with them. That's why i usually prefer the kind of graded mock labs, so i can better evaluate my knowledge after i have acquired it using my own means (too bad i haven't found any vendor offering these for the SP track). To be honest, Mike's offer was quite generous, but it didn't fit me; at least not for the present (we had a very interesting talk about all this). Nevertheless i decided to add his company's banner on my blog, because i enjoyed all this conversation with Mike and of course you never know what the future will hold (when J.Chambers talks so eagerly about "The Power of Collaboration" in Live 2008, you'd better keep notes).
• The disclaimer at the bottom of the page has been updated to include information about 3rd party content, blog posts/comments and advertisements.
• The width of the main column (where the posts are shown) has been increased, so most IOS configuration examples can be displayed without the need to scroll left-right.
  

My next step is to finalize the css style regarding my posts, so everything has a common format. HTML/CSS isn't my best, but i like messing almost with everything.

Embedded Packet Capture - How to make routers more active

How many times where you in a need to get a remote packet capture and either ERSPAN wasn't available or the network architecture couldn't help you accomplish it easily?
How many times were you wondering what packets are being dropped in a interface or are being punted to the CPU?
Can you think of an easy way to capture traffic with source and destination on the same router?

Using EPC you can solve -quite easily- all of these issues.

Cisco IOS Embedded Packet Capture (EPC) (available in latest 12.4(20)T; Cisco says 12.2SR too, but SRC on 7200 and SRB on 7600 do not support it) is a powerful troubleshooting and tracing tool which allows network administrators to capture data packets flowing through, to, and from, a Cisco router.

It's actually a onboard packet capture facility that facilitates troubleshooting, the gathering of information on packet format, application analysis, and security. The devices become active participants in the management and operation of the network.

Generally Cisco seem to be investing a lot on this kind of active management; We see EEM get expanded release by release and new Embedded XXX features are coming often into surface on each new release. Long gone are the days of dumb passive routers; the future needs active devices (maybe "I, Robot" was sponsored by Cisco?)

Ok, back to reality...EPC now...

EPC can be used in troubleshooting scenarios where it is helpful to see the actual data being sent through, from, or to the network device. It simplifies operations by allowing the devices to become active participants in the management and operation of the network.

To capture packet data and analyze it, the following tasks need to be performed:

1) Define a capture buffer on a device
2) Define a capture point on a device
3) Associate some capture points with a capture buffer
4) Start (& stop if needed) the capture point
5) View the buffer data either locally or remotely in pcap format


1) Defining a capture buffer on a device

The Capture Buffer is where the packet data will be contained. Capture Buffers are user-named and you can define how the buffer handles the data going into it.

The available configuration offers the following options:

You can specify the size (why only 512KB?) and type of buffer: linear or circular.

• A linear buffer will stop capturing automatically when full.
• A circular buffer will continue to capture packet data (overwriting old data with newer as it fills up).

R1#monitor capture buffer EPC-BUFFER-1 ?
  circular  Circular Buffer
  ...
  linear    Linear Buffer(Default)
  ...
  size      Packet Dump buffer size (in Kbytes)


R1#monitor capture buffer EPC-BUFFER-1 size ?
  <1-512>  Buffer size in Kbytes : 512K or less (default is 256K)

The maximum number of bytes to capture per packet can be limited to save space. But why only 1024?

R1#monitor capture buffer EPC-BUFFER-1 ?
  ...
  max-size  Maximum size of element in the buffer (in bytes)
  ...


R1#monitor capture buffer EPC-BUFFER-1 max-size ?
  <68-1024>  Element size in bytes : 1024 bytes or less (default is 68 bytes)

Rate limiting can also be enabled to:

• Specify a max capture rate (in packets per second).
• Capture every "nth" packet.

Or an automatic limit criteria can be defined to:

• Stop the capture after a specified time interval.
• Stop the capture after capturing a given number of packets.

R1#monitor capture buffer EPC-BUFFER-1 limit ?
  allow-nth-pak    Allow every nth packet through
  duration         Duration of capture
  packet-count     Limit total Number of packets captured
  packets-per-sec  Limit number of packets copied per sec

Filters can also be set for packets being stored in a buffer via ACLs.

R1#monitor capture buffer EPC-BUFFER-1 ?
  ...
  filter    Configure filters

R1#monitor capture buffer EPC-BUFFER-1 filter ?
  access-list  Set access list

Two types of data are stored in a capture buffer: Meta Data and Packet Data.

Meta Data (which helps in filtering too) contains:

• A timestamp of when it is added to a buffer.
• Direction, egress or ingress.
• The switch path it captured.
• Encapsulation type corresponding to input/output interface to allow the decoding of L2.
• Offset to network_start, to facilitate the decoding of L3, if complete L2 decoders are unavailable.
• L3 protocol ID, to facilitate the decoding of L3, if complete L2 decoders are unavailable.

R1#sh monitor capture buffer EPC-BUFFER-1 filter ?
  direction         Filter output based on direction
  input-interface   Filters packet on an input interface
  l3protocol        Filter packets with specific L3 protocol
  output-interface  Filters packet on an output interface
  pak-size          Filter output based on packet size
  time              Filter packets from a specific clock time/date

The packet data starts from datagram-start and copies a minimum of the per packet capture size or datagram-size.

In our example we'll use a circular capture buffer (so it won't stop automatically), 512 Kbytes long ("size"), set to include up to 1024 bytes per packet ("max-size"). We'll call the buffer EPC-BUFFER-1.

R1#monitor capture buffer EPC-BUFFER-1 size 512 max-size 1024 circular

R1#sh monitor capture buffer all parameters
Capture buffer EPC-BUFFER-1 (circular buffer)
Buffer Size : 524288 bytes, Max Element Size : 1024 bytes, Packets : 0
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Configuration:
monitor capture buffer EPC-BUFFER-1 size 512 max-size 1024 circular

Note: The "monitor capture" commands are on exec-level, so they are not stored in the config/nvram. So, it's a nice addition that you can see them using the appropriate show commands.


2) Defining a capture point on a device

The Capture Point is a traffic transit point where the packet capture takes place. It is also identified by a user-defined name.

The following protocols are available as capture points:

• IPv4
• IPv6

And each one of them can be combined with the following forwarding methods:

• CEF
• process switching

R1#monitor capture point ?
  ...
  ip            IPv4
  ipv6          IPv6
  ...

R1#monitor capture point ip ?
  cef               IPv4 CEF
  process-switched  Process switched packets

R1#monitor capture point ipv6 ?
  cef               IPv6 CEF
  process-switched  Process switched packets

Capture points can be interface specific or include all interfaces.

R1#monitor capture point ip cef EPC-POINT-1 ?
  ...
  Async              Async interface
  BVI                Bridge-Group Virtual Interface
  Dialer             Dialer interface
  FastEthernet       FastEthernet IEEE 802.3
  Group-Async        Async Group interface
  Loopback           Loopback interface
  all                All interfaces
  ...

They can also include specific kinds of traffic like :

• Punt
• Drop
• From-us (locally generated packets) - This applies only to process switched traffic

R1#monitor capture point ip cef EPC-POINT-1 ?
  ...
  drop               Drop on any interface
  punt               Punt on any interface
  ...

R1#monitor capture point ip process-switched EPC-POINT-2 ?
  ...
  from-us  Packets originating locally
  ...

Capture points can also be specific to traffic direction:

• In (meaning capture at ingress)
• Out (meaning capture at egress)
• Both

R1#monitor capture point ip cef EPC-POINT-1 S1/0 ?
  both  capture ingress and egress
  in    capture on ingress
  out   capture on egress

R1#monitor capture point ip process-switched EPC-POINT-2 ?
  both     Inbound and outbound and packets
  ...
  in       Inbound packets
  out      Outbound packets

Note: I couldn't find the combination of process-switched traffic and an interface. Also Cisco provides an example of a combination of CEF switched traffic and local originated. Strange...

We'll use 2 capture points : One for IPv4 process switched traffic originated from the router itself and another one for IPv4 CEF switched traffic passing through S1/0 in both directions.

R1#monitor capture point ip process-switched EPC-POINT-1 from-us
R1#
*Jul 16 01:37:14.571: %BUFCAP-6-CREATE: Capture Point EPC-POINT-1 created.

R1#monitor capture point ip cef EPC-POINT-2 S1/0 both
R1#
*Jul 16 01:36:06.027: %BUFCAP-6-CREATE: Capture Point EPC-POINT-2 created.

R1#sh monitor capture point all
Status Information for Capture Point EPC-POINT-2
IPv4 CEF
Switch Path: IPv4 CEF            , Capture Buffer: None
Status : Inactive

Configuration:
monitor capture point ip cef EPC-POINT-2 Serial1/0 both

Status Information for Capture Point EPC-POINT-1
IPv4 Process
Switch Path: IPv4 Process        , Capture Buffer: None
Status : Inactive

Configuration:
monitor capture point ip process-switched EPC-POINT-1 from-us

3) Associating some capture points with a capture buffer

Association (and disassociation) are actions that can be performed in order to combine a capture point with a capture buffer. A capture point can only be associated with one capture buffer (an ACL filter can also be applied). A capture buffer can be associated with many capture points. So, a buffer can collect data from many points but a point can send data to only one buffer.

R1#monitor capture point ?
  associate     Associate capture point with capture buffer
  disassociate  Dis-associate capture point from capture buffer

Multiple packet capture points may be active on a given interface simultaneusly; i.e. BGP packets can be captured into one capture buffer and OSPF packets into another. You just have to use the filter/acl option while creating each capture buffer.

We'll associate our 2 capture points with our single capture buffer..

R1#monitor capture point associate EPC-POINT-1 EPC-BUFFER-1

R1#monitor capture point associate EPC-POINT-2 EPC-BUFFER-1

R1#sh monitor capture point all
Status Information for Capture Point EPC-POINT-2
IPv4 CEF
Switch Path: IPv4 CEF            , Capture Buffer: EPC-BUFFER-1
Status : Inactive

Configuration:
monitor capture point ip cef EPC-POINT-2 Serial1/0 both

Status Information for Capture Point EPC-POINT-1
IPv4 Process
Switch Path: IPv4 Process        , Capture Buffer: EPC-BUFFER-1
Status : Inactive

Configuration:
monitor capture point ip process-switched EPC-POINT-1 from-us

R1#sh monitor capture buffer all parameters
Capture buffer EPC-BUFFER-1 (circular buffer)
Buffer Size : 524288 bytes, Max Element Size : 1024 bytes, Packets : 0
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Name : EPC-POINT-1, Status : Inactive
Name : EPC-POINT-2, Status : Inactive
Configuration:
monitor capture buffer EPC-BUFFER-1 size 512 max-size 1024 circular
monitor capture point associate EPC-POINT-1 EPC-BUFFER-1
monitor capture point associate EPC-POINT-2 EPC-BUFFER-1

4) Starting (& stopping if needed) the capture

The creation of capture points doesn't automatically start them too. You have to do it manually for all capture points that you need to enable.

R1#monitor capture point ?
  ...
  start         Enable Capture Point
  stop          Disable Capture Point

R1#monitor capture point start ?
  WORD  Name of the Capture Point
  all   All Capture Points

R1#monitor capture point stop ?
  WORD  Name of the Capture Point
  all   All Capture Points

So everything is ready for us to start capturing. Just note that in all of our previous outputs, status was inactive. After staring them, it turns to active.

R1#monitor capture point start EPC-POINT-1
R1#
*Jul 16 01:55:13.475: %BUFCAP-6-ENABLE: Capture Point EPC-POINT-1 enabled.
R1#monitor capture point start EPC-POINT-2
R1#
*Jul 16 01:55:21.503: %BUFCAP-6-ENABLE: Capture Point EPC-POINT-2 enabl

R1#sh monitor capture point all
Status Information for Capture Point EPC-POINT-2
IPv4 CEF
Switch Path: IPv4 CEF            , Capture Buffer: EPC-BUFFER-1
Status : Active

Configuration:
monitor capture point ip cef EPC-POINT-2 Serial1/0 both

Status Information for Capture Point EPC-POINT-1
IPv4 Process
Switch Path: IPv4 Process        , Capture Buffer: EPC-BUFFER-1
Status : Active

Configuration:
monitor capture point ip process-switched EPC-POINT-1 from-us

R1#sh monitor capture buffer all parameters
Capture buffer EPC-BUFFER-1 (circular buffer)
Buffer Size : 524288 bytes, Max Element Size : 1024 bytes, Packets : 0
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Name : EPC-POINT-1, Status : Active
Name : EPC-POINT-2, Status : Active
Configuration:
monitor capture buffer EPC-BUFFER-1 size 512 max-size 1024 circular
monitor capture point associate EPC-POINT-1 EPC-BUFFER-1
monitor capture point associate EPC-POINT-2 EPC-BUFFER-1
R1#

5) Viewing the packet data either locally or remotely in pcap format

You can display the buffer contents in either an ASCII-like format (not very useful) or in HEX format (by using the "dumb" keyword at the end).

Below, you can see a ping from 9.9.9.2 (R2) to 9.9.9.1 (R1) passing through S1/0.

R2#ping 9.9.9.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 9.9.9.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/40/60 ms

Let's check the buffer contents in R1:

R1#sh monitor capture buffer EPC-BUFFER-1
02:03:02.579 UTC Jul 16 2008 : IPv4 CEF Turbo  : Se1/0 None

02:03:02.579 UTC Jul 16 2008 : IPv4 LES CEF    : Se1/0 None

02:03:02.583 UTC Jul 16 2008 : IPv4 Process    : None Se1/0

02:03:02.663 UTC Jul 16 2008 : IPv4 CEF Turbo  : Se1/0 None

02:03:02.663 UTC Jul 16 2008 : IPv4 LES CEF    : Se1/0 None

02:03:02.663 UTC Jul 16 2008 : IPv4 Process    : None Se1/0

02:03:02.683 UTC Jul 16 2008 : IPv4 CEF Turbo  : Se1/0 None

02:03:02.683 UTC Jul 16 2008 : IPv4 LES CEF    : Se1/0 None

02:03:02.683 UTC Jul 16 2008 : IPv4 Process    : None Se1/0

02:03:02.719 UTC Jul 16 2008 : IPv4 CEF Turbo  : Se1/0 None

02:03:02.719 UTC Jul 16 2008 : IPv4 LES CEF    : Se1/0 None

02:03:02.719 UTC Jul 16 2008 : IPv4 Process    : None Se1/0

02:03:02.735 UTC Jul 16 2008 : IPv4 CEF Turbo  : Se1/0 None

02:03:02.735 UTC Jul 16 2008 : IPv4 LES CEF    : Se1/0 None

02:03:02.735 UTC Jul 16 2008 : IPv4 Process    : None Se1/0
...

R1#sh monitor capture buffer EPC-BUFFER-1 dump
02:03:02.579 UTC Jul 16 2008 : IPv4 CEF Turbo  : Se1/0 None

6771C8A0: 0F000800 45000064 00000000 FE019884  ....E..d....~...
6771C8B0: 09090902 09090901 08008E62 00000000  ...........b....
6771C8C0: 00000000 0003EFE4 ABCDABCD ABCDABCD  ......od+M+M+M+M
6771C8D0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD  +M+M+M+M+M+M+M+M
6771C8E0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD  +M+M+M+M+M+M+M+M
6771C8F0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD  +M+M+M+M+M+M+M+M
6771C900: ABCDABCD ABCDABCD 00                 +M+M+M+M.

02:03:02.579 UTC Jul 16 2008 : IPv4 LES CEF    : Se1/0 None

6771C8A0: 0F000800 45000064 00000000 FE019884  ....E..d....~...
6771C8B0: 09090902 09090901 08008E62 00000000  ...........b....
6771C8C0: 00000000 0003EFE4 ABCDABCD ABCDABCD  ......od+M+M+M+M
6771C8D0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD  +M+M+M+M+M+M+M+M
6771C8E0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD  +M+M+M+M+M+M+M+M
6771C8F0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD  +M+M+M+M+M+M+M+M
6771C900: ABCDABCD ABCDABCD 00                 +M+M+M+M.
...

Analyzing the first part we get the following for the header :

0F000800 45000064 00000000 FE019884

0F00 = Cisco HDLC, Address: Unicast (0x0f)
0800 = Protocol: IP (0x0800)
45   = 0100 0101 = IP v4
00   = TOS/DSCP 0x00
0064 = Total Length: 100
01   = Protocol: ICMP (0x01)

09090902 09090901 08008E62 00000000

09090902 = Source 9.9.9.2
09090901 = Destination 9.9.9.1
08       = Type: 8 (Echo (ping) request)
00       = Code: 0

Now, if we send 36 bytes ICMP packets, we can see the difference:

R2#ping 9.9.9.1 size 36

Type escape sequence to abort.
Sending 5, 36-byte ICMP Echos to 9.9.9.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/32/48 ms

We check again the buffer contents:

R1#sh monitor capture buffer EPC-BUFFER-1 dump
02:30:47.419 UTC Jul 16 2008 : IPv4 Process    : None Se1/0

6771C8A0: 0F000800 45000024 000A0000 FF0197BA  ....E..$.......:
6771C8B0: 09090901 09090902 0000A8C4 00020000  ..........(D....
6771C8C0: 00000000 001D571C 00                 ......W..

02:30:47.491 UTC Jul 16 2008 : IPv4 Process    : None Se1/0

6771C8A0: 0F000800 45000024 000B0000 FF0197B9  ....E..$.......9
6771C8B0: 09090901 09090902 0000A88F 00020001  ..........(.....
6771C8C0: 00000000 001D5750 00                 ......WP.

And analyze again the header:

0F000800 45000024 000A0000 FF0197BA

0F00 = Cisco HDLC, Address: Unicast (0x0f)
0800 = Protocol: IP (0x0800)
45   = 0100 0101 = IP v4
00   = TOS/DSCP 0x00
0024 = Total Length: 36
01   = Protocol: ICMP (0x01)

You can also export the buffer contents to an external location in the pcap format. Then you can use Wireshark to examine them more thoroughly.

R1#monitor capture buffer EPC-BUFFER-1 export ?
  ftp:    Location to dump buffer
  http:   Location to dump buffer
  https:  Location to dump buffer
  pram:   Location to dump buffer
  rcp:    Location to dump buffer
  scp:    Location to dump buffer
  tftp:   Location to dump buffer

PS: Btw, you can find a lot of sample pcap files in Jeremy's excellent site, PacketLife.


Generally, EPC provides the following :

• Ability to capture IPv4 and IPv6 packets in the Cisco Express Forwarding path
• A flexible method for specifying the capture buffer size and type
• EXEC-level commands to start and stop the capture
• Show commands to display packet contents on the device
• Facility to export the Packet Capture in PCAP format suitable for analysis using an external tool such as Wireshark
• Extensible infrastructure for enabling packet capture points


Another hooray for Cisco!!!

There seem to be some inconsistencies on this release of EPC plus some without-obvious-reason limitations, but i hope newer releases will improve its functionality (an extra option showing the basic fields of the packet header in understandable format would be a welcome addition). We needed it and we welcome it!.

Object Groups for ACLs - At last!

If someone was telling you that's it's possible to enable the following communication using an access-list (ACL) with only 5 ACL entries (ACEs), you would probably laugh!

hosts 10.10.10.1, 20.10.20.1, 30.10.30.1 40.10.40.1 should be able to telnet to any host
hosts 10.10.10.1, 20.10.20.1, 30.10.30.1 40.10.40.1 should be able send mail
hosts 10.10.10.1, 20.10.20.1, 30.10.30.1 40.10.40.1 should be able to ping anyone
hosts 10.10.10.1, 20.10.20.1, 30.10.30.1 40.10.40.1 should be able to send tcp/udp packets at ports 1000-2000

hosts in the range 10.20.20.1 10.20.20.20 should be able to telnet to any host
hosts in the range 10.20.20.1 10.20.20.20 should be able send mail
hosts in the range 10.20.20.1 10.20.20.20 should be able to ping anyone
hosts in the range 10.20.20.1 10.20.20.20 should be able to send tcp/udp packets at ports 1000-2000

hosts in the network 10.30.30.0 255.255.0.0 should be able to telnet to any host
hosts in the network 10.30.30.0 255.255.0.0 should be able send mail
hosts in the network 10.30.30.0 255.255.0.0 should be able to ping anyone
hosts in the network 10.30.30.0 255.255.0.0 should be able to send tcp/udp packets at ports 1000-2000

everything else should be denied


The conventional way of accomplishing the above would probably include around 30-40 ACEs (by aggregating some hosts and possibly using more than 1 ports at the same ACE) and a lot of copy/edit/paste, but you'll never be able to make it using only 5 entries.

You don't want to imagine what would happen if instead of "any" as destination you had another group of host/ranges/networks.

Welcome to ACL Object Groups (or object group-based ACLs); a new -much requested- feature of IOS, available in latest 12.4(20)T.

The Object Groups for ACLs feature lets you classify users, devices, or protocols into groups and apply them to access control lists (ACLs) in order to create access control policies for those groups. This feature lets you use object groups instead of individual IP addresses, protocols, and ports, which are used in conventional ACLs. It also allows multiple access control entries (ACEs), but now you can use each ACE to allow an entire group of users to access a group of servers (or services) or to deny them from doing so.

These are the main characteristics of ACL Object Groups:

1) Ease security-policy management by introducing level of abstraction in security policies
2) Classifies users/devices/applications into groups allowing you to apply policies based on the group classification
3) Allows use of group names in ACEs instead of IP addresses and protocol ports - reduces configuration size


Back to our example and let the fun begin....

Using Network Object Groups you can decrease the number of ACEs to just 5:

object-group network ACL-OGN
description ** Object Group Network **
 host 10.10.10.1
 host 20.10.20.1
 host 30.10.30.1
 host 40.10.40.1
 range 10.20.20.1 10.20.20.20
 10.30.30.0 255.255.0.0
!
ip access-list extended ACL-1
 permit tcp object-group ACL-OGN any eq telnet
 permit tcp object-group ACL-OGN any eq smtp
 permit icmp object-group ACL-OGN any echo
 permit tcp object-group ACL-OGN any range 1000 2000
 permit udp object-group ACL-OGN any range 1000 2000

A network object group is a group of any of the following objects:

• Single IPs or Hostnames
• Subnets
• Ranges of IP addresses
• Other network object groups (nested object groups)

A conventional ACE could allow a group of users to have access only to a specific group of servers. In an object group-based ACL, you can create a single ACE that uses an object group name instead of creating many ACEs (which would require each one to have a different IP address/range/network). These ACEs can have object groups for the source only, destination only, none, or both.


Ok, let's push it a little more. What about if someone was telling you that's it's possible to enable the above communication using an access-list with only 1 entry? Still listening?

Using Network and Service Object Groups you can decrease the number of ACEs to just 1:

object-group network ACL-OGN
 description ** Object Group Network **
 host 10.10.10.1
 host 20.10.20.1
 host 30.10.30.1
 host 40.10.40.1
 range 10.20.20.1 10.20.20.20
 10.30.30.0 255.255.0.0
!
object-group service ACL-OGS
 description ** Object Group Service **
 tcp eq telnet
 tcp eq smtp
 icmp echo
 tcp-udp range 1000 2000
!
ip access-list extended ACL-2
 permit object-group ACL-OGS object-group ACL-OGN any

A service object group is a group of any of the following objects:

• Source and destination protocol ports (such as Telnet, SMTP, etc.)
• ICMP types (such as echo, echo-reply, etc.)
• Top-level protocols (such as TCP, UDP, ESP, OSPF, etc.)
• Other service object groups (nested object groups)

This is another object group (imagine it like a protocol/service port group) that can be extended to provide access only to a set of applications for a user group to a server group.


The general idea of ACL Object-Groups is "define access from user-group A to X services of server-group B".

ip access-list extended ACL-1
 permit IP object-group user-grp object-group serv-grp

ip access-list extended ACL-2
 permit object-group apps-grp object-group user-grp object-group serv-grp

Where:
apps-grp = application ports (Service Object Group)
user-grp = user (client) IP addresses (Network Object Group)
serv-grp = server IP addresses (Network Object Group)


Generally, you can use ACL Object-Groups with QoS match criteria, Cisco IOS Firewall and many other features that use extended ACLs. I think you understand the unlimited new prospects.

According to Cisco, when there are many inbound and outbound packets, using object group-based ACLs increases performance when compared to conventional ACLs (probably a faster lookup happens?). Also, in large configurations, this feature reduces the storage needed in NVRAM, because using object groups in ACEs means that you do not need to define an individual ACE for every address-protocol pair.


Note 1 : An ACE that you define using a group name is equivalent to multiple conventional ACEs (one applied to each entry in the object group). The router expands automatically the object group-based ACL ACE into multiple ACEs (one ACE for each entry in the group) and populates the ACEs in the TCAM of the router. Therefore, the Object Groups for ACLs feature reduces the number of entries that you need to configure, but it does not reduce TCAM usage. So, you might want to be careful when configuring this on HW switching platforms.

Note 2 : Ranges under Network Object Groups don't seem to work as described (i'm still investigating this). Also i couldn't find any command that displays the expanded ACL, although on CCO there is such an output using "sh ip access-list" (probably a bug?).


So next time you're asked a similar question, give them a surprise!

Cisco Live 2008

It has been almost 1 week since i returned from Cisco Live (Networkers) in Orlando and since i enjoyed Michael's report card about it, i decided to use something similar in order to describe (and grade) my experience.

Category    Grade  Comments
------------------------------------------------------------------
Hotels        B+   I stayed at a non-Cisco hotel, but it was good
                   for its price. It was also only 10 mins walk 
                   from the Convention Center.

Buses         -    I didn't use them. Maybe Cisco should think 
                   to support other hotels too for its bus routes.

Conference    A-   Excellent Convention Center! 
Center             Large area, many session rooms, impressive 
                   keynote rooms, lunch area was more than enough.
 
Training      B    I tried to follow 2 categories : 
                   Carrier/Metro, MPLS/VPLS
                   While you could clearly understand that 
                   most of the presenters were experts in their area, 
                   some of them were talking too fast 
                   or were speaking english in a strange way.
                   Also i would prefer to have less sessions
                   overlapping each other and some sessions
                   should have been longer.
                   On the other hand, techtorial was very good 
                   and detailed.
 
Meet the      B-   It was interesting to see some of the top engineers
Experts            together (+ famous Ian from c-nsp), but i was 
Session            disappointed by the session's limited time.
                   C'mon Cisco!!! Only 50 mins?

Meet the      A    I arranged two of them and both went very well.
Engineer           I was able to find solutions in some interesting
Sessions           problems of our network and i was happy to meet an
                   old friend of mine (hi Yves :).

Food          C-   Techtorial-day lunch was too cheap,
                   breakfast could have been better
                   (i was lucky to have my hotel's too).
                   Lunch was ok and desert at WoS was fine.

Snacks        D-   Not something you would enjoy. It was good to 
                   have them, but a bigger variety would be better.
                   Also i couldn't find any fresh juice.
                   At least there was some ice-cream the last day.

On-Site Help  A    Helpful staff, there were everywhere, 
                   answered most of my questions.
                   If only their ages were smaller, 
                   i would have it enjoyed better :p

Cisco Store   B-   Too expensive! Also there weren't many sizes 
                   (regarding clothes) available. The bag that was
                   given for free (for >$150 buys) could have been
                   better.
    
Conference    A    Excellent! Although a little bit heavy, 
Bags               it had everything i needed for my daily carrying
                   needs.

Internet      B    Everything i needed was there.
Access             Maybe a little bit slow sometimes
                   especially when watching streaming video.

World of      C+   Too many vendors, too many people.
Solutions          Guitar hero was annoying for nearby vendors.
                   CCBootCamp, Emulex and Qumu were very HOT!!! 

Food at WoS   B+   Desert was great, food could have been better.

Certification B+   Nice room, but a little bit cold in the morning.
Lounge             The exam procedure was quick 'n' easy and 
                   some of the girls were extremely friendly!

Chambers      A+   Excellent speech by John Chambers, 
Keynote            nice iPhone video-call demonstration 
                   (since when does a Cisco iPhone exist?).
                   I really enjoyed that John was walking around us 
                   and talking almost directly to our faces.
                   Human network, human communication was the key.

CCIE Party    B+   It was my first CCIE party and it was good.
                   I still can't believe i meet some fellows 
                   that read my blog.

Warrior's     B-   If i'm right, this was Warrior's first public
Keynote            appearance on her new role and it went well.
                   Some topics weren't of my interest, but it 
                   was nice to get a general idea about everything.

Conference    B-   The party at Universal was generally better
Party              than expected.
                   Blue man show was incredible but very short
                   (although nobody informed us that we were 
                   going to need tickets), live shows were just 
                   interesting (not my kind of music).
                   Food and drinks were above average.
                   I was disappointed by its limited time availability,
                   because you probably needed double the time 
                   to see and enjoy everything.
                   The CCIE hat (cowboy style) was given as a present 
                   to Amanda for her beautiful blue eyes!

Overall       A-   One of the greatest networking events i have 
                   been to. It was my first time in the USA, 
                   but if i want to compare it to the European ones, 
                   i would say it was much better.

Cisco Exam Price Update as of June 24, 2008

In case you didn't notice it, there has been an increase in the price of Cisco written exams.

Some interesting facts about it, taken from certification online support:

Q. What exactly is the price adjustment being made at this time?
A. As of June 24, 2008, the price of the CCNA comprehensive exam #640-802, the single exam option for achieving CCNA certification, will be $250 USD, the professional-level Composite exam #642-892, will be $300 USD and the CCIE written exams will be $350 USD or the local currency equivalent in all regions. All other exam prices still apply. For more information, contact Pearson VUE at www.pearsonvue.com/cisco.

Q. Will the price be adjusted in all worldwide locations?
A. Yes, the price will be adjusted in all regions. Cisco Certified Learning Partners in some areas may include the exam along with a training course for a single price.

Q. How can I find out the local currency price for exams?
A. All prices cited are in U.S. dollars. For details about local currency pricing in the country where you take an exam, contact Cisco’s authorized test delivery partner, Pearson VUE.

Q. Will the price to Networking Academy students also be changed?
A. Consistent with our past years strategy, Cisco will provide financial assistance to Cisco Networking Academy students in the form of discounts to help defray the cost of key certification exams.

Q. Will the price increase impact the Cisco CA employee discount?
A. CA employee voucher program will not change ($50USD).

Q. Why is the price being adjusted at this time?
A. Our market analysis indicates the price of these exams are out of line with the market value it provides and with other IT certification exams at the Associate, Professional and Expert level. Cisco Career Certifications is one of the industry's most recognizable and highly valued programs for IT professionals. Achieving either a CCNA, Professional or Expert certification validates knowledge and hands-on skill with the world's leading networking solutions.


I read almost 10 times the last QA, but i couldn't think of any no-money-included relationship between exam price and exam market value. Does a higher priced exam (alone by itself) make it a higher valued exam?

CCIP completed

After 40 days of hard preparation (there were times i was feeling more exhausted than the days of my CCIE preparation) for the MPLS exam, i finished my CCIP certification. The MPLS exam was the most difficult, because it was almost new to me, besides some basic theory which i already knew (and 2-3 labs on my dynamips setup). So i had to spend a lot of time on understanding the concepts behind it, creating various L2/L3 VPN scenarios and experimenting with TE. BGP & QoS were like a review of my recent CCIE plus some extra (more detailed) information.

CCIP
Start day: 1 Feb 2008 (12 days after my CCIE; would you believe that? i still don't)

• 642-901 (BCSI): 4 Jan 2007 (from CCNP)
• 642-642 (QOS): 6 Feb 2008
• 642-661 (BGP): 9 May 2008
• 642-611 (MPLS): 22 Jun 2006

End day: 22 Jun 2008

I'm thinking of publishing on my blog some MPLS tutorials for "dummies" (like myself) in the near future, based on my last month's intensive reading/writing/experimenting. I don't consider myself an expert in (M|V)PLS, but i have gathered some nice info while preparing for the CCIP/MPLS exam. Also Networkers 2008 in Orlando was a major source of information.

But first i have to pass the CCIE SP written exam (hopefully before the end of this summer), because i'm planning (and hoping) to book for a 2008 lab date (will another 3 months be enough for a new CCIE certification???). Or maybe i'll have to wait a little more; until Cisco decides to retire that ugly looking plaque :p

Inform Cisco of your disappointment regarding the new CCIE plaque

This is the email i had sent some months ago to Abby Douglas (adouglas AT cisco.com), Certification Program Manager (Customer Advocacy), regarding the new CCIE plaque.

If you're also disappointed by the new CCIE plaque (like Arden Packeer is), you should probably do the same.


Dear Abby,

I'm writing this email because i feel very disappointed by the new CCIE plaque.
I received mine 1 week ago and i must say i didn't expect it to be so cheap.

It seems like a simple plastic frame with a printed paper inside it. Something that i could possibly buy on the nearby gift shop for less than $10. I don't know based on what criteria you have chosen this new design, but it's the worst ever. It doesn't even resemble a plaque.

Let me remind you what's written on the CCIE page (http://www.cisco.com/web/learning/le3/ccie/certified_ccies/index.html):

"CCIE Plaque and Certificate
As an official CCIE, you will receive an engraved plaque and certificate, shipped to the address listed in your profile within 10-12 weeks. Please make sure your contact information is up-to-date."

The words "engraved plaque" point to something else, something better than a "plastic frame with a printed paper inside it".

I remember the first plaque, the one with the medallion and the wooden frame and i envy it.
I tried to contact Brandvia in order to buy one, but they said that they're not allowed to do so because Cisco changed its logo and they are no longer authorized to make the old style plaque.

Even the previous plaque, the crystal inscribed one, was better than the last one. It's like every year or so, you're making the CCIE plaque worse. It's a shame that the plaque for one of the best certifications out there (if that's what you want CCIE to be) seems so cheap. Even Juniper is said to create a much better looking "lead-crystal desk thing engraved with the logo and your name/number/date".

Please have a second though and try to redesign it. If the cost is the reason (which seems strange if we think of the recent price increase of the CCIE Lab), you can create a better-looking plaque and sell it as an extra.

Otherwise you'd better correct the CCIE page and replace "engraved plaque" with something more appropriate. You don't want to lie to your candidates.


Best Regards
XXX
CCIE #19858


PS: You should probably do not expect an answer; I never got one...


Update : 4 Jul 2008

I found out the following in the certification tracking tool:
"Plaques - Cost is $100 USD (shipping not included). Only available for CCIE certifications. Please allow 4 weeks for processing and 10 business days for shipping via FedEx."

$100 for this plaque? They must be kidding!!!!