Labbing…

Boot Camp Locked In

PayPal finally cleared my payment to Micronics for Narbiks London boot camp. All I am waiting for now is confirmation of the location, although I have been assured it will be in Central London, so this wont be a problem. Its still alot closer than Sydney, Dubai or Pasedena. I received the Soup-To-Nuts workbook and have been having a read through. The style is very simple but easy to follow. I will be working through this workbook over the next few weeks, while also fitting in some core practice labs from IEWB Volume III. These core labs are great for blasting out in a few hours, I seem to get through them in around 3 hours or so, so have improved my speed immensely setting up layer 2 and layer 3.

Once I have worked through StN I will be aiming to complete all sections of the IEWB Volume II labs that I have done so far, as I will hopefully have a better understanding of Multicast, IPv6, QoS etc.

Then come July attend the boot camp, work through the supplied workbooks (and IEWB) for a couple of months and then see where I stand. My lab is booked out for October, but I want to move this forward once I asses my position in August after I have digested all of the material.

Update on updates

You may have noticed a distinct lack of updating on this site recently. I have been continuing with my lab practice, but am finding it harder and harder to write up notes to the blog.

I will be updating the site from time to time. I have booked a place on Narbik’s London Boot camp in July, so between now and then will be continuing with the IEWB labs, and also having a look through the soup-to-nuts workbook when I get it.

IEWB-DYN Lab 10

Updates coming for all of the labs soon, been very busy at work, but have been making progress through the labs. I have now done the core section of Lab 10. I am hoping to get my updates done soon.

IEWB-DYN Lab 9

Change of Lab Date

So, I have been reading through the various blogs out there and boot camps seem to be a hot topic of thought at the moment. I have been deliberating about whether or not to attend one, I am mindful of the good reviews received for Narbik Kocharians‘ bootcamps, and he has finally announced some dates for London classes.

I was contemplating going to Dubai for his class, but now he is coming to London it works out even better on price. I am going to book a place on the bootcamp starting on the 7th July - unfortunately this is when I had my lab date booked for, so I have pushed this out a couple of months so I can absorb all of the bootcamp material. I don’t mind doing this as I am not in a particular hurry to get my CCIE done. Also, attending the bootcamp will give me some additional material to work through different to the IEWB materials, so will be able to get a different perspective I hope.

If anyone out there is interested in attending this bootcamp get in touch with Narbik through his website and let him know.

IEWB-DYN Lab 8

Tonight I worked through the core sections of Lab 8. As I write this I have just completed all core sections up to and including BGP. I started at 20:00 prompt and it is now 22:45, so it took me 2 hours 45 minutes to work though the core sections. I will be writing up my notes for this lab tomorrow, but I was generally impressed with my speed, progress and understanding on this lab.

…

IEWB-DYN Lab 5 - BGP Highlights

Again, nothing too tricky on the BGP section (this is a lab rated 6!), quite a few peerings to configure. I actually missed on of these (R3 to SW2) out on my first pass of the question, but good job that I checked it and corrected my mistake.

AS-Path Manipulation

This scenario had a number of private BGP AS numbers configured. The task wanted to strip these out when they were being advertised out of AS 300.

router bgp 300
no synchronization
bgp router-id 150.1.3.3
neighbor 162.1.0.4 remote-as 100
neighbor 162.1.0.4 remove-private-as
neighbor 162.1.13.1 remote-as 200
neighbor 162.1.13.1 remove-private-as

This config removes the any private AS numbers when advertising to the specified neighbors, so they appear to be from AS 300.

BGP Filtering

To stop an advertised network form being advertised beyond an AS use the no-advertise keyword. This task had a network advertised on R5 into AS 500 and didn’t want it to be advertised out from R4 beyond AS 100.

First create an ip prefix-list to match the network

ip prefix-list LO15 seq 5 permit 162.1.15.0/24

Then, a route-map to match the prefix-list and set the community value accordingly.

route-map NO-ADVERTISE permit 10
match ip address prefix-list LO15
set community no-advertise

Finally, apply the route map on the peering statement to R4, and set the send-community value

neighbor 150.1.4.4 send-community
neighbor 150.1.4.4 route-map NO-ADVERTISE out

Check this route is received on R4 and not advertised to other AS’s

Rack1R4#sh ip bgp 162.1.15.0
BGP routing table entry for 162.1.15.0/24, version 34
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to any peer)
Not advertised to any peer
500
150.1.5.5 (metric 65) from 150.1.5.5 (150.1.5.5)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-advertise

Rack1R3#sh ip route 162.1.15.0
% Subnet not in table

IEWB-DYN Lab 5 - IGP Highlights

The IGP section again, was quite straight forward, with the usual OSPF over FR shenanigans going on, where by not being able to change one of the interface types, so have to match the others accordingly.

OSPF

This was a simple hub and spoke setup, with a NON_BROADCAST interface at the hub that couldn’t be changed. All other spoke interface were using the physical interfaces, so didn’t need to be changed, apart from R2 that was a point-to-point sub interface that needed to be changed to OSPF interface NON_BROADCAST. Always remember to set the spokes to priority 0 when on a NON_BROADCAST network so they don’t try to become the DR for the segment - and remember to manually specify the neighbors under the OSPF process on the DR (hub).

R3 (HUB)

router ospf 1
router-id 150.1.3.3
neighbor 162.1.0.2
neighbor 162.1.0.4
neighbor 162.1.0.5

Rack1R3#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
Internet Address 162.1.0.3/24, Area 0
Process ID 1, Router ID 150.1.3.3, Network Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DR, Priority 1

R2 (SPOKE)

interface Serial1/0.1 point-to-point
ip address 162.1.0.2 255.255.255.0
ip ospf network non-broadcast
ip ospf priority 0
frame-relay interface-dlci 203

Rack1R2#sh ip ospf int s1/0.1
Serial1/0.1 is up, line protocol is up
Internet Address 162.1.0.2/24, Area 0
Process ID 1, Router ID 150.1.2.2, Network Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DROTHER, Priority 0

EIGRP Metrics

There was a task to tweak EIGRP to use bandwidth, delay and load as part of the metric calculation. An additional task was to make sure the bandwidth value is 3 times more significant than delay and load.

Rack1R3#sh run | s eigrp
router eigrp 200
metric weights 0 3 1 1 0 0

The K values need to match on each device within the EIGRP AS, in order for the neighbor adjacency to form, so this needed to be applied to all routers within AS 200.

Routing Redundancy

Task to ensure R5 remains available when its FR connection goes down to the OSPF domain. There is a PP link configured between R4 and R5 (R4 is in the OSPF domain). This task stated that static routes were allowed, so this hinted at floating static routes.

Create routes on R4 pointing to R5 networks via the PPP link, but set them with an AD higher than the OSPF routes that are in the table.

ip route 150.1.5.0 255.255.255.0 162.1.45.5 111
ip route 162.1.5.0 255.255.255.0 162.1.45.5 111
ip route 162.1.55.0 255.255.255.0 162.1.45.5 111

Redistribute these statics into OSPF (they will only be distributed when the routes are actually in the table)

router ospf 1
router-id 150.1.4.4
redistribute static subnets

On R5 make sure there is a route out the the rest of the network when the FR (OSPF) link is down

ip route 0.0.0.0 0.0.0.0 162.1.45.4 111

As these routes have a manually configured AD of 111 which is higher than OSPF’s AD of 110 they don’t appear in the routing table when OSPF learned routes are present. Once the OSPF routes are removed the statics with the AD of 111 come into effect.

IGP Redistribution

The redistribution on this lab was quite easy, no multiple redistribution points, so no need for any filtering. There were a couple of differences between my solution and the SG, but it appeared to me that they had some additional configuration that wasn’t asked for (or needed) to get reachability across the network. A quick check on the IE forum showed that a few people had the same issue, so I decided to leave my solution as it was. Seeing as my ping scripts worked just fine.

IEWB-DYN Lab 5 - Layer 2 Highlights

So I did the core section for Lab 5 this morning. The L2 section was quite straight forward - nothing too tricky, and time wise didnt take long to complete at all.

PPP

To turn on reliable transport over a PPP link use the ppp reliable-link command

interface Serial1/1
ip address 162.1.45.4 255.255.255.0
encapsulation ppp
ppp reliable-link

This is easy enough to figure out from the ? on the command prompt.

CAM Table Management

There was a task to ensure the CAM table doesnt fill with entries, by ensuring inactive entries time out after 10 seconds:

mac-address-table aging-time 10

Again, easy enough to work out form the command line help.