Author Archives: Piotr Kaluzny
Author Archives: Piotr Kaluzny
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 (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 :
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
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
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
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.
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
IP Routing : RIP -> Configuring Routing Information Protocol
IP Routing : EIGRP -> IP EIGRP Route Authentication
IP Routing : EIGRP -> IPv6 Routing : EIGRP Support
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 10.1.1.0/24 are protected networks
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
service-policy output QOS
Voice traffic Continue reading
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).
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
We will authenticate the tunnel using pre-shared-keys, and since authentication method is no longer negotiated in IKEv2 we Continue reading