Hi, it’s been a while since I logged onto here!  I just thought I’d put a little notice up to let you know that I’ve now started blogging again.  The general subjects will be Data Centres, Data Centre Fabrics, Virtualisation, Cloud, XaaS, Orchestration, Automation and Programmability.  There you go, more buzz words than you can shake a stick at!  I promise those words will only be used sparingly on the new blog!

http://snapshotsofrelevance.com

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”