Piotr Kaluzny

Author Archives: Piotr Kaluzny

CCNA Security 210-260 IINS

As some of you probably already know, the CCNA Security IINS exam topics have been refreshed from version 2.0 to version 3.0. The new exam is now called CCNA 210-260 “Implementing Cisco Network Security”. We will now take a look at the differences between the two exams and highlight the most important topic changes.

First thing, IINS 3.0 topics combine and adjust the current domains. Instead of covering nine domains (IINS 2.0), only seven domains are now included. This change was made to better reflect current job roles and job tasks typically performed by CCNA Security individuals. Note that although there are fewer domains, the exam remains the same length – it lasts for 90 minutes and contains 60-70 questions. This is because some new technologies were added and certain topic areas are now covered in more depth. The exam prerequisites did not change – you will not be able to obtain a valid CCNA Security Certificate until you already possess a valid CCENT or CCNA R&S, or any CCIE certificate.

In general, the new CCNA Security exam tests the candidate’s knowledge of secure network infrastructure, understanding core security concepts, managing secure access, VPN encryption, firewalls, Continue reading

Router IP Traffic Export

Router IP Traffic Export (RITE), or simply IP Traffic Export, is a method of copying traffic directly from a router to an external device, such as a Protocol Analyzer or an Intrusion Detection System (IDS). This feature can be used to replace SPAN/RSPAN configurations deployed on L2 ports/VLANs. Two main benefits of RITE is, first, the ability to duplicate the traffic received on a WAN interface, such as Serial port, and second, granularity of our configuration – we can be very selective in what traffic will finally get copied from the network.

Before we discuss the configuration of RITE, just few words about limitations of this feature :

  1. The device receiving the exported traffic must be in the same L2 network as the router’s interface (e.g. must be directly connected). This interface is known as “outgoing” in the RITE’s terminology
  2. This (outgoing) interface must be an Ethernet port. Incoming interface(s) (where the traffic is received and optionally sent through) can be anything (e.g. WAN/LAN)
  3. Traffic generated by the router configured for RITE cannot be exported

A sample topology for RITE may look like one below. Our monitoring station (PC) is directly connected to R2’s RITE outgoing interface, Gig0/0 Continue reading

IPv6 DMVPN Routing

In our last article we looked at IPv6 over IPv4 DMVPN configuration, where IPv4 transport was used to tunnel IPv6 traffic. In this blog post I would like to show you how to deploy pure IPv6 DMVPN network, and even more importantly, how to enable one IPv6 Routing Protocol over another in the Cloud.

Since IPv6 will be now also used as the underlying transport, the overall configuration of the DMVPN devices will be a little bit different from the previous example; also note that our topology was slightly modified :


Key thing here is that NBMA addresses are no longer IPv4; basically IPv6 is used everywhere, which means that our mappings on the Spokes will be always referring to v6 information.

Let’s start our configuration. We will first configure our Hub (R3), then the Spokes (R2, R4), and finally enable routing on the Overlay network. Since IPSec is optional, we will not be using it in this example (note that to protect IPv6 packets IKEv2 would have to be used, not IKEv1).

R3 (Hub) configuration. Again, everything is IPv6, including the tunnel mode. Don’t forget that link-local addresses must be always hard-coded on a given Cloud, on every device Continue reading

DMVPN for IPv6

As you probably already know, every DMVPN network consists of multiple GRE tunnels that are established dynamically. At the beginning, every Spoke in the Cloud is supposed to build a direct tunnel to the Hub. Then, once the Control Plane converges, the Spokes can possibly build tunnels with other DMVPN device(s), of course assuming that our DMVPN deployment (aka “Phase”) allows for that. 

In most cases DMVPN tunnels will be deployed over an IPv4 backbone, interconnecting different sites running IPv4. But since GRE is a multi-protocol tunneling mechanism, we can use it to carry different protocol traffic, like for example IPv6. Frankly, in the newer versions of IOS code you could even change the underlying transport from IPv4 to IPv6. This basically means that you can use an IPv4 OR IPv6 network to tunnel IPv4 OR IPv6 traffic.

In this particular article I am going to discuss a scenario in which the Transport/NBMA network (“Underlay”) uses IPv4 addresses, but the goal will be to use the DMVPN to interconnect sites enabled only for IPv6.

As you can see from the topology below, our private sites are configured with prefixes starting with 2192:1:X::/64, and the VPN (“Overlay”) subnet used is Continue reading

Build Your CCIE Security Knowledge with Cisco Docs!

A good knowledge of Cisco’s Documentation is what could make a difference in passing or failing the exam. Because of that, I would like to show you how to access most useful Doc CD resources on a per blueprint-section basis. In addition, we will also take a look at the location of a particular document, so you know how to access it without using the Search function. Same thing as what you will have to do to access those resources in the lab.

Unless otherwise mentioned, all documents discussed in this blog are part of Configuration Guides.

1.System Hardening and Availability

Probably the most useful doc here will be for Control Plane features. However, I am going to show you more so you at least know how to find them.

Our starting point for this section is IOS Configuration Guides :
IOS and NX-OS Software -> IOS -> IOS Software Release 15M&T -> 15.2M&T

Routing Protocol Authentication :

IP Routing : RIP -> Configuring Routing Information Protocol
IP Routing : EIGRP -> IP EIGRP Route Authentication
IP Routing : EIGRP -> IPv6 Routing : EIGRP Support
Continue reading

Interactions between QoS and IPSec on IOS and the ASA

Quality of Service configuration for the traffic entering/leaving a VPN tunnel may require some special considerations. In this article, I am going to focus on interactions between QoS and IPSec on IOS and the ASA.

There are two methods of deploying QoS for VPNs – you can match the original (Clear-text/ unencrypted) traffic flows or the actual VPN (Aggregate traffic). This second option can be useful when you want to apply a single QoS policy to all packets leaving a tunnel, no matter what are the original sources and destinations protected by the VPN.

We have got a VPN tunnel built between R1 and ASA. R6 and are protected networksQosipsecG1

Let’s start on IOS (R1). The VPN tunnel is already up – we will configure a basic QoS Policy to enable LLQ for delay-sensitive traffic, such as Voice (I assume these are all packets with DSCP of EF). Note that this configuration would normally match all EF-colored packets (including non-VPN EF traffic), but since we won’t have any clear-text EF flows in this network we don’t really care:

class-map match-all VOICE
match dscp ef
policy-map QOS
class VOICE

int f0/0
service-policy output QOS

Voice traffic Continue reading

Configure a Highly-Available IPSec VPN tunnel on IOS

It is possible to configure Highly-Available IPSec VPN tunnel on IOS so that the SA information is replicated between the routers. This ensures that a potential failover will be transparent to users and it will not require adjustments or reconfiguration of any remote peers.

There are two protocols used to deploy this feature, HSRP and Stateful Switchover (SSO). HSRP is one of the First Hop Redundancy Protocols that provide network redundancy for IP networks, ensuring that user traffic immediately and transparently recovers from failures in network edge devices. The protocol monitors the interfaces so that if either interface goes down, the whole router is deemed to be down and the ownership of IKE and IPSec SAs is passed to the standby router (which now transitions to the HSRP active state). SSO allows the active and standby routers to share IKE and IPSec state information so both routers have enough information to become the active router at any time.

Before we take a look at the configuration, let’s have few words about our topology. The internal network (VLAN 146 below) configuration is outside the scope of this post, but it would be normally configured with a separate HSRP instance, tracking not Continue reading


In our next blog post, we will focus on configuring an IKEv2 VPN between the ASA and IOS.

Is there anything special about that configuration? Yes and no. It is still “just” IKEv2 that will take care of negotiating our tunnels, but there will definitely be a difference in how we configure one platform versus another. Remember – tunnel interfaces are not supported on the ASA, at least as of 8.6, and this generally means that we will not be able to use tunnels (FlexVPNs) on IOS, too (there is actually one small exception to this rule, but it will not be discussed in this article).

Let’s take a look at our simple network:

We’ll try to build a VPN tunnel between R10 and ASA3 that we will then use to protect traffic flowing between VLANs 10 and 8. I am going to start with the ASA configuration.

First and foremost – the Policy. Note that PRF must generally be the same as what you have selected for Integrity/Hashing:

crypto ikev2 policy 10
encryption aes-256
integrity sha384
prf sha384
group 14

We will authenticate the tunnel using pre-shared-keys, and since authentication method is no longer negotiated in IKEv2 we Continue reading