Hey guys and girls!

I was just about to post a new article on some of the notes that i had made recently. As you all know i recently posted up the CCIE-blueprint as a checklist and i’ve started ticking things off , as i finish them ! Well, here’s the good news..

Cisco, did EXACTLY the same thing and their new( and expanded ) CCIE-v3 blueprint rocks my face! HERE’s the link to it ( Registered customers only ). If you want it in a PDF format, you can find it HERE.

This is really awesome, as i no longer have to keep guessing about the topics that might be included under a particular section. It’s always a good feeling when you hear it from *THE MAN* himself, rather than providers

I will be updating the CCIE-sec blueprint later today to match this new and improved list.

Cheers!

TacACK

Hey all,

I’m taking a break from Cisco for 2 weeks or so.. ( 2nd week running ) as i prepare for the CWNA cert. Hold on, i’ma be back

Today i was researching if there are any ways to block users have Valid certificates from making VPN connections to a Router. I found that this can be achieved using an IOS feature called Certificate-based ACL’s.( CALC’s ).

Using a CALC we can define a filtering condition for the user certificates , such that only users having certificates which match the filter criteria are permitted to pass through Certificate Authentication and VPN setup. The other users do not even go through the certificate checking process, they are immediately denied VPN access.

SYNTAX

 (conf-t)#crypto pki certificate map <certificate-map-name> <entry-number> 

 Certificate-map-name : Represents the name of the CALC

After creating the CALC, we can specify match conditions  or ACE’s.

# <field-name> <match-criteria> <match-value>

 field-name : Represents which field in the certificate will be used for the filter. There are many options here:

• alt-subject-name
• expires-on
• issuer-name
• name
• serial-number
• subject-name
• unstructured-subject-name
• valid-start

match-criteria : This will indicate “how” the match will take place. This tells how the value indicated in the field- name will be used. The various possibilities are :

• eq , ne , co ( contains ) , nc ( does not contain ) , lt ( less-than ), ge ( greater then or equal to )

match-value : Value which will be used to match against the field-name using the criteria mentioned in match-criteria.

EXAMPLE

#crypto pki certificate map Certs_TB_blocked 10

#subject-name co Marketing

The above CALC will only permit dudes having a “marketing” certificate to create VPN connections to the Router.

In order to apply this CALC, we need to apply this to the trustpoint definition in our Central Router. When the Central router receives a certificate from a user, it checks with it’s trustpoint if the certificate is valid or not. At this junction, the CALC can be applied to identify which certificates should be even checked ( ex : from marketing ) and which should be shown the door ( ex : other deparments who are not eligible to make VPN connections ).

#crypto pki trustpoint Tacack

#match certificate Certs_TB_blocked

#enrollment-url… ( bla bla bla… )

Using this, a powerful certificate filtering feature can be enforced on a Router to limit or police the VPN connections from various users in a company.

No , that wasn’t a typo. The first time i heard that, i nearly gave up Cisco studies. I mean C’mon! What next? Voice in an ASA? Jupiter on MARS ( get the pun? ) . But thanks to @packetu’s discussion on CLN is started reading about this and it’s super insightful into how routers work. What i’m writing here is mercilessly and shamelessly copied from Cisco documentation which can be found here. Here’s what i learnt:

Hokay! Some clarfications first!

Uno : By switching inside a router, i don’t mean a “L-2 Router” ( Even if that exists! )

Dos : No, It’s not a new technology

Now that we’ve got that outta the way. Lemme tell you what switching here refers to. In simple terms, switching refers the “mechanism” employed by the routers to get a packet from the source-interface to the destination-interface with all the make-up required. Clear enough? This is a totally internal process( which happens inside a router when it recieves a packet ). There are a couple of steps which happen when a packet arrives :

• The router checks if the packet’s destination is reachable.
• If yes, to the previous question- How the F does it get there? Which’s the next hop of the packet.
• If the next hop has been determined, Send it. But hold on- bef0re sending , the source MAC address of the packet must be re-written to the MAC-address of the outgoing interface of the router.

In-order to do this the router can choose between 2 methods:

• Process switching
  • The packet is switched by a “process” running among other processes in a router
  • It IOS doesn’t give a rats ass if the packet arrives. It will switch it when it wants to ( i.e when the “switching process” gets priority to run )
  • Not -very good ‘coz an overloaded router can cause problems to the switching
  • Uses the Routing Information Base ( fancy name for “routing table” ) and the ARP cache , to get hold of the MAC-address of reachable hosts.
• Interrupt Context Switching
  • Them packets are worshipped. Aka they are switched on demand
  • When a packet arrives, an interrupt is raised and all other processes stop, and the switching process switches the packet.
  • Unlike Process switching ( which referes to the RIB and ARP cache ), ICS refers to a separate Route-Cache to get the MAC-Address of the destination .
  • Getting this data from the route-cache can be done in one of the 3 following methods:
    • Fast switching
    • Optimum switching
    • Cisco Express Forwarding ( Ta-Da!!!)

Fast Switching

The point as we all know is to find the MAC-Address of the destination using the IP address of the destination. This as we learnt earlier is done using a “route-cache”. The Fast-switching route-cache comprises of the following

• A Gigantic Binary Tree ( 32 levels ) having a leaf node for every IP address imaginable.
   
• The MAC-address of the IP ( if reachable ) is stored in the leaf as payload.
• For the router to find the MAC corresponding to a destination IP, it has a to do a lookup through all the entries based on the bit pattern of the IP address.
• It’s obvious at this point that there is no link between the tree and the Routing Information Base ( Routing table ) and the ARP table.
• This leads to the following problems:
  • So suppose in the future some routing entry changes in the RIB or the MAC-address of a destination changes and it’s updated in the ARP table, the change will not be reflected in the Route-cache.
  • If the tree has to be as up-to-date as possible, the entries have to be renewed continuosly. This leads to additional overhead.
  • Suppose there is some route-recursion between the destinations, it’s impossible to represent here in the cache because the MAC-addresses of the destinations are burnt in.
• So a better solution was developed

Optimum Switching

The disadvantages in the previous caching method had to countered here. So the following method is followed:

• Instead of having one huge Binary tree having all the MAC-address related information, they are broken down into 4 hierarchical multiway (not binary) trees.

Optimum-Switching

• So, now the router’s job has become easy. It only needs to do 4 checks. ( 1 for every octet of the IP address ).
• Similar to Fast-switching, the MAC address of the destination is stored in the payload of the corresponding leaf-node .
• The problems which plague fast-switching still exist here as there is not relation between this and the routing and arp tables.
• So the problems of Mac-address changes and aging still exist.
• Even the route-recursion issue still exists

The better way to do this is through or friend CEF!

Continued in Part 2….