Saturday, 28 May 2011

Drinking from the Firehose (Narbik's Bootcamp Review)

Caution: Big wall of Text Warning!  If you're a TL:DR (Too long: Didn't Read) type of person maybe skip this post or just jump down to the conclusion.
 
At the time of writing (the Saturday after the bootcamp) I'm still recovering from the marathon Routing and Switching bootcamp that was run by Narbik from Micronics Training in Sydney, Australia between May 23 2011 and May 27 2011 but I wanted to give some impressions as to what I thought about it because when the opportunity to take a bootcamp came up, I wanted to be sure that I was spending my money (and time) wisely.  This is obviously all my opinion about my experience but I figure I'll try to give as much relevant information as to the bootcamp and the surrounding environent as possible because if you're going to be spending a lot of money on a bootcamp especially if its your own you want to know what your in for and what you get and what you need.  Your experience may be slightly different even if you do it in Sydney.

The class size with around 14 students with slightly more depending.  The reason for the slightly more is that once you have attended one of Narbik's bootcamps you are welcome to re-attend it for free.  Please note that this doesn't cover the Cisco 360 material (I'll get into that shortly) nor the use of Narbik's lab equipment (however you can rent a lab for what appears to be a very modest fee indeed, use your own rack at home if you have remote access, or simulate the topology using dynamips but accepting that you wont be able to do the advanced Cat 3560 features).  So during the bootcamp there were a few guys who popped in for a couple of days to brush up on some of the topics.   Actually when I asked the re-attendees if what was being presented was exactly the same, they mentioned that the information itself didn't really change but that in some areas Narbik was presented in a slightly different but more easily to understand manner which suggests that he's continuously refining his delivery method based on feedback.

Our class was located right in the Sydney Central Business District - initially on the website (before the class was 100% confirmed - I believe that there is a minimum of 7 new students required before a class can take place - so if you're looking at trying to get a bootcamp happening in your area if you can get close to 6 like minded mates together, it might be worth seeing if something can be arranged) it mentioned North Sydney and listed some hotels in the area.  I had booked a hotel in North Sydney (wanting to be in easy walking distance to the training centre) so was a little surprised when the venue had changed to the Sydney CBD itself (fortunately I didn't pre-pay my accomodation so I was able to re-book somewhere else without paying a fee) I would strongly suggest that rather than just reading the location on the website that you send an email to the people at Micronics to check.  It still may be worth foregoing any pre-payment discount just in case for whatever reason the course gets relocated or postponed)  I actually think that the different location was much better because North Sydney seems to shutdown not long after 5pm, where in the CBD is right near entertainment venues and many resturants etc so it was easy to get food at any time and there was a major grocery store (Coles) in very close proximity so getting your own supplies was easy.

Part of the way that the bootcamp costs are controlled is that you need to bring your own equipment - bring your own laptop - pretty much you just need something with a web browser and a telnet client.  While you could probably get by with linux, some of the material you get access to are locklizard protected PDFs so it might be a problem.  The material from Narbik can be read on Mac OSX but for some reason the Cisco 360 Assessment Lab Answer keys cannot be read on OSX (requiring a virtualised XP/Windows 7 instance or bootcamp to read it)  Network access provided was wireless (not so good most likely because other businesses in the building with their own wireless networks going) so I used the wired network which was very reliable and fast.  Besides bringing your own laptop, any meals, snacks, note pads, pens etc - bring that yourself.  As I said due to the location it was easy enough to be able to get your own stuff pretty much at any time (Coles for instance would open at 6am and close as midnight) with plenty of fast food options nearby with China town not that far of a jump for a more substantial feed at the end of the day if you so chose.  Actually I know a number of guys brought lunch/dinner from home and were able to use the fridge/microwave at the training centre to keep their food, so if you're on a tight budget that might help you some too.

A number of the guys in the class were Sydney based and took public transport to the site which just because they lived a fair way out could take over an hour in travel in each direction and worse outside of peak travel times.  The hours of the bootcamp are going to be longer than a typical workday, so if you are able to, it could be worth looking at getting a hotel room nearby just so you can cut down on that (there is some homework that you don't have to but if you can you should be doing - knocking out 2 hours of travel so you can do that may be a good idea, so you can get some sleep in - it's not essential but it may help you get that little bit more out of your bootcamp experience)


Okay, so you've decided you're going to do the bootcamp - you book the class, and pay your money.  Not too long later you'll get some workbooks "The Foundation Volumes 1 and 2" from Janet (Narbik's wife) that are in your interests to go through prior to attending the bootcamp.  These are the first of the locklizard protected workbooks you get.  If you have performed these labs or are familiar with the topics, you are going to get the most out of the bootcamp.  To be honest I looked through these but didn't do the labs (I have been doing my lab prepation with another training vendor's materials)  If you come to this bootcamp towards the beginning of your CCIE study journey rather than towards the end like myself, I think this material will be very beneficial and you may not need to necessarily look elsewhere.  So while there is probably an advantage to booking onto the bootcamp early to get access to these workbooks early to prepare yourself for the bootcamp, I did ask Janet if I purchased the workbooks on their own - if I would get a discount from the bootcamp fee and she indicated that this was the case.  I guess if you wanted to dip your feet in the water and de-risk things for yourself, I guess you can start with just purchasing the foundation workbooks, see if you like the labs and style (the bootcamp labs use the same topology) and then sign up for the bootcamp.   Please note that the foundation workbooks themselves are not actually used or referred to in the bootcamp and are simply there to help ensure you have the fundamentals down in order to get the most out of the bootcamp.  Coming up to the bootcamp you'll need to have a valid cisco.com account, Janet will ask you for your details since the Cisco 360 program uses those credentials to send you your relevant information and setting things up for Cisco 360 rack access.  During the bootcamp you will have access to two racks.  One rack will be a Cisco 360 rack which you really only use for the Assessment Labs and another being Narbik's.  Everyone has their own gear, there's no sharing.  Access to the labs is via a terminal server so if you prefer to have a separate telnet/ssh session for each device or just go through the terminal server and using the control shift 6 (or whatever it is - that's not the way I work my lab) you can go that way.

