What Makes a Router an OSPF ABR: Cisco Juniper Comparison
This blog is not directly tied to any topics related to CCIE studies, but it can be useful. It’s more of a general networking post. I had fun researching this information and decided it would be a nice thing to share with experts such as our readers.
In the Packet Pushers Podcast episode 89 (OSPF vs IS-IS Smackdown – Where You Can Watch Their Eyes Reload) published few months ago, I made few statements about border routers in both OSPF and IS-IS and their differences. This prompted some disagreement on the panel consisting of Ivan Pepelnjak of NIL, Petr Lapukhov of Microsoft, host Greg Ferro and myself. In this post, I’ll examine OSPF issues and follow-up with IS-IS in the next.
For the purpose of this testing, I will use the network of three routers connected in a “chain”. I will not change this network layout, only the configuration of the routing protocols, as required. Even though both IOS and Juniper configurations are completed in production ProctorLabs racks, I gave routers fictional names to avoid slight router numbering differences between our Cisco and Juniper racks.
Lab time!
One of the statements I made about OSPF was that OSPF router connected to two areas will not act as an ABR, i.e. the “B” bit in its type 1 LSA will not be set unless one of the areas is the backbone area 0.0.0.0. Petr mentioned it might be a Cisco specific behavior and given my recent Junos interest this was a perfect thing to test. The problem basically, boils down to how different vendors implement RFC3509.
OSPF Border in IOS
Here are the relevant initial configurations for our three Cisco routers. To make configurations as similar to the subswquent Juniper configurations, I will use subinterfaces in IOS. There is no other reason to do it.
R1:
interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface FastEthernet0/1 no shutdown ! interface FastEthernet0/1.12 encapsulation dot1q 12 ip address 192.168.12.1 255.255.255.0 ip ospf network point-to-point ! router ospf 1 router-id 1.1.1.1 passive-interface Loopback0 network 1.1.1.1 0.0.0.0 area 12 network 192.168.12.0 0.0.0.255 area 12 !
R2:
interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface FastEthernet0/1 no shutdown ! interface FastEthernet0/1.12 encapsulation dot1q 12 ip address 192.168.12.2 255.255.255.0 ip ospf network point-to-point ! interface FastEthernet0/1.23 encapsulation dot1q 23 ip address 192.168.23.2 255.255.255.0 ip ospf network point-to-point ! router ospf 1 router-id 2.2.2.2 network 192.168.12.0 0.0.0.255 area 12 network 192.168.23.0 0.0.0.255 area 23 !
R3:
interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface FastEthernet0/1 no shutdown ! interface FastEthernet0/1.23 encapsulation dot1q 23 ip address 192.168.23.3 255.255.255.0 ip ospf network point-to-point ! router ospf 1 router-id 3.3.3.3 passive-interface Loopback0 network 3.3.3.3 0.0.0.0 area 23 network 192.168.23.0 0.0.0.255 area 23 !
As we can see, routers R1 and R2 are neighbors in area 12, and routers R2 and R3 are neighbors in area 23. Does this make R2 and ABR? The discussion in the podcast revolved around Cisco-specific behavior in this case. Let’s check what R2 thinks about its situation.
Information whether a router is an ABR is carried in Router (Type 1) LSA as a “B” bit. If this bit is set to 1, router is an ABR. IOS will translate this bit into a helpful “Area Border Router” message. So, to get this information, I will have to check the OSPF database and read Router LSAs originated by R2. Since R2 will have both area 12 and area 23 databases even if it’s not an ABR, I will truncate the output for the sake of brevity.
R2:
R2#show ip ospf database router self-originate
OSPF Router with ID (2.2.2.2) (Process ID 1)
Router Link States (Area 12)
LS age: 663
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
LS Seq Number: 80000002
Checksum: 0x53CD
Length: 48
Number of Links: 2
[...]
Router Link States (Area 23)
LS age: 646
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
LS Seq Number: 80000002
Checksum: 0xFF3
Length: 48
Number of Links: 2
[...]
In the output above, there is no trace of the “B” bit being set. As further proof of this, let’s see if the route for 192.168.23.0/24 can be seen in the routing table on R1. If R2 was an ABR, we’d see this route.
R1:
R1#show ip route 192.168.23.0
% Network not in table
This is what I expected to see. It’s clear that IOS doesn’t consider R2 to be an ABR. This is a very important concept to remember when preparing for your CCIE, as at first glance it appears that R2 is an ABR. At this moment, we don’t have reachability between networks advertised by R1 and R3. How can we repair this situation? We will need to make R2 and ABR. In Cisco IOS, ABR is the router that has interfaces in area 0.0.0.0 and one or more other areas. Remedy of the situation is therefore rather simple. We’ll advertise R2′s Loopback0 into OSPF area 0 and see if that changes anything.
R2:
router ospf 1 network 2.2.2.2 0.0.0.0 area 0 !
R1:
R1#show ip route 192.168.23.0 Routing entry for 192.168.23.0/24 Known via "ospf 1", distance 110, metric 2, type inter area Last update from 192.168.12.2 on FastEthernet0/1.12, 00:38:38 ago Routing Descriptor Blocks: * 192.168.12.2, from 2.2.2.2, 00:38:38 ago, via FastEthernet0/1.12 Route metric is 2, traffic share count is 1 R1#show ip route ospf 2.0.0.0/32 is subnetted, 1 subnets O IA 2.2.2.2 [110/2] via 192.168.12.2, 00:38:44, FastEthernet0/1.12 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/3] via 192.168.12.2, 00:38:44, FastEthernet0/1.12 O IA 192.168.23.0/24 [110/2] via 192.168.12.2, 00:38:44, FastEthernet0/1.12
We now have the OSPF routes on R1. As a final confirmation of my position, let’s take a look at R2′s OSPF database. I will truncate it again, as I’m interested only in LSA headers.
R2:
R2#show ip ospf database router self-originate OSPF Router with ID (2.2.2.2) (Process ID 1) Router Link States (Area 0) LS age: 377 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 2.2.2.2 Advertising Router: 2.2.2.2 LS Seq Number: 80000002 Checksum: 0xA770 Length: 36 Area Border Router Number of Links: 1 [...] Router Link States (Area 12) LS age: 377 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 2.2.2.2 Advertising Router: 2.2.2.2 LS Seq Number: 80000004 Checksum: 0x52CB Length: 48 Area Border Router Number of Links: 2 [...] Router Link States (Area 23) LS age: 379 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 2.2.2.2 Advertising Router: 2.2.2.2 LS Seq Number: 80000004 Checksum: 0xEF1 Length: 48 Area Border Router Number of Links: 2 [...]
Clearly, just adding one interface into area 0 caused R2 to behave as an ABR. I wonder, how will Junos act in the same situation?
OSPF Border in Junos
Here are the relevant configurations from our Juniper routers. I have tried to replicate the configuration as much as I could. Since all logical configuration on Junos must be done on logical link units, including loopback (lo0) interface, some differences still exist. They are minor though.
R1:
interfaces {
fe-0/0/1 {
vlan-tagging;
unit 12 {
vlan-id 12;
family inet {
address 192.168.12.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 1.1.1.1/32;
}
}
}
}
routing-options {
router-id 1.1.1.1;
}
protocols {
ospf {
area 0.0.0.12 {
interface fe-0/0/1.12 {
interface-type p2p;
}
interface lo0.0 {
passive;
}
}
}
}
R2:
interfaces {
fe-0/0/1 {
vlan-tagging;
unit 12 {
vlan-id 12;
family inet {
address 192.168.12.2/24;
}
}
unit 23 {
vlan-id 23;
family inet {
address 192.168.23.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 2.2.2.2/32;
}
}
}
}
routing-options {
router-id 2.2.2.2;
}
protocols {
ospf {
area 0.0.0.12 {
interface fe-0/0/1.12 {
interface-type p2p;
}
}
area 0.0.0.23 {
interface fe-0/0/1.23 {
interface-type p2p;
}
}
}
}
R3:
interfaces {
fe-0/0/1 {
vlan-tagging;
unit 23 {
vlan-id 23;
family inet {
address 192.168.23.3/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 3.3.3.3/32;
}
}
}
}
routing-options {
router-id 3.3.3.3;
}
protocols {
ospf {
area 0.0.0.23 {
interface fe-0/0/1.23 {
interface-type p2p;
}
interface lo0.0 {
passive;
}
}
}
}
Let’s start the verification by looking for OSPF routes on R1.
R1:
ipexpert@R1> show route protocol ospf inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) @ = Routing Use Only, # = Forwarding Use Only + = Active Route, - = Last Active, * = Both 3.3.3.3/32 *[OSPF/10] 01:18:39, metric 2 > to 192.168.12.2 via fe-0/0/1.12 192.168.23.0/24 *[OSPF/10] 01:26:19, metric 2 > to 192.168.12.2 via fe-0/0/1.12 224.0.0.5/32 *[OSPF/10] 01:26:43, metric 1 MultiRecv
That came almost unexpected. All the routes are there. I can see both R3′s link to R2 and the loopback interface. I can even ping…
R1:
ipexpert@R1> ping rapid 3.3.3.3
PING 3.3.3.3 (3.3.3.3): 56 data bytes
!!!!!
--- 3.3.3.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.509/1.999/2.544/0.349 ms
It looks like R2 is performing ABR duties even without having any interfaces in the backbone area. Let’s confirm that by looking into the OSPF database.
Unlike IOS, Junos is a little bit more cryptic about ABR status by virtue of not converting bit values into mnemonics. We’ll have to decipher VEB bit-field manually. The bit we’re after, the B-bit has bit-value of 1. Let’s take a look.
R2:
ipexpert@R2> show ospf database router advertising-router self area 12 detail OSPF database, Area 0.0.0.12 Type ID Adv Rtr Seq Age Opt Cksum Len Router *2.2.2.2 2.2.2.2 0x80000005 1145 0x22 0x50cc 48 bits 0x1, link count 2 id 1.1.1.1, data 192.168.12.2, Type PointToPoint (1) Topology count: 0, Default metric: 1 id 192.168.12.0, data 255.255.255.0, Type Stub (3) Topology count: 0, Default metric: 1 Topology default (ID 0) Type: PointToPoint, Node ID: 1.1.1.1 Metric: 1, Bidirectional
Indeed, bit-field shows value 0×01, which translates into B-bit being set. R2 is an ABR! Therefore, in Junos there is no need for a router to be connected to the backbone area to perform ABR duties (generate Type 3 summary LSAs between areas).
This is still a broken configuration. It only has an appearance of being fully operational, but adding a single interface in area 0 on either R1 or R3 would render those networks unreachable beyond quasi-ABR R2. I will leave this for another time though…
No comments:
Post a Comment