CCDE Topic: docs I found useful

CCDE Topic: docs I found useful

Step One: the written (read this even if you already passed!)

I found the written outline to be the most useful preparation not only for the written exam, but also the practical.  I went through all of the topics outlined and made sure I understood exactly what they were trying to get at.  Honestly, there were a number of items I had never heard of, so doing the research felt like I was accomplishing something.  I’ve posted a few of the written items on this blog, like What is the issue with re-marking and OoO packets? and What is fate sharing, and what is its impact?.

If you want to see more about the security portion of the written outline, be sure to check out this post too.

In case you can’t tell, I’m saying that even if you passed the written easily, you probably want to go back & make sure you understand everything that’s covered on the outline.

Step Two: the practical

This is the difficult part, but I’ll try to give a summary of what I found most useful for me.  Of course, you may already be an expert in one of these topics and won’t need to review it (but you probably should anyway).


High Availability Campus Network Design–Routed Access Layer using EIGRP or OSPF

Enterprise QoS Solution Reference Network Design

RFCs (in no particular order):

Multicast RFC1112


If you have access to the Partner Education Connection you’re in luck.  If not, your best bet is to check out elementK.  Your company may already have a subscription.  I’m sure there are others with equivalent training, but I’m speaking specifically about the path I took.

I took the online MPLS SE training, reviewed the Multicast training, and reviewed the EIGRP training.

I’ll go into the specific courses in a later post, as well as a book listing & the Cisco Live / Networkers materials I found useful.

What is the issue with re-marking and OoO packets?

This question, taken from the CCDE Written Outline, taught me something new. Since that’s the purpose of any certification, I welcome these interesting, if somewhat vague, questions.

The main issue with re-marking and Out-of-Order packets can be found in RFC3819: (aka BCP89)

reordering does come at a cost with TCP as it is currently defined. Because TCP returns a cumulative acknowledgment (ACK) indicating the last in-order segment that has arrived, out-of-order segments cause a TCP receiver to transmit a duplicate acknowledgment. When the TCP sender notices three duplicate acknowledgments, it assumes that a segment was dropped by the network and uses the fast retransmit algorithm [Jac90] [RFC 2581] to resend the segment. In addition, the congestion window is reduced by half, effectively halving TCP’s sending rate. If a subnetwork reorders segments significantly such that three duplicate ACKs are generated, the TCP sender needlessly reduces the congestion window and performance suffers.”

In English, this means that if your Service Provider is doing any sort of re-marking (with a traffic policer, for example) your TCP flows may suffer due to re-ordering within the network. Let’s say your SP provides a subrate Ethernet attachment circuit to you at 10Mbps. You’re permitted to go over this rate but your traffic will be classified as less-than-best-effort (COS=1). You begin transmitting a large PDF via FTP. Once your flow goes over the committed rate, it was remarked to COS=1. Next, those packets are delayed within the core through a shaping mechanism (realizing that in the real world, less-than-best-effort would most likely be policed). Anyhow, the packets are delivered out-of-order due to this shaping policy. Meanwhile, the TCP session established by FTP notices segments are arriving out-of-order and performs the fast retransmit algorithm. This causes your FTP transfer to slow down during the transfer.

Now that we know this, how will it influence our design?

The first and most obvious result would be to configure an outbound shaping policy to match the SP’s subrate Ethernet AC. In general, reordering is not something that we can design for, as once we hand-off the packet to the provider we cannot control the path it takes. Within our own network, we can reduce the number of paths a packet takes by using traffic engineering or reducing the number of equal-cost links. Within Cisco devices, CEF attempts to ensure the same path is taken by using a hash of the socket information. This is one of the reasons equal-cost paths may not show equal utilization.

CCDE Written Outline Topic 5 : Security

