Consider the following scenario.

R1 s0/0.12  ————— s0/0.21 R2

There is a PPPoFR link configured between R1 & R2, with the following configuration:

R1

int s0/0.12
frame int 102 ppp virtual-temp 12
int virtual-temp 12
ip add 1.1.1.1 255.0.0.0

R2

int s0/0.21
frame int 201 ppp virtual-temp 21
int virtual-temp 21
ip add 2.2.2.2 255.0.0.0

With this setup, R1 can ping 2.2.2.2 (R2) & R2 can ping 1.1.1.1 (R1).
This is because peer neighbor route (enabled by default for ppp links) results in:

• R1 receiving a /32 host route for 2.0.0.0
• R2 receiving a /32 host route for 1.0.0.0

The routing table below for R1 & R2 confirm this:

R1#sh ip ro | i /32
2.0.0.0/32 is subnetted, 1 subnets

R2#sh ip ro | i /32
1.0.0.0/32 is subnetted, 1 subnets

However, neither R1, nor R2 can ping their own IP’s:

R1#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

R2#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

Hmm…what to do?

Well there are a no of ways to make self ping work with only slight modifications to our PPPoFR setup.
The 1st two revolve around ppp multilink, one without using interface multilink & another with interface multilink.
The 2nd solution merely employs ip unnumbered.

Solution 1 – PPP multilink + NO interface multilink

With 1 line added to R1 & R2 we can resolve the self ping problem
Simply add ppp multilink under the virtual template interfaces and you are golden!

R1

int virtual-temp12
ppp multilink

R2

int virtual-temp21
ppp multilink

You will see some error messages pop up regarding frame relay traffic shaping, but just ignore those.
As can be seen below, both R1 & R2 are now able to ping themselves now!

R1#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms

R2#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/8 ms

Solution 2 – PPP Multilink + interface multilink

With this solution we 1st of all create a multilink interface, & tie it to the virtual-template interface.
1st of all let’s return to the original config we had for R1 & R2:

R1

int s0/0.12
frame int 102 ppp virtual-temp 12
int virtual-temp 12
ip add 1.1.1.1 255.0.0.0

R2

int s0/0.21
frame int 201 ppp virtual-temp 21
int virtual-temp 21
ip add 2.2.2.2 255.0.0.0

Modifications we need to make are as follows:

R1

int virtual-temp12
no ip address

int multilink12
ip add 1.1.1.1 255.0.0.0

int virtual-temp12
ppp multilink group 12

R2

int virtual-temp21
no ip address

int multilink21
ip add 2.2.2.2 255.0.0.0

int virtual-temp21
ppp multilink group 21

Once you do this, you see the multilink interface come up & will see some error messages but again, ignore those!

Let’s test this:

R1#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/14/48 ms

R2#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms

Cool!

Solution 3 – IP unnumbered under virtual template interface

Again let’s return to our original base configuration:

R1

int s0/0.12
frame int 102 ppp virtual-temp 12
int virtual-temp 12
ip add 1.1.1.1 255.0.0.0

R2

int s0/0.21
frame int 201 ppp virtual-temp 21
int virtual-temp 21
ip add 2.2.2.2 255.0.0.0

Modifications we need to make are simply to move the ip addressing off the virtual template onto a loopback interface & then use ip unnumbered on the virtual template interfaces:

R1

int virtual-temp 12
ip unnumbered loopback0
int lo0
ip add 1.1.1.1 255.0.0.0

R2

int virtual-temp 21
ip unnumbered loopback0
int lo0
ip add 2.2.2.2 255.0.0.0

Testing this solution, again, self ping works just dandy:

R1#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

R2#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

That’s the end of this post!

This post follows on the back of my previous blog entry:
RIP updates over pt2pt serial: a few methods

In that post I mentioned that ONE way to get RIP updates across a pt2pt link that has ip addresses in different subnets at both ends is by using ip unnumbered.

To recap, before ip unnumbered we have this:

R1 s0/1 ————- s0/1 R2

R1 s0/1 ip: 10.1.100.1/24
R2 s0/1 ip: 10.11.100.2/24
R1 has no validate update-source in RIP.
R2 performs update source validation in RIP.