The day before or the day of the bootcamp, you'll get the access credentials from Cisco 360 and you'll get a bunch of other workbooks from Janet.  You'll get the Advanced Routing and Switching 4.0 Workbooks Volumes 1 and 2 - which have the worked out labs inside (other vendors may call this the detailed solution guide) You'll also get the Bootcamp 4.0 Workbook (again with worked out labs and explanations) and initial configurations for the Bootcamp Workbook labs.  These workbooks are actively being worked on and Narbik was mentioning that there are some new sections being added which will be get access to (that said these are very comprehensive as is)

The reality though, is that this is a 5 day bootcamp and there is no way to cover this all in depth, so only a limited list of the blueprint topics can be covered.  That's not to say that Narbik wont talk to you about an area you are having issues with - its just that to cover all of the topics listed with the depth required, it's impossible to touch everything (I think if you were to look at the Services portion of the blueprint you could have a dedicated bootcamp just for that)

Day 1 (Monday)
Just about everyone shows up just before 9am bright-eyed and bushy-tailed ready to get into it, if they are like me they have heard all the good things about Narbik and are wondering if he's 10 feet tall and can fix faults by staring hard at routers.  Well, he's not 10 feet tall and I don't think he stares hard at routers to fix problems, though perhaps he looks intently at telnet sessions - he's a very likable and knowledgable person.  He very quickly goes into his background and puts down what the agenda for the following days are going to be and then goes around the room asking us to talk briefly about ourselves, what we do, where we are at with our studies, if we have a lab date scheduled yet, if we have already attempted the lab and what we want to get out of the bootcamp.  If I remember correctly, at our bootcamp Multicast and MPLS were hot topics (mine was L2 QoS)

After that we pretty much jumped into the Cisco 360 lab racks and started on an 8 hour Assessment lab exam.  It wasn't the hardest of exams but I think it was good thing to do, as it helps Narbik gauge what else the class might be have problems with and can ensure that those topics are particularly re-enforced throughout the bootcamp.  Also for myself it helped to clarify what topics I might need to attention on.  The Cisco 360 Assessment Labs are automatically graded but besides being sent the answer key (this is the file that can only be opened in windows) their is a web page that takes your configs and compares them with the reference configs, allowing you to see side-by-side of what you did vs what the recommended method was.  Besides that, you could simulate the commands "show ip route", "show ip bgp summary" and many many more on the simulation and see what you had and should have seen, very nice but probably better if you had more time to review.

After the Assessment Lab we started on the switching lecture, there's a level of expectation here, so we dont go into STP and basic stuff like that, rather it's more on the security related features including port-security and dhcp snooping and a good session on Private VLANs and dot1x.  The next session goes into Frame-Relay topics.  All of these lectures are Narbik standing at a whiteboard going through the topics in what is obviously orchestrated to go through a sequence (to ensure nothing gets left out) but is certainly free-flow with active discussion with the class.  One of the things that comes to light early on is that Narbik has a great passion to teach and has a great desire to ensure that any uncertainties someone has, things are clarified using different examples until they comprehend a topic.  I think one of the things that Narbik enjoys is seeing someone's expression change from looking quizzical about something to looking satisfied that they understand the how and why.

At around 9:30pm we leave the class to go home or back to our hotels with the advice to do some of the Frame-Relay labs from the Advanced CCIE Routing and Switching lab book

Day 2 (Tuesday)
Most people show up around 9am a little tired and ready to get into it - some of the guys probably weren't quite prepared for the length of the day (and if you factor in the travel time they might have had, they would have had very little sleep if they spent a couple of hours or labs) which is really just sign of things to come.

We spent a few hours in the morning doing some more Frame Relay Labs.  The point of the bootcamp is not just to get a face full of lecture but to also play with the equipment, observe the behaviour, verify it and take advantage of Narbik (and the other students) to help clarify your problems or misunderstanding (as a student I find trying to explain how things work to someone else, helps me ensure that I actually know it)

The two topics under discussion are OSPF and EIGRP with most of the day associated with OSPF.  To be honest coming in I thought I knew OSPF pretty well but now I understand it a lot better, particularly in areas around filtering and summarisation.  Narbik made it a point to talk about things from an IOS point of view rather than what RFCs say.  Even then sometimes IOS documentation can be ambiguous at best or misleading in other cases, so whatever Narbik described as a behaviour, he was able to back what he was saying with labs in his workbook (the whole bootcamp is done that way, so he can back up anything he says with a demonstration)

At around 9:30pm we leave the class to go back and do some OSPF labs.

Day 3 (Wednesday)
Not too long after 9am most people are ready to start, the enthusiam is still there but people are starting to look a little weary but Narbik is like the Energizer Bunny and is ready to go like its his first day.  After doing more OSPF and EIGRP labs in the morning.  The main topics for the day are BGP, MPLS and L3 VPNs including the different CE-PE routing protocols and possibly implications you need to be aware of.

We finish up the around 9:00pm as Thursday was going to be a long day indeed...


Day 4 (Thursday)
Everyone is looking a little rough around the edges and kind of dreading what a long day it's going to be, that is everyone except for Narbik who is fresh as a daisy.  I've had so much coffee, that the guy at the coffee shop starts making my coffee before I order it - I've become a regular there in less than a week!

After a few hours of labbing, the QoS lectures kick in.  Starting with MLS QoS which was a particular topic I don't know if I was looking forward to as such but certainly wanted to ensure that I would help get some clarification as to how things work, particular around the srr-queue area.  The lecture was great, I've taken a lot of notes in that area now and have access to some good labs to help crystalise my thoughts further.  We then go stuck into L3 QoS primarily on FRTS and CBWFQ.

At around 6pm we started the troubleshooting portion of the Cisco 360 Assessment lab which went for about two and a half hours.

After this we had a dinner break and the Assement lab Configuration portion started at 10pm with 6 hours to complete the tasks. There was enough time for some of the locals to head home to do that component.  I stayed at the class because my hotel internet connection was pretty average and it was a short walk from the class room to the hotel.  At around 4am I saved my configs and walk to the hotel and organised a wake up call for 7:30am since I needed to get ready for check out to fly home on Friday evening.  After being pumped up on caffeine and sugar for most of the night, towards the end I was stuck in a task because the router was doing what I was telling it do to do, rather than what I though I was telling it to do :)

