02-22-2014 04:27 AM - edited 03-04-2019 10:24 PM
Hi all,
I have the following topology
R1 -> RID 1.1.1.1
R2 -> RID 2.2.2.2
R1 has a static route towards 192.168.1.0/24
R2 has a static route towards 192.168.1.0/24
R1 and R2 belong to the same ospf area and same ospf process.
R1 and R2 redistribuite the static route
Partial configuration of R1 is
router ospf 200
router-id 1.1.1.1
auto-cost reference-bandwidth 100000
capability vrf-lite
area 0 authentication message-digest
redistribute static subnets
network 3.3.3.0 0.0.0.3 area 0
Partila configuration of R2
router ospf 200
router-id 2.2.2.2
log-adjacency-changes detail
auto-cost reference-bandwidth 100000
capability vrf-lite
area 0 authentication message-digest
redistribute static metric 100 subnets
network 3.3.3.0 0.0.0.3 area 0
Problem: R1 is not advertising the LSA 5 for the 192.168.1.0.
Here the output of R1
R1#show ip ospf 200 database external 192.168.1.0
OSPF Router with ID (1.1.1.1) (Process ID 200)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 763
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 192.168.1.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000B6B
Checksum: 0x398
Length: 36
Network Mask: /21
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 100
Forward Address: 0.0.0.0
External Route Tag: 0
R1#show ip ospf 200 database self-originate | i 192.168.1.0
Here the output of R2
R1#show ip ospf 200 database self-originate | i 192.168.1.0
192.168.1.0 2.2.2.2 995 0x80000B6B 0x000398 0
R2#show ip ospf 200 database external 192.168.1.0
OSPF Router with ID (2.2.2.2) (Process ID 200)
Type-5 AS External Link States
LS age: 816
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 192.168.1.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000B6B
Checksum: 0x398
Length: 36
Network Mask: /21
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 100
Forward Address: 0.0.0.0
External Route Tag: 0
What am I missing?
Thanks all guys!!
02-22-2014 04:41 AM
Fabio,
Is this your real network and real command outputs? According to what you have posted, the network R2 advertises is 192.168.1.0/21 - the netmask does not make sense.
If these outputs have been changed and your real network uses different addressing, is it possible that both LSA-5 regarding "192.168.1.0/24" are using the same non-zero forward address field? That would explain the behavior but first we need to clarify the discrepancies in your outputs.
Best regards,
Peter
02-22-2014 05:36 AM
Hi Peter,
Thanks for your reply.
This is the real output.
02-22-2014 06:18 AM
Hi Fabio,
This is the real output.
This is strange. Why, then, is the 2.2.2.2 advertising the redistributed network with a netmask of /21 instead of /24?
Please post the following complete output from both your routers:
Thank you!
Best regards,
Peter
02-22-2014 08:11 AM
Hi Peter,
Many thanks for your support.
One corrections. The subnet is /27 and not /24 but nothing will change with regards to the issue.
I can not post here the whole routing table but I think the info that I am going to provide below are valid as well. Please be aware that there is no redistribution of BGP into OSPF (Here seems that the router R2 is redistribuiting into ospf the 192.168.1.0/21 but as you can see from my configuiration only static route can be resitribuited into ospf. From where is coming this network /21???? )
R2#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Vl8 100 0 3.3.3.2/29 1 P2P 1/1
R2#show ip ospf 200 database self-originate | i 192.168.1.0
192.168.1.0 2.2.2.2 995 0x80000B6B 0x000398 0
R1#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Vl8 100 0 3.3.3.3/29 1 P2P 1/1
R1#show ip ospf 200 database self-originate | i 192.168.1.0
R1#show ip route 192.168.1.0
Routing entry for 192.168.1.0/24, 4 known subnets
Attached (2 connections)
Variably subnetted with 3 masks
O 192.168.1.168/30
[110/160] via 172.18.144.89, 7w0d, GigabitEthernet1/1.101
S 192.168.1.0/27 [1/0] via 192.168.1.73
C 192.168.1.72/29 is directly connected, GigabitEthernet1/16.362
C 192.168.1.108/30 is directly connected, Vlan622
R2#show ip route 192.168.1.0
Routing entry for 192.168.1.0/24, 4 known subnets
Attached (2 connections)
Variably subnetted with 3 masks
O 192.168.1.168/30
[110/160] via 172.18.144.93, 7w0d, GigabitEthernet1/1.101
S 192.168.1.0/27 [1/0] via 192.168.1.73
C 192.168.1.72/29 is directly connected, GigabitEthernet1/16.362
C 192.168.1.108/30 is directly connected, Vlan622
02-22-2014 09:24 AM
Fabio,
Can you perhaps post the output of
show ip route 192.168.0.0 255.255.0.0 longer-prefix
from R2 please?
Best regards,
Peter
02-23-2014 12:34 AM
Hi Peter,
You got it!! Thanks. I won´t post all the output here, but I found the on R2 there are two static route
R2#show ip route 192.168.1.0 255.255.0.0 longer-prefix
...
S 192.168.1.0/27 [1/0] via 192.168.1.73
S 192.168.1.0/21 is directly connected, Null0
...
but this is not explaining why R1 and R2 are not generting sla 5 for 192.168.1.0/27.
R1#show ip route 195.233.184.0 255.255.255.0 longer-prefixes
192.168.1.0/24 is variably subnetted, 4 subnets, 3 masks
(...)
S 192.168.1.0/27 [1/0] via 192.168.1.73
O E2 192.168.1.0/21 [110/100] via 172.18.145.2, 1w1d, Vlan6
[110/100] via 192.168.1.109, 1w1d, Vlan622
(...)
02-23-2014 01:38 AM
Hi Fabio,
Thank you for these listings! Unfortunately, I have to say that the issue is only getting more confusing. I am not going to give an attempt for explanation, rather, I am going to point out the discrepancies - we need to have them ironed out before we can proceed.
First, if OSPF is configured to redistribute static routes without a route-map to do filtering then it must redistribute all static networks, even if they overlap or one is a subnet of the other. The only exception to this rule is the default route that can not be redistributed into OSPF but that's off topic for now. The behavior of R2 is suspicious in that it redistributes only the 192.168.1.0/21 and not the 192.168.1.0/27. There is absolutely no logical reason for that if the information and listings you have provided are accurate and complete.
Second, the prefix 192.168.1.0/21 alone is a nonsense. This is not a network prefix but rather a host address, because 192.168.1.0 AND 255.255.248.0 = 192.168.0.0 , and the range of addresses in this networks goes from 192.168.0.0 till 192.168.7.255. Your output from R2 shows that the "192.168.1.0/21" network is a static route configured towards Null0. However, the router should have never accepted such static route:
Router(config)# ip route 192.168.1.0 255.255.248.0 Null0
%Inconsistent address and mask
Router(config)#do show run | i ip route
Router(config)#
Third, even if R2 was originating an LSA-5 with LSID of 192.168.1.0 and netmask of /21, R1 is required to mask the LSID with the netmask in the LSA's body to obtain the network address. I am saying this because this is the only way to advertise overlapping external networks in OSPF that all have the same IP address but a different netmask. As an example, consider my two routers. My R2 has the following static routes:
R2(config-if)#do show ip route static
10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
S 10.0.0.0/25 is directly connected, Null0
S 10.0.0.0/24 is directly connected, Null0
S 10.0.0.0/16 is directly connected, Null0
On R1, the external LSAs received from R2 are:
R1(config-if)#do show ip ospf data | b Type-5
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.0.0 192.168.1.2 56 0x80000002 0x0044E4 0
10.0.0.127 192.168.1.2 61 0x80000001 0x004EDB 0
10.0.0.255 192.168.1.2 61 0x80000001 0x0046E3 0
Notice the differing LSIDs for the three networks whose prefix should in all three cases be 10.0.0.0. The netmask in the LSA-5 bodies is:
R1(config-if)#do show ip ospf data ext | i Link State ID:|Network Mask:
Link State ID: 10.0.0.0 (External Network Number )
Network Mask: /16
Link State ID: 10.0.0.127 (External Network Number )
Network Mask: /25
Link State ID: 10.0.0.255 (External Network Number )
Network Mask: /24
After masking the LSID with the netmask in the respective LSA, we get:
And this is what my R1 has in its routing table:
R1(config-if)#do show ip route ospf
10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
O E2 10.0.0.0/25 [110/20] via 192.168.1.2, 00:04:16, FastEthernet0/0
O E2 10.0.0.0/24 [110/20] via 192.168.1.2, 00:04:16, FastEthernet0/0
O E2 10.0.0.0/16 [110/20] via 192.168.1.2, 00:04:16, FastEthernet0/0
Therefore, I simply can not understand why your R1 would insert an OSPF-learned route 192.168.1.0/21 into the routing table, as the OSPF would always do the binary AND between the LSA-5 LSID and the contained netmask to compute the network address.
I have to ask again: do your outputs posted here display the IP addresses truly used by you, i.e. are you really using subnets of 192.168.x.x in your network exactly as we see them here in the show outputs? If yes then your routers must be running some seriously brain-damaged IOS - but I have never seen such grave flaws yet, so I am very reluctant to believe that.
Please do not take me as being overly focusing on the addressing and not paying much attention to missing LSA-5 which is your original problem. As you can see here, OSPF itself cares quite a lot about the addresses and this may have to do with the origination of the missing LSA-5.
Best regards,
Peter
02-23-2014 03:50 AM
Hi Peter,
the addresses here used are not the real one that I can not post here.
So do not be focus on ip address problem but at the same time I got you that investigation is not possible if not real output is there but the concept is clear: R2 has two static routes: /21 and /27.
R1 only /27.
Only /21 R2 side is redistruited into ospf.
I will try to go deeper on my own and I will update you. So far thanks for the effort, in any case you gave here precious information.
02-23-2014 04:37 AM
Fabio,
I am sorry I could not help further - but to accurately diagnose the symptoms, I would probably need more data than you can make public.
One more hint... If you can tolerate a short outage of external routes advertised from your R1, try doing this on R1:
debug ip ospf lsa-generation
clear ip ospf redistribution
The second command will cause R1 to immediately flush all its LSA-5 and within a minute, it will rescan the routing table and reoriginate the LSA-5. Perhaps some interesting information can be gathered in this debug. Once again, be careful, as the clear command here will cause R1 to initially remove its LSA-5 from the entire OSPF domain, so if some redistributed routes are available through R1 only, they will be unreachable for approximately one minute.
Best regards,
Peter
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: