Archive for April, 2009
No matter what your opinion is on the new Core Knowledge section of the Route/Switch CCIE Lab Exam, everyone agrees that it is a section that we cannot take lightly. After all, miss 2 out of 4 questions because you did not read closely enough or you misinterpreted a phrasing, and your entire exam day just got a lot worse.
While all of our Route/Switch products here at Internetwork Expert can help to varying degrees with the Core Knowledge section, there are two products we developed that help tackle this section head on. The first, and most obvious, is the Core Knowledge Simulation product. This product features a 4,20, or 40 random question quiz option, and an Answer Key option that provides critical More Information links for all questions. This product links to the documents that Cisco loves to compose questions from. If you would like to test drive the 4 question random quiz option, simply click here.
Another product that addresses Core Knowledge prep head on is the brand new CCIE R/S Written Bootcamp. This product allows students to review the very core concepts that makeup this section. EVERY lesson of the course contains Core Knowledge question practice. These sample Core Knowledge questions are not duplicated in any other course materials. To test drive this product, click here.
As always, enjoy your studies, and please, don’t forget your Core Knowledge!
the new section has been posted and should appear under every account subscribed to IEWB-RS VOL1 v5.0. This is an initial update, containing the following 35 technology-focused labs:
Establishing iBGP Peerings
Establishing EBGP Peerings
BGP Update Source Modification
Multihop EBGP Peerings
Authenticating BGP Peerings
iBGP Route Reflection
Large Scale iBGP Route Reflection with Clusters
BGP Next-Hop Processing – Next-Hop-Self
BGP Next-Hop Processing – Manual Modification
BGP over GRE
BGP Redistribute Internal
BGP Peer Groups
BGP Network Statement
BGP Bestpath Selection – Weight
BGP Bestpath Selection – Local Preference
BGP Bestpath Selection – AS-Path Prepending
BGP Bestpath Selection – Origin
BGP Bestpath Selection – MED
BGP Bestpath Selection – Always Compare MED
BGP Bestpath Selection – AS-Path Ignore
BGP Bestpath Selection – Router-IDs
BGP Bestpath Selection – DMZ Link Bandwidth
BGP Bestpath Selection – Maximum AS Limit
BGP Aggregation – Summary Only
BGP Aggregation – Suppress Map
BGP Aggregation – Unsuppress Map
BGP Aggregation – AS-Set
BGP Aggregation – Attribute-Map
There are still approximately the same amount of labs to come soon. The list of additional labs includes the following:
The latest version of the R/S Core Knowledge Simulation released today.
This new version includes the use of Self Graded questions in order to allow the product to more closely simulate the actual Lab Exam Core Knowledge section.
Here is a sample of a four question quiz from the prouct:
The product also includes:
- 20 Question Random Quiz
- 40 Question Random Quiz
- Answer Key Version with critical More Information links and Instructor Tips
we have just uploaded the initial update of IEWB-SC VOL1 “VPN” section to all subscribed accounts. The update contains 15 new labs listed below:
LAN-to-LAN VPN between IOS and ASA
IPsec and NAT Interaction in ASA Firewall
Peer Authentication using Digital Signatures
ASA Tunnel Group Names
ASA Certificate Mapping Rules
Filtering traffic inside LAN-to-LAN tunnels
LAN-to-LAN tunnel between IOS Routers
IOS IPsec NAT Traversal
IOS IKE Aggressive Mode
VPN between Overlapping Subnets
IOS VPN with Digital Signatures Authentication
IOS Certificate Access Lists
Virtual Tunnel Interfaces
GRE over IPsec
The following labs are in process of being developed should be available soon. Notice that there might be more labs than currently are on the list.
IOS ezVPN Server
IOS ezVPN Server with RADIUS
IOS ezVPN Server with Digital Certificates
IOS ezVPN Remote
ASA ezVPN Server
ASA ezVPN Server with RADIUS
ASA ezVPN Server with Digital Certificates
IOS Clientless SSL VPN
IOS SSL VPN
ASA SSL VPN
ASA Clientless SSL VPN
ASA L2TP over IPsec
IPSec High Availability
The next thing you guys would see updated is the long-awaited IEWB-RS VOL1 v5.0 “BGP” section
I have received tons of requests to make the self-paced Class On Demand version of the new CCIE R/S Written Bootcamp available as soon as possible. I think the main reason is that many students want to refresh on written knowledge is the new Core Knowledge section of the exam. I am pleased to announce the release schedule of this new course, and the fact that it will be available later this week! This course will be available as an ADD ON for existing CCIE 2.0 customers. This means those folks can receive it at an incredible discount. Enjoy!
- Module 1 General Networking Theory available the week of April 20
- Module 2 LAN Switching available the week of April 27
- Module 3 IP available the week of May 11
- Module 4 IP Routing available the week of May 18
- Module 5 QoS available the week of May 25
- Module 6 WAN available the week of June 1
- Module 7 IP Multicast available the week of June 8
- Module 8 Security available the week of June 15
- Module 9 MPLS and Module 10 IPv6 available the week of June 29
One of the challenges inherint in the CCIE Lab Exam is the fact that you are really, really pressed for time. You simply cannot afford to spend too much time on any one task, since you have such a shortage of time overall.
One of the keys to my success was using a Skipped Task Tracker where I would record any non-core tasks that I might struggle with and that I decided to skip until the end of the day. After all, as the day draws to a close, you have a much better idea of how much time you have to spare.
General Logic Overview
When establishing a VPN tunnel, ASA firewall matches tunnel-group names based on the following criteria list:
1) Using the IKE ID presented by the remote peer. It may be an IP address (default) or hostname. In some cases this might be an ezVPN group name, for example when you are using Cisco ezVPN client or ezVPN Remote feature.
2) Using the OU (Organization Unit) field from the DN found in digital certificate presented by the peer OR by using the certificate mapping rules. This only works when ISAKMP phase uses digital signatures for authentication. Certificate mapping rules translate the DN (distinguished name) found in the certificate to the tunnel-group name.
3) Using the remote endpoint’s IP address. It’s the last resort rule, and this is the only way to match the identity with PSK (pre-shared keys) and IKE Main Mode.
Recall that IKE uses either of two modes of operation for Phase 1: Main Mode (default) and Aggressive Mode:
a) Main Mode (MM), which is mandatory per the RFC – creates an encrypted channel before exchanging the identities.
b) Aggressive Mode (AM), which is quicker than Main Mode, exchanges endpoint IDs in “clear text”, while performing DH (Diffie Hellman) exchange and establishing the secure channel. AM is less secure than MM is thus should be less preferred. However, there are some properties that make AM uniquely useful.
IKE MM with PSK
There are some important consequences of MM behavior, when implementing authentication based on pre-shared keys (PSK). When pre-shared keys are used for authentication, they are also used to generate the shared encryption key for ISAKMP SA (along with the DH generated key). This feature is very important to prevent man-in-the middle attacks. When ISAKMP responder receives a MM proposal from initiator and choses authentication based on pre-shared keys, it should generate the shared encryption key. This procedure requires knowing the PSK of the remote peer in advance. However, the responder does NOT know the IKE ID of the initiator yet, only its IP address. Therefore, the only way to select the proper pre-shared key in MM is by looking the key in the database based on the initiator’s IP address. Even if you use of hostnames for IKE IDs with PSK authentication, the keys and tunnel-group names are still matched based on the IP addresses. This is the unique “feature” of ISAKMP MM with PSK.
IKE MM with digital signatures
Now consider the case when you are using IKE MM along with digital signatures (RSA sigs) authentication. In this situation, session encryption key is not derived based on the pre-shared authentication key. Thus, the respondent that accepts the policy based on digital signatures may delay the proper tunnel-group selection until it learns the IKE ID of the initiator. More than that, it may use the information from the DN field of the digital certificate presented by the initiator for more detailed matching. With the default configuration, the subject’s OU field in the certificate is used to match the tunnel group names, but it is possible to set up flexible mapping rules.
In ASA firewall, the following default commands enable tunnel-group name lookup based on the OU (first) than IKE-ID (if present) and finally the Peer IP address:
tunnel-group-map enable ou tunnel-group-map enable ike-id tunnel-group-map enable peer-ip
IKE AM and names matching
When the responding node receives an AM proposal, the proposal already contains the initiator’s IKE ID, regardless of the authentication method selected. The IKE ID might be an IP address or hostname or just any text string – e.g. ezVPN group name. The responder may use it to match the local tunnel-group and pre-shared key if needed. Thus, you may utilize tunnel-group names based on hostnames with IKE AM even with PSK authentication.
Activating IKE AM
IKE AM is automatically enabled with some VPN features, such as ezVPN remote. In order to engage AM negotiation in ASA firewalls manually, use the command crypto map [TAG] [SEQ#] set phase1-mode aggressive. Enabling this feature in IOS is a bit more trickier. You should configure an ISAKMP profile first and then use it with a crypto map similar to the following:
crypto isakmp profile AGGRESSIVE initiate mode aggressive self-identity fqdn keyring default ! crypto map VPN isakmp-profile AGGRESSIVE crypto map VPN 10 ipsec-isakmp
You may globally disable AM in Cisco IOS router using the command crypto isakmp aggressive-mode disable or using the command isakmp am-disable in ASA firewall. This will prevent the devices from ever accepting or initiaing any IKE AM connections.
What happens if none of the configured tunnel groups matches? In this case, the firewall would use the default group that is always present in the system: DefaultRAGroup. Thus, if you don’t have a specific group configured for the remote endpoint, but the authentication using the default group succeeds, the system will use the default policy for the new tunnel. In case you wonder, you may change the default tunnel-group name using the command tunnel-group-map default-group <NAME> and specify your own group.
Certificate Mapping Rules
When using digital signatures authentication, ASA firewall supports certificate mapping rules to translate issuer and subject names in the certificate to the tunnel-group name. The rules are configured using the command crypto ca certificate map [<NAME>] <SEQ#>. If no name is specified, the default map named DefaultCertificateMap is used for this purpose. Every entry in this map matches either part of issuer or subject DN in the certificate. For example
crypto ca certificate map MYMAP 10 issuer-name attr cn eq IESERVER1 subject-name co R3
You may match the DN as a whole string, without specifying any particular attribute like the second line in the above example does. When you have the map configured, you need to perform the following two steps:
1) Enable the mapping rules using the command tunnel-group-map enable rules.
2) Configure certificate map to tunnel-group mapping using the global commands tunnel-group-map [<NAME>] <SEQ#> <Tunnel-Group-Name>.
You may repeat the second step how many times you want to map the particular entry to a tunnel group that exists in the sytem. If you don’t specify the name for the certificate map, the default is DefaultCertificateMap used. Notice that OR logic is implemented by mapping multiple certificate map entries to the same group. Thus, any of the matching entries will result in the incoming session being matched on the same group.
Modular Policy Framework (MPF) configuration defines set of rules for applying firewall features, such as traffic inspection, QoS etc. to the traffic transiting the firewall. MPF has many similarities to MQC (Modular QoS CLI) syntax found in Cisco IOS, but there are some major differences in the flow of operations, even though many commands look the same. The following post assumes basic understanding of ASA firewall and its configuration. It covers the basic logic of the MPF, but does not go over all firewall features in depth.
Our Core Knowledge Simulation product contains More Information links to many of the Web documents that Cisco composes questions from. For those that want to supplement with the bookshelf, here are some recommendations by topic. If you have a favorite not listed below, be sure to comment!
A. Bridging and Switching
1. Frame relay – Chin, Cisco Frame Relay Solutions Guide
2. Catalyst configuration: VLANs, VTP, STP, MSTP, RSTP, Trunk, Etherchannel, management, features, advanced configuration, Layer 3 – Barnes, Cisco LAN Switching Fundamentals
3. Tunneling – DOC-CD
as promised before, updated Security VOL2 Lab1 has been posted to all subscribed members accounts. The new lab features completely new diagram (I hope you guys like it and significants updates to its contents. Alongside with removing the PIX and VPN3k sections we’ve added tasks covering such topics as IPsec VTI, Zone-Based Firewall, IPS virtual sensors/VLAN groups, ASA reliable static routes, 802.1x authorization and a few more goodies to this lab. The updated content should be less “crazy hard” than its v3.0 predecessor and better mimic the difficulty of the real exam. Still, it was designed to be *harder* than the real stuff, just to make sure you don’t relax too much and don’t let your guards down Anyways, enjoy the first update in the series! We plan to post updates periodically and finish the whole process in June.
For you CCIE-RS folks waiting for the BGP section to be posted. Our apologies for the delay, we’re working to get it done ASAP. The section appears to be bigger than we estimated before, and it may take an extra week to finish it. We’ll try to make an intermittent update by the end of this week, covering at least some of BGP Section tasks. Thank you for your patience!