We were told roughly that if we were to put the level of difficulty of the Monday Assement lab as 3, that this might be considered about a 9, however this was not really analagous to the actual R&S Lab and that doing well in this was not a guarantee that you would pass the R&S Lab exam but to be used as a datapoint in determining your readiness.

That said, one of the advantages of doing this bootcamp is with the association with the Cisco 360 program, if you do well in the assessment labs, you can qualify for a free lab re-take voucher.

Day 5 (Friday)
Around 9am the classroom was half empty and those that are present are looking like extras from a zombie movie except for Narbik who looks like he has just had 2 weeks of vacation.

No one really feels like labbing this morning, so it's mainly chatting about how things went in the Assessment lab until more and more people come back to class.

The topics covered today are Multicast, and the other sub-topics we didn't quite finish on previous days (things like ZBPFW and class based policing)

Upon closing Narbik mentioned about the free re-attendance to the bootcamps for past students in the same track (as I mentioned there were some guys here doing just that) and that he expected that we treat the bootcamp as the beginning of our relationship with him, the expectation of using email and forums with him and other students to help clarify problems or concerns.

He also again re-iterated that the bootcamp didn't cover all of the topics of the blueprint, there just isnt enough time, however the workbooks (which I believe are subject to free electronic updates) do cover these topics.


Overall conclusion
I really enjoyed this bootcamp.  If I were to do things differently, I would probably have looked at attending one of Narbik's bootcamps earlier into my studies, gone through his workbooks and then re-visted his bootcamp within a few weeks of attempting the lab.  This hasn't worked out that way in my case but I think the current preparation that I have done (using material from other vendors as my prime resource) has helped me, with this bootcamp enabling me to solidify what I do know and helping to uncover what I thought I knew but didn't.  I will be attemping my lab exam in a few weeks, and I will most certainly be using the material in the workbooks as well as my notes to do my final bit of preparation.  Should I not pass on the first attempt which is a possibility, I will certainly look at taking advantage of the lab re-take voucher and again make use of the material.


The ratio of labbing to lecture was around 40:60 but that is kind of skewed with the assessment (mock labs).

Being with a bunch of people where you can talk directly and/or draw on a whiteboard your problem and get help either from Narbik or your fellow students just isn't as easy to get from mailing lists and forums (which I most certainly have used)

How do I rate the workbooks?  I haven't had enough use to give a comprehensive review but so far I think they're great, they're different in format to the other vendor's material I've used (Narbik's topology is slightly smaller but I believe is on par with the CCIE R&S Configuration topology), I don't necessarily think they're better or worse, the labs in Narbik's workbooks appear to focus on individual subtopics.

I haven't been on another bootcamp so I cant compare it to anything else.  I have used Video on Demand material which simulated a one week bootcamp and while I did get value from the VoD, a prerecorded non/dynamic environment is just not the same as being able to interact directly.

It does appear to be a program that you could follow with a single investment of the bootcamp which includes the workbooks and a training sessions from an instructor that really knows his stuff, and is passionate about transferring his knowledge to you.


I liked the idea of the mocklabs but that's probably because I'm closer to sitting the exam than most of my other classmates (plus that lab voucher is a good draw card to the bootcamp) however I do see an advantage to covering the same level of material in smaller assessment labs spread out across the days so you don't have such an overload on the second last day.  Spreading it out may mean that there is more information retained on Day 5 - Narbik mentioned that this might be on the cards for future bootcamps so get in touch with Micronics for the latest information in that area.

I kind of hope I don't come across as some kind of religious fanatic praising Narbik or his methods, I'm just attempting to help those that may be trying to determine if they want to go on a bootcamp, what they need to put in to get value, and what they get for their money for the one I went to.  Pass or fail the Lab, it will be down to the individual and not the training vendor, regardless of the training vendor and the material used, all that can do is help unlock the knowledge required but its the perserverance, determination and desire of the CCIE candidate to achieve the status.

I hope that this rather long posting should anyone read it helps someone determine if they want to go on a bootcamp what they might expect, or even if they were interested in starting their CCIE studies, how a program such as this one might help them along.  I think going for a CCIE is possibly like scaling a mountain, it's not really a race, it's something you pretty much have to do yourself but there can be people around to help you out but it's up to you to get to the peak and it's great that there is a whole community of training vendors, CCIE candidates and CCIEs and others out there helping us all to success.

Saturday, 21 May 2011

Study Update (Lab attempt #1 is approaching)

With nearly three week until I face off against the lab, I'm travelling to Sydney this weekend to take part in one of Narbik's CIERS-I bootcamps - I've been warned to get plenty of sleep before hand because there's a lot of material to cover and some long days indeed including two mock lab exams.  I'm definitely looking forward to meeting Narbik and the rest of the CCIE candidates, I know at least David will be there too.

I think my preparation is going well but I'm sure it can always be better...

I've nearly completed the IPExpert Volume 3 Workbook - for those unaware of what it is about, it covers 10 simulated lab examinations each with a two hour troubleshooting and six hour configuration section.  Generally I have found these quite challenging, not in depth of technology, since the IPExpert Volume 1 Workbook did a pretty good job drilling into detailed labs focusing on specific technologies, and the IPExpert VoD has helped clarify things a lot (the biggest downside for the VoD is that lectures that cover a topic go for a couple of hours, so if you are wanting to hear about a specific sub topic it can be difficult to get to the exact stage - a recent example for me is going through the QoS material where I felt pretty comfortable with most of it but wanted to jump to the Catalyst QoS - I hope in future versions IPExpert consider breaking things down into more digestable chunks for revisting specifics)

Originally I wasn't actually planning on attending the bootcamp at all, because there is a serious cost associated with it, and also there aren't really that many training vendors that come out to Australia, so I was hoping that the VoD and plenty of self study and hooking into online resources like the fantastic Group Study and IPExperts OnlineStudyList mailing lists and forums like Internetwork Expert's as well as the multitude of great blogs and of course the Cisco documents and in all honesty I think that would be fine on its own; however some good happenstance with the alignment as to when a bootcamp became available, and a rough timeline as to when I thought I might be ready to face the lab (and there's nothing like scheduling a date for an exam to make you pull your finger out and get cracking) and the opportunity to take the time off work as well as scrounging up the finances together for flights/accomodation/meals/bootcamp means that I am hoping that this will increase my understanding of topics, and maybe pass the lab the first time around.  At the end of the day though, pass or not pass it's all down to me (unless there is some force majeure or equipment failure).

Which parts of the lab concern me the most?  I don't think it's the technology so much - I think I have a pretty good handle on most of that, it's more along the lines of reading the question/task and reading the implications of what needs to be done.  The fact that a subsection/ticket that is worth multiple points is an all or nothing affair (partly right is 0 points) can have a significant impact on making it through or not.  Also time management - when I started the practice labs I tended to need an extra two hours, now I seem to need an extra 30 minutes, so I think my process is improving but I think controlling time is going to be a key thing, knowing when to stop and move on.

It will be interesting to hear at the bootcamp what is concerning the other candidates, I'm looking forward to it!

Tuesday, 10 May 2011

IPv6 over MPLS (6PE)

There are multiple ways to tunnel IPv6 over IPv4 based networks, however if tunnelling using tuneling interfaces such as used in GRE tunnels for whatever reason is not allowed, one method is to tunnel IPv6 over MPLS

In this example, R6 will be an IPv4 only router (MPLS P Router) that with R5 and R7 acting as IPv6 PEs (though for the base routing instance, not IPv6 VPNs)


Topology Description

                R4========R5========R6========R7=========R8
Layer 2            Ethernet Ethernet  Ethernet   HDLC
Layer 2.5                     MPLS      MPLS
Layer 3              IPv6     IPv4      IPv4     IPv6
Routing Protocol    OSPFv3   MP-BGP    MP-BGP  IPv6EIGRP


Router Configurations

Routers are 3725s emulated in dynamips

R8#sh ver | I IOS
Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T14, RELEASE SOFTWARE (fc2)


R4 is running OSPFv3 process 1 and has Loopback0 directly in OSPF process 1 (if instead of this Loopback 0 was redistributed into OSPF and therefore was shown as an external route to OSPF, when R5 redistributes OSPF into the BGP IPv6 Unicast address-family, you would need to specific the "external" keyword)

I prefer to manualy set the link-local IP addresses on external interfaces

R4
hostname R4
ipv6 unicast-routing
ipv6 cef
interface Loopback0
no ip address
ipv6 address FEC0::4/128
ipv6 ospf 1 area 0
!
interface FastEthernet0/0
description R5 Fa0/1
no ip address
ipv6 address FE80::4 link-local
ipv6 address FEC0:45::4/64
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 4.4.4.4
log-adjacency-changes
passive-interface Loopback0


R5 is running OSPFv3 with R4 and OSPFv2 with R6. MPLS is enabled between R5 and R6 with R5 a route-reflector client of R6

R5
hostname R5
ipv6 unicast-routing
ipv6 cef
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface FastEthernet0/0
description R6 Fa0/1
ip address 192.168.56.5 255.255.255.0
mpls ip
!
interface FastEthernet0/1
description R4 Fa0/0
no ip address
ipv6 address FE80::5 link-local
ipv6 address FEC0:45::5/64
ipv6 ospf 1 area 0
!
router ospf 1 log-adjacency-changes
network 5.5.5.5 0.0.0.0 area 0
network 192.168.56.5 0.0.0.0 area 0
!
router bgp 64512
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 6.6.6.6 remote-as 64512
neighbor 6.6.6.6 password secret
neighbor 6.6.6.6 update-source Loopback0
!
address-family ipv6
neighbor 6.6.6.6 activate
neighbor 6.6.6.6 send-label
redistribute ospf 1 metric 100 include-connected
no synchronization
exit-address-family
!
ipv6 router ospf 1
log-adjacency-changes
redistribute bgp 64512 metric 100
!


R6 is running OSPFv2 with R5 and R7. MPLS is enabled on R5 and R7 facing interfaces and R6 is a route-reflector and using peer-group configuration. There is no IPv6 link configuration on R6, only the MP-BGP IPv6 unicast address family definition (which requires us to enable ipv6 unicast-routing to be able to configure)

R6
hostname R6
ip cef
ipv6 unicast-routing
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
interface FastEthernet0/0
description R7 Fa01/0
ip address 192.168.67.6 255.255.255.0
mpls ip
!
interface FastEthernet0/1
ip address 192.168.56.6 255.255.255.0
mpls ip
!
router ospf 1
log-adjacency-changes
network 6.6.6.6 0.0.0.0 area 0
network 192.168.56.6 0.0.0.0 area 0
network 192.168.67.6 0.0.0.0 area 0
!
router bgp 64512
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor RR-client peer-group
neighbor RR-client remote-as 64512
neighbor RR-client password secret
neighbor RR-client update-source Loopback0
neighbor 5.5.5.5 peer-group RR-client
neighbor 7.7.7.7 peer-group RR-client
!
address-family ipv6
neighbor RR-client route-reflector-client
neighbor RR-client send-label
neighbor 5.5.5.5 activate
neighbor 7.7.7.7 activate
exit-address-family
!

R7 is running IPv6 EIGRP with R8 and OSPFv2 with R6. MPLS is enabled between R7 and R6 with R7 a route-reflector client of R6

R7
hostname R7
ipv6 unicast-routing
ipv6 cef
interface Loopback0
ip address 7.7.7.7 255.255.255.255
!
interface FastEthernet0/1
description R6 Fa0/0
ip address 192.168.67.7 255.255.255.0
mpls ip
!
interface Serial1/0
description R8 S1/0
no ip address
ipv6 address FE80::7 link-local
ipv6 address FEC0:78::7/64
ipv6 eigrp 100
clock rate 2016000
!
router ospf 1
log-adjacency-changes
network 7.7.7.7 0.0.0.0 area 0
network 192.168.67.7 0.0.0.0 area 0
!
router bgp 64512
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 6.6.6.6 remote-as 64512
neighbor 6.6.6.6 password secret
neighbor 6.6.6.6 update-source Loopback0
!
address-family ipv6
neighbor 6.6.6.6 activate
neighbor 6.6.6.6 send-label
redistribute connected metric 100
redistribute eigrp 100 metric 100
no synchronization
exit-address-family
!
ipv6 router eigrp 100
no shutdown
redistribute bgp 64512 metric 100000 1 1 1 1500
!

R8 is running IPv6 EIGRP and has Loopback0 redistributed into it

R8
hostname R8
ipv6 unicast-routing
ipv6 cef
interface Loopback0
no ip address
ipv6 address FEC0::8/128
!
interface Serial1/0
description R7 S1/0
no ip address
ipv6 address FE80::8 link-local
ipv6 address FEC0:78::8/64
ipv6 eigrp 100
!
ipv6 router eigrp 100
eigrp router-id 8.8.8.8
no shutdown
redistribute connected


Lets look on our IPv6 routers and see if the routes to the other side can be seen:

R4#sh ipv6 route ospf
IPv6 Routing Table - Default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
OE2 FEC0::8/128 [110/100]
via FE80::5, FastEthernet0/0
OE2 FEC0:78::/64 [110/100]
via FE80::5, FastEthernet0/0


R8#sh ipv6 route eigrp
IPv6 Routing Table - Default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
EX FEC0::4/128 [170/2170112]
via FE80::7, Serial1/0
EX FEC0:45::/64 [170/2170112]
via FE80::7, Serial1/0

Okay, very promising - Lets see if R4 Lo0 can reach R8 Lo0

R4#ping fec0::8 source fec0::4 repeat 20

Type escape sequence to abort.
Sending 20, 100-byte ICMP Echos to FEC0::8, timeout is 2 seconds:
Packet sent with a source address of FEC0::4
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 16/21/36 ms


No problem here. So how does this work?

Lets see if we see the IPv6 routes on the route-reflector

R6#sh ip bgp ipv6 unicast summary
BGP router identifier 6.6.6.6, local AS number 64512
BGP table version is 9, main routing table version 9
4 network entries using 624 bytes of memory
4 path entries using 304 bytes of memory
2/1 BGP path/bestpath attribute entries using 336 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory
BGP using 1296 total bytes of memory
BGP activity 15/11 prefixes, 18/14 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
5.5.5.5 4 64512 127 127 9 0 0 00:00:20 2
7.7.7.7 4 64512 114 119 9 0 0 00:00:08 2

Well we can see that we've learnt 2 prefixes from each of the PEs

R6#sh ip bgp ipv6 unicast | begin Network
*>iFEC0::4/128      ::FFFF:5.5.5.5         100    100      0 ?
*>iFEC0::8/128      ::FFFF:7.7.7.7         100    100      0 ?
*>iFEC0:45::/64     ::FFFF:5.5.5.5         100    100      0 ?
*>iFEC0:78::/64     ::FFFF:7.7.7.7         100    100      0 ?
Lets look at R6's MPLS label table to see if we can see anything related to IPv6

R6#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     7.7.7.7/32        0             Fa0/0      192.168.67.7
17     Pop Label     5.5.5.5/32        0             Fa0/1      192.168.56.5
Not directly in the forwarding path, however there are labels associated with the IPv6 routes themselves used by the PEs to identify routes:

R6#sh ip bgp ipv6 unicast labels
Network Next Hop In label/Out label
FEC0::4/128 ::FFFF:5.5.5.5 nolabel/20
FEC0::8/128 ::FFFF:7.7.7.7 nolabel/21
FEC0:45::/64 ::FFFF:5.5.5.5 nolabel/19
FEC0:78::/64 ::FFFF:7.7.7.7 nolabel/19

Okay, Lets lets go to each of the PEs and see the associated Labels


R5#sh mpls forwarding-table
   Network          Next Hop      In label/Out label
   FEC0::4/128      ::FFFF:5.5.5.5  nolabel/20
   FEC0::8/128      ::FFFF:7.7.7.7  nolabel/21
   FEC0:45::/64     ::FFFF:5.5.5.5  nolabel/19
   FEC0:78::/64     ::FFFF:7.7.7.7  nolabel/19

R7#sh mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     16            7.7.7.7/32        0             Fa0/0      192.168.56.6
17     Pop Label     6.6.6.6/32        0             Fa0/0      192.168.56.6
18     Pop Label     192.168.67.0/24   0             Fa0/0      192.168.56.6
19     No Label      FEC0:45::/64      0             aggregate
20     No Label      FEC0::4/128       2280          Fa0/1      FE80::4

We'll clear the MPLS related counters and send 1000 packets between the two endpoints to see which MPLS paths we're using - first we'll clear the associated counters.


R5#clear mpls counters
Clear "show mpls forwarding-table" counters [confirm]
R6#clear mpls counters
Clear "show mpls forwarding-table" counters [confirm]
R6#clear mpls counters
Clear "show mpls forwarding-table" counters [confirm]


R4#ping fec0::8 source fec0::4 repeat 1000

Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to FEC0::8, timeout is 2 seconds:
Packet sent with a source address of FEC0::4
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 4/25/72 ms


Lets look at the forwarding-tables again to see the bytes switched values...

R5#sh mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     16            7.7.7.7/32        0             Fa0/0      192.168.56.6
17     Pop Label     6.6.6.6/32        0             Fa0/0      192.168.56.6
18     Pop Label     192.168.67.0/24   0             Fa0/0      192.168.56.6
19     No Label      FEC0:45::/64      0             aggregate
20     No Label      FEC0::4/128       114000        Fa0/1      FE80::4

Ok, so traffic coming into R5 with a label of 20 is going through to FE80::4 (R4 Lo0)


R6#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     7.7.7.7/32        118000        Fa0/0      192.168.67.7
17     Pop Label     5.5.5.5/32        118000        Fa0/1      192.168.56.5


We can see traffic destined to each of the PEs

R7#sh mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     6.6.6.6/32        0             Fa0/1      192.168.67.6
17     Pop Label     192.168.56.0/24   0             Fa0/1      192.168.67.6
18     17            5.5.5.5/32        0             Fa0/1      192.168.67.6
19     No Label      FEC0:78::/64      0             aggregate
21     No Label      FEC0::8/128       104000        Se1/0      point2point

We can see traffic coming into R7 with a label of 21 is destined to FE80::8 (R8 Lo)


So if we trace the path from R4 to R8:

R4#trace
Protocol [ip]: ipv6
Target IPv6 address: fec0::8
Source address: fec0::4
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [0]:
Type escape sequence to abort.
Tracing the route to FEC0::8

  1 FEC0:45::5 28 msec 32 msec 16 msec
  2 ::FFFF:192.168.56.6 [MPLS: Labels 16/21 Exp 0] 20 msec 28 msec 28 msec
  3 FEC0:78::7 [MPLS: Label 21 Exp 0] 32 msec 28 msec 16 msec
  4 FEC0:78::8 28 msec 32 msec 16 msec

