CCNP ROute - OSPF Area Mismatch alarms

Hi Everybody,
I have gone over my steps several times and keep getting the same error. I am missing something. Is there always an area mismatch alarm between areas on OSPF? I cant seem to stop getting an error mismatch on area 1, connecting to area 0. Any troubleshooting suggestions? Im starring at my Odom books and feel like the configs are correct.

Any ideas?

Thanks!

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

networker050184

No there shouldn't be alarms. How are you connecting it? Different areas on each side of a link (the wrong way) or a router with an interface in each area (the right way)?

Node Man

Here are the running-configs:
1.1.1.1#show run
Building configuration...

Current configuration : 861 bytes
!
version 12.4
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname 1.1.1.1
!
!
!
!
!
!
no ip cef
no ipv6 cef
!
!
!
!
!
!
!
!
!
!
!
!
spanning-tree mode pvst
!
!
!
!
!
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
shutdown
!
interface Serial0/0/0
ip address 10.1.12.1 255.255.255.252
clock rate 2000000
!
interface Serial0/0/1
ip address 10.1.36.1 255.255.255.252
clock rate 2000000
!
interface Vlan1
no ip address
shutdown
!
router ospf 1
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 1
!
ip classless
!
ip flow-export version 9
!
!
!
!
!
!
!
line con 0
!
line aux 0
!
line vty 0 4
login
!
!
!
end

1.1.1.1#
01:51:09: %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must be virtual-link but not found from 10.1.12.1, Serial0/0/0

2.2.2.2#show run

Building configuration...

Current configuration : 949 bytes
!
version 12.4
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname 2.2.2.2
!
!
!
!
!
!
no ip cef
no ipv6 cef
!
!
!
!
!
!
!
!
!
!
no ip domain-lookup
!
!
spanning-tree mode pvst
!
!
!
!
!
!
interface Loopback1
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip address 10.1.2.2 255.255.255.128
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
shutdown
!
interface Serial0/0/0
ip address 10.1.12.2 255.255.255.252
clock rate 2000000
!
interface Serial0/0/1
ip address 10.1.23.2 255.255.255.252
clock rate 2000000
!
interface Vlan1
no ip address
shutdown
!
router ospf 2
log-adjacency-changes
network 10.1.12.0 0.0.0.0 area 1
network 10.1.12.2 0.0.0.0 area 1
network 10.1.0.0 0.0.255.255 area 0
!
ip classless
!
ip flow-export version 9
!
!
!
!
!
!
!
line con 0
!
line aux 0
!
line vty 0 4
login
!
!
!
end

Heero

Both of those configs are for the same device.

You almost certainly have a config issue, so please post the config from the other device.

networker050184

Really not understanding what you are trying to do here since it's the same show run twice.

Regardless as I said, you connect areas by having a router with two interfaces in different areas, not by putting a different area on opposite sides of a link.

Node Man

whoops cut and paste abuse. I corrected the configs in the post

Heero

I'm assuming the area mismatch is on s0/0/0 (10.1.12.0/30)? Do a "show ip ospf interface s0/0/0" and see which area the interface is operating on for each side. I'm thinking that router 2.2.2.2 had serial/0/0 in area 0 and then afterwards you added "network 10.1.12.2 0.0.0.0 area 1" afterwards. It might be a simple case of reloading the OSPF process.

networker050184

I was thinking the same as Heero.

theodoxa

Does s0/0/0 on 2.2.2.2 go to 1.1.1.1?

Node Man

Thanks for the advice guys. I redid the topology with subnets that don't overlap and the trouble resolved. I think the issue was overlapping wilcards in 2.2.2.2

_Gonzalo_

Node Man wrote: »

I cant seem to stop getting an error mismatch on area 1, connecting to area 0. Any troubleshooting suggestions?

That´s the error. One link belogs to one area, on both sides. You cannot connect two routers defining the network between them in two different areas.

I suppose that overlapping (or any incorrect IP addressing) could cause you to advertise a network in some area that you do not want it to be, but the root problem is the one I stated. In any case, there is no "overlapping wildcards". I´ll give you an example:

R1 connects to R2 through link g0/1 through 10.0.12.0/24
R1 has a LAN connected to it with 10.0.1.0/24
R2 has a LAN connected to it with 10.0.2.0/24

If I wanted all of my network to belong to area 0, I could go with: network 10.0.0.0 0.255.255.255 area 0 on both routers and have all my networks assigned to area 0.

You can advertise any range in a router (ie: network 0.0.0.0 255.255.255.255 area 0) but at the end of the day, router will only advertise whatever it has connected to it and belongs to the range you defined.

Never know if I´m helping or confusing things further...

OfWolfAndMan

For future reference, when t-shooting OSPF, here are the general parameters you want to go over to make both sides of a link establish neighbors:

-Are the IP addresses on each side of the link on the same subnet?
-Are the areas identical?
-Is the stub area flag ID identical (Stub, total stub, nssa, total nssa)
-Hello and Dead timers
-Identical authentication when it is enabled.

_Gonzalo_

OfWolfAndMan wrote: »

For future reference, when t-shooting OSPF, here are the general parameters you want to go over to make both sides of a link establish neighbors:

-Are the IP addresses on each side of the link on the same subnet?
-Are the areas identical?
-Is the stub area flag ID identical (Stub, total stub, nssa, total nssa)
-Hello and Dead timers
-Identical authentication when it is enabled.

Good OSPF adjacency summary!

Just one thing... Maybe I´m not remembering it right, but those matching flags are limited to stub and nssa, as the "totally" part is only configured in ABRs.