At last I can talk about it!  Sometimes internal announcements can lead to a great deal of frustration when something great has been done and you can’t tell anybody!  -> “I can’t tell anybody about this for how long!”……

Much has been made of the energy drawn by ICT systems and a push has been made by most vendors to make their hardware as efficient as possible.  Let’s have a think about that though – how much of a difference are vendors making by focusing on making their power supplies/power draw the most efficient on the market? and, to focus on networking –> what percentage of the total energy draw of a company’s ICT estate do network devices actually consume?  I’m going to hazard a very scientific guess of “not much”… queue “Cisco Energywise”…

Cisco EnergyWise has just been unveiled at Cisco Networkers 2009.  It can be installed on any Cisco Catalyst switch to allow users to measure and control the energy consumption of devices such as IP phones, PCs/laptops, and access points.  Devices that are typically not IP enabled now will be monitored/managed in the future – lights, heating/cooling etc.  Now that increases the scope of control a great deal further than routers and switches!

I’m not going to blast you with technical information now; I think it’s more important to understand the benefits of the approach being taken by Cisco before getting swamped in config commands etc, so please find out more here, here, and here and I’ll look to go into more tech detail in the future…

It was true after-all…

 

“Changes to CCIE Lab and Written Exam Question Format and Scoring

Effective February 1, 2009, Cisco will introduce a new type of question format to CCIE Routing and Switching lab exams. In addition to the live configuration scenarios, candidates will be asked a series of four or five open-ended questions, drawn from a pool of questions based on the material covered on the lab blueprint. No new topics are being added. The exams are not been increased in difficulty and the well-prepared candidate should have no trouble answering the questions. The length of the exam will remain eight hours. Candidates will need to achieve a passing score on both the open-ended questions and the lab portion in order to pass the lab and become certified.  Other CCIE tracks will change over the next year, with exact dates announced in advance.

Effective February 17th, 2009, candidates will also see two other changes in CCIE written exams. First, candidates will now be required to answer each question before moving on to the next question; candidates will no longer be allowed to skip a question and come back to it at a later time. Second, there will be an update to the score report. The overall exam score and the exam passing score will now be reported as a scaled score, on a scale from 300-1000. This change will not affect the difficulty of the current set of exams and will assure CCIE written exams will be consistent with Cisco’s other career certification exams.”

My view -> The written exam changes are logical, the lab exam ‘interview’ could result in protests if fails are handed-out based on it…

As a continuation of last month’s “Sovereign BGP” post, this post will demonstrate the implementation of an Advertise-Map + an Exist-Map:

I’ll be honest, it took me a few minutes to figure out when you could use this feature, two situations came to mind but I opted for this one -> my apologies if it’s a rubbish example.

To keep things straight-forward we’ll stick with the majority of the setup from the previous post; an internal router is the only device that has been added to the diagram and the non-exist-map configuration remains in place.

Please take a look at the new network topology:

The aim of SanFran Systems is to only advertise their public network (146.55.43.0/26) to AS456 and AS789 if their private network (192.168.3.0/24) is available; the private network is where hosts on the inside of static one-to-one NATs are found, the public network provides the addresses for the outside of the NATs -> if the inside network isn’t available (and therefore the servers) SanFran Systems wish to withhold the advertisement of their outside network to AS456 and AS789.
In the case of AS789; the route should only be advertised if the private network is in the BGP table of SF_R1 and the 146.55.0.0/16 route isn’t being received from AS456 (non-exist-map + exist-map policy).  The private network has reached the BGP table of SF_R1 over an iBGP session being run with SF_R2 -> please remember, this is imaginary, I haven’t addressed the security side of things other than a lazy addition of a firewall symbol J

Our task detailed:

