IPV6, Things have changed...

Hey Guys,

Hope new years eve is finding you well. While waiting for someone to come and pick me up for a party I have been doing some IPv6 study (I sure do know how to paint the town red don't I ;).)

So, IPv6: It's coming guys. No avoiding it, I recommend if you haven't started reading up on it you better start now.

Bit of a gotcha with that though, ya see a lot of the information out on the Internet at the moment regarding IPv6 is a little outdated. With the IETF feverishly working on the RFC it's getting very hard to get a "Current state" of IPv6

Super Duper Quick Primer on IPv6:

  • All Addresses are 128 Bits Long
  • The 128 bits are made up of groupings of hexadecimal characters
  • You can compress the format of the IPv6 address to make it more readable
  • More than one address on an interface is now quite normal
  • Broadcast has been done away with
  • what bits an address start with now control what "Scope" that address is used for. The Scope defines the "Role" of that address (think loop back, or RFC 1918 addresses)

For me personally, when I did my CCIE in 2007 IPv6 was in quite a diffirent state to what it is now. Here are things that have changed since I started studying it. I hope that you find them useful.


1. Site Local Addressing = Gone

Site Local addressing has been replaced, in its place we now get "Unique Local Addressing" which is essentially the same thing, the major diffirence being what the prefix starts with (FF0C/7)


2. Before they wanted to make it so you could NOT get any address allocations directly for an enterprise, you had to go through an ISP. They have changed that now. you can get Provider indepedent addresses allocated to you should you be able to prove the need. The reason they did not want this at first was because they where worried about how big the routing tables could get if we had tons of ipv6 prefixes floating around instead of being nicely aggregated as they should be.

Thats the two major things I can see so far, I can also see they have dropped most of the IPv6 to IPv4 translation mechanisms, that I will cover later on in my next IPv6 related blog post

Untill next time!

CEF - The Final Frontier

Hi Guys,

Wow been a long time since I have done an update: Sorry about that guys I have been concentrating pretty heavily on two things:

1. Ironport Exam (passed it, got my CICSP woo!)2. Working on something called AXL which is basically a SOAP object for CCM that lets you talk directly to the database: Stay tuned for more info in another blog

3. Weighing up if i should finish my final CCSP Exam so i can get my damn CCSP (Its the NAC exam which is annoying because it is quite difficult to get real-world NAC experience)

Anyway, I think it's important I talk about something pretty low-level in Cisco routers called CEF.

CEF stands for Cisco Express forwarding and is a special algorithm that utilizes the Cisco Hardware ASICS for routing, saving CPU cycles.
(I think the algorithm is called a B-Tree algorithm, if you know the name please post in the comments!)

Has my bland description of CEF bored you yet? It shouldnt: CEF is exceptionally important in how a router makes routing decisions. The Common belief is that a show ip route will tell you exactly where a packet is to be routed, this is not strictly true, although the Cisco router does use the routing table, it only copies this information to the CEF table, which you can see for yourself with show ip cef:

PeterCCIE18371#show ip cef
Prefix Next Hop Interface
0.0.0.0/0 attached Virtual-Access2
attached Dialer1
0.0.0.0/32 receive
10.0.0.0/24 attached FastEthernet0/1
10.0.0.0/32 receive
10.0.0.1/32 10.0.0.1 FastEthernet0/1
10.0.0.2/32 10.0.0.2 FastEthernet0/1
10.0.0.3/32 receive

99.999 percent of the time the routing-table and CEF table will match (except in the instance of policy-maps, which is why the CEF table can be extra useful: you can see what routing decisions where made AFTER your policy-map was applied which you can't always do in the routing table)

However, the CEF table is also extremely useful for debugging hard to troubleshoot problems, For example, a customer of mine had a 837 router that could not be pinged or reached by users on an SSLVPN sitting on an ASA in another part of the customers network.

A policy-map was being used for a nonat statement and had not been updated with the addresses of the ASA SSL VPN Users, so I modified that access-list Everything appeared totally OK according to packet-tracer on the ASA and other debugging tools. After going through things a few times I double checked the cef output

Sure enough, CEF had not updated to reflect the changes in the policy-map and still had a cached entry for that particular IP address, turning CEF off and back on again resolved the issue.

So Top Tip readers: when you look at a problem and your POSITIVE everything is configured the way it should be, don't trust the routing table to tell you what decision the router will be making, check the cef table with show ip cef or show ip cef

Now quickly to talk about another interesting issue: Load Balancing.

As you are probably aware, a Cisco Router can load balance outgoing routes to two different hops. This works as long as your two routes have the same administrative distance and same cost or metric in your routing protocol (except in the case of the EIGRP Variance command)

So, assuming your using static routes for some odd reason and have the administrative distance for both of those routes set to the same value your routing table might look a little something like this:

PeterCCIE18371#show ip route 10.10.10.10
Routing entry for 10.10.10.10/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
10.0.0.71
Route metric is 0, traffic share count is 1
* 10.0.0.70
Route metric is 0, traffic share count is 1

Why has 10.0.0.70 got a little * next to it you might ask? I am glad you ask: This is your indication to let you know what hop the router last took for traffic to that destination, if you see this little asterisk moving between your two next-hops your probably load-balancing reasonably effectively.

The question is, what algorithm is the Cisco router using for this load balancing? How can we determine this? Remember the routing table only tells us about potential routing decisions, it is not the definitive authority on how we will route our packets.. Do you remember what is?

Thats Right CEF

So, if we ask CEF how it is load balancing this route?

PeterCCIE18371#show ip cef 10.10.10.10
10.10.10.10/32, version 7386, epoch 0, per-destination sharing
0 packets, 0 bytes
Flow: Origin AS 0, Peer AS 0, mask 32
via 10.0.0.71, 0 dependencies, recursive
traffic share 1
next hop 10.0.0.71, FastEthernet0/1 via 10.0.0.0/24
valid glean adjacency
via 10.0.0.70, 0 dependencies, recursive
traffic share 1
next hop 10.0.0.70, FastEthernet0/1 via 10.0.0.0/24
valid glean adjacency
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes



So now we have a bit more information to work with: The router is using per-destination sharing. While fine for most situations it might not work in your particular requirements, for example what if 10.10.10.10 is another router you have a tunnel to? You have two paths to it but because the destination is always going to be 10.10.10.10 the load-balancing algorithm is never going to utilize the second route!

You have two options, you could turn off ip cef and cisco fast switching completely on the interface with the no ip route-cache and no ip cef interface config and global config commands (this may be your only option on certain platforms) OR you could enable per-packet sharing with the following interface commands:

interface FastEthernet0/1
ip address X.X.X.X secondary
ip address 10.0.0.3 255.255.255.0
ip access-group block_others in
ip accounting output-packets
ip load-sharing per-packet
ip nbar protocol-discovery
ip nat inside
duplex auto
speed auto
fair-queue
end

You must enable this command on EVERY interface that is involved in any load sharing, so for example if you had two interfaces you where load-balancing across you must enable load-sharing per-packet on both interfaces. you can confirm with show ip interface

if we return to our CEF entry, we see the following:

PeterCCIE18371#show ip cef 10.10.10.10
10.10.10.10/32, version 7386, epoch 0, per-packet sharing
0 packets, 0 bytes
Flow: Origin AS 0, Peer AS 0, mask 32
via 10.0.0.71, 0 dependencies, recursive
traffic share 1, current path
next hop 10.0.0.71, FastEthernet0/1 via 10.0.0.0/24
valid glean adjacency
via 10.0.0.70, 0 dependencies, recursive
traffic share 1
next hop 10.0.0.70, FastEthernet0/1 via 10.0.0.0/24
valid glean adjacency
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes


There you have it folks, CEF and Load-balancing! Until next time.

Pete

ASA Botnet FIlter feature

Hi Guys,

Been a while since I have done an update but i came across something pretty cool i wanted to share: ASA Botnet filter.

This feature (available on all ASA's version 8.2 and above) basically does what it says on the label: Tracks and reports back on any suspicious activity leaving your network that looks like one of your boxes may be infected. It of course is constantly updated with new botnet-like patterns so it should be able to detect all the latest bot's as they come out.

It is a licensed feature but a 30 day trial is available, check out:

http://www.cisco.com/en/US/prod/vpndevc/ps6032/ps6094/ps6120/botnet_index.html

for more details

New Cisco ISR G2 Routers: The Facts Part 1


Cisco ISR G2 Routers

Who what when where why

You have probably heard the fuss regarding Cisco’s release of the next generation of ISR Routers, ISR G2. ISR Routers have been the most successful access routers EVER. Now comes the ISR G2 which appears to be able to continue this success.

Enough marketing talk, plenty of that on cisco.com: Let’s get down to the details on what exactly we are looking at, each article will focus on a different area of the G2, Today we will be looking at

Software Licensing

The software is where the vast majority of the changes to the way you think about Cisco are occurring

First of all, No more separate IOS images per platform: IOS version 15 is a “universal” IOS which means that the same IOS is used across all platforms. What is even more interesting is that this “universal” IOS also comes pre-loaded with all the feature sets (i.e. security etc.) ready to go: They just need to be licensed.





It is also important to note that the different feature sets have been broken up into much smaller and more easily understood sections, rather than ADV IP Services, IP Services, IP Plus etc. etc. the model has been significantly simplified:


A default IP base image is enabled by default and you can then enable the feature sets that you require (SEC, DATA or UC). These are referred to as cisco IOS “Technology packages”

Routers that you have pre-purchased for UC etc will obviously come licensed for that technology package. Just so you know: yes you can enable multiple technology packages at the same time.

How do you license them? With a PAK File, you order the license, a PAK file with a special key number is provided to you, you go to www.cisco.com/go/license and enter in this PAK number along with the unique ID of the router (which is made up of the serial number of the router and the PID)

Once you have done that you are then sent a .lic file that you can then apply to the router. Your done!

It is important to note that while this sounds like a pain in the butt it makes ordering IOS a lot simpler and means you don’t have to worry about downloading a new IOS in order to apply the feature set you want. What’s even cooler is that the concept of temporary licenses allowing you to try a feature for 60 days is now supported.

What about features such as SSL you say, or CCME? These are enabled using a “feature license” which is basically an add-on to a particular technology package, so for example, in order to enable CME feature license you obviously must have a voice feature package license already. There are two types of feature licenses

Subscription Licenses

Subscription licenses are time-based licenses that require the subscriber to periodically renew or the license will expire after an agreed-upon time. Some examples of Subscription license are URL Filtering and IPS.

Counted Licenses

Feature licenses can be either uncounted licenses or counted licenses. Uncounted licenses do not have any count and simply enable the unrestricted feature on the router when activated. Counted licenses enable a defined number of uses e.g. CME User Licenses”

SSID Broadcasting on Cisco

Hi Guys,

Very quick update this one: Just letting you guys know how to broadcast an SSID on a cisco wireless device, i know it sounds simple but its such a weird command to enable broadcasting of the SSID i wanted to document it for those of you who have trouble finding it.

dot11 ssid
guest-mode
!

Hope this is help to some of you!

IPSEC Redundancy

Hi Guys,

Straight into it: Did you know that there are some very nice redundancy features for IpSEC? Sure I always kind of realized you could put two routers in a VRRP or HSRP Arrangement, but what if I told you not only could you do this but you could also even get them to exchange state information about the traffic in the IPSEC session?

Or what if your routers are in entirely different subnets? So maybe you have an ipsec router on one ISP and a backup IPSEC router on the other? That is the topic of this blog.

Lets first cover off a very basic redundancy option that might fit the bill for you perfectly:

Just add more than one peer in your set peer command!


EBGP Multihop protection

I assume ofcourse if your reading this blog you probably know what BGP is :) So I won't bore you with that, but what I will say is man: BGP Security globally is in a pretty sorry state.

From non-password encrypted BGP sessions to lax prefix filters, disaster is just a step away with such lax security.

A fairly simple attack that you might fall victim to is BGP spoofing. Take for example you peer with 203.1.1.1 and you dont use MD5 encryption because the network engineer at that ISP thinks MD5 is some oddly named rock-band

Further to this, not only does he not know what he is doing from a encryption perspective, he has also failed to implement any sort of ip spoofing protection on his network. One of the customers on his network, Dr Evil decides to spoof a BGP packet to you as source 203.1.1.1 where he claims he knows the routes to google. Since your not using MD5 your quite stuffed at this point! But I have prefix list protection you say! Okay fair enough, what if he just kept sending resets for your BGP Session? That could still potentially cause you issues.

"Save me Dr Cisco!" I hear you cry.

Enter BGP TTL-Security check

this funky little feature takes advantage of the fact that all IP packets have a TTL value. If your peering with someone directly (and its important to note that key word DIRECTLY (Remember, if the other end is sourcing its BGP traffic from a loopback interface or is peering to YOUR loopback interface the hop count is going to be slightly diffirent.))

So if a packet is spoofed from a customer, the TTL will still have to be "marked down" and thus when the TTL Value makes it to your router it will be something like 248 or 249 instead of 254 or 253 as it should be.


The BGP Support for TTL Security Check feature is configured with the neighbor ttl-security command in router configuration mode or address family configuration mode. When this feature is enabled, BGP will establish or maintain a session only if the TTL value in the IP packet header is equal to or greater than the TTL value configured for the peering session. Enabling this feature secures the eBGP session in the incoming direction only and has no effect on outgoing IP packets or the remote router. The hop-count argument is used to configure the maximum number of hops that separate the two peers. The TTL value is determined by the router from the configured hop count. The value for this argument is a number from 1 to 254.


I hope this helps guys!

Hints and tips for the CCIE Security from the guy who actually writes the tests!

Hi again guys,

Well as you may have saw in my previous blog entry, I am at networkers Brisbane and in my techtutorial for CCIE Security my tutor was Yusuf Bhaiji who actually writes the CCIE Security coursework, here are some hints and tips I picked up:

  • There is no more Windows CA Server! Unlike the previous exams where a Windows CA server was setup ready to use, in the new exam you must setup your own Crypto PKI server on the router itself, easy enough but something to keep in mind
  • This is a common question so its nice to get an answer, for those of you who like using the ASDM and SDM you will be unhappy to know that these are NOT enabled and CANNOT be enabled for the exam, the files are actually deleted off the flash drives of the routers and the ASA's. So NO GUI's for the routers or ASA's
  • In saying that however you ARE allowed to use the GUI for IPS
  • IOS IPS version 5 is used
  • Don't underestimate the implicit and explicit troubleshooting questions that you will get
  • Don't underestimate the core knowledge questions, they are going to be difficult! Look for a book coming out in December from Yusuf featuring up to 300 sample core knowledge questions.
  • You must know virtualization on the IPS devices and multiple contexts on the ASA's as these will feature HEAVILY in the exam
  • You must understand all the different types of VPN including the new GETVPN, Dynamic VTI and VTI (I have done a blog post on VTI already and one is coming up for Dynamic VTI)
  • You will be asked to implement at LEAST three different types of VPN's so know them backwards
  • You need to know about IPSEC redundancy (another topic about that will be posted soon.)
  • In the new version of IPS 6.1 all high risk attacks are denied by default, some questions will try and use this to trip you up deliberately! So watch out for this.
  • Control-Plane and Management plane policing are heavily heavily focused on as these are new topics in this blueprint, you can always expect topics that are new to the blueprint to be tested heavily.
  • You will have 0 initial config done on the ACS Server
  • You can expect questions like "Someone has attempted to configure an IPSEC tunnel between router X and ASA Y, But it is not working" and you will need to troubleshoot and resolve (Explicit troubleshooting)
  • You can expect questions like"the following traffic was captured during an attack earlier today" followed by a screenshot of a packet capture and you must identify the attack and use appropriate methods to mitigate the attack from occurring in the future within the constraints confined in the question (for example, something like "Due to your ISP's routing policy you must not use reverse-path forwarding to protect against this attack")
I hope this helps some of you out there!

Networkers Brisbane, A non-tech perspective.

Hi Guys,
Reporting to you from sunny Brisbane here, staying at the Rydges hotel (which I cannot recommend enough, its literally right next to the convention center and has pretty decently priced accommodation and Internet access.)

Can I just first say: Brisbane is very pretty, and the convention center is well organised and massive for Australia. I hope I get chance to check out the awesome museum too which has a dinosaur themed section (see below for the cool mock ups outside the front of the museum)







Cool hey?

So about networkers, from the minute you step in the whole effort and the money Cisco must spend to put the event together is obvious. The first thing they give you is a special badge with a scannable device on it, this scannable code is your ticket to all events, you simply scan the badge to register for events or to print your schedule. Everything went silky smooth:


Once you get your badge its time to collect your merchandise! Considering how stingy Cisco normally are with merchandise, the items you get are impressive:

  • A very nice Cisco carry bag with padding and all
  • A Shirt
  • USB Key (2 gig) with all the Cisco content from the ALL the technical breakout sessions.
  • Water bottle, cap etc

For those who know Cisco, all this merchandise is quite generous for them!

So on my first day, the Monday which is an optional day I had my techtutorial, I chose CCIE Security as I want another one to go with my CCIE Routing and Switching.

The tutor we had was none of than... Yusuf Bhaiji,
The author of the Cisco press book Network Security Technologies and Solutions and also the lead for the actual CCIE Security exams itself! Can you think of anyone more qualified to talk about the exam topics?

He gave us a great handout and did an amazing job of covering the material that will appear in as much detail as one day would allow (that is to say, not much detail but good bits of hints and tips.)

I will follow this blog post up with all the hints he gave but for now let me just say some of them will be quite useful to those preparing for the exam! He also mentioned his new book is out in a months time which is an updated version of his CCIE Security practice labs (so second edition of that same title.) If I had my copy of his book I would have got him to sign it. Sad I know, but my rock stars are different from your rock stars (for an interesting take on that check out this video:
http://www.youtube.com/watch?v=jqLPHrCQr2I )


Well that's it for the non-technical side of my blog kids, I will post the hints and tips from Yusuf next, but so far apart from missing my girlfriend back home in Perth I am enjoying it here in Brisbane.



IPSEC with VTI: The best damn way to do it.

Back when I was finally sick of working for ISP's and wanted to make the switch to enterprise, I had the normal "I am ISP background working in enterprise" worries (more of these and tips for those making the switch in a future article) but one particular technology had always stumped me.

IPSEC

Few other technologies require you to configure so many damn things to get them going! The steps you had to remember, ISAKMP policies, transform sets, crypto maps, interesting traffic ACL's, nat-traversal, the list could just go on and on and the debugging was just horrific!

Luckily I got my head around IPSEC to the point where of all the topics on the CCIE security IPSEC is the one I feel most confident with.

BUT my dear reader, I want you to be able to _AVOID_ the problems with IPSEC completely! Let me show you: VTI Tunnels


Virtual Tunnel Interface is a Cisco technology that basically allows you to have IPSEC tunnels, I am not talking about the pseudo IPSEC tunnels that are encapsulated inside GRE or GRE tunnels encapsulated inside IPSEC.

What we have with VTI is a pure Virtual tunnel, no GRE MTU issues to worry about and no real drawbacks that I have been able to see so far (if you know of any drawbacks id love to hear from you please comment in the section below.)

So, without any further rantings lets get onto some configuration:


First of all, you must configure your ISAKMP policies as normal (Hey, I didn't say it got rid of ALL the steps :p)

crypto isakmp policy 100
encr 1des
authentication pre-share
group 1
!


Obviously you need to make sure this matches on both your routers!

Go ahead and configure the transform sets:


crypto ipsec transform-set STRONGSET esp-3des esp-md5-hmac


Now here is a new step you probably have not seen before (except those of you who have configured GRE tunnels with IPSEC protection.. you know who you are!)


crypto ipsec profile VTI
set transform-set STRONGSET
!



Okay, so we have our transform set, our crypto isakmp policy and something that you may not have run across yet called a "profile."

Lets configure our tunnel, you perform this just like you would a normal GRE tunnel but with a few important differences:

interface Tunnel0
ip address 192.168.10.2 255.255.255.0
tunnel source 203.56.14.17
tunnel destination 61.88.88.88
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI


The two lines that should look different to you are "tunnel mode ipsec ipv4"
and "tunnel protection ipsec profile VTI"

These enable the VTI tunnel for IPSEC (obviously) and define the transform set to use,

We just have one more step now, earlier when I configured my ISAKMP policy I missed out a crucial stage that some of you may have picked up on (Hint: What authentication method am I using?)

Thats right, Pre-share, which means i need a pre-shared KEY! Now the reason i missed out on this was because a question i had when i first looked at this was what should i specify as the peer address? Well the answer is easy, you specify the peer address as the actual destination of the tunnel, so in our example our peer key looks like this:

crypto isakmp key CcI3R4ntsIs4Gr43tBl0g address 61.88.88.88




Assuming you have obviously mirrored the configuration on the other side guess what... that's it!! No Crypto-maps to worry about, interesting ACL's to define, no-nat statements to write, the next step is to bring up the tunnel by pinging the other end of the tunnel (so in our case 192.168.10.1) which should bring up the tunnel, you can verify using your regular crypto commands (show crypto isakmp sa and show crypto ipsec sa respectively.)

You can now route traffic over this interface just like a regular tunnel, you can even use a dynamic routing protocol!

Enjoy!

An Important lesson on QOS

Today I had a strange QOS problem to solve. This article mentions the problem and hopefully gives you guys a few pointers on QOS design.

So essentially the job involved me going to a company to teach a young CCNA about QOS, luckily he had some idea of QOS already and was a very quick learner. I took him through the basics of DSCP, COS, and the various tools available to you for QOS (shaping, policing, priority, bandwidth and WRED)

So far so good right?

Like I explained to the customer though, the biggest problem with QOS has nothing to do with the syntax or the configuration. The biggest issue is DESIGN and TROUBLESHOOTING. A few people apply QOS policies to there Internet-facing interfaces on OUTPUT and then think to themselves "Jee QOS does not seem to work" when it fails to achieve anything. The problem however lies in there design.

Without going into too much detail, it is CRITICAL to remember that the QOS "tools" priority and bandwidth do not do ANYTHING unless an interface is congested, so the very first thing you must do when designing your QOS is consider the size of the interface.

For example, lets say you have an Ethernet connection that connects to your ISP (pretty common these days.) Your actual speed the ISP provides you is 2 megabits per second, but your Ethernet interface is 100 Megabits. It is important to remember when using a QOS policy on an interface that the QOS policy only works if traffic is in the software buffer, and if your actual interface SPEED is 100 meg but your ISP speed is 2 meg, then the software buffer will never be used! Because as far as your router is concerned, there is PLENTY of bandwidth available. To get around this problem you must use a hierarchical policy map. An important note here: the bandwidth command under the interface is NOT used to control the bandwidth of the interface from a QOS perspective or to speed limit the traffic on that interface.

This configuration is simply used as a metric for internal routing protocols such as OSPF to help them calculate the cost of a link so for example, if a link is 100 meg and you want to make it less desirable, you could use the bandwidth command to say it is a 1 meg link in OSPF calculations. This would not limit the speed of the interface.

A hierarchical policy map is how you solve this issue, see below a configuration example:


policy-map parent_policy
class class-default
shape average 2048000
service-policy child_policy
!


We then apply this policy to our interface, and our child_policy is where we put our actual QOS policy, the one that prioritizes VOIP traffic, rate-limits HTTP or whatever else we desire to do.

What this does is limit the speed of the traffic to 2 megabits per second, so that a software buffer is created for this traffic. Once the traffic is inside the software at this point we can manipulate it with our QOS policy and our policy will actually have some effect!

But wait! There is more. The second important factor to consider is WHERE to apply your QOS policy, as you may know you can only use the priority and bandwidth commands on OUTPUT and NOT on input since no software buffer can possibly exist for traffic ENTERING your interface (how can you queue traffic thats not actually going out your router?)

Therefore, when writing your QOS policy, consider in what direction the traffic is most likely to experience congestion, so for example:

internet----> Dialer1 on router <--- Router ---> fa0/0

The thinking may be to prioritize FTP over HTTP for example that you would place your policy-map on the dialer interface, but if you think about it, traffic going OUT the dialer interface is only going to be acknowledgments! So chances are you wont experience congestion on your UPLOADS and hence your QOS policy is not going to accomplish what you set out to do. Since you can't apply it on the input because you want to use priority and bandwidth, the best choice is the fa0/0 interface. By placing it here you will be controlling the traffic as it leaves the router towards your network, so you can prioritize and shape as you see fit. I guarantee this works because I do it at home.

To complete the config, here is the full details guys:

policy-map parent_policy
class class-default
shape average 2048000
service-policy child_policy
!

class-map ftp
match protocol ftp
!
policy-map child_policy
class ftp
bandwidth percent 75
!
class class-default
fair-queue
!
!

interface fa0/0
service-policy output parent_policy
!

So in this example what I am doing is guaranteeing FTP 75 percent of the 2 megabits of bandwidth during times of congestion. All other traffic is in the class default class and the fair-queue command ensures that each queue is given equal amounts of bandwidth if there is congestion on the link.


Super quickly, to check if it is working correctly you would issue

#Show policy-map interface fa0/0 (but more on the output of this tomorrow.)


Coming tomorrow: Advanced QOS Design (what to do when we add IPSEC to the picture) and troubleshooting your QOS effectively.

Call Recording: The good, the bad, the ugly

Ahh Call-recording, its a feature many customers ask me about so I thought I would briefly speak about it here.

Just before we go on any further, I think I ought to mention the legal requirements surrounding call recording. First we shall look at a legal definition of call recording:

"Recording a call

Recording is the physical act of making a recording; monitoring is the listening to a call when being made or later."

Now lets look at the legal requirements for making a call recording:

“Every reasonable effort is made to inform parties that recording or monitoring is taking place.”

So in other words, you MUST inform the calling party that they may be recorded and/or are being recorded.

The Data Protection Act of 1998 also specifies that you must treat these recordings like any other form of private data stored electronically.

So now we have that out of the way and you understand your legal requirements, what kind of call-recording can we offer?

First of all, Later versions of Cisco Unity Express, Most versions of Cisco Unity Connection and Cisco Unity come with a feature called "Live Record." This rather handy feature allows a user to "conference" in the live-record pilot number, a beep will then sound indicating that the live-record feature has started, and the resulting .wav file will be placed in the users voicemail box after the call is complete.

SPAN is another method of configuring recording but is much more difficult to do, the idea behind this is to catch the RTP stream using port-mirroring. This requires more than just call-manager software however to execute and recording cannot be performed "on-demand" by the end user.

The final option is the use of third party software, to be totally honest I have not completely looked into this option as yet but I had a very interesting email from a company called Red Box who develop a voice-recording app. I will be investigating over the week and will let you know my findings.

Cheers
Pete
CCIE #18371

Ironports can perform man-in-the-middle for SSL.

Ironport WebProxys are capable of intercepting SSL to ensure they are not being used to tunnel other protocols. It used to be that you could run your SSH daemon on port 443, and even if you where behind a proxy you could potentially tunnel your traffic via SSH so you can get out and do whatever it is you want to do (BitTorrent, MSN, etc. etc.)

The reason for this was fairly simple: Since the connection was a secure connection, the proxy could not see the traffic encapsulated inside the port and thus was unable to determine if it was legitimate traffic or not. Luckily however the Cisco Ironport has a method around this, by inserting itself in any SSL path, so the actual SSL stream looks like this:

Client <--- Secure SSL with IronPorts Public Cert ---> Iron Port <---- Iron Port secure connection with SSL website ---> Secure Website.

The main drawback from this approach is that the certificate presented to the client will be untrusted, because it is signed by the Ironport application. This is easily resolved by either trusting the ironports self-signed certificate as a root-CA (Meaning any certificates the ironport subsequently signs are trusted) or by having the ironport request a Root-CA certificate from your own organizations root-CA and then rolling out the trust relationship via group policy.

Another awesome Ironport feature and a great way to stop people doing the dodgy on your network.

Ironports can perform man-in-the-middle for SSL.

Ironport WebProxys are capable of intercepting SSL to ensure they are not being used to tunnel other protocols. It used to be that you could run your SSH daemon on port 443, and even if you where behind a proxy you could potentially tunnel your traffic via SSH so you can get out and do whatever it is you want to do (BitTorrent, MSN, etc. etc.)

The reason for this was fairly simple: Since the connection was a secure connection, the proxy could not see the traffic encapsulated inside the port and thus was unable to determine if it was legitimate traffic or not. Luckily however the Cisco Ironport has a method around this, by inserting itself in any SSL path, so the actual SSL stream looks like this:

Client <--- Secure SSL with IronPorts Public Cert ---> Iron Port <---- Iron Port secure connection with SSL website ---> Secure Website.

The main drawback from this approach is that the certificate presented to the client will be untrusted, because it is signed by the Ironport application. This is easily resolved by either trusting the ironports self-signed certificate as a root-CA (Meaning any certificates the ironport subsequently signs are trusted) or by having the ironport request a Root-CA certificate from your own organizations root-CA and then rolling out the trust relationship via group policy.

Another awesome Ironport feature and a great way to stop people doing the dodgy on your network.

Waiting to Exhale (Via Networkers.)

Well, the wait for networkers is well underway, luckily for me the week of networkers is quite litreally the day after my birhtday party! Should make for a very rapid cleanup before I fly off to brisbane.

I am really looking forward to the video surviellance/Physical security side of things. This is a product you really don't hear much about but is another great ISR module you can install in your router:

http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6918/ps9145/ps9152/at_a_glance_c45-468316.pdf
Interesting new features for IPS 7.0

I ran across this article on network world and thought I would share it. SenderBase is basically what your paying for when you buy an Ironport so it's good to see Cisco intergrating it into other products.

It's a great idea, lets say for example the 139.0.1.0 network is infected with Code Orange (or some other new worm,) as this network launches attacks on other networks equipped with Cisco IPS's the reputation of the network will suffer and future IPS devices will flag it as dangerous based on the network it's coming from alone!

Personally I am just patiently waiting for the Ironport to come out as a module for the ISR routers and/or ASA devices, can't wait!

Cheers
Pete
CCIE #18371 and all round nice guy




Popular old posts.