Daniels quest for CCIE

OSPF magic – Make interarea routes become intraarea

reaper81 — Thu, 26 Jan 2012 07:36:56 +0000

This is a follow up post to my last OSPF post about repairing area 0.
In the comments section Ray asked me what we can do if we have a
scenario where we have another area that is discontigous. In this
example we are using area 1. Area 1 is used everywhere but between
R1 and R4 is the backbone area. The routes will therefore be
interarea. What if we were told to make these routes appear as
intra area? First look at the topology. Download .net file and
initial and final configs here.

First we start by confirming that routes received on R1
are coming in as interarea routes.

Yes they are. This is expected behaviour. So what can we do to
make them appear as intraarea? Using a virtual link does not help
since it always belongs to area 0. We could use the tunnel technique
that was used in the previous post. Let’s try that. Same procedure as
last time. Source tunnel from physical interface. Use IP unnumbered
from an interface in area 1.

The tunnel is up and we have a new adjacency.

The IP address is 0.0.0.0/0 and located in area 1. Lets look at the
router LSA for area 1.

The address is 0.0.0.16 just as the last time. This should be 10 according
to the SNMP MIB but as one of my friends Patrick pointed out 16 in decimal
is 0×10 in hex. Maybe it is encoded in hex?

So now lets check the routing table.

Problem solved. Routes are now received as intraarea. So there you have it,
another OSPF problem solved.

Repairing a discontigous area 0 in OSPF

reaper81 — Wed, 25 Jan 2012 12:09:42 +0000

First start by looking at the diagram above. This is a scenario I ran into while
doing my mock lab. It is pretty obvious that we will have issues with OSPF since area 0
is discontigous. You should be able to spot this by just looking at the diagram.

So what are the tools we have to repair discontigous areas? The most common and
straightforward is to use a virtual-link. However in this scenario it is not allowed.
First lets look what issues we will have in this topology. I have prepared the
topology and initial configs with OSPF for you which can be downloaded here, final configs are also included.

We start by looking at the routing table of R1.

We can only see the loopback of R2. Why is that? R1 is an ABR. It has an
interface in area 0 and in another area. It will not install interarea routes
received on a non backbone interface.

This is the database on R1. We can see that all IA routes are indeed in
the database but they are not being installed into the RIB. To test our
thesis from the last OSPF post, lets shutdown Fa0/0 on R1. This should in
theory mean that R1 is no longer an ABR and that it can install routes
received on a non backbone area.

It works. So our knowledge of OSPF seems good. So this is an option we
can use, although we would not have reachability to R2′s loopback. The techniques
I show here would generate no points for the OSPF section but having reachability
in IGP is critial so if you can’t do something the right way, cheat!
What I mean by that is that if you don’t have reachability you will loose points
later in BGP, MPLS, multicast and maybe even IPv6 and security section. So you
see a lot of points are at stake and if we can’t solve a task the right way do it
some other way. Use static routes if you must!

We were not allowed to use a virtual-link but lets try that anyway to
see that we can install all the routes.

Yes, now we have reachability. We would loose 2 or 3 points probably for doing
this but could potentially save us 10-15 points later. I ended up having to do
this on my mock since I had problems configuring the solution below.

So if we can’t use a virtual link, where does that leave us? We need a link
between R1 and R4 that is located in area 0. How about a tunnel? Yes, that is
definately an option. However we are not allowed to introduce any new
IP addresses into the network. How do we solve that? IP unnumbered, we have to
borrow an IP from another interface. Lets setup the tunnel.

We source the tunnel from a physical interface and the destination is the other
side of the FR connection. Why source from the physical interface? We don’t have
reachability to loopbacks yet since our IGP is broken, therefore we have to use
the physical address. Why unnumbered from the Ethernet interfaces? They are located
in area 0. We must have an IP that is located in area 0 to repair the discontigous network.

So now we have an adjacency both over serial0/0 and over the tunnel. The tunnel
interface is point-to-point and has a very high cost. Notice that the IP for
the tunnel is 0.0.0.0/0.

Now look at the routing table of R1.

We can see that prefixes are reached via 155.1.34.4. This is the IP of Fa0/0
on R4 which was derived from the IP unnumbered. So what is interesting here
is that the adjacency between R1 and R4 is not in the same subnet, so we
are bypassing that check. We can also see that we need to recurse routing
lookups since the routes are pointing at 155.1.34.4.

This route is reached via the tunnel. If we look at the OSPF database on R1
we see a router LSA for R4 and there is the P2P link.

Router Interface address is 0.0.0.16. This is interesting, normally this is
the IP address of the interface. We are now using unnumbered. I’m not sure
why it is choosing 16. RFC says the following:

“For unnumbered point-to-pointlinks, the Link Data field should be set to
the unnumbered interface’s MIB-II [Ref8] ifIndex value.

If we look at the SNMP MIB, must enable SNMP first.

So this value should be 10. Seems like Cisco is not really following
the RFC (RFC2328) here. We can enable that behaviour with interface-id snmp-if-index.

Now we have the expected value of 10.

You can read more at Cisco.

So this should give you a look into OSPF. I have also attached a packet capture so that you can look at the LS Update going over the tunnel interface. We can see that the source of the
packet is 155.1.14.4 which is R4 IP addess and the destination is 155.1.14.1.
In there we have the other IP packet which has a source of 155.1.34.4 and a destination
of 224.0.0.5.

First mock lab done (Cisco 360)

reaper81 — Fri, 20 Jan 2012 19:39:19 +0000

So I had my first run at a mock lab (Cisco 360). It was not a great score by any means. I got 59% on the TS and 49% on the config. Still, it does show that I’m not THAT far away. The lab was rated as advanced and there were a lot of tricky stuff. Some tasks I solved but not in the way I should have done.

I learned a lot of leassons. How to read the tasks and how to solve tasks in TS without breaking requirements. I spent a lot of time on some EIGRP config because I misread the task. The task was to do unequal load balance but I thought I wasn’t allowed to change the delay of the interface which I was.

Very good practice indeed. Will try another mock in a couple of weeks.

50000 views!

reaper81 — Tue, 17 Jan 2012 05:19:32 +0000

The site has now hit 50000 views. I did not really expect this when I started the blog. Thanks to all my readers

I’m doing my final prep for the CCIE. Vol1 has be finished. Right now I’m focusing on full scale labs and troubleshooting labs. Tonight I have 2 TS labs planned and on friday I’m taking a Cisco360 mock lab. I’ve heard that they are high quality and close to the experience of the real exam. I hope so because they cost a pretty penny.

I’ll post my results when done, hopefully they won’t be too terrible but I’m not expecting a really good result either.

How well do you really know OSPF?

reaper81 — Sun, 15 Jan 2012 11:33:29 +0000

OSPF is by far the most complicated IGP on the RS lab if we go in to the details of the protocol and the loop prevention mechanisms. While doing some labs this week I ran in to some interesting issues. This post will describe different scenarios and test your understanding of OSPF. I will show a diagram and ask a question, try to answer it and when you want to know the answer then the text is hidden below. You can see the text by marking it since it’s written with a white font.

Lets begin. We will start with an issue I ran into while doing an ASET lab (Cisco partner labs). Look at the following diagram.

R5 is a PE in a MPLS VPN backbone. R5 is running OSPF in a VRF towards the CE R4. However R5 will not install interarea routes received from R4, why? Look at the following output.

R5#sh ip ospf data sum 1.1.1.3

OSPF Router with ID (1.1.1.5) (Process ID 100)

OSPF Router with ID (5.5.5.5) (Process ID 1)

Summary Net Link States (Area 51)

Routing Bit Set on this LSA
LS age: 1386
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 1.1.1.3 (summary Network Number)
Advertising Router: 1.1.1.4
LS Seq Number: 80000003
Checksum: 0xED3
Length: 28
Network Mask: /32
TOS: 0 Metric: 76

R5 is part of the MPLS super backbone (area0) so it is an ABR. ABRs will not install interarea routes that are received over a non backbone area. If the area between R4 and R5 was area 0 then there would be no issues but since we are using area 51 we have to use a workaround. We enable the capability vrf-lite under the ospf process which disables the loop checks of the PE

Now lets define some of the concepts of OSPF and test your understanding. Look at the diagram.