R2 rejects R1’s update:
RIP: ignored v2 update from bad source 10.1.100.1 on Serial0/1

So using ip unnumbered to resolve this issue we have:

R1
int s0/1
ip unnumbered lo0
int lo0
ip add 10.1.100.1 255.255.255.0

R2
int s0/1
ip unnumbered lo0
int lo0
ip add 10.11.100.2 255.255.255.0

All is well, R2 accepts the updates from R1:

R2
RIP: received v2 update from 10.1.100.1 on Serial0/1

But say later on we have the following task:

Create the following loopbacks & ensure only the routes that have an ODD no in the 3rd octet are advertised by RIP.

lo0 – 30.3.0.1/24
lo1 – 30.3.1.1/24
lo2 – 30.3.2.1/24
lo3 – 30.3.3.1/24
lo4 – 30.3.4.1/24

When we do this, as R2 s0/1 is ip unnumbered off loopback0, R2 s0/1 ip address changes to 30.3.0.1:

R2(config-router)#do sii
Interface                  IP-Address      OK? Method Status                Protocol
—
Serial0/1                  30.3.0.1 YES TFTP   up                    up

As Serial0/1 ip is now 30.3.0.1 what happens is that R2 now advertises routes to R1 with IP address: 30.3.0.1.

Now R1 WILL receive the RIP routes from R2 with ip 30.3.0.1, but R1 will NOT have reachability to 30.3.0.1 over s0/1:

R1
R       30.3.1.0 [120/1] via 30.3.0.1, 00:00:18, Serial0/1
R       30.3.3.0 [120/1] via 30.3.0.1, 00:00:18, Serial0/1

R1#ping 30.3.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 30.3.0.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5) <——————–

If reachability is desired, then clearly you do not want this.

To get around this then, I would say:

• Be wary whenever using ip unnumbered loopback command
• Use a loopback which is unlikely to be used elsewhere in the lab eg..int loopback 2147483647 (the largest loopback no! )
  • R1(config)#int loopback ?
    <0-2147483647>  Loopback interface number

    R1(config)#int loopback 2147483647

Ok let’s say you have this scenario:

R1 & R2 are connected via a serial link.
HDLC is running over this link.
You can NOT change the encapsulation over this link (ie. no enc frame-relay or ppp )
You need to exchange RIP updates over this link.
R1 can be configured with no validate update-source but R2 can NOT use this command.

R1 s0/1 ————- s0/1 R2

R1 s0/1 ip: 10.1.100.1/24
R2 s0/1 ip: 10.11.100.2/24

So we have R1 & R2 on different subnets.
R1, as it is configured to NOT validate the update source, will accept the routes received from R2 over the serial.
R2 on the other hand, will compain:

R2(config-if)#
IP: s=10.1.100.1 (Serial0/1), d=224.0.0.9, len 512, rcvd 2
RIP: ignored v2 update from bad source 10.1.100.1 on Serial0/1

So how to resolve this situation?
We have a no of ways.
There may be more ways than what I will list, but that’s life

Way 1 – Using ip unnumbered

If we remove the ip addresses from the serial ints & instead place them on loopbacks, while still running ip on the serial links, we can overcome the update source validation issue.

R1

int s0/1

ip unnumbered loopback0

int lo0

ip address 10.1.100.1 255.255.255.0

R2

R1

int s0/1

ip unnumbered loopback0

int lo0

ip address 10.11.100.2 255.255.255.0

Once done, R2 is now able to accept routes from R1:

R2(config-if)#
RIP: received v2 update from 10.1.100.1 on Serial0/1
10.1.4.0/24 via 0.0.0.0 in 2 hops
10.1.12.0/24 via 0.0.0.0 in 1 hops
10.1.13.0/24 via 0.0.0.0 in 1 hops

——- rest of update omitted for brevity purposes

Cool

Way 2 – Using NAT!

Now bear in mind I am using dynamips here, so I do not know if this will work for sure on real routers, but here is another simple solution.
It is based on this idea:
We know R2 cannot accept by default routes from R1 as it is from a different update source.
But what if we changed the updates R1 sends so that R2 sees them coming in from the SAME subnet as R2’s s0/1?
NAT can do this.

