Re: Routing Issue

i-chowdhury · ‎11-18-2008

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.

Giuseppe Larosa · ‎11-19-2008

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

i-chowdhury · ‎11-19-2008

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

i-chowdhury · ‎11-19-2008

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

Giuseppe Larosa · ‎11-20-2008

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