What happens if you connect two OSPF areas together when neither of them is area 0?
Will routes be shared between the two areas, or will it simply not work?
I can think of two scenarios for this:
- Two or more non-backbone areas connected together – area 1 to area 2 to area 3.
- Two areas with both a connection to each other and a connection to the backbone – area 1 to area 0 to area 2 back to area 1.
In this post, we’re going to lab the first scenario out and see what happens. We’ll look at both Junos and IOS-XE.
Part 2 looks at the second scenario.
Before you read on, I want you to think about the following questions:
- If two non-backbone OSPF areas are connected together, will they share routes?
- What if three non-backbone areas are connected together?
- Will this behavior differ between Junos and IOS-XE?
The Juniper Lab
The lab is going to be set up as per the following diagram. We’ll start with just area 1 and area 2. Area 3 will be added a little later.
- A mix of device types is used to add a little variety
- R4, R5, and R3 will be in area 2. Their loopback interfaces will be in this area too.
- R1 and R2 will be in areas 1 and 3 respectively.
- We’re using plain areas, no stub or NSSA area types.
Area 1 and 2 Configuration
Let’s start by configuring area 2 first.
R3
The OSPF stanza for R3 is configured as follows:
protocols {
ospf {
area 0.0.0.2 {
interface lo0.0 {
passive;
}
interface ge-0/0/1.0;
}
reference-bandwidth 100g;
}
}R5
R5 is configured similarly:
protocols {
ospf {
area 0.0.0.2 {
interface lo0.0 {
passive;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
reference-bandwidth 100g;
}
}R4
For now, we’ll just configure the area 2 interface for R4.
protocols {
ospf {
area 0.0.0.2 {
interface lo0.0 {
passive;
}
interface ge-0/0/0.0;
}
reference-bandwidth 100g;
}
} Verification of Area 2
Now that we’ve configured the routers in area 2, let’s just validate a few things. From R5 we check the routing table to ensure we have the loopbacks of R4 and R3, and check the OSPF database.
lab@vmx-R5> show route protocol ospf
inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.3/32 *[OSPF/10] 00:07:39, metric 100
> to 10.100.4.1 via ge-0/0/1.0
172.16.0.4/32 *[OSPF/10] 00:02:02, metric 100
> to 10.100.5.1 via ge-0/0/0.0
224.0.0.5/32 *[OSPF/10] 00:07:49, metric 1
MultiRecv
inet6.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
lab@vmx-R5> show ospf database
OSPF database, Area 0.0.0.2
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 172.16.0.3 172.16.0.3 0x80000004 468 0x22 0x1ef 48
Router 172.16.0.4 172.16.0.4 0x80000004 129 0x22 0x771a 48
Router *172.16.0.5 172.16.0.5 0x80000004 133 0x22 0xc66b 60
Network 10.100.4.1 172.16.0.3 0x80000001 473 0x22 0x572e 32
Network 10.100.5.1 172.16.0.4 0x80000001 133 0x22 0x5032 32
lab@vmx-R5>Everything looks as we would expect it to at this stage. The OSPF database shows three router LSAs and two Network LSAs for the link nets between the routers.
Adding Area 1
Now we can add area 1. We’ll start by configuring R1, and then updating the configuration for R4.
R1
protocols {
ospf {
area 0.0.0.1 {
interface lo0.0 {
passive;
}
interface ge-0/0/1.0;
}
reference-bandwidth 100g;
}
}R4
R4 is now updated to add area 1.
protocols {
router-advertisement {
interface fxp0.0;
}
ospf {
area 0.0.0.2 {
interface lo0.0 {
passive;
}
interface ge-0/0/0.0;
}
area 0.0.0.1 {
interface ge-0/0/1.0;
}
reference-bandwidth 100g;
}
}Verification of Area 1 and Area 2
We’ve now connected areas 1 and 2 together using R4. Let’s see how things look from R5.
lab@vmx-R5> show route protocol ospf
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.100.3.0/24 *[OSPF/10] 00:02:38, metric 200
> to 10.100.5.1 via ge-0/0/0.0
172.16.0.1/32 *[OSPF/10] 00:02:37, metric 200
> to 10.100.5.1 via ge-0/0/0.0
172.16.0.3/32 *[OSPF/10] 00:13:52, metric 100
> to 10.100.4.1 via ge-0/0/1.0
172.16.0.4/32 *[OSPF/10] 00:08:15, metric 100
> to 10.100.5.1 via ge-0/0/0.0
224.0.0.5/32 *[OSPF/10] 00:14:02, metric 1
MultiRecv
inet6.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
lab@vmx-R5> show ospf database
OSPF database, Area 0.0.0.2
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 172.16.0.3 172.16.0.3 0x80000004 854 0x22 0x1ef 48
Router 172.16.0.4 172.16.0.4 0x80000005 182 0x22 0x7817 48
Router *172.16.0.5 172.16.0.5 0x80000004 519 0x22 0xc66b 60
Network 10.100.4.1 172.16.0.3 0x80000001 859 0x22 0x572e 32
Network 10.100.5.1 172.16.0.4 0x80000001 519 0x22 0x5032 32
Summary 10.100.3.0 172.16.0.4 0x80000004 177 0x22 0x6c37 28
Summary 172.16.0.1 172.16.0.4 0x80000001 175 0x22 0x3b1f 28
lab@vmx-R5> ping 172.16.0.1 source 172.16.0.5 count 2
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: icmp_seq=0 ttl=63 time=55.517 ms
64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=5.736 ms
--- 172.16.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.736/30.627/55.517/24.890 ms
lab@vmx-R5>That is interesting. It appears that R4 is acting like a normal ABR and in area 2 we have a type 3 summaries for the area 1 LSAs. We can happily ping between loopbacks from R5 to R1.
On R1, we see similar results. There are routes for area 2 present in the routing table, and the OSPF database shows several summaries advertised by R4 into area 1.
lab@vsrx-R1> show route protocol ospf
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.100.4.0/24 *[OSPF/10] 00:06:17, metric 210
> to 10.100.3.2 via ge-0/0/1.0
10.100.5.0/24 *[OSPF/10] 00:06:17, metric 110
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.3/32 *[OSPF/10] 00:06:17, metric 210
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.4/32 *[OSPF/10] 00:06:17, metric 10
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.5/32 *[OSPF/10] 00:06:17, metric 110
> to 10.100.3.2 via ge-0/0/1.0
224.0.0.5/32 *[OSPF/10] 00:07:31, metric 1
MultiRecv
inet6.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
lab@vsrx-R1> show ospf database
OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *172.16.0.1 172.16.0.1 0x80000004 382 0x22 0xde1a 48
Router 172.16.0.4 172.16.0.4 0x80000003 387 0x22 0x84e0 36
Network *10.100.3.1 172.16.0.1 0x80000001 386 0x22 0x4c3f 32
Summary 10.100.4.0 172.16.0.4 0x80000003 381 0x22 0x4fef 28
Summary 10.100.5.0 172.16.0.4 0x80000003 381 0x22 0x584a 28
Summary 172.16.0.3 172.16.0.4 0x80000001 388 0x22 0x13e0 28
Summary 172.16.0.4 172.16.0.4 0x80000001 388 0x22 0x318a 28
Summary 172.16.0.5 172.16.0.4 0x80000001 388 0x22 0x1343 28
lab@vsrx-R1>This shows, on Junos at least, that connecting two OSPF areas together without using area 0 can work. I wouldn’t recommend this approach, but it does seem to work.
Time to add area 3 and see what happens.
Adding Area 3
R3
On R3 we update the OSPF configuration to the following:
protocols {
ospf {
area 0.0.0.2 {
interface lo0.0 {
passive;
}
interface ge-0/0/1.0;
}
area 0.0.0.3 {
interface ge-0/0/0.0;
}
reference-bandwidth 100g;
}
}R2
The R2 OSPF configuration looks as follows:
protocols {
ospf {
area 0.0.0.3 {
interface lo0.0 {
passive;
}
interface xe-0/0/1.0;
}
reference-bandwidth 100g;
}
igmp-snooping {
vlan default;
}
}Verification Of Three Areas With No Backbone
First, let’s check R5 and see how the route table and OSPF database look.
lab@vmx-R5> show route protocol ospf
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.100.2.0/24 *[OSPF/10] 00:03:22, metric 110
> to 10.100.4.1 via ge-0/0/1.0
10.100.3.0/24 *[OSPF/10] 00:21:31, metric 200
> to 10.100.5.1 via ge-0/0/0.0
172.16.0.1/32 *[OSPF/10] 00:21:30, metric 200
> to 10.100.5.1 via ge-0/0/0.0
172.16.0.2/32 *[OSPF/10] 00:02:34, metric 110
> to 10.100.4.1 via ge-0/0/1.0
172.16.0.3/32 *[OSPF/10] 00:32:45, metric 100
> to 10.100.4.1 via ge-0/0/1.0
172.16.0.4/32 *[OSPF/10] 00:27:08, metric 100
> to 10.100.5.1 via ge-0/0/0.0
224.0.0.5/32 *[OSPF/10] 00:32:55, metric 1
MultiRecv
inet6.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
lab@vmx-R5> show ospf database
OSPF database, Area 0.0.0.2
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 172.16.0.3 172.16.0.3 0x80000005 207 0x22 0x2ec 48
Router 172.16.0.4 172.16.0.4 0x80000006 616 0x22 0x7618 48
Router *172.16.0.5 172.16.0.5 0x80000004 1639 0x22 0xc66b 60
Network 10.100.4.1 172.16.0.3 0x80000001 1979 0x22 0x572e 32
Network 10.100.5.1 172.16.0.4 0x80000002 907 0x22 0x4e33 32
Summary 10.100.2.0 172.16.0.3 0x80000003 165 0x22 0xf709 28
Summary 10.100.3.0 172.16.0.4 0x80000004 1297 0x22 0x6c37 28
Summary 172.16.0.1 172.16.0.4 0x80000001 1295 0x22 0x3b1f 28
Summary 172.16.0.2 172.16.0.3 0x80000001 159 0x22 0xaf05 28
lab@vmx-R5> ping 172.16.0.2 source 172.16.0.5 count 2
PING 172.16.0.2 (172.16.0.2): 56 data bytes
64 bytes from 172.16.0.2: icmp_seq=0 ttl=63 time=164.093 ms
64 bytes from 172.16.0.2: icmp_seq=1 ttl=63 time=540.605 ms
--- 172.16.0.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 164.093/352.349/540.605/188.256 ms
lab@vmx-R5>Once again, R5 has connectivity to another area without using a backbone area. This isn’t surprising as it is the same as the behavior when we connected in area 1.
What about R2, what does it see?
{master:0}
lab@vqfx-R2> show route protocol ospf
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.100.4.0/24 *[OSPF/10] 00:04:34, metric 20
> to 10.100.2.2 via xe-0/0/1.0
10.100.5.0/24 *[OSPF/10] 00:04:34, metric 120
> to 10.100.2.2 via xe-0/0/1.0
172.16.0.3/32 *[OSPF/10] 00:04:34, metric 10
> to 10.100.2.2 via xe-0/0/1.0
172.16.0.4/32 *[OSPF/10] 00:04:34, metric 120
> to 10.100.2.2 via xe-0/0/1.0
172.16.0.5/32 *[OSPF/10] 00:04:34, metric 20
> to 10.100.2.2 via xe-0/0/1.0
224.0.0.5/32 *[OSPF/10] 00:04:44, metric 1
MultiRecv
inet6.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
{master:0}
lab@vqfx-R2> show ospf database
OSPF database, Area 0.0.0.3
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *172.16.0.2 172.16.0.2 0x80000002 289 0x22 0x7f1 48
Router 172.16.0.3 172.16.0.3 0x80000004 294 0x22 0x2c95 36
Network 10.100.2.2 172.16.0.3 0x80000001 294 0x22 0x3950 32
Summary 10.100.4.0 172.16.0.3 0x80000004 288 0x22 0xdf1e 28
Summary 10.100.5.0 172.16.0.3 0x80000004 288 0x22 0xc0d7 28
Summary 172.16.0.3 172.16.0.3 0x80000001 335 0x22 0x417c 28
Summary 172.16.0.4 172.16.0.3 0x80000001 335 0x22 0x87c6 28
Summary 172.16.0.5 172.16.0.3 0x80000001 335 0x22 0x9120 28
{master:0}
lab@vqfx-R2>This is where we start to see a difference in behavior. The routes and LSAs for area 1 are not present. So Area 2 is not exactly acting as a backbone area.
It seems that for Junos connecting two non-zero areas works, but when using three or more areas the summaries are not crossing the area boundaries.
IOS-XE Lab
The lab is going to be set up similar to the Juniper lab. We’ll start with just area 1 and area 2.
- All routers are CSR1000v running IOS-XE 16.06.06
- R4, R5, and R3 will be in area 2. Their loopback interfaces will be in this area too.
- R1 and R2 will be in areas 1 and 3 respectively.
- We’re using plain areas, no stub or NSSA area types.
Area 1 and 2 Configuration
Let’s start by configuring area 2 first.
R3
interface Loopback0
ip address 172.16.0.3 255.255.255.255
!
interface GigabitEthernet2
ip address 10.100.4.1 255.255.255.0
negotiation auto
no mop enabled
no mop sysid
!
interface GigabitEthernet3
ip address 10.100.2.2 255.255.255.0
negotiation auto
no mop enabled
no mop sysid
!
router ospf 1
network 10.100.4.0 0.0.0.255 area 2
network 172.16.0.3 0.0.0.0 area 2R4
interface Loopback0
ip address 172.16.0.4 255.255.255.255
!
interface GigabitEthernet3
ip address 10.100.3.2 255.255.255.0
negotiation auto
no mop enabled
no mop sysid
!
interface GigabitEthernet4
ip address 10.100.5.1 255.255.255.0
shutdown
negotiation auto
no mop enabled
no mop sysid
!
router ospf 1
network 10.100.5.0 0.0.0.255 area 2
network 172.16.0.4 0.0.0.0 area 2R5
interface Loopback0
ip address 172.16.0.5 255.255.255.255
!
interface GigabitEthernet2
ip address 10.100.4.2 255.255.255.0
negotiation auto
no mop enabled
no mop sysid
!
interface GigabitEthernet4
ip address 10.100.5.2 255.255.255.0
shutdown
negotiation auto
no mop enabled
no mop sysid
!
router ospf 1
network 10.100.4.0 0.0.0.255 area 2
network 10.100.5.0 0.0.0.255 area 2
network 172.16.0.5 0.0.0.0 area 2Verification Of Area 2
Now that we’ve set up area 2, let’s quickly validate it looks OK.
CSR-R5#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
172.16.0.0/32 is subnetted, 3 subnets
O 172.16.0.3 [110/2] via 10.100.4.1, 00:08:29, GigabitEthernet2
O 172.16.0.4 [110/2] via 10.100.5.1, 00:08:24, GigabitEthernet4
CSR-R5#show ip ospf database
OSPF Router with ID (172.16.0.5) (Process ID 1)
Router Link States (Area 2)
Link ID ADV Router Age Seq# Checksum Link count
172.16.0.3 172.16.0.3 513 0x80000004 0x0046B2 2
172.16.0.4 172.16.0.4 508 0x80000004 0x006E85 2
172.16.0.5 172.16.0.5 503 0x80000005 0x00DF17 3
Net Link States (Area 2)
Link ID ADV Router Age Seq# Checksum
10.100.4.1 172.16.0.3 513 0x80000001 0x00572E
10.100.5.1 172.16.0.4 508 0x80000001 0x005032
CSR-R5#From R5 we can see two OSPF routes for the loopbacks of R3 and R5. We can also see three router LSAs and two network LSAs. This all looks good so we can continue setting up area 1.
Adding Area 1
We will configure R1 and modify R4.
R1
interface Loopback0
ip address 172.16.0.1 255.255.255.255
!
interface GigabitEthernet3
ip address 10.100.3.1 255.255.255.0
negotiation auto
no mop enabled
no mop sysid
!
router ospf 1
network 10.100.3.0 0.0.0.255 area 1
network 172.16.0.1 0.0.0.0 area 1R4
router ospf 1
network 10.100.3.0 0.0.0.255 area 1
network 10.100.5.0 0.0.0.255 area 2
network 172.16.0.4 0.0.0.0 area 2Verification Of Area 1 and Area 2
Time to see what has happened now we’ve added Area 1. Let’s start by looking at R5 again.
CSR-R5#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
172.16.0.0/32 is subnetted, 3 subnets
O 172.16.0.3 [110/2] via 10.100.4.1, 00:14:30, GigabitEthernet2
O 172.16.0.4 [110/2] via 10.100.5.1, 00:14:25, GigabitEthernet4
CSR-R5#show ip ospf database
OSPF Router with ID (172.16.0.5) (Process ID 1)
Router Link States (Area 2)
Link ID ADV Router Age Seq# Checksum Link count
172.16.0.3 172.16.0.3 873 0x80000004 0x0046B2 2
172.16.0.4 172.16.0.4 868 0x80000004 0x006E85 2
172.16.0.5 172.16.0.5 864 0x80000005 0x00DF17 3
Net Link States (Area 2)
Link ID ADV Router Age Seq# Checksum
10.100.4.1 172.16.0.3 873 0x80000001 0x00572E
10.100.5.1 172.16.0.4 868 0x80000001 0x005032
CSR-R5#ping 172.16.0.1 source 172.16.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.0.5
.....
Success rate is 0 percent (0/5)
CSR-R5#This looks the same. Not surprisingly R5 cannot ping R1’s loopback address.
Time to look at R1.
CSR-R1#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
CSR-R1#show ip ospf database
OSPF Router with ID (172.16.0.1) (Process ID 1)
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
172.16.0.1 172.16.0.1 258 0x80000005 0x0038C6 2
172.16.0.4 172.16.0.4 253 0x80000003 0x008E3A 1
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.100.3.2 172.16.0.4 266 0x80000001 0x002463
CSR-R1#R1 has only information from area 1. Note that because the loopback of R4 is in area 2, not area 1, R1 does not have information for that route.
Finally, let’s look at R4.
CSR-R4#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
O 10.100.4.0/24 [110/2] via 10.100.5.2, 00:19:10, GigabitEthernet4
172.16.0.0/32 is subnetted, 4 subnets
O 172.16.0.1 [110/2] via 10.100.3.1, 00:06:40, GigabitEthernet3
O 172.16.0.3 [110/3] via 10.100.5.2, 00:19:10, GigabitEthernet4
O 172.16.0.5 [110/2] via 10.100.5.2, 00:19:10, GigabitEthernet4
CSR-R4#show ip ospf database
OSPF Router with ID (172.16.0.4) (Process ID 1)
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
172.16.0.1 172.16.0.1 406 0x80000005 0x0038C6 2
172.16.0.4 172.16.0.4 399 0x80000003 0x008E3A 1
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.100.3.2 172.16.0.4 412 0x80000001 0x002463
Router Link States (Area 2)
Link ID ADV Router Age Seq# Checksum Link count
172.16.0.3 172.16.0.3 1169 0x80000004 0x0046B2 2
172.16.0.4 172.16.0.4 1162 0x80000004 0x006E85 2
172.16.0.5 172.16.0.5 1160 0x80000005 0x00DF17 3
Net Link States (Area 2)
Link ID ADV Router Age Seq# Checksum
10.100.4.1 172.16.0.3 1169 0x80000001 0x00572E
10.100.5.1 172.16.0.4 1163 0x80000001 0x005032
CSR-R4#
CSR-R4#ping 172.16.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
CSR-R4#ping 172.16.0.1 source 172.16.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.0.4
.....
Success rate is 0 percent (0/5)
CSR-R4#Because R4 is connected to both area 1 and area 2 it sees information from both areas. Unlike the Junos example, R4 is not advertising summaries from one area to another.
R4 can ping R1’s loopback address when we don’t specify a source address. This causes R4 to source the traffic from the outgoing interface, which R1 knows how to reach. If we make the source of the traffic R4’s loopback address, then the ping fails. This is due to R1 not having a route back to R4’s loopback.
Since R4 in this case is not advertising summaries between areas, there is no need to add area 3 to this lab. R3 will behave the same as R4.
Conclusions
I want you to think again about the questions I asked at the start of this post:
- If two non-backbone OSPF areas are connected together, will they share routes?
- What if three non-backbone areas are connected together?
- Will this behavior differ between Junos and IOS-XE?
Junos and IOS-XE differ in their behavior. Junos will share routes between non-zero areas and IOS-XE won’t.
But what else can we take away from this information?
What we now know is that two reasonable people can have opposite answers to this question and both be right, depending on which vendor they are familiar with. If you only work with one vendor, it is easy to assume that equipment or software from other vendors will work the same because a standard is a standard, isn’t it?
It also has implications for how we study and learn. When studying a new topic we often try to configure things the “right way”, as the book or example shows us. I think this post shows the importance of trying something out the “wrong way” and seeing what happens. I hope you’ll keep this in mind next time you try something out in your own lab.
And finally, I should add that I don’t recommend configuring multiple OSPF areas without an area 0 backbone. It may work and do what you need, but it adds a complication that most Ops staff won’t thank you for.
The next logical question is what if I directly connect two areas that already have a connection to a backbone area? We’ll look at that in part 2.