We can see on entry #2 that R6 is using label 16 to get to R7 and inner label 21 will be used to tell R7 this is destined for FEC0::8/128
On entry #3 we can see that R7 is using label 21 to determine we send traffic out S1/0 to reach R8


Tracing in the reverse direction?

R8#trace
Protocol [ip]: ipv6
Target IPv6 address: fec0::4
Source address: fec0::8
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [0]:
Type escape sequence to abort.
Tracing the route to FEC0::4

  1 FEC0:78::7 76 msec 136 msec 28 msec
  2 ::FFFF:192.168.67.6 [MPLS: Labels 17/20 Exp 0] 88 msec 120 msec 72 msec
  3 FEC0:45::5 [MPLS: Label 20 Exp 0] 116 msec 100 msec 116 msec
  4 FEC0:45::4 88 msec 116 msec 96 msec

We can see on entry #2 that R6 is using label 17 to get to R5 and inner label 20 will be used to tell R5 this is destined for FEC0::4/128
On entry #3 we can see that R5 is using label 20 to determine we send traffic out Fa0/1 to reach R4

PBR Support for Multiple Tracking Options

Policy Based Routing allows us to bypass the standard routing table behaviour and route based on our own a policy.  If the PBR rule fails, the traffic does not get dropped, it just falls into the typical routing methods.  This means we can do some non-obvious things with our routing.

PBR can be tied to object tracking or to CDP, so there can be a dynamic approach as to what happens.  As it takes quite a while by default for the CDP hold time to expire (180 seconds) this example will be using object tracking which will use ip sla. In this example we are going to have three parallel paths between R4 and R7.  Object tracking will be used to determine if the next-hop is actually reachable, following an order of preference for which path that will be used. In our example the order will be S0/0, then S1/0 and finally S1/1


R4
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface Serial0/0
 ip address 192.168.47.4 255.255.255.0
 clock rate 2000000
!
interface Serial1/0
 ip address 192.168.147.4 255.255.255.0
 clock rate 2000000
!
interface Serial1/1
 ip address 192.168.247.4 255.255.255.0
 clock rate 2000000
!
ip sla 1
 icmp-echo 192.168.47.7 source-ip 192.168.47.4
 timeout 500
 frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
 icmp-echo 192.168.147.7 source-ip 192.168.147.4
 timeout 500
 frequency 10
ip sla schedule 2 life forever start-time now
ip sla 3
 icmp-echo 192.168.247.7 source-ip 192.168.247.4
 timeout 500
 frequency 10
ip sla schedule 3 life forever start-time now
track 1 rtr 1 reachability
track 2 rtr 2 reachability
track 3 rtr 3 reachability
!
ip access-list extended L0
 permit ip host 4.4.4.4 any
route-map ToR7L0 permit 10
 match ip address L0
 set ip next-hop verify-availability 192.168.47.7 1 track 1
 set ip next-hop verify-availability 192.168.147.7 2 track 2
 set ip next-hop verify-availability 192.168.247.7 3 track 3

Normally the ingress interface on the router would have the policy routing configured such as

interface Fa0/0
 ip policy route-map ToR7L0
!

However for this testing, we are just going to use traffic between R4 L0 and R7 L0, which is considered self-generated traffic.  As such the configuration for self-generated traffic is

ip local policy route-map ToR7L0

If you notice in the route-map definition we use an acccess list to match only on the source IP address of R4 L0, if we didn't the traffic associated with ip sla-echo tests would also be matched which wouldn't work as effectively.

The Corresponding configuration for R7 is very similar to R4s

R7
interface Loopback0
 ip address 7.7.7.7 255.255.255.255
!
interface Serial0/0
 ip address 192.168.47.7 255.255.255.0
!
interface Serial1/0
 ip address 192.168.147.7 255.255.255.0
!
interface Serial1/1
 ip address 192.168.247.7 255.255.255.0
!
ip sla 1
 icmp-echo 192.168.47.4 source-ip 192.168.47.7
 timeout 500
 frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
 icmp-echo 192.168.147.4 source-ip 192.168.147.7
 timeout 500
 frequency 10
ip sla schedule 2 life forever start-time now
ip sla 3
 icmp-echo 192.168.247.4 source-ip 192.168.247.7
 timeout 500
 frequency 10
ip sla schedule 3 life forever start-time now
track 1 rtr 1 reachability
track 2 rtr 2 reachability
track 3 rtr 3 reachability
ip access-list extended L0
 permit ip host 7.7.7.7 any
route-map ToR4L0 permit 10
 match ip address L0
 set ip next-hop verify-availability 192.168.47.4 1 track 1
 set ip next-hop verify-availability 192.168.147.4 2 track 2
 set ip next-hop verify-availability 192.168.247.4 3 track 3
ip local policy route-map ToR4L0

The configuration basically reflects what is happening on R4

Lets check things with all interfaces up and running

R4#sh track
Track 1
  Response Time Reporter 1 reachability
  Reachability is Up
    7 changes, last change 00:01:46
  Latest operation return code: OK
  Latest RTT (millisecs) 12
  Tracked by:
    ROUTE-MAP 0
Track 2
  Response Time Reporter 2 reachability
  Reachability is Up
    11 changes, last change 00:00:56
  Latest operation return code: OK
  Latest RTT (millisecs) 20
  Tracked by:
    ROUTE-MAP 0
Track 3
  Response Time Reporter 3 reachability
  Reachability is Up
    6 changes, last change 00:19:21
  Latest operation return code: OK
  Latest RTT (millisecs) 4
  Tracked by:
    ROUTE-MAP 0
R4#sh route-map
route-map ToR7L0, permit, sequence 10
  Match clauses:
    ip address (access-lists): L0
  Set clauses:
    ip next-hop verify-availability 192.168.47.7 1 track 1  [up]
    ip next-hop verify-availability 192.168.147.7 2 track 2  [up]
    ip next-hop verify-availability 192.168.247.7 3 track 3  [up]
  Policy routing matches: 248 packets, 17188 bytes