R1

ip nat inside source static 10.1.100.1 10.11.100.1
int s0/1
ip nat outside

And thats it!

Debug ip rip & debug ip packet on R2 shows this:

IP: s=10.11.100.1 (Serial0/1), d=224.0.0.9, len 512, rcvd 2
RIP: received v2 update from 10.11.100.1 on Serial0/1
10.1.4.0/24 via 0.0.0.0 in 2 hops
10.1.12.0/24 via 0.0.0.0 in 1 hops
10.1.13.0/24 via 0.0.0.0 in 1 hops

Thats it for now

Anyway, this tutorial is a great example in being CAREFUL, & rechecking the task to ENSURE you have done what was asked before moving onto the next task.
For those who will be doing Narbiks redistribution labs (Volume 4), Id suggest you dont read this post!

Consider the following scenario:

R1 <==10.1.12.0/24==> R2 <==10.1.23.0/24==> R3

R1 is running RIP only.
R2 is running RIP & OSPF.
R3 is running OSPF only.

We have the following task requirements:

• Create Lo40 on R1: 172.16.0.1/24
• R1 should be configured to advertise this loopback interface into RIPv2
• Ensure that the ONLY 172.16.x.x route present in R2’s routing table is 172.16.0.0/24
• R3 should see 172.16.0.0/16 ONLY & not 172.16.0.0/24

Lets do this:
On R1, let’s create int lo40 with ip 172.16.0.1/24, & have RIP advertise it to R2:

R1
int lo40
ip add 172.16.0.1 255.255.255.0
router rip
net 10.0.0.0
net 172.16.0.0

Checking R2 we see it has the RIP route:

R2#sh ip route rip
172.16.0.0/24 is subnetted, 1 subnets
R       172.16.0.0 [120/1] via 10.1.12.1, 00:00:07, FastEthernet0/0.12

Ok so let’s redistribute this into OSPF so that R3 learns about it:

R2
access-list 1 permit 172.16.0.0
route-map RIP->OSPF permit 10
match ip address 1
router ospf 1
redistribute rip subnets route-map RIP->OSPF

Checking R3 we see that it has 172.16.0.0/24:

R3#sh ip ro
–
172.16.0.0/24 is subnetted, 1 subnets
O E2    172.16.0.0 [110/20] via 10.1.23.2, 00:00:01, FastEthernet0/0

However checking the task:

• R3 should see 172.16.0.0/16 ONLY & not 172.16.0.0/24

Now of course, when we redistributed the RIP route into OSPF on R2, R2 immediately became an ASBR.
As such we are able to summarise any redistributed routes with the summary-address command under the ospf process.

R2
router ospf 1
summary-address 172.16.0.0 255.255.0.0

If we check R3 now, we see that we have indeed met the task requirement of R3 ONLY having 172.16.0.0/16 in its RIB:

R3#sh ip ro
—
O E2 172.16.0.0/16 [110/20] via 10.1.23.2, 00:34:43, FastEthernet0/0

Now some people may easily move onto the next task in “error” thinking they have the full marks for the task.
But we are not done yet.

We still have the following task requirement:

• Ensure that the ONLY 172.16.x.x route present in R2’s routing table is 172.16.0.0/24

By default, the commands summary-address on ASBRs (& area-range on ABRs), create a discard route to Null0:

R2#sh ip ro
—
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
R       172.16.0.0/24 [120/1] via 10.1.12.1, 00:00:11, FastEthernet0/0.12
O       172.16.0.0/16 is a summary, 00:00:10, Null0

This VIOLATES the task requirement:

• Ensure that the ONLY 172.16.x.x route present in R2’s routing table is 172.16.0.0/24

So we need to remove the discard route.
As the discard route was generated when we redistributed a RIP route into OSPF we do:

R2
router ospf 1
no discard-route external

(NB, we would use no discard-route internal if we wanted to remove a discard route created with the area-range command)

Now rechecking R2 we see we have met the task requirement:

R2#sh ip ro
–
172.16.0.0/24 is subnetted, 1 subnets
R       172.16.0.0 [120/1] via 10.1.12.1, 00:00:09, FastEthernet0/0.12

————-

This is an easy scenario, but I hope it goes to show some people (& that includes me!) that you really do need to be careful in rechecking you have the task requirements before moving on from the task.

Happy labbing!

Consider the following topology:

R1 s0/0.12 <====102===201====> s0/0 R2

R1 & R2 are connected via a frame relay PVC.
R1 s0/0.12 & R2 s0/0 are both in OSPF Area 2.

Configs:

R1

interface Serial0/0.12 point-to-point
ip address 10.1.12.1 255.255.255.0
ip ospf 1 area 2
ip ospf network point-to-multipoint non-broadcast
frame-relay interface-dlci 102

R2

interface Serial0/0
ip address 10.1.12.2 255.255.255.0
encapsulation frame-relay
ip ospf 1 area 2
ip ospf network non-broadcast
ip ospf priority 0
frame-relay map ip 10.1.12.1 201 broadcast
no frame-relay inverse-arp

The following interfaces on R1 & R2 are participating in OSPF:

R1#sh ip o int b
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1        0               1.1.1.1/8          1     LOOP  0/0
Se0/0.12     1      2               10.1.12.1/24       64    P2MP  1/1

R2#sh ip o int b
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Se0/0        1     2               10.1.12.2/24       64    DROTH 1/1
Lo0          1     2               2.2.2.2/8          1     LOOP  0/0

Now R1 & R2 are incompatible network types, but as they have the same hello/dead timers (hello – 30, dead – 120), a full OSPF adjacency is formed, so R1 & R2 HAVE synched their LSDBs:

R1#sh ip o n

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  - 00:01:56    10.1.12.2       Serial0/0.12

R2#sh ip o n

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/DR 00:01:56    10.1.12.1       Serial0/0

Notice above that the neighbor state on R1 is FULL/- i.e no DR/BDR election takes place, as opposed to R1 seeing neighbor state as FULL/DR.
The config on R2 has ip ospf priority 0, so R2 knows it CANT be the DR, & so thinks that R1 MUST be the DR, even though R1 does not engage in the DR/BDR election.

However neither R1 nor R2 have INSTALLED the OSPF routes into their respective routing tables, due to the incompatible network types, as seen below:

R1# sh ip ro os
R1#

R2# sh ip ro os
R2#

What to do?
Well we can resolve this by making both R1 & R2 network types compatible with each other.
See the INE blog article if you are unaware about which network types are compatible.

However what if we had the following scenario:

• Ensure that these routers install OSPF routes into their routing tables, WITHOUT changing the network types.

Hmm…

Well we can resolve this using good ol’ GRE tunnels.
What we will do is create a GRE tunnel in Area 0 to connect R1’s Area 2 to R2’s Area 2.

Config

R1

interface Tunnel12
ip address 200.1.1.1 255.255.255.0
ip ospf 1 area 0
tunnel source Serial0/0.12
tunnel destination 10.1.12.2

R2

interface Tunnel21
ip address 200.1.1.2 255.255.255.0
ip ospf 1 area 0
tunnel source Serial0/0
tunnel destination 10.1.12.1

R1#sh ip ro os
2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/11112] via 200.1.1.2, 00:00:14, Tunnel12

Ok looks good so far…but wait:

R1#
*Mar  1 08:26:30.602: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel12 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#
*Mar  1 08:27:01.473: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel12 from LOADING to FULL, Loading Done
R1#

Checking R2 we see recursive routing issues!

R2#
*Mar  1 08:27:03.941: %TUN-5-RECURDOWN: Tunnel21 temporarily disabled due to recursive routing
*Mar  1 08:27:04.942: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel21, changed state to down
*Mar  1 08:27:04.942: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Tunnel21 from FULL to DOWN, Neighbor Down: Interface down or detached
R2#u all
*Mar  1 08:28:04.945: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel21, changed state to up
*Mar  1 08:28:05.265: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Tunnel21 from LOADING to FULL, Loading Done

The problem is this.
When the tunnel comes up, a /32 route for 10.1.12.1/32 gets advertised by R1 to R2.
When R2 receives this route, as it is more specific than the /24 route that R2 has for its direct connection to R1, the 10.1.12.1/32 route is preferred.
But this /32 host route is learned via the tunnel, and as we know you cannot route to the tunnel destination VIA the tunnel itself.
Hence we have recursive routing issues.

With tunnel DOWN:

R2#sh ip ro 10.1.12.1
Routing entry for 10.1.12.0/24
Known via “connected”, distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Serial0/0
Route metric is 0, traffic share count is 1

With tunnel UP:

R2#sh ip ro 10.1.12.1
Routing entry for 10.1.12.1/32
Known via “ospf 1″, distance 110, metric 11111, type inter area
Last update from 200.1.1.1 on Tunnel21, 00:00:01 ago
Routing Descriptor Blocks:
* 200.1.1.1, from 1.1.1.1, 00:00:01 ago, via Tunnel21
Route metric is 11111, traffic share count is 1

Now some of you may be wondering why R2 is receiving /32 host route in the 1st place.
The reason?
We have ip ospf network point-to-multipoint non-broadcast on R1 s0/0.12 !

R1#sh run int s0/0.12 | i ospf
ip ospf network point-to-multipoint non-broadcast
ip ospf 1 area 2

With the network types ip ospf network point-to-multipoint non-broadcast, ( & ip ospf network point-to-multipoint), R1 advertises all routes to R2 with a /32 host route that is itself.

As the /32 host route 10.1.12.1 just happens to correspond to R2’s tunnel DESTINATION, it is R2 that is having trouble with routing to the tunnel destination VIA the tunnel.

We can resolve this issue in a few ways:

1) Change the network type on R1 <— not permitted to by our task requirement!
2) NOT run OSPF on R1’s serial0/0.12 interface!

The reason 2) works is that, after all we really don’t NEED to be running OSPF, and advertising 10.0.12.0/24 to R2, as it already knows about it, as it is directly connected.
This plus the fact that we are using a GRE tunnel, so there is no NEED to be running OSPF on the serial interfaces when we want OSPF to run on the GRE tunnel between R1 & R2.

Config:

R1(config)#int s0/0.12
R1(config-subif)#no ip ospf 1 area 2
R1#
*Mar  1 08:42:59.655: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0.12 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 08:43:00.509: %SYS-5-CONFIG_I: Configured from console by console
R1#
*Mar  1 08:43:21.555: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel12 from LOADING to FULL, Loading Done

Now if we check R1 & R2 we see they are both seeing each other’s loopbacks & all is well!

R1#sh ip ro | b Gate
Gateway of last resort is not set

C    1.0.0.0/8 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/11112] via 200.1.1.2, 00:01:01, Tunnel12
C    200.1.1.0/24 is directly connected, Tunnel12
10.0.0.0/24 is subnetted, 1 subnets
C       10.1.12.0 is directly connected, Serial0/0.12

R2#sh ip ro | b Gate
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/11112] via 200.1.1.1, 00:00:32, Tunnel21
C    2.0.0.0/8 is directly connected, Loopback0
C    200.1.1.0/24 is directly connected, Tunnel21
10.0.0.0/24 is subnetted, 1 subnets
C       10.1.12.0 is directly connected, Serial0/0

As can be seen above, no issues with learning /32 host routes

That’s it for this tutorial.

Typically you will see every 30 seconds a barrage of output from the debug.

If you are only interested in seeing the debug on a particular interface/subinterface, this is where debug condition helps.

So say we have R1 with the following interfaces all running RIP:

R1#sh ip int b
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            100.1.111.1     YES manual up                    up
Serial0/0                  unassigned      YES unset  up                    up
Serial0/0.12               10.1.12.1       YES manual up                    up
Serial0/0.13               10.1.13.1       YES manual up                    up
Serial0/0.14               10.1.14.1       YES manual up                    up
FastEthernet0/1            unassigned      YES unset  up                    up
Serial0/1                  10.1.100.1      YES manual up                    up

If we are only interested in debug ip rip for s0/0.14 we can do this:

R1#debug condition interface s0/0.14
Condition 1 set
R1#

R1#debug ip rip
RIP protocol debugging is on
R1#
RIP: received v2 update from 10.1.14.4 on Serial0/0.14
10.1.45.0/24 via 0.0.0.0 in 1 hops
10.1.46.0/24 via 0.0.0.0 in 1 hops
10.1.56.0/24 via 0.0.0.0 in 2 hops

Cool we can see debug condition working its magic.

You can select multiple interfaces/subinterfaces with debug condition.

To view the current list of interfaces with debug condition:

R1#sh debug condition

Condition 1: interface Se0/0.14 (1 flags triggered)
Flags: Se0/0.14

Something to bear in mind here, is that doing: undebug all does NOT remove debug condition.

So if you want to remove the debug condition on your interfaces you need to do (in this case)

no debug condition interface s0/0.14

If s0/0.14 was the only remaining interface with the debug condition you’ll see the following:

R1#no debug condition int s0/0.14
This condition is the last interface condition set.
Removing all conditions may cause a flood of debugging
messages to result, unless specific debugging flags
are first removed.

Proceed with removal? [yes/no]: yes

NB. As s0/0.14 had condition id of 1, you could have also done: no debug condition 1 instead of no debug int s0/0.14.

Finally, debug condition can be used in quite a varied no of ways as seen below:

R1#debug condition ?
application  Application
called       called number
calling      calling
card         card
glbp         interface group
interface    interface
ip           IP address
mac-address  MAC address
match-list   apply the match-list
standby      interface group
username     username
vcid         VC ID
vlan         vlan

Studying for the R&S, at times has had to take a back seat to my job hunting.

My contract is ending somewhat shortly so I am on the lookout.

Anyway, I am continuing to progress through Narbik’s workbooks.

Progress is slow, but sure. Like Nickelby I am making sure I understand what I am doing.

I am also at times coming up with different solutions to Narbik’s; it’s certainly good to know one’s options.

However, in the midst of all this, I didn’t book my lab date. With all the version 3 lab dates pretty much taken, I’ve resigned myself to version 4.

This is not a big deal for me as such…I’ve spent a large amount of my career troubleshooting, and I am CCIP, plus the network I currently manage has an MPLS backbone, so I’m by far no stranger to MPLS.

So I am looking at version 4 in a positive light.

Sure, more work will be needed, but I will be a better engineer for it.

So my plan still stands in that I will study until I feel I am ready, and only at that point will I book the lab for the earliest available date.

Additionally for me, with time being taken on the job hunting aspect, for me it’s better that I do not have a lab date booked.

Narbik will, at some point, be returning to our UK shores, with his new spangled “best of the best” bootcamp . Having attended his bootcamp previously I am very interested in seeing how his new bootcamp will differ, seeing that he is also incorporating the 360 program into the bootcamp…

Narbik also mentions the new bootcamp will be more intense.

I found it pretty intense the 1st time around, and sometimes had to rely on red bull (it gives u wings) to keep focused. I think even after awhile red bull stopped doing its thing

Anyway back to studies.

I had always wanted to attend Narbiks bootcamp due to all the great things I had heard about it, but once I found out it was just over an hour from my home, I just HAD to attend.

This was the 1st of what will probably be many times that Narbik visits our shores for bootcamp purposes.

As has been mentioned before, Narbik uses a whiteboard, some coloured pens, & his insane memory of the cli.
The commands he was able to write on the whiteboard from memory were quite frankly, staggering at times.

I mean, to be able to list all the options under match, under a class-map is just 1 example.

Narbik starts off by telling you to only believe what he says if he has tested it/shown it to be true.
Narbik does not tell you anything that he has not personally tested and verified to be true.
If there is something Narbik is unsure about (which rarely happens), Narbik will hold his hands up and say he doesnt know. However these instances typically correspond to things occurring within the IOS that only the guy who coded the IOS would know.

Narbik does not repeat something (unless you ask him to repeat it).
This means you need to be 100% focused on what he is saying.
He will start with any topic from the basics, but quickly he will build on it, and pretty often to a level which you may be unfamiliar with.
I mean, I thought I knew RIP prior to this bootcamp.
I sat back, and said internally “you are talking about RIP?! cmon jeez”.
Well I didnt pay attention for a very short period and in that time Narbik mentioned something, and I thought…ok maybe i didnt know rip too well
But this is a GOOD thing!
Narbik mentions that you need to respect technologies.
There is always something to learn, to know about a technology, so give everything the respect it deserves.

Upon reflection, I would say I actually found BGP an easier lecture for the most part than certain aspects of RIP, so this should tell you something.. (hopefully not that my RIP sucks lol).

Narbik is very REAL WORLD.
He does go deep into everything, but as Ali G likes to say he “keeps it real”.
He doesnt go into the toilet-flushing-5 times methods (if you follow groupstudy you will understand what I mean)

Now prior to this bootcamp, I would have followed the configure/verify model.
After this bootcamp, I intend to follow the configure/verify/test model.
There are instances where you can configure & verify something looks fine, but until you actually TEST that its working, you may not be 100% sure that it works.
Additionally, say you make a mistake in your verification…if you also test something is working, say with ping, you can easily see whether it is working, or not.

Tips:

Bring a notepad, & maybe a multicolored pen.

Be ready to pay attention to everything that is being said.

Be as prepared as you can for the bootcamp.

The more you know (or think you know, in my case ), the better off you will be.

Ideally prepare a list of questions that you have, anomalies, anything that you need clarification on.

Also, if you make notes in shorthand, even better.

Having said this, the workbooks does go into verification & testing with explanations, so they will be a refresher for the things you hear in the bootcamp.

Conclusion
I’m so glad I went to this bootcamp, as I have been exposed to, and have learned things that I would just not have learned otherwise.
I can only recommend others to make a beeline, as Darby Weaver puts it, to this bootcamp.
You will not regret it.
Value for money wise, its hard to beat; you get 7 bound workbooks which are focus based, as well as other labs.

Narbik does have a great sense of humour, so its worth attending just for the jokes

And watch out the little men!

I have to say, I did learn quite a bit today.

Now I thought I knew these topics to a fair degree, but every time Narbik starts talking about stuff that makes me question what I really do know.

This is a good thing. We are here to be challenged, to learn new things, and thats certainly happening at this bootcamp.

Anyway off to sleep soon, to be ready for another day of learning

Quite a day it was, running from 9am till 9pm-ish.

We were all delayed at the beginning of the day due to idle timeouts to the terminal server.

For users of securecrt under session options, its pretty eas to resolve this…just send a character every 5 secs or something.

As I am using iterm under mac os x, I somewhat struggled here.

Did find an option to send an ASCII character on timeout for default terminal profile (iterm users will know what I mean). Will test it today to see if my sessions time out.

If my sessions still time out, Ill just switch to the windows virtual machine, and use securecrt.

As I didnt have securecrt under windows, this was the main reason I didnt use windows from the start.

Anyway will see how things go today with the idle timeout.

On the learning side of things, Narbik went over elements of layer 2 security (DHCP snopping, dynamic arp inspection etc), and later covered frame relay.

Now I thought I could not learn anything more about frame relay prior to attending, but there were a few surprises, and I learned stuff that I just havent seen from books etc.

Narbik’s memory really is something else…as others have said, there are no slides, its all whiteboard.

Narbik also does not like you using a option unless its really needed, eg…a lot of ppl *cough* will put no frame inverse under the main serial interface. Well if theres no IP address under the main interface, why do no frame inv? After all no inarp requests will be sent out a main interface that has no IP address assigned to it.

Narbik also does not like the use of the broadcast keyword used after frame maps unless its really needed

—

Didn’t really get much work done after the bootcamp this night, as some of my colleagues and I spent some time just trying to find a chinese that was open The chinese takeaway was ridicilously expensive too…can you say over 5 quid for special fried rice?!

Anyway Im sure today will go smoother.

There is a certain challenge though that needs to be overcome and that is with ppl talking about various things non bootcamp related, and you are trying to concentrate

Someone in gs mentioned the use of earplugs, and I can see why!

All in all though yesterday was a good day.