1a) If 192.168.3.0/24 exists in the local BGP table of SF_R1, then advertise the 146.55.43.0/26 route to ISP1_R1 (AS456) 1b)If 192.168.3.0/24 does not exist in the local BGP table of SF_R1, then do not advertise the 146.55.43.0/26 route to ISP1_R1 (AS456) ———————————————————————————— 2a) If 192.168.3.0/24 exists in the local BGP table of SF_R1 and we are receiving the  146.55.0.0/16 route from ISP1_R1 (AS456), then do not advertise the 146.55.43.0/26 route to ISP2_R1 (AS789) 2b) If 192.168.3.0/24 exists in the local BGP table of SF_R1 and we aren’t receiving the  146.55.0.0/16 route from ISP1_R1 (AS456), then advertise the 146.55.43.0/26 route to ISP2_R1 (AS789) 2c) If 192.168.3.0/24 does not exist in the local BGP table of SF_R1 and we are receiving the  146.55.0.0/16 route from ISP1_R1 (AS456), then do not advertise the 146.55.43.0/26 route to ISP2_R1 (AS789) 2d) If 192.168.3.0/24 does not exist in the local BGP table of SF_R1 and we aren’t receiving the  146.55.0.0/16 route from ISP1_R1 (AS456), then do not advertise the 146.55.43.0/26 route to ISP2_R1 (AS789)

Initial Configuration of SF_R1, new lines in bold, retained lines not:

router bgp 123  no synchronization  bgp log-neighbor-changes  network 146.55.43.0 mask 255.255.255.192  neighbor 146.55.43.1 remote-as 123  neighbor 146.55.43.1 next-hop-self  neighbor 146.55.251.13 remote-as 456  neighbor 146.55.251.13 route-map AS456_IN in  neighbor 146.55.251.13 route-map AS456_OUT out  neighbor 146.55.251.13 advertise-map SEND_THIS exist-map IF_THIS_EXISTS  neighbor 163.86.53.5 remote-as 789  neighbor 163.86.53.5 route-map AS789_IN in  neighbor 163.86.53.5 route-map AS789_OUT out  neighbor 163.86.53.5 advertise-map SEND_THIS non-exist-map IF_THIS_IS_MISSING  neighbor 163.86.53.5 advertise-map SEND_THIS exist-map IF_THIS_EXISTS  no auto-summary ! ip community-list 1 permit 123:456 ip as-path access-list 1 permit ^$ ! ip prefix-list ISP456_TRACK seq 10 permit 146.55.0.0/16 ! ip prefix-list CONDITIONAL seq 10 permit 146.55.43.0/26 ! ip prefix-list PRIVATE_NET seq 10 permit 192.168.3.0/24 ! route-map IF_THIS_IS_MISSING permit 10  match ip address prefix-list ISP456_TRACK  match community 1 ! route-map IF_THIS_EXISTS permit 10  match ip address prefix-list PRIVATE_NET ! route-map AS456_OUT deny 5  match ip address prefix-list PRIVATE_NET ! route-map AS456_OUT permit 10  match as-path 1 ! route-map AS789_OUT deny 5  match ip address prefix-list PRIVATE_NET ! route-map AS789_OUT permit 10  match as-path 1 ! route-map SEND_THIS permit 10  match ip address prefix-list CONDITIONAL ! route-map AS789_IN permit 10  set community 8061717 ! route-map AS456_IN permit 10  set local-preference 110  set community 8061384 !   Configuration explanation: The first two highlighted lines are for the new iBGP session required, the next two lines assign CR in the form of an advertise-map + exist-map to the neighbours in AS456 and AS789.  We then get into the route-maps…  we have been polite and filtered the internal private network from outbound advertisements, this has been done by adding lines above the existing “OUT” route-map permit lines to be able to selectively deny – in this case, a prefix-list that identifies 192.168.3.0/24 is matched.  The “IF_THIS_EXISTS” route-map that is referenced by CR has been created and also matches the same prefix-list, the “SEND_THIS” route-map then matches the existing “CONDITIONAL” prefix-list -> We want to advertise the route identified by “SEND_THIS” when the route identified by “IF_THIS_EXISTS” exists in the local BGP table.

So, now let’s test things… starting with the BGP tables of ISP1_R1 and ISP2_R1 after applying the configuration above:

ISP1_R1#sho ip bgp neighbors 146.55.251.14 received-routes *output omitted* *> 146.55.43.0/26   146.55.251.14            0             0 123 i     ISP2_R1#show ip bgp neighbor 163.86.53.6 received-routes Total number of prefixes 0

(note. “received-routes” = neighbor ‘ip-address’ soft-reconfiguration inbound)