R7#sh route-map
route-map ToR4L0, permit, sequence 10
  Match clauses:
    ip address (access-lists): L0
  Set clauses:
    ip next-hop verify-availability 192.168.47.4 1 track 1  [up]
    ip next-hop verify-availability 192.168.147.4 2 track 2  [up]
    ip next-hop verify-availability 192.168.247.4 3 track 3  [up]
  Policy routing matches: 273 packets, 18254 bytes

Everything is operational, we can see the next-hop IP addresses followed by the order of preference (lowest number is more preferrable).  We can see that the route table for each router does not have reachability information for corresponding routers Loopback


R4#sh ip route 7.7.7.7
% Network not in table

R7#sh ip route 4.4.4.4
% Network not in table

Lets clear the counters and do a ping test

R4#clear route-map counters ToR7L0
R7#clear route-map counters ToR4L0

R4#ping 7.7.7.7 source 4.4.4.4 repeat 20

Type escape sequence to abort.
Sending 20, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 1/2/4 ms
R4#sh route-map
route-map ToR7L0, permit, sequence 10
  Match clauses:
    ip address (access-lists): L0
  Set clauses:
    ip next-hop verify-availability 192.168.47.7 1 track 1  [up]
    ip next-hop verify-availability 192.168.147.7 2 track 2  [up]
    ip next-hop verify-availability 192.168.247.7 3 track 3  [up]
  Policy routing matches: 20 packets, 2000 bytes

R7#sh route-map
route-map ToR4L0, permit, sequence 10
  Match clauses:
    ip address (access-lists): L0
  Set clauses:
    ip next-hop verify-availability 192.168.47.4 1 track 1  [up]
    ip next-hop verify-availability 192.168.147.4 2 track 2  [up]
    ip next-hop verify-availability 192.168.247.4 3 track 3  [up]
  Policy routing matches: 20 packets, 2080 bytes

Lets bring down S0/0 and see how things behave

Saturday, 7 May 2011

IOS Firewall (CBAC)

I think of CBAC as "ip inspect" because the majority of commands related to this technology piece start with this string.  To me it seems to be a more intelligent form of reflexive access lists as it can look in applications rather than only tracking port numbers of a conversation. 

You can get alarming and audit messages so its helpful in tracking issues and checking policy conformance and troubleshooting.

Note that fragmentation can be an issue for the IOS Firewall, so "ip virtual-reassembly" on the interface is a good idea, unlike NAT it is not enabled by default.

To configure CBAC - an extended ACL on the inbound interface that pretty much blocks everything is required, CBAC traffic that is allowed outbound will have the return path open via an invisible entry in the inbound ACL (sh ip inspect session).  An Audit trail can show when a conversation starts, stops and how much data was transferred.

Below are some basic configurations, with the topology as:

R4 is acting as a host inside the LAN
R5 is acting as my border router with a BGP peering with R6
R6 is acting as the service provider/internet


Below are our starting configurations with CBAC

R4
hostname R4
no ip routing
interface FastEthernet0/0
 ip address 192.168.101.4 255.255.255.0
!
ip default-gateway 192.168.101.5

R5
hostname R5
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
interface FastEthernet0/0
 description R6 Fa0/1
 ip address 192.168.56.5 255.255.255.0
!
interface FastEthernet0/1
 description R4 Fa0/0
 ip address 192.168.101.5 255.255.255.0
!
router bgp 64512
 bgp router-id 5.5.5.5
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 192.168.56.6 remote-as 65535
 !
 address-family ipv4
  redistribute connected metric 20 route-map Local
  neighbor 192.168.56.6 activate
  no auto-summary
  no synchronization
 exit-address-family
!
route-map Local permit 10
 match interface Loopback0 FastEthernet0/1

R6
hostname R6
aaa new-model
aaa authentication login default none
aaa authentication enable default none
ip http server
interface Loopback0
 ip address 6.6.6.6 255.255.255.255
!
interface FastEthernet0/1
 ip address 192.168.56.6 255.255.255.0
!
router bgp 65535
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 192.168.56.5 remote-as 64512
 !
 address-family ipv4
  neighbor 192.168.56.5 activate
  neighbor 192.168.56.5 default-originate
  no auto-summary
  no synchronization
 exit-address-family
!

So in this example we are going to be using the IOS firewall on R5's interface facing R6

First we're going to set up the applications we're going to inspect and allow through the network

R5(config)#ip inspect name StuffAllowed telnet alert on audit-trail on
R5(config)#ip inspect name StuffAllowed icmp router-traffic
R5(config)#ip inspect name StuffAllowed http alert on
R5(config)#ip inspect name StuffAllowed dns

the "router-traffic" keyword means that router originated or terminated traffic is included in inspection, normally only traffic flowing through the router is considered.

Now we'll set up some access-lists, this is somewhat similar to reflexive access-lists where the inbound entry will have pinholes matching the outbound sessions going through.  In this case, we're going to allow the internet to ping our WAN interface, allow our BGP peering with R6 and block anything else.

R5(config)#ip access-list extended FW-IN
R5(config-ext-nacl)#permit icmp any host 192.168.56.5
R5(config-ext-nacl)#permit tcp host 192.168.56.6 host 192.168.56.5 eq bgp
R5(config-ext-nacl)#deny ip any any log

Now we apply the access-list for inbound traffic, inspect outbound traffic to enable pinholes on return and we need to make sure we have virtual-reassembly turned on so the firewall can deal with ip fragments:

R5(config-ext-nacl)#interface FastEthernet0/0
R5(config-if)#ip access-group FW-IN in
R5(config-if)#ip inspect StuffAllowed out
R5(config-if)#ip virtual-reassembly

Let's give it a test R4 telnetting to R6 Lo0

R4#telnet 6.6.6.6
Trying 6.6.6.6 ... Open

R6>sh users
    Line       User       Host(s)              Idle       Location
* 98 vty 0                idle                 00:00:00 192.168.101.4

  Interface    User               Mode         Idle     Peer Address

R6>exit

[Connection to 6.6.6.6 closed by foreign host]

Good, since we had auditing turned on for telnet, we should have a record of the session on R5