Topic 5 : Security is not fleshed out as far as the other four topics, so I thought I would tackle it first.

  • Explain the impact of security availability design in the characteristics of a network.What does this mean? Let’s dig into the subtopics and see if we can find an explanation.
    • OOB Access – out-of-band access to devices. If your network goes down or if a device is unreachable, you may need some way of remotely logging into the device. A good example would be a modem connected to the AUX port on a router.
    • Decoupling – This probably refers to the separation of control/data planes in routed networks.
    • Paul Baran Model – according to Wikipedia, Paul was one of the thought leaders in distributed networking as an answer to reliability. Building networks that could withstand nuclear attack, etc.. This shows some mathematical rigor for communications networks.
    • Compartmentalization – this probably relates to Schneier’s book Beyond Fear where he states that:

      All systems have a weakest link, and there are several general strategies for securing systems despite their vulnerabilities. Defense in depth ensures that no single vulnerability can compromise security. Compartmentalization ensures that a single vulnerability cannot compromise security entirely. And choke points reduce the number of potential vulnerabilities by allowing the defender to concentrate his defenses. In general, tried and true countermeasures are preferable to innovations, and simpler overlapping countermeasures are preferable to highly complex stand-alone systems. However, because attackers inevitably develop new attacks, reassessment and innovation must be ongoing.

I’m a huge fan of Bruce Schneier. I highly recommend crypto-gram and Beyond Fear.

Another issue Schneier talks about is ‘brittleness’:

Brittleness refers to the way a system fails. Microsoft Windows is a brittle system. A small insecurity breaks the entire system, and often the entire network. The credit-card system is resilient. It can tolerate all sorts of insecurities and still work profitably.

  • Use available tools in a network security design to address identity, monitoring and correlation aspects.
    • SNMP: This falls under the ‘monitoring’ requirement. Keep in mind that SNMP is by default not very secure, and you should be using SNMPv3 if at all possible.
    • NetFlow: You can use records generated by NetFlow to look for all sorts of security events in your network. Normally the data generated is too much and you’ll have to use a third party tool to analyze it. NetFlow uses port 9996/udp by default so designing a system that can accept all of the NetFlow records without dropping is essential if you’re to use it for auditing.
    • Syslog: Obviously, syslog is something you should have enabled in your network. It runs on udp as well, so all the usual udp rules apply. It’s also unencrypted by default.
    • RMON: I’ve not used much RMON in the past, but this falls under application classification/utilization. Third-party tools are best for RMON probes and analysis.
    • DNS: DNS can help to correlate – if for example all of your routers and switches are in DNS and you source records like Syslog and NetFlow, if you have everything defined to do so the IP addresses will resolve in your logs/reports.
    • Radius/AAA: Authentication/Authorization/Accounting is a requirement for any large-scale network. You’ll have to audit the logs for events in this as well.
    • Full Packet Classifiers: They probably refer to NBAR (network based application recognition). It is a tool built in to the routers and switches that will classify your application based on its behavior. It can, for example, classify P2P applications. It does increase the load on your infrastructure, so be careful when implementing it. NBAR can be used to classify and then police/shape applications like P2P, etc.
  • Explain the impact of control plane design decisions on the security of a network; implement security mechanisms to protect the control plane.
    • Use and impact of addressing: This may refer to the concept of infrastructure hiding, where you assign addresses to your devices that are unreachable from outside your network. You could assign all RFC1918 addresses to your loopbacks and refuse to NAT/advertise these networks. This does not automatically hide the infrastructure addresses from your internal users and devices, so you would have to apply inbound filters to prevent access. You can use control-plane policing for this (COPP)
    • Use and impact of area (flooding domain/summary points) placement.
    • Route/Topology/Link Hiding
    • Adjacency Protection (MD5, GTSM, etc.): you should be using MD5 to authenticate links between adjacent neighbors. All of the major dynamic routing protocols support MD5. GTSM stands for Generic TTL Security Mechanism. Defined in RFC3682, it outlines the use of the TTL as a way to ensure your updates are coming from directly-attached neighbors. If you receive an update with a TTL <>
    • Route Validation: probably a manual process, anyone have any ideas?
    • Route Filtering: filter updates from your neighbors that you don’t want. Or just allow those that you do want.
    • Routing Plan: You need to know where your packets will route in steady state.
    • Other routing techniques: unsure of what they mean here.
  • Explain the impact of data plane design decisions on the security of a network; implement security mechanisms to protect the data plane.
    • Infrastructure Protection: Think COPP
    • Policy Enforcement (QoS, BCP38): Probably just want to read BCP38
  • Prepare and explain security incident preparation and response strategies in a network.
    • Reaction Tools (Identification and Classification): IDS/IPS
    • Traceback Tools: not Cisco tracebacks, look here.
    • Remotely-Triggered Black Holes (RTBH) (destination, source, rate limit, etc.): good whitepaper here.
    • Sink Holes: paper here.
    • Reactive ACLs: this may refer to installation of ACLs by a third-party IDS/IPS tool.