That looks good, we are receiving 192.168.3.0/24 and 146.55.0.0/16 on SF_R1, so we should be sending 146.55.43.0/26 to ISP1_R1 and withholding our advert to ISP2_R1 until we stop receiving 146.55.0.0/16 from ISP1_R1 -> That fulfils the requirements of “1a” and “2a” -> let’s check the requirement “2b” by shutting down the interface connected to ISP1_R1:

SF_R1(config)#interface serial 1/0 SF_R1(config-if)#shutdown   After waiting a little while…. ISP2_R1#sho ip bgp neighbors 146.55.251.14 received-routes *output omitted* *> 146.55.43.0/26   146.55.251.14            0             0 123 i

Great, SF_R1 is sending its 146.55.43.0/26 route to ISP2_R1 because it has stopped receiving the 146.55.0.0/16 route from ISP1_R1 whilst still having the 192.168.3.0/24 route in its BGP table.  (“and breathe”)

Let’s address requirements “1b” and “2c” now.  We’ll start by doing a “no shut” on the interface previously shutdown and then after everything has stabilized we’ll shutdown the link to SF_R2 –the 192.168.3.0/24 route will no longer be received:

SF_R1(config)#interface serial 1/0 SF_R1(config-if)#no shutdown   … SF_R1(config)#interface fastethernet 0/0 SF_R1(config-if)#shutdown … ISP1_R1#show ip bgp neighbor 163.86.53.6 received-routes Total number of prefixes 0   ISP2_R1#show ip bgp neighbor 163.86.53.6 received-routes Total number of prefixes 0

Superb, the 146.55.43.0/26 route isn’t being sent to ISP1_R1 or ISP2_R1 when SF_R1 doesn’t have the 192.168.3.0/24 network in its BGP table.

That just leaves “2d”.  We’ll shutdown the respective BGP neighbors and not the interfaces this time -> “there’s more than one way to skin a cat”… 

SF_R1(config)#router bgp 123 SF_R1(config-router)#neighbor 146.55.251.13 shutdown SF_R1(config-router)#neighbor 163.86.53.5 shutdown   … ISP1_R1#show ip bgp neighbor 163.86.53.6 received-routes Total number of prefixes 0   ISP2_R1#show ip bgp neighbor 163.86.53.6 received-routes Total number of prefixes 0

And there we have it -> all requirements fulfilled

A new IOS feature has been announced that I think will prove to be a very useful tool in any network technician’s armory:

Cisco IOS Embedded Packet Capture

 

I was going to do ‘how-to’ on EPC but after a check on the web I found that CCIE in 3 Months has already done a great one… take a look here

A quick status update -> I’m currently putting the finishing touches to “Sovereign BGP – Part 2” and running through a ‘getting to know you’ exercise with the DocCD – more on that later.

New Cisco Validated Designs and Design Resources:

I thought some readers may find one or two of the links below of use:

Implementing Nexus 7000 in the Data Center Aggregation Layer with Services

Wi-Fi Location-Based Services 4.1 Design Guide

Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 7.x

Cisco Unified Contact Center Enterprise 7.5 Solution Reference Network Design (SRND)

Media Ready Network Architecture Overview

“Sovereign BGP cont… “+ an update on what I’ve been doing recently to come…

Sorry about the wait…

An interesting BGP configuration option I have recently come-across is the “Conditional Advertisement Feature” -> it’s been around for a while, and what it allows you to do is to apply policy to outbound BGP advertisements…

Two examples of the kind of export policy that can be performed are:

1)
“Only advertise “route A” when “route B” isn’t available”
the yang being:
“Don’t advertise “route A” when “route B” is available”

2)
“Only advertise “route A” if “route B” is available”
the yang being:
“Don’t advertise “route A” if “route B” isn’t available”

The core commands required to add advertisement policies are added to BGP configuration as neighbor statements and take the following form:

neighbor {ip address} advertise-map ‘send_this’ non-exist-map ‘if_this_is_missing’

neighbor {ip address} advertise-map ‘send_this’ exist-map ‘if_this_exists’

 

Let’s break that down:

The advertise-map name specifies the route map that matches routes that can have conditional advertisement policy applied against them; any routes not matched by the advertise-map cannot have conditional advertisement policy applied (and will always be advertised so long that nothing else is preventing it).

When a non-exist-map is used alongside the advertise map:
If ‘route A’ is matched by the advertise-map and ‘route B’ is matched by the non-exist-map, ‘route A’ will be advertised only when ‘route B’ is not present in the local BGP table.  If ‘route B’ appears in the local BGP table the advertisement of ‘route A’ will cease.

When an exist-map is used alongside the advertise map:
If ‘route A’ is matched by the advertise-map and ‘route B’ is matched by the non-exist-map, ‘route A’ will be advertised only when ‘route B’ is present in the local BGP table.  If ‘route B’ disappears from the local BGP table the advertisement of ‘route A’ will cease.

Notes.
- A “match” = route-map “permit” + referenced access/prefix/as-path list “permit”
– Any other combination = no match
- When a non-exist-map or exist-map is configured it is scanned for changes by the BGP scanner process every 60 seconds (be patient…)

So, let’s bring this to life (i.e. into the real world)… starting with an Advertise-Map with a Non-Exist-Map

Here’s a simple multi-homed setup:

AS456 is the primary ISP of “SanFran Systems” and AS789 is the backup ISP, AS456 is providing a full internet routing table and a default route whereas AS789 is providing just a default route.  SanFran Systems’ public address space is provided by ISP1.  The plan is to not advertise any local AS routes to AS789 so long that AS456 is providing us with the routes we need, this will be achieved by selecting a route originated in AS456 and tracking its existence in the local BGP table -> existence = don’t advertise anything to AS789, non-existence = advertise to AS789

Getting into the details, our requirements on SF_R1 are:
- If 146.55.0.0/16 exists in the local BGP table, do not advertise the 146.55.43.0/26 prefix to ISP2_R1.
- If 146.55.0.0/16 does not exist in the local BGP table, advertise the 146.55.43.0/26 prefix to ISP2_R1

Before getting into the configuration of conditional advertisement we need to ensure that the information it relies on is valid – we do this by giving the routes learned from each of the ISPs an identification to match against, by doing this we are being a little bit more pro-active vs reactive (I’ll explain more later), here is our initial BGP configuration on SF_R1:

router bgp 123  no synchronization  bgp log-neighbor-changes  network 146.55.43.0 mask 255.255.255.192  neighbor 146.55.251.13 remote-as 456  neighbor 146.55.251.13 route-map AS456_IN in  neighbor 146.55.251.13 route-map AS456_OUT out  neighbor 163.86.53.5 remote-as 789  neighbor 163.86.53.5 route-map AS789_IN in  neighbor 163.86.53.5 route-map AS789_OUT out  no auto-summary ! ip as-path access-list 1 permit ^$ ! route-map AS456_OUT permit 10  match as-path 1 ! route-map AS789_OUT permit 10  match as-path 1 ! route-map AS789_IN permit 10  set community 8061717 ! route-map AS456_IN permit 10  set community 8061384  set local-preference 110 !   Configuration explanation: In this base configuration we are preventing AS123 from becoming a transit AS by affecting outbound policy towards both AS456 and AS789 using an AS path list to filter. The “set local-preference” line causes BGP routers in AS123 to prefer routes received from AS456 over AS789 -> i.e. the default route. We are also setting unique community tags on routes as they are received inbound from AS456 and AS789 -> 8061717 = 123:456 and 8061384 = 123:789

Here’s a snapshot of the BGP table of ISP2_R1 following the configuration above:

ISP2_R1#show ip bgp neighbor 163.86.53.6 received-routes *output omitted* *> 146.55.43.0/26   163.86.53.6              0             0 123 i

Our aim is to stop the advertisement of 146.55.43.0/26 from SF_R1 whilst it is still receiving routes from ISP1_R1, here is how we do it:

ip community-list 1 permit 123:456 ! ip prefix-list ISP456_TRACK seq 10 permit 146.55.0.0/16 ip prefix-list CONDITIONAL seq 10 permit 146.55.43.0/26 ! route-map IF_THIS_IS_MISSING permit 10  match ip address prefix-list ISP456_TRACK  match community 1 ! route-map SEND_THIS permit 10  match ip address prefix-list CONDITIONAL ! router bgp 123  neighbor 163.86.53.5 advertise-map SEND_THIS non-exist-map IF_THIS_IS_MISSING ! exit ! exit clear ip bgp 163.86.53.5 soft in   Configuration explanation: A permit line in the advertise-map named “SEND_THIS” references a permit line in a prefix list, thus causing a match (or a “1” vs “0” in my mind – does anybody else think like that?).  This is the route that will be advertised when any routes matched in the following non-exist-map aren’t present in the local BGP table. The following non-exist-map named “IF_THIS_IS_MISSING” references not only a prefix list but a community list – the prefix list defines a route to track and the match on community ensures that we have learned the route from the correct place -> it’s quite possible that the conditional advertisement feature can fail because the route you are tracking is also received from another source (i.e. AS789)… <- see my reference to being pro-active.  Using a community list is one way to do this but others exist – such as using an AS path list…

