fredrik's thread

fredrikjj

I guess I should upgrade from the CCNP forum since I've started on Doyle's books. Inspiratonal intro, huh?

Find more posts tagged with

Comments

fredrikjj

I'm looking forward to some hardcore RIP talk in the coming weeks.

reaper81

Good luck!

gorebrush

RIP still has some "weird" things you can pull off with it.

EdTheLad

gorebrush wrote: »

RIP still has some "weird" things, you can pull off with it.

I prefer to look at hot chicks for that!

gorebrush

Filth.

fredrikjj

Guys, name my blog. I have a feeling that "just another boring ccie blog" is taken though...

Scales

fredrikjj wrote: »

Guys, name my blog. I have a feeling that "just another boring ccie blog" is taken though...

fred-IE

fredrikjj

I've covered the first 200 page of Routing TCP/IP Vol 1, and it does in fact live up to the hype. It's hard to pinpoint exactly what makes it such an enjoyable read, but it probably has something to do with it being at just the right level of difficulty for some who has completed the CCNP. Most of the concepts have been familiar so far, but I've picked up a few things:

1) More details on static routing. How/when/why they are installed in the routing table.
2) Sequence numbers, and how their are used in link state protocols.
3) How to connect discontiguous major networks with RIP version 1 using secondary addresses. I don't expect this to ever be relevant knowledge, but I found it very neat.

Scales wrote: »

fred-IE

That's clever

fredrikjj

Why you shouldn't roll over OSPF keys in a live environment

A paranoid manager comes to you and asks you to change the OSPF password. The manager wants it done yesterday and has heard that you can do this without affecting the operation of the network. Here's is why you probably don't want to do that unless absolutely necessary.

OSPF's MD5 Authentication operates using numbered keys, where each key has a corresponding password. Our baseline for this experiment is this configuration:

Router 1
interface GigabitEthernet1/0
 ip address 192.168.1.1 255.255.255.0
 ip ospf message-digest-key 1 md5 password1

Router 2
interface GigabitEthernet1/0
 ip address 192.168.1.2 255.255.255.0
 ip ospf message-digest-key 1 md5 password1

#debug ip ospf adj gives us:

OSPF-1 ADJ   Gi1/0: Send with youngest Key 1

The idea behind rolling keys over is that as you enter a new key (OSPF calls this a younger key - it doesn't have to be a higher key number) on one router, that router starts sending multiple copies of OSPF packets going out that interface. Once a new key number has been agreed upon by both routers, only packets with this new key is sent. It sounds easy enough, but there is one big caveat that we need to be aware of.

You enter a new key on router 1:

R1
interface GigabitEthernet1/0
 ip address 192.168.1.1 255.255.255.0
 ip ospf message-digest-key 1 md5 password1
 ip ospf message-digest-key 2 md5 password2

OSPF starts sending copies of packets with both key 1 and key 2.

OSPF-1 ADJ   Gi1/0: Send with key 1
OSPF-1 ADJ   Gi1/0: Send with key 2

So far so good.

You go to the second router and enter the same key:

R2
interface GigabitEthernet1/0
 ip address 192.168.1.2 255.255.255.0
 ip ospf message-digest-key 1 md5 password1
 ip ospf message-digest-key 2 md5 password3

We now get the following debug output from R1:

OSPF-1 ADJ   Gi1/0: Send with key 1
OSPF-1 ADJ   Gi1/0: Send with key 2
OSPF-1 ADJ   Gi1/0: Rcv pkt from 192.168.1.2 : Mismatched Authentication Key - Message Digest Key 2
OSPF-1 ADJ   Gi1/0: Send with youngest Key 2
OSPF-1 ADJ   Gi1/0: Rcv pkt from 192.168.1.2 : Mismatched Authentication Key - Message Digest Key 2
....
OSPF-1 ADJ   Gi1/0: 2.2.2.2 address 192.168.1.2 is dead, state DOWN

Note how it stops sending key 1 after hearing about key 2 from router 2.

Despite the fact that we had a working key (key 1) and didn't remove it, the typo we made on router 2 still brought down the neighbor relationship. Basically, OSPF does not verify that the new key is actually correct before it stop transmitting the old key(s).

fredrikjj

OSPF Transit Capability In A Nutshell

I've started working on the OSPF section in INE Volume 1, and the first section that I got stuck on was 6.13 that deals with the OSPF Transit Capability. It's not something that I've encountered in Doyle or any of the CCNP books.

I've read this post Understanding OSPF Transit Capability and this is basically a short summary, leaving out all the details and just focusing on the concepts. We have this topology:

Normal OSPF behavior is that inter-area data must flow through the backbone and cannot take shortcuts through other areas:

In this topology, that leads to an unfavorable traffic pattern from R4 to R1 because traffic must use the slow links R4-R5 and R5-R2.

In CCNP you learn that virtual links are used to a) fix a discontiguous backbone and b) attach areas to the backbone that do not have a physical connection to it. A third use is to create shortcuts through non-backbone areas. For example, if we create a virtual link between R4 and R3, R3 has an interface in area 0, and R4-R3-R2 becomes a valid pattern.

The Transit Capability sounds fancy, but it's just the default behavior of OSPF. Essentially it means that data does not have to follow the same path as the virtual links across the transit area. For example, if we establish virtual links between R4-R5 and R5-R3, traffic can still take the shorter R4-R3 path:

However, if we disable the transit capability with the command router(config-router)#no capability transit on R4 and R5, traffic must follow the virtual links:

ospf-transit-capability1.jpg

ospf-transit-capability1-1.jpg

ospf-transit-capability1-3.jpg

ospf-transit-capability1-2.jpg

bermovick

... and you understand this? Cripes, maybe I don't belong in this section of the forums.

fredrikjj

I don't know what to say to that, but there's obviously a reason why my post is a few pictures and 200 words and Lapukhov's original is a 10 page essay. There are different levels of understanding, and acquiring conceptual understanding is much easier than the detailed fundamentals that you'll find in his blog post.

You could probably argue that it's good enough to know what I now know about the transit capability, but it seems equally likely that someone with very deep OSPF knowledge could construct a scenario where I will make a mistake because don't have the real fundamentals.

EdTheLad

The basic idea is learn the type 3 flooding rules, i.e. you cant accept a type 3 lsa that comes from non-area 0. But when the transit capability is enabled you can. This becomes tricky when you can start preferring type 3 lsa's over type 1.

fredrikjj

EdTheLad wrote: »

The basic idea is learn the type 3 flooding rules, i.e. you cant accept a type 3 lsa that comes from non-area 0. But when the transit capability is enabled you can. This becomes tricky when you can start preferring type 3 lsa's over type 1.

Strictly speaking, the transit capability is the ability for OSPF to use different next hops than the virtual link. This is on by default. You need the virtual link to accept the type 3 across the non-backbone, and the transit capability is an additional feature to enhance the VL.

EdTheLad

I've played around allot with VLs and transit capability, can't remember all the details without reviewing it, no time. The different next-hops what you mention are the type 3 lsa's accepted via non area 0. Without transit capability enabled, the abr doesn't accept the type 3 lsa's from the transit area and hence the only path is via the type 3 received over the VL.

fredrikjj

You probably mean type 3 received over the VL?

EdTheLad

Yup, i'll edit it.

bermovick

