11-18-2008 08:54 PM - edited 03-04-2019 12:23 AM
Hi Guys,
I have a main router (RTRA_MAIN) and a backup vpn router (RTRB_VPN) on a different subnet, the idea is to re-route the traffic to vpn only when main connection goes down and re-route back to main when it comes back. Now the problem is RTRB_VPN learns the routes from the tunnel (see the ip route.txt) instead of learning from the main while main is up. Tracing from external network to the vpn router shows trace directly comes to the tunnel instead of taking path from the RTRA_MAIN. Show ip route in RTRB_VPN shows the metric of 2222 and tag value of 2222 which I am confused of the origin of the tag and the metric calculation of 2222. I even tried increasing administrative distance of ospf process 1 in RTRB_VPN which changes the distance form 110/2222 to 135/2222, but it learns form the tunnel. What I am missing here?? Your expert opinions will be highly appreciated. Thanks in advance.
11-19-2008 12:37 PM
Hello Iqbal,
here you have multiple OSPF processes running on the both routers RTRA_MAIN and RTRB_VPN:
ospf process 1 running between the two routers and ospf process 2 running over the tunnel2 on RTRB_VPN.
First Note:
when you have multiple OSPF processes running in the same router they are executed separately as "ships in the night".
Even if the route type (o, O IA, O E1, O E2) and metric value could be compared they aren't.
Each OSPF process is in competition with the other one in presenting routes to the IP routing table maintainer: all detailed information about route type and even metric value are not considered:
the first process to converge can see its routes installed.
Second Note:
basic OSPF config
on RTRA_MAIN I see
fas0/1 is the physical interface to neighbor for OSPF process 1.
fas0/0 is the interface for OSPF process 2
on RTRB_VPN
GRE tunnel is the interface to neighbor for process 1 and is carried inside IPSec via the crypto map. The IPSEC/GRE/OSPF packets are sent out physical interface f0/0
interface f0/1 is associated with OSPF process 2.
Third Note redistribution:
in addition to what said in note1 you are performing on both routers two-way redistribution of OSPF2 into OSPF1 and of OSPF1 into OSPF2.
Redistribution are made using route filters with route-maps only prefixes matching some ACLs are imported.
Let's take a prefix
RTRB_VPN#sh ip route 10.95.1.1
Routing entry for 10.95.1.0/24
>>> Known via "ospf 1", distance 110, metric 2222
Tag 2222, type extern 2, forward metric 195
Redistributing via ospf 2
Last update from 10.1.7.53 on Tunnel1, 01:06:47 ago
Routing Descriptor Blocks:
* 10.1.7.53, from 200.23.29.54, 01:06:47 ago, via Tunnel1
Route metric is 2222, traffic share count is 1
Route tag 2222
the prefix is learnt via OSPF1 on tunnel1.
the prefix is not redistributed into OSPF2 because the line "Advertised in OSPF2" is missing.
the forwarding metric 195 is the result of bandwidth 512 inside interface tunnel1.
there is a tag 2222 that someone has inserted and a seed metric of type 2 of 2222.
To have prefixes coming on OSPF process2 preferred over OSPF process1 you need to modify the admin distance for external routes inside OSPF process 1
router ospf 1
distance ospf external 135
see
http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_osp1.html#wp1013195
then it can be a good idea to restart ospf process 1 only
clear ip ospf proc 1
during the time OSPF process 1 is restarted and converge again OSPF2 routes have a chance to get installed in the routing table
When OSPF1 comes back all its OSPF routes of type external are proposed to the routing table with AD 135.
This should make the trick if OSPF 2 domain has the routes otherwise you will see again the routes of OSPF1.
You can use
sh ip ospf 2 database external
to verify if the desired routes are present.
Hope to help
Giuseppe
11-19-2008 09:01 PM
Hi Giuseppe,
Thank you for reply.
I did change the AD of the ospf process 1 of RTRB_VPN, still getting the same result. I even did clear the both of the processes. Please see below.
router ospf 1
no log-adjacency-changes
summary-address 10.140.0.0 255.255.0.0
summary-address 10.136.0.0 255.255.0.0
summary-address 10.139.0.0 255.255.0.0
redistribute ospf 2 metric 5000 subnets route-map CZE2MTY
network 10.1.7.52 0.0.0.3 area 0
distance ospf external 135
RTRB_VPN#sh ip ospf 2 database external 10.95.1.0
OSPF Router with ID (10.136.1.10) (Process ID 2)
RTRB_VPN#sh ip ospf database external 10.95.1.0
OSPF Router with ID (10.136.1.10) (Process ID 2)
OSPF Router with ID (194.228.86.252) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 236
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.95.1.0 (External Network Number )
Advertising Router: 200.23.29.54
LS Seq Number: 80000154
Checksum: 0x82D2
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 2222
Forward Address: 0.0.0.0
External Route Tag: 2222
RTRB_VPN# sho ip route
Gateway of last resort is 194.228.86.249 to network 0.0.0.0
O E2 194.245.10.0/24 [135/2222] via 10.1.7.53, 00:09:32, Tunnel1
S 172.17.0.0/16 is directly connected, Null0
172.16.0.0/16 is variably subnetted, 4 subnets, 3 masks
O E2 172.16.40.0/28 [135/2222] via 10.1.7.53, 00:09:32, Tunnel1
O E2 172.16.3.40/32 [135/2222] via 10.1.7.53, 00:09:32, Tunnel1
O E2 172.16.3.17/32 [135/2222] via 10.1.7.53, 00:09:32, Tunnel1
S 172.16.0.0/16 is directly connected, Null0
200.23.29.0/32 is subnetted, 1 subnets
S 200.23.29.54 [1/0] via 194.228.86.249
10.0.0.0/8 is variably subnetted, 2698 subnets, 18 masks
O E2 10.216.106.184/30 [135/2222] via 10.1.7.53, 00:09:32, Tunnel1
O E2 10.216.98.176/29 [135/2222] via 10.1.7.53, 00:09:32, Tunnel1
O E2 10.178.184.0/24 [135/2222] via 10.1.7.53, 00:09:32, Tunnel1
O E2 10.176.186.0/24 [135/2222] via 10.1.7.53, 00:09:32, Tunnel1
RTRB_VPN#sh ip route 10.95.1.0
Routing entry for 10.95.1.0/24
Known via "ospf 1", distance 135, metric 2222
Tag 2222, type extern 2, forward metric 195
Redistributing via ospf 2
Last update from 10.1.7.53 on Tunnel1, 00:10:36 ago
Routing Descriptor Blocks:
* 10.1.7.53, from 200.23.29.54, 00:10:36 ago, via Tunnel1
Route metric is 2222, traffic share count is 1
Route tag 2222
11-19-2008 10:49 PM
Hi Giuseppe,
Yes, you are right, ospf process 1 is not injecting the routes to ospf 2 process. But I cant identify, whats preventing it.
RTRA_MAIN#sh ip ospf 2 database external 10.95.1.0
OSPF Router with ID (10.139.11.31) (Process ID 2)
RTRA_MAIN#sh ip ospf 1 database external 10.95.1.0
OSPF Router with ID (10.222.0.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 484
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.95.1.0 (External Network Number )
Advertising Router: 135.32.116.136
LS Seq Number: 8000011E
Checksum: 0x58F5
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 1000
Forward Address: 0.0.0.0
External Route Tag: 77
11-20-2008 02:22 AM
Hello Iqbal,
missing routes in OSPF process 2 on the MAIN router was the most likely reason for what you see.
The output you provided show that the prefix 10.95.1.0/24 is not present in OSPF2 DB.
You need to review your route filters in redistribution, when I looked at your first post attach files I was in doubt about how you have implemented filters.
Usually filters are made using route-tags, you are using ACLs so if the prefix is not permitted by the ACL(s) invoked in the route-map blocks the prefix will not redistributed.
Start from
sh ip route 10.95.1.0 on main router
it should tell you
redistributing in OSPF2
but the line
Advertised by OSPF2 should be missing
I would suggest you an approach based on route-tags that has the benefit to be self-adaptive to changes as discussed in the other thread.
Hope to help
Giuseppe
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: