Loaded up your PT file. What exactly is not working?
Like @Kasun Bandara noted, you have multiple interfaces not included/advertised in OSPF (the five subinterfaces on g0/0/0).
@Flavio Miranda then suggested using the OSPF section command
redistribute connect subnets
, which will, indeed, get connected interfaces placed into OSPF. However, they will be injected as externals, which, unless that's what you really want them to be, I would advise against doing.
M02@rt37 then follows up on using
redistribute connect subnets
while also changing OSPF network statements masks on Router C, which aren't necessary, although your OSPF network statements, on your routers (plural), I suspect, shows a misunderstanding exactly how the OSPF network statement works.
An OSPF network statement works much like an ACL ACE matching an interface IP. It has NOTHING to do with what subnet will be advertised.
For example, Router C has 3 interfaces:
interface GigabitEthernet0/0/0
ip address 10.0.1.1 255.255.255.0
interface Serial0/1/0
ip address 10.0.0.2 255.255.255.252
interface Serial0/1/1
ip address 10.0.0.5 255.255.255.252
If I wanted all of those interfaces, in the same area, I could use just this one OSPF network statement:
network 0.0.0.0 255.255.255.255 area 0
Or since all 3 interfaces are in the 10.0.0.0 /23 block, you could also use just this one OSPF network statement:
network 10.0.0.0 0.0.1.255 area 0
If I wanted to make sure I only selected those particular 3 interfaces, I might use the following 3 network statements:
network 10.0.0.2 0.0.0.0 area 0
network 10.0.0.5 0.0.0.0 area 0
network 10.0.1.1 0.0.0.0 area 0
or, BTW, in later IOS OSPF versions, rather than using OSPF section network statements, you can instead do:
interface GigabitEthernet0/0/0
ip address 10.0.1.1 255.255.255.0
ip ospf 1 area 0
interface Serial0/1/0
ip address 10.0.0.2 255.255.255.252
ip ospf 1 area 0
interface Serial0/1/1
ip address 10.0.0.5 255.255.255.252
ip ospf 1 area 0
Since OSPF network statement work like ACL ACEs, sequence and mask used can be important.
For example, all our /23 networks should be in
area 0
but for the interface with address 10.0.0.5 should be in
area 1
, we might do:
network 10.0.0.5 0.0.0.0 area 1
network 10.0.0.0 0.0.1.255 area 0
But, understand, there are other ways to accomplish the above.
Again, what's important to understand, OSPF network statements work like ACL ACEs matching interface IP addresses. When they find a match, the interface's subnet is determined by the interface's address mask, NOT the OSFP network statement's mask.
BTW, with your original OSPF Router C network statements:
network 10.0.0.0 0.0.0.255 area 0
network 10.0.0.0 0.0.0.3 area 0
network 10.0.1.0 0.0.0.255 area 0
Your first and second network statements overlap, which makes the second statement, redundant, but as such, it's not causing any OSPF issue, although it can make one wonder why it's there. Just as using a /24 mask for the two /252 networks does. I.e. following the scheme you seem to be using, using OSPF network masks to (needlessly) match the interface's mask, I would expect what M02@rt37 suggested:
network 10.0.0.0 0.0.0.3 area 0
network 10.0.0.4 0.0.0.3 area 0
network 10.0.1.0 0.0.0.255 area 0
But, I would recommend against this scheme. In my experience, it's too easy to get it wrong. I suggest you either match individual interface IPs (as shown) above, or you match IP address blocks intended to be in specific OSPF areas, also shown above. You can mix and match, for special needs, as also shown above. Personally, my OSPG network statement goals include brevity and clarity for what's intended.
As an example, in one large Enterprise I worked at, each 10.0.0.0/16 was related to the same numbered OSPF area. So, every area 4 router had:
network 10.4.0.0 0.0.255.255 area 4
. (With a /16 per area, we didn't expect to run out of IPs within the area, and with 256 /16s, we didn't expected to run out of /16s either. This also lent itself to summarize an area's IPs, to the core, as just the single /16 address block.)
I strongly suggest, you try some experimentation, with the above, in your PT lab. For example, you might first try replacing each router's OSPF network statements with just network 0.0.0.0
255.255.255.255 area 0
; also remove the
redistribute
connect subnets.
Lastly, another useful show command is (e.g. from Router A):
Router>show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Gig 1 0.0.0.0 10.0.10.1/255.255.255.0 1 DR 0/0
Gig 1 0.0.0.0 10.0.20.1/255.255.255.0 1 DR 0/0
Gig 1 0.0.0.0 10.0.30.1/255.255.255.0 1 DR 0/0
Gig 1 0.0.0.0 10.0.40.1/255.255.255.0 1 DR 0/0
Gig 1 0.0.0.0 10.0.50.1/255.255.255.0 1 DR 0/0
Se0/1/1 1 0.0.0.0 10.0.0.10/255.255.255.252 64 POINT 0/0
Se0/1/0 1 0.0.0.0 10.0.0.1/255.255.255.252 64 POINT 0/0
I got the above result after adding (on Router A):
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 10.0.0.0 0.0.0.255 area 0
network 10.0.0.0 0.0.0.3 area 0
network 10.0.1.0 0.0.0.255 area 0
network 0.0.0.0 255.255.255.255 area 0
The newly added network statement, besides adding the five previously subinterfaces, makes the other network statements redundant (needless) and doesn't required
redistribution
of connected interfaces.