Is R3 an ABR?

No, the definition is that an ABR is a router with an UP interface in the backbone area and at least another area.

Will R3 generate IA routes for Area 1 and 2?

No, it is not an ABR so it will not generate any IA routes.

Now we create a loopback on R3 and put it in OSPF area 0. No OSPF adjacencies can of course be built over this interface. Will R3 generate any summary routes now?

Yes, even though R3 is not really connected to Area 0 it has an UP interface in area 0 so it will announce itself as an ABR and generate summary routes.

R2#sh ip ospf border-routers

OSPF Process 1 internal Routing Table

Codes: i – Intra-area route, I – Inter-area route

i 1.1.1.1 [1] via 155.1.12.1, FastEthernet0/1, ABR, Area 1, SPF 7
i 3.3.3.3 [1] via 155.1.23.3, FastEthernet0/0, ABR, Area 1, SPF 7

Summary Net Link States (Area 1)

Link ID ADV Router Age Seq# Checksum
33.33.33.33 3.3.3.3 13 0×80000001 0×004566
155.1.16.0 1.1.1.1 1958 0x8000000D 0x00B9C5
155.1.34.0 1.1.1.1 939 0×80000006 0x00155D
155.1.34.0 3.3.3.3 19 0×80000001 0x00CEA2
155.1.35.0 1.1.1.1 942 0×80000006 0x00145C
155.1.35.0 3.3.3.3 21 0×80000001 0x00C3AC
155.1.45.0 1.1.1.1 942 0×80000006 0x009BCB
155.1.45.0 3.3.3.3 21 0×80000001 0x005F06
155.1.46.0 1.1.1.1 942 0×80000006 0x0086E0

If we traceroute the IP of R5 this is the path.

R1#traceroute 155.1.35.5

Type escape sequence to abort.
Tracing the route to 155.1.35.5

1 155.1.16.6 140 msec 76 msec 48 msec
2 155.1.46.4 92 msec 64 msec 64 msec
3 155.1.45.5 184 msec * 108 msec

Why is this and how can we make the path go directly from R1 to R3 to R5? Look at the OSPF database.

Summary Net Link States (Area 1)

Link ID ADV Router Age Seq# Checksum
33.33.33.33 3.3.3.3 534 0×80000001 0×004566
155.1.16.0 1.1.1.1 437 0x8000000E 0x00B7C6
155.1.34.0 1.1.1.1 1459 0×80000006 0x00155D
155.1.34.0 3.3.3.3 542 0×80000001 0x00CEA2
155.1.35.0 1.1.1.1 1463 0×80000006 0x00145C
155.1.35.0 3.3.3.3 543 0×80000001 0x00C3AC
155.1.45.0 1.1.1.1 1463 0×80000006 0x009BCB
155.1.45.0 3.3.3.3 543 0×80000001 0x005F06
155.1.46.0 1.1.1.1 1463 0×80000006 0x0086E0

R3 is announcing the summary but it is not being used by R1. Why?

R1 and R4 have full adjacencies via Area 0 so they will not accept summary routes received on a non backbone interface. To fix this we need a full adjacency between R1 and R3 which is created with a virtual link.

R3(config-router)#area 1 virtual-link 1.1.1.1
R1(config-router)#area 1 virtual-link 3.3.3.3

R1#sh ip ospf data sum 155.1.35.0

OSPF Router with ID (1.1.1.1) (Process ID 1)

Summary Net Link States (Area 0)

Routing Bit Set on this LSA
LS age: 10 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 155.1.35.0 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0xC3AC
Length: 28
Network Mask: /24
TOS: 0 Metric: 1

R1#traceroute 155.1.35.5

Type escape sequence to abort.
Tracing the route to 155.1.35.5

1 155.1.13.3 64 msec 40 msec 44 msec
2 155.1.35.5 80 msec * 64 msec

R1 is now using the direct path since R3 is now a real ABR. However as R3 now has an adjacency to Area 0 it will no longer accept summary routes from R4. If we want to fix this another virtual link is needed.

I hope this post gave you some things to think about regarding OSPF. This post was mostly inspired by the great document from Petr Lapukhov

Happy new year!

reaper81 — Sat, 31 Dec 2011 16:02:53 +0000