ISP2_R1’s BGP table following the change:

ISP2_R1#show ip bgp neighbor 163.86.53.6 received-routes Total number of prefixes 0

 

So it’s working up until now, lets shutdown the link to ISP1_R1 and see what happens:

SF_R1(config)#interface serial 1/0 SF_R1(config-if)#shutdown   After waiting a little while…. ISP2_R1#show ip bgp neighbor 163.86.53.6 received-routes *output omitted* *> 146.55.43.0/26   163.86.53.6              0             0 123 i

Success!

More to come…

A quick update on what I’ve been up-to…

I travelled to Lancaster University this morning to take the 350-001 exam, and I……

 

 

 

 

 

 

*PASSED*

Woohoo!
Now, that’s not an easy exam!  My head was hurting afterwards, although I think part of that is the after-effects of trying to judge when a typo in a question is in fact a typo!  Oh and when a question instructs you to view the configuration “shown” and guess what… no configuration is there!  I think I need to find a contact in the States whilst my head still hurts.

What now?  I need to take a step back and work out the best route to Brussels…
During this time I also need to rebuild my home PC, fix a few PCs for family members, reply to a few e-mails (sorry if you’re reading this after sending me one and you are still waiting for a reply), learn some UC stuff (enough to make people think I’m becoming a “specialist”), and finish my non-exist-maps break-down.
I plan to take a look at the 360 program to see if it’s the right choice for me, and actually earn the privilege of my name being put down as a developer of the CCIE Command Memorizer by David Bombal.  A study plan will also be needed; one that is a little bit more “dynamic” in nature (just take a look the end date on my written study plan hehe)

More from my adventures @ Cisco:
I attended a one-day course at Bedfont Lakes last Monday and got chatting with the instructor – he joined Cisco as part of the Selsius acquisition when Cisco first moved into the VOIP space, he currently contributes to the development of the CCIE Voice certification.  Anyway, moving along, whilst chatting I caught “weather pack” and “7970 in my shower”… I said “hang-on, you have a 7970 in your shower!” and the reply was that he had setup an XML app so that he could watch programs on the BBC iPlayer while showering! -> I think I’m going to have to step my geekness up a level if I want to mix-it with the big boys @ Cisco :- )

Lastly, check out Performance Routing

I received a “Green Update” e-mail today and after glancing over the subjects something caught my attention:

“Announcing time–based PoE on all modular Catalyst PoE linecards – EEM script solution to turn off PoE devices based on time – First platforms to offer PoE, ePoE management through switch – Script for Catalyst 6500 at: TIME BASED POE SCRIPT – Script for Catalyst 4500: look for an announcement soon With the support of EEM and scriptable actions, it’s possible to schedule the activation of PoE for a ‘time-based’ operation. This can have a very significant impact for large IP Telephony installations where voice services are not needed during non-business hours.”

 

Here’s a script that can turn-off telephones during non business hours – if nobody is in a building why power all of the phones?

Two TCL scripts are included in the download, one to turn-off PoE enabled interfaces and a second to search for PoE interfaces in an “off” state and enable PoE again.  EEM triggers the scripts using Cron at customizable times each day (e.g. 6am and 8pm)

Impressive stuff!

 

A quick update on my studies:

As you have probably noticed I’ve not been blogging to often recently – the reason is because I have given myself a strict schedule between now and my ‘most recent’ exam date.  I have setup a series of Outlook appointments telling me what I should be studying each night – I’m adamant that I won’t put my exam date back again and that’s why I’m being ultra-strict with myself.
During my most recent look at BGP I came across the very interesting “non-exist-maps” and “exist-maps” – I have started a post about them and will aim to get it finished in the near future…

Ever wanted to be involved in the development of a new Cisco feature?

Well, now you have the opportunity – Cisco is offering a pretty juicy $ reward for anybody that can develop a new Linux based application using the Cisco Application Extension Platform (AXP) to be placed on an ISR service module.  Don’t be put off completely if you’ve thought of the best idea since sliced bread and you’re not a fully fledged “coder” – some help may be available.  So, go on – “think inside the box”

Hi All,

I have to admit that I’ve been an awful blogger recently L (sorry!), I’m hoping to improve things in the near future – since starting @ Cisco I have been studying in sporadic spells of time instead of a fixed 2 hrs each evening which in-turn has caused me to neglect this blog…

Anyway, I’ve got a few little things to update you on:

1) I’ve been tasked with becoming a “semi-specialist” in UC by my manager – this is due to a need for additional LGov UC resource.  What this means as far as I’m concerned is that I have a much bigger gap in knowledge to fill (compared to R&S) and therefore any spare time I have during the working day will more than likely be spent trawling through endless docs and labs making sure I’m up-to the standard I would expect if I were a customer – on a business and technical level that is.  It’s a challenge I’m ready for and I always welcome additional knowledge to store in my memory banks.  It has been said to me in the past that Cisco tends to keep employees outside of their comfort zone – I have a feeling that this also contributed to the decision on what my specialisation will be…  Just to clarify – I do still have the full support of Cisco for my R&S CCIE quest J

2) David Bombal has continued the development of the Command Memorizer tool – it was already a great learning aid and his commitment to the development of it is great to see.  A number of other bloggers in the community have now used the software and some reviews are linked on the product page.

3) A new consolidated source for Enterprise Technical content has been launched on cisco.com – it’s called “Design Zone”.  It’s organized around Network Architectures, Technologies and Vertical Industries and brings Cisco Validated Designs, legacy design guides and SRNDs, white papers, podcasts, videos together in one place – check it out @ www.cisco.com/go/designzone

4) I received an e-mail whilst in the office announcing that Solarwinds Real Time Netflow Analyzer is now free – a great tool to get started with Netflow…

5) From another e-mail –> Ever wanted to search cisco.com, the IOS bug database, or the command lookup tool from the search box in IE or Firefox? –> add the Cisco.com Searches and Tools to Your Browser (instructions are included)

6) Another e-mail –> CCIE SP Mini-Scenarios by Antonio Soares – definitely worth taking a look at if you’re studying or interested in the CCIE SP track

7) I’ve been fortunate enough to come across some great presentations (with audio) down one of the dark corridors of the intranet here at Cisco.  I have watched some advanced (some of it is very advanced!) breakdowns of “Spanning Tree”, “MLS QoS”, and “RACLs/VACLs/PVLANs” – I’m very confident with Spanning Tree and the presentation confirmed that I should be able to deal with any STP tasks thrown at me in the exams, I did however learn one or two new things from the “MLS QoS” and “RACLs/VACLs/PVLANs” breakdowns.
I thought it would be nice to share some ACL theory with you to see whether it is known/used in the wild by anyone?  If not, and you’re currently studying towards the CCIE R&S, I just know you’ll be really happy with me for introducing you to some extremely technical non-blueprint information after reading this J

Let’s start with a simple “Yes or No” question:

Q) You’ve just added an ACE to an ACL and now your being told that your switch’s TCAM is full, will the ACE still be added and processed by the switch?           A) Yes, the route processor will process the ACE after the rest of the ACL has been handled by the TCAM

Relatively easy if you’ve read a bit about the subject.  Now, let’s get deep into ACLs, and how they affect hardware resources…