Actually, once I spent some time going through it (slowly), I mostly get it. Some of the explanations escape me - stuff like "it relies on the fact that the inter-area routes flooded into the transit area are “congruent” to the virtual-link", and my skin itches at the whole "here's a terribly inefficient design. Make it work efficiently without actually fixing it" of the example from the link (that I've labbed to tinker with). I'll stop with the hijacking of your thread though

fredrikjj

EdTheLad wrote: »

I've played around allot with VLs and transit capability, can't remember all the details without reviewing it, no time. The different next-hops what you mention are the type 3 lsa's accepted via non area 0. Without transit capability enabled, the abr doesn't accept the type 3 lsa's from the transit area and hence the only path is via the type 3 received over the VL.

The ABR will still accept and install the LSAs even without the transit capability (TC) as long as you have triggered their flooding with a virtual link. When you enable TC, the router is capable of changing the nexthop of the route to align with a shortcut advertised by another router than the virtual link neighbor. It's unclear to me how this happens since the LSDB looks largely the same even if you disable TC.

Maybe we're just discussing semantics here, I'm not sure, but to me the VL seems like the primary variable, with the TC adjusting the forwarding behaviour slightly if a shorter path exists through the transit area than over the virtual link.

EdTheLad

fredrikjj wrote: »

The ABR will still accept and install the LSAs even without the transit capability (TC) as long as you have triggered their flooding with a virtual link. When you enable TC, the router is capable of changing the nexthop of the route to align with a shortcut advertised by another router than the virtual link neighbor.

Those LSAs will be accepted and installed but not used i.e. the "routing bit" isn't set. This is normal for type 3 lsa's arriving via non Area 0. But when transit capability is enabled the "routing bit" will be set.

fredrikjj

Yes, that would make sense, right. But the routing bit is set on the summary in area 0 learned over the virtual link, TC or no TC. That is, if another summary advertises a shortcut, it's still not the one installed in the RIB, if the routing bit is to be believed. If that's even a meaningful distinction to make.

PS.
Of course, there's also the possibility that I've broken dynamips.

EdTheLad

Yes, it should be. So then you have type 3 lsa's learned via the VL and via the transit area, whichever is lowest metric wins.

xnx

I look forward to following this, i'm currently studying QoS(IntServ and DiffServ) and BGP, it seems reading RFC's can be useful if you want to find the actual definition for a term rather than a paraphased one!

reaper81

Just a note on the routing bit. It's just an indicator that it's a valid LSA, it doesn't mean that the LSA will get installed into the RIB. It's a quick check as opposed to going through each LSA each time if it is valid or not.

EdTheLad

reaper81 wrote: »

Just a note on the routing bit. It's just an indicator that it's a valid LSA, it doesn't mean that the LSA will get installed into the RIB. It's a quick check as opposed to going through each LSA each time if it is valid or not.

Yes normally, but when it comes to transit capability, it's not always the case. I'll show an example in my next post.

EdTheLad

My topology

R1 <---> R2 <

> R3,R4

R1

hostname R1
!
interface Ethernet0/0
 ip address 10.0.12.1 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 router-id 1.1.1.1
 network 10.0.12.1 0.0.0.0 area 0
!

!
hostname R2
!
interface Ethernet0/0
 ip address 10.0.12.2 255.255.255.0
 ip ospf network point-to-point
!         
interface Ethernet0/1
 ip address 10.0.23.2 255.255.255.0
 ip ospf network point-to-point
 ip ospf cost 10
!
interface Ethernet0/2
 ip address 10.0.24.2 255.255.255.0
 ip ospf network point-to-point
 ip ospf cost 5
!
router ospf 1
 router-id 2.2.2.2
 area 1 virtual-link 3.3.3.3
 network 10.0.12.2 0.0.0.0 area 0
 network 10.0.23.2 0.0.0.0 area 1
 network 10.0.24.2 0.0.0.0 area 1
!

!
hostname R3
!
interface Loopback100
 ip address 100.100.100.100 255.255.255.255
!
interface Ethernet0/1
 ip address 10.0.23.3 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 router-id 3.3.3.3
 area 1 virtual-link 2.2.2.2
 network 10.0.23.3 0.0.0.0 area 1
 network 100.100.100.100 0.0.0.0 area 2
!

hostname R4
!
interface Loopback100
 ip address 100.100.100.100 255.255.255.255
!
interface Ethernet0/2
 ip address 10.0.24.4 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 router-id 4.4.4.4
 network 10.0.24.4 0.0.0.0 area 1
 network 100.100.100.100 0.0.0.0 area 0
!

So as per the configs, i have a VL between R2 and R3 with area 1 being the transit area. Prefix 100.100.100.100/32 is in area 2 on R3, with VL, R3 becomes an ABR and sends 100.100.100.100/32 as a type 3 lsa over the VL and also into area 1.

R2#sh ip ospf 1 database summary 100.100.100.100 ADv-router 3.3.3.3

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

Summary Net Link States (Area 0)

Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 6 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 100.100.100.100 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0x2F6F
Length: 28
Network Mask: /32
MTID: 0 Metric: 1

Summary Net Link States (Area 1)

LS age: 1455
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 100.100.100.100 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0x2F6F
Length: 28
Network Mask: /32
MTID: 0 Metric: 1

As a hack to advertise another 100.100.100.100 type 3 lsa into area 1, i configured R4 with 100.100.100.100 in area 0. R4 will then advertise this prefix into area 1.

R2#sh ip ospf 1 database summary 100.100.100.100 ADv-router 4.4.4.4

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

Summary Net Link States (Area 1)

LS age: 1021
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 100.100.100.100 (summary Network Number)
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0x1189
Length: 28
Network Mask: /32
MTID: 0 Metric: 1

So looking at 100.100.100.100/32 in the database from all neighbors

R2#sh ip ospf database summary 100.100.100.100

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

Summary Net Link States (Area 0)

Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 6 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 100.100.100.100 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0x2F6F
Length: 28
Network Mask: /32
MTID: 0 Metric: 1

Summary Net Link States (Area 1)

LS age: 5
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 100.100.100.100 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000002
Checksum: 0x2D70
Length: 28
Network Mask: /32
MTID: 0 Metric: 1

LS age: 1413
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 100.100.100.100 (summary Network Number)
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0x1189
Length: 28
Network Mask: /32
MTID: 0 Metric: 1

Due to the VL, R2 is transit capable by default, which means it can receive type 3 lsa's from nonArea 0, i.e. coming from area 1.

R2#sh ip ospf | b Area 1
Area 1
Number of interfaces in this area is 2
This area has transit capability: Virtual Link Endpoint
Area has no authentication
SPF algorithm last executed 00:18:00.178 ago
SPF algorithm executed 17 times
Area ranges are
Number of LSA 6. Checksum Sum 0x033478
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0

R2#sh ip ospf int bri
Interface PID Area IP Address/Mask Cost State Nbrs F/C
VL0 1 0 10.0.23.2/24 10 P2P 1/1
Et0/0 1 0 10.0.12.2/24 10 P2P 1/1
Et0/2 1 1 10.0.24.2/24 100 P2P 1/1
Et0/1 1 1 10.0.23.2/24 10 P2P 1/1
R2#

R2#sh ip route 100.100.100.100
Routing entry for 100.100.100.100/32
Known via "ospf 1", distance 110, metric 11, type inter area
Last update from 10.0.23.3 on Ethernet0/1, 00:00:50 ago
Routing Descriptor Blocks:
* 10.0.23.3, from 3.3.3.3, 00:00:50 ago, via Ethernet0/1
Route metric is 11, traffic share count is 1
R2#

R2#sh ip ospf border-routers

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

Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 4.4.4.4 [100] via 10.0.24.4, Ethernet0/2, ABR, Area 1, SPF 19
i 3.3.3.3 [10] via 10.0.23.3, Ethernet0/1, ABR, Area 0, SPF 11
i 3.3.3.3 [10] via 10.0.23.3, Ethernet0/1, ABR, Area 1, SPF 19
R2#

At the moment R2 prefers the path via R3 due to the egress interface metric.

Now i'll reduce the ospf cost on eth 0/2 to 5.

R2#sh ip ospf int brie
Interface PID Area IP Address/Mask Cost State Nbrs F/C
VL0 1 0 10.0.23.2/24 10 P2P 1/1
Et0/0 1 0 10.0.12.2/24 10 P2P 1/1
Et0/2 1 1 10.0.24.2/24 5 P2P 1/1
Et0/1 1 1 10.0.23.2/24 10 P2P 1/1
R2#
R2#sh ip route 100.100.100.100
Routing entry for 100.100.100.100/32
Known via "ospf 1", distance 110, metric 6, type inter area
Last update from 10.0.24.4 on Ethernet0/2, 00:00:17 ago
Routing Descriptor Blocks:
* 10.0.24.4, from 3.3.3.3, 00:00:17 ago, via Ethernet0/2
Route metric is 6, traffic share count is 1

As you can see, R2 now prefers the path via R4, the funny part is, it still thinks its learned via 3.3.3.3 i.e. the routing bit is still set in the database for R3.

R2#sh ip ospf database summary 100.100.100.100

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

Summary Net Link States (Area 0)

Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 6 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 100.100.100.100 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0x2F6F
Length: 28
Network Mask: /32
MTID: 0 Metric: 1

Summary Net Link States (Area 1)

LS age: 167
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 100.100.100.100 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000002
Checksum: 0x2D70
Length: 28
Network Mask: /32
MTID: 0 Metric: 1

LS age: 1574
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 100.100.100.100 (summary Network Number)
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0x1189
Length: 28
Network Mask: /32
MTID: 0 Metric: 1

Now i'll disable transit capability on R2 and even though the lowest cost is to R4, the preferred route will be to R3. This is because R2 will no longer accept type 3 lsa's arriving from nonArea 0.

R2(config)#router ospf 1
R2(config-router)#no ca
R2(config-router)#no capability tr
R2(config-router)#no capability transit
R2(config-router)#do sh ip ospf | b Area 1
Area 1
Number of interfaces in this area is 2
Area has no authentication
SPF algorithm last executed 00:00:00.433 ago
SPF algorithm executed 22 times
Area ranges are
Number of LSA 7. Checksum Sum 0x03CE74
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0

R2#sh ip ospf int br
Interface PID Area IP Address/Mask Cost State Nbrs F/C
VL0 1 0 10.0.23.2/24 10 P2P 1/1
Et0/0 1 0 10.0.12.2/24 10 P2P 1/1
Et0/2 1 1 10.0.24.2/24 5 P2P 1/1
Et0/1 1 1 10.0.23.2/24 10 P2P 1/1
R2#
R2#sh ip route 100.100.100.100
Routing entry for 100.100.100.100/32
Known via "ospf 1", distance 110, metric 11, type inter area
Last update from 10.0.23.3 on Ethernet0/1, 00:00:37 ago
Routing Descriptor Blocks:
* 10.0.23.3, from 3.3.3.3, 00:00:37 ago, via Ethernet0/1
Route metric is 11, traffic share count is 1
R2#

fredrikjj

As a hack to advertise another 100.100.100.100 type 3 lsa into area 1, i configured R4 with 100.100.100.100 in area 0. R4 will then advertise this prefix into area 1.

A cool thing that I discovered when I labbed it up yesterday is that it's enough to just enter a virtual link statement for the transit area for the type 3s to get flooded in that scenario. You don't have to put an interface in area 0, or create an actual virtual link adjacency.

EdTheLad

fredrikjj wrote: »

A cool thing that I discovered when I labbed it up yesterday is that it's enough to just enter a virtual link statement for the transit area for the type 3s to get flooded in that scenario. You don't have to put an interface in area 0, or create an actual virtual link adjacency.

You mean config a VL towards R4, which would make R4 an ABR and hence R4 would send summarizes into the transit area. Yes i could have done that but it wouldn't have been as clear as creating area 0 on R4. With a VL to R4, R2 would have seen R4 type 3 lsa's describing 100.100.100.100/32 prefix and then you could say R2 was using the type 3 coming over the VL from R4.

fredrikjj

EdTheLad wrote: »

You mean config a VL towards R4, which would make R4 an ABR and hence R4 would send summarizes into the transit area. Yes i could have done that but it wouldn't have been as clear as creating area 0 on R4. With a VL to R4, R2 would have seen R4 type 3 lsa's describing 100.100.100.100/32 prefix and then you could say R2 was using the type 3 coming over the VL from R4.

I'm saying that if your only goal is to make a router an ABR so that it floods type 3s into the transit area, you can configure a virtual link statement under the router process pointing to an ABR, and that alone will make the router an ABR. The VL doesn't have to actually connect. Of course, you already have another virtual link between two different routers. I'm only talking about making a router an ABR so that it can be used for the transit capability.

I don't claim that there's any advantage to this compared to creating an interface in area 0 to accomplish the same thing. And if you input the virtual link command on one side, you might as well do it on the other side as well to have redundant virtual links.

Essentially, a virtual link is an interface in area 0, and it's technically "up" even before it creates an adjacency with the other side of the link as long as it points to a valid router-id.

Virtual Link configured:

R12#show run | s router ospf 1
router ospf 1
 router-id 2.2.2.2
 area 1 virtual-link 1.1.1.1

It's an interface in area 0:

R12#show ip ospf int brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
VL5          1     0               192.168.1.2/24     64    P2P   0/0
Se1/0        1     1               192.168.1.2/24     64    P2P   1/1
Lo0          1     2               10.2.2.2/24        1     P2P   0/0

The virtual link interface is not adjacent with anything:

R12#show ip ospf neighbor 
Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           0   FULL/  -        00:00:38    192.168.1.1     Serial1/0

The router is still an ABR:

R12#show ip ospf | inc area border
 It is an area border router

fredrikjj

I finished OSPF in INE Workbook Volume 1 (v4) a few days ago. I'm also working on an OSPF mind map where I feel like I've covered most topics but there are still some loose ends that I need to tie up. I'm currentinly in the process of adding the troubleshooting scenarios from the 2002 book Troubleshooting IP Routing Protocols which I expect to finish later tonight. Here's the mind map, but keep in mind that it's very much a work in progress, and it desperately needs to be improved aesthetically.

https://drive.google.com/file/d/0B2bdhZFpmd44YzRXSWZ5RTlFTEU/edit?usp=sharing

PS.
Once I feel like I'm done with OSPF, I'm probably going to move to BGP. The logical choice for the next protocol to study would be EIGRP since it's also an IGP, but being stronger on BGP would be a lot more useful in real life I imagine as EIGRP has little to no deployment in Sweden from what I've heard. Plus, I already kind of know EIGRP from CCNP. Or I might just quickly run through the INE EIGRP labs, who knows. I guess I haven't decided.