Here is to a great 2012 for everyone reading this blog. I hope all your dreams come true in 2012. I will only make one new years resolution. I will become a CCIE in 2012.

Happy new year!

Merry X-mas!

reaper81 — Fri, 23 Dec 2011 14:29:34 +0000

Wanted to wish everyone a merry christmas. I’ve been labbing a lot lately and today I finished the Vol1 security section. I have MPLS, IP services and Applications left. I might do some revision of QoS as well. I’m trying hard to be in good shape for the lab but time is not on my side. So far I have spent 800h preparing for the CCIE.

I’m taking a few days off to charge my batteries and I’ll be back next week.

Merry christmas and a happy new year to everyone!

Quiz – AAA authorization

reaper81 — Sun, 18 Dec 2011 19:49:53 +0000

I’m doing the security section of Vol1 right now and this is something I think people might have confused. Look at the following configuration:

! Scenario 1
aaa authentication login default group tacacs+ none
aaa authorization exec default none
!
line console 0
privilege level 15
! Scenario 2
aaa authentication login default group tacacs+ none
aaa authorization exec default if-authenticated
!
line console 0
privilege level 15

Assume that the Tacacs+ servers are unavailable. What will be the result and what is the difference between scenario 1 and 2? Post your answer in comments.

Frame-relay IPv6 speed drill

reaper81 — Tue, 13 Dec 2011 21:29:41 +0000

Going for the lab we need both speed and skills. I made a simple IPv6 frame-relay lab that should test your speed. Time yourself and post your time to configure in the comments. Just by looking at the time I could probably tell if you are typing manually or not. This is the scenario.

Routers R1, R2, R3 and R4 are connected to a frame-relay cloud. They are all spokes connecting to the hub R5. R1 has a DLCI 105 to R5 which is 501 from R5 POV. R2 has a DLCI that is 205 and 502 from R5 POV and so on. This is the task.

Configure all devices with a global address of 2001:1:0:1234::Y where Y is the device number.
Configure static mappings on all devices.
All devices should be able to ping each other.

Download the .net from here and then edit for your IOS version and working dir etc.

I didn’t time myself but I think I could do it in less than 2 minutes for sure. Later I will post some tips on how to improve speed.

Followup on multicast helper map

reaper81 — Fri, 09 Dec 2011 14:31:32 +0000

I had some requests for the final configs so I have fixed those. You can download them here. Also I had some issues getting the traffic through but thanks to my helpful readers like zumzum I now have it figured out.

Lets start on R4 since this is the source of the traffic.

R4 wants to send traffic to 1.1.1.1 with a source of 155.1.12.4. We know that route via RIP and the next-hop is 155.1.12.1. That network is directly connected (secondary). We need to find out the MAC address of 155.1.12.1 for our ARP entry. R3 has proxy arp enabled, which is the default. However it will not respond to R4 ARP request since it does not have the subnet 155.1.12.0/24 connected. R4 must therefore have a static ARP entry. I did an error here earlier by typing in R1 MAC but this should be the MAC of R3 Fa0/0 since that is the link connecting us. We create the static ARP with arp 155.1.12.1 xxxx.xxxx.xxxx arpa. R4 now has all the info needed.

Packet travels to R3. R3 does not have a route for 1.1.1.1. We create a static route, ip route 1.1.1.0 255.255.255.0 155.1.23.2. We also need a static route back to R4 for the 155.1.12.4 IP. Ip route 155.1.12.4 255.255.255.0 155.1.34.4.

Packet now travels to R2. R2 also needs to know about 1.1.1.1 so we add a route there as well. Ip route 1.1.1.0 255.255.255.0 155.1.12.1. R2 also needs to find its way back to R4 so we add a static route, ip route 155.1.12.4 255.255.255.255 155.1.23.2.

Packet goes to R1 which will respond. It will send the packet out Fa0/0. R1 needs to know the MAC address for 155.1.12.4. R2 has proxy ARP enabled so it will reply with its own MAC address to R1. R1 will insert this into ARP cache and adjacency table and then we are good to go.

So except learning a multicast feature we also got to practice how to make connectivitiy in an unusual way and think through the whole process of packet flow.