R5#
*Mar  1 00:29:49.655: %FW-6-SESS_AUDIT_TRAIL_START: Start telnet session: initiator (192.168.101.4:22391) -- responder (6.6.6.6:23)
*Mar  1 00:30:00.611: %FW-6-SESS_AUDIT_TRAIL: Stop telnet session: initiator (192.168.101.4:22391) sent 40 bytes -- responder (6.6.6.6:23) sent 267 bytes

Lets try a basic http session (we can do this by telnetting to port 80 of R6 and typing "GET / HTTP/1.0" to simulate a web browser trying to get the front page)

R4>do telnet 6.6.6.6 80
Trying 6.6.6.6, 80 ... Open
GET / HTTP/1.0

HTTP/1.1 401 Unauthorized
Date: Fri, 01 Mar 2002 02:03:20 GMT
Server: cisco-IOS
Accept-Ranges: none
WWW-Authenticate: Basic realm="level_15_access"

[Connection to 6.6.6.6 closed by foreign host]

Okay - that works, the response is saying that we're not allowed in because we have authenticated into the web interface but that's ok for this test, now time to play with the application firewall functionality. This is where the real difference between reflexive acls and CBAC come together.  The application firewall allows us to check whether the conversation using the ports associated with the protocol are actually the protocol itself and can do things like check that protocol level messages are valid or even filter on certain objects (such as filtering file types)

For the example here we're just going to ensure that we're following strict HTTP messages and will drop the session and generate a log message

R5(config)#appfw policy-name HTTPcontrol
R5(cfg-appfw-policy)#application http
R5(cfg-appfw-policy-http)#strict-http action alarm reset
R5(cfg-appfw-policy-http)#port-misuse default action reset

Then we just add it to our ip inspect definition

R5(cfg-appfw-policy-http)#ip inspect name StuffAllowed appfw HTTPcontrol

And check the overall configuration

R5(config)#do sh ip inspect all
Session audit trail is disabled
Session alert is enabled
one-minute (sampling period) thresholds are [unlimited : unlimited] connections
max-incomplete sessions thresholds are [unlimited : unlimited]
max-incomplete tcp connections per host is unlimited. Block-time 0 minute.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
tcp reassembly queue length 16; timeout 5 sec; memory-limit 1024 kilo bytes
dns-timeout is 5 sec
Inspection Rule Configuration
 Inspection name StuffAllowed
    icmp alert is on audit-trail is off timeout 10
 inspection of router local traffic is enabled
    dns alert is on audit-trail is off timeout 30
    telnet alert is on audit-trail is on timeout 3600
    Application Policy name HTTPcontrol
      Application http
        strict-http action reset alarm
        port-misuse default action reset

Interface Configuration
 Interface FastEthernet0/0
  Inbound inspection rule is not set
  Outgoing inspection rule is StuffAllowed
    icmp alert is on audit-trail is off timeout 10
 inspection of router local traffic is enabled
    dns alert is on audit-trail is off timeout 30
    telnet alert is on audit-trail is on timeout 3600
    Application Policy name HTTPcontrol
      Application http
        strict-http action reset alarm
        port-misuse default action reset
  Inbound access list is FW-IN
  Outgoing access list is not set


So Let's try with an improper http message type by typing "123 PROTOCOL VIOLATION TEST"

R4(config)#do telnet 6.6.6.6 80
Trying 6.6.6.6, 80 ... Open
123 PROTOCOL VIOLATION TEST
[Connection to 6.6.6.6 closed by foreign host]

Well we can see that the session was closed without a response - what did R5 say?

R5#
*Mar  1 02:12:20.071: %APPFW-4-HTTP_STRICT_PROTOCOL: Sig:15 HTTP protocol violation detected - Reset -  HTTP Protocol not detected from 192.168.101.4:51629 to 6.6.6.6:80

So it appears to be blocking improper HTTP syntax.  Let's confirm it works ok with proper protocol usage

R4(config)#do telnet 6.6.6.6 80
Trying 6.6.6.6, 80 ... Open
GET / HTTP/1.0

HTTP/1.1 401 Unauthorized
Date: Fri, 01 Mar 2002 02:14:12 GMT
Server: cisco-IOS
Accept-Ranges: none
WWW-Authenticate: Basic realm="level_15_access"

401 Unauthorized

[Connection to 6.6.6.6 closed by foreign host]

Yep, no problem here.

Next we can play around with URL Filtering, for this example we're going to allow access to 6.6.6.6 (R6 Lo) but not to 192.168.56.6 (R6 Fa0/1)

R5(config)#ip urlfilter exclusive-domain permit 6.6.6.6
R5(config)#ip urlfilter exclusive-domain deny 192.168.56.6
R5(config)#ip urlfilter audit-trail

Let's try 192.168.56.6 since that should be blocked

R4#telnet 192.168.56.6 80
Trying 192.168.56.6, 80 ... Open
GET / HTTP/1.0
HTTP/1.1 403 Forbidden
Server: IOS Firewall HTTP/1.1
Content-type: text/html
Connection: close

<html>
      <head>
            <title>Forbidden</title></head>
                                           <body bgcolor="#ffffff">
                                                                   <center><h1><font color="#ff0000">HTTP Error 403 - Forbidden</font></h1>
                                                                                                                                           <b>You do not have permission to access the document or program you requested.
                 </b></center>
                              </body></html>


[Connection to 192.168.56.6 closed by foreign host]

We can see that we recieved a message back not allowing us to R6 Fa0/1 and we can see the log entry on R5 confirming this occurred as well.

R5#
*Mar  1 02:21:01.967: %URLF-4-SITE_BLOCKED: Access denied for the site '192.168.56.6', client 192.168.101.4:59608 server 192.168.56.6:80


Lets verify that going to R6 Lo0 is ok:

R4#telnet 6.6.6.6 80
Trying 6.6.6.6, 80 ... Open
GET / HTTP/1.0

HTTP/1.1 401 Unauthorized
Date: Fri, 01 Mar 2002 02:23:05 GMT
Server: cisco-IOS
Accept-Ranges: none
WWW-Authenticate: Basic realm="level_15_access"

401 Unauthorized

[Connection to 6.6.6.6 closed by foreign host]

R5#
*Mar  1 02:23:09.271: %URLF-6-SITE_ALLOWED: Client 192.168.101.4:23109 accessed server 6.6.6.6:80


This blog entry has really only scratched the surface as to what the IOS firewall can do but it shows some of the extra functionality within IOS