Take a look at the following configuration on a 6500: 10  access-list 101 permit udp 10.0.0.0 0.255.255.255 range 16384 32767 172.16.0.0 0.15.255.255 range 16384 32767 20  access-list 101 permit udp 10.0.0.0 0.255.255.255 range 16384 32767 192.168.1.0 0.0.0.255 range 16384 32767 30  access-list 101 permit udp 10.1.0.0 0.0.255.255 host 192.168.1.1 eq 53 40  access-list 101 permit udp 10.2.0.0 0.0.255.255 host 192.168.1.1 eq 53 50  access-list 101 permit tcp 10.1.0.0 0.0.255.255 10.20.0.0 0.0.7.255 eq 80 60  access-list 101 permit tcp 10.1.0.0 0.0.255.255 10.20.8.0 0.0.3.255 eq 22 70  access-list 101 permit tcp 10.1.0.0 0.0.255.255 10.100.0.0 0.0.15.255 gt 1023 80  access-list 101 permit tcp 10.2.0.0 0.0.255.255 10.200.200.0 0.0.0.3 eq 22 90  access-list 101 permit tcp 10.2.0.0 0.0.255.255 host 192.168.1.2 eq 443 Q1) How many “Mask Patterns” exist in the ACL? Q2) How many “Mask Slots” will the ACL below consume in the TCAM? Q3) How many “L4 Ops” are in the ACL? Q4) How many “LOUs” does the ACL populate?         A1) A “Mask Pattern” is a unique mask length in an ACL.  The unique masks from the ACL above are 255.0.0.0, 255.240.0.0, 255.255.0.0, 255.255.240.0, 255.255.248.0, 255.255.252.0, 255.255.255.0, 255.255.255.252, and 255.255.255.255 (“host”), and therefore, 9 “Mask Patterns” exist. A2) A “Mask Slot” stores Mask Patterns.  Each slot has space to hold 8 patterns and slots are created each time space runs out (i.e. 8 patterns = 1 slot, 9 patterns = 2 slots, 16 patterns = 2 slots, 17 patterns = 3 slots etc etc) .  The number of slots used by the ACL above is therefore 2 –> The 9th pattern triggered the 2nd slot. A3) A “L4 Op” (“Layer 4 Operation”) is an occurrence of a “gt”, “lt”, “neq”, or “range” keyword in an ACL – all of which require some level of software processing.  “eq” is not included as they are dealt-with by hardware.  If the same L4 Op occurs at the same point of two ACEs it only counts as 1 L4 Op (e.g. see lines 10 vs 20 – “range 16384 32767” = 2 Ops and not 4).  The answer to this question is 3 – in lines 10, 20,  and 70. A4) A “LOU” (“Logical Operation Unit”) stores L4 Ops.  Each LOU is made-up of two hardware registers.  ACEs that include a “gt”, “lt”, or “neq” consume 1/2 LOU, whereas the “range” keyword consumes one full LOU.  The LOU registers are system wide, the number available is platform independent, they are shared between ACLs and QoS, and if all LOUs are populated additional ACEs are processed entirely in software.  The number of LOUs populated by the ACL above = 2.5 –> 1 + 1 + 0.5

Believe me, that stuff is the just tip of the iceberg!  And my explanations probably don’t tell you everything you need to know to understand what’s going-on.  The general rule is that a hardware limit for each one of the items above exists, and software will be used after the limit has been reached (possibly affecting perfomance).  For more information click here.

8- After having a few questions fired at me by Channel Partners and Customers during my first few days on the job I realised that the answers might be of use to the readers of this blog, here a couple, I’ll try to publish the interesting/useful ones as they come along:

Q1) “Is it possible to field upgrade a Cat 6509 chassis to a 6509-E. Reason for doing this is to install a SUP-720-10G initially with a view to implementing VSS next year. Looking on CCO it says SUP-720-10G is supported in a 6509 chassis but doesn’t confirm this will work with VSS? After a chat this was translated to: “Will the VSS SUP720 work in the standard 6509, and if the answer is yes, can a VSL (VSS) be created between a standard 6509 and a 6509E?” A1) Yes and Yes: “From a chassis perspective, both E-Series chassis and non E-Series chassis are supported within a Cisco Virtual Switching System environment, with the exception of the Cisco Catalyst 6503 (non E-Series) and Cisco Catalyst 6509-NEB” “It should be noted that there is no requirement that the two members of the Cisco Virtual Switching System use the same chassis type. The members consisting of the Cisco Virtual Switching System can be different chassis with varying slot counts” Q2) “The Unified Communications 500 series ‘Baby Call Manager’ – does this support 7941, 7911 & 7921 wireless handsets. The data sheet suggests it does but I’ve got people telling me it doesn’t. Was hoping you could clarify??” A2) Yes, it does support “standard” Cisco UCM compatible phones