09-23-2011 02:09 AM - edited 03-04-2019 01:42 PM
Hi all,
Back with another question / issue on my OSPF routing
I have 2 ASBR routers, AGFR01RTR03 and AGFR02RTR03, performing OSPF to OSPF redistribution in both ways for the same ASs.
They also do summarization for our private addressing scheme. It is all working just fine for that part (neighbors, summarization, redistribution).
AGDC01RTR01 --- AGDC02RTR01 (OSPF 1000 ABRs)
| |
| |
AGFR01RTR03 --- AGFR02RTR03 (OSPF 1000 / 53 ASBRs)
Let's focus on AGDC01RTR01 with a specific entry here (IP subnet is fake) :
Routing entry for 1.1.1.0/25
Known via "ospf 1000", distance 110, metric 300, type inter area
Last update from 10.2.244.76 on GigabitEthernet5/1, 1d03h ago
Routing Descriptor Blocks:
* 10.2.244.76, from 10.2.1.249, 1d03h ago, via GigabitEthernet5/1
Route metric is 300, traffic share count is 1
Compare with AGDC02RTR01 :
Routing entry for 1.1.1.0/25
Known via "ospf 1000", distance 110, metric 400, type inter area
Last update from 10.2.244.121 on GigabitEthernet5/2, 1d03h ago
Routing Descriptor Blocks:
* 10.2.244.121, from 10.2.1.249, 1d03h ago, via GigabitEthernet5/2
Route metric is 400, traffic share count is 1
I would expect AGFR01RTR03 (in full state on its peering with AGDC01RTR01) to learn that network from OSPF 1000, but no :
Routing entry for 1.1.1.0/25
Known via "ospf 53", distance 110, metric 23000
Tag 1000, type extern 2, forward metric 45
Redistributing via ospf 1000
Last update from 10.5.1.9 on GigabitEthernet1/2, 3d00h ago
Routing Descriptor Blocks:
* 10.5.1.9, from 10.5.0.134, 3d00h ago, via GigabitEthernet1/2
Route metric is 23000, traffic share count is 1
Route tag 1000
The route comes from OSPF 1000 being redistributed into OSPF 53 on AGFR02RTR03 (which tagged the route + adjusted metric to 23K).
HEre is the OSPF and route maps existing on AGFR01RTR03. Note that config is very close on AGFR02RTR03 (only the metric goes to 23K instead of 18K)
router ospf 1000
log-adjacency-changes
nsf
summary-address 10.4.0.0 255.254.0.0 tag 33
summary-address 172.18.0.0 255.255.0.0 tag 33
redistribute ospf 53 metric 18000 subnets route-map EU_US
network 10.2.244.80 0.0.0.3 area 0
router ospf 53
log-adjacency-changes
auto-cost reference-bandwidth 10000
nsf
network 10.5.1.8 0.0.0.7 area 0
summary-address 10.2.0.0 255.254.0.0 tag 1000
summary-address 172.16.0.0 255.255.0.0 tag 1000
redistribute ospf 1000 metric 18000 subnets route-map US_EU
route-map US_EU deny 10
match tag 33
!
route-map US_EU permit 20
set tag 1000
!
route-map EU_US deny 10
match tag 1000
!
route-map EU_US permit 20
set tag 33
Would you have any recommendation on how I could possibly debug this issue ? I'm a little confused on what to verify.
Tom
Solved! Go to Solution.
10-04-2011 03:32 AM
Hi Tom,
Oh, I am relieved to see that this mystery has been solved Thank you for letting me know! And you are of course welcome to use whatever "tools" I suggested so far - that's what these forums are for: sharing knowledge.
I am somewhat puzzled by the fact that the distribute list caused so many routes to be removed but it seems that it is an implementation-specific issue: all routes are removed and the re-added while being filtered by the distribute list. Inefficient but obviously effective.
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide