1720 ignoring static routes 1

[lgarner]

I have a 1720 configured with 2 ethernet and 1 serial i/f. The serial is a frame link into my "cloud", one ethernet (call it eth0) is for the LAN and the other (eth1) is for internet access. The internet is accessed through a Linux server providing a VPN to back up the frame relay. The router is using EIGRP to learn its routes and doing fine, except...

Due to bandwidth needs, I'm trying to get traffic between two hosts to traverse the VPN, not the frame. I add static routes to both sides, and "sh ip route x.x.x.x" shows the correct route. Still, traceroute indicates that routing is done through the serial link (eigrp, cost=70) not through the vpn (static, cost=1).

IOS is 12.2(4)

Any ideas would be appreciated.

 

[rcasta]

When you apply that static route, it seems weird that your router prefers EIGRP route instead of lower metric static route. Could you post a "show ip route host2". Further, take note that any host that wants to send traffic towards host2 will go out eth1 instead of your primary Frame Relay link.

On the other hand, I would suggest using policy routing. If I got right your scenario, you need that whenever traffic from chosen Host1, coming from eth0, wants to reach Host2, makes it through eth1 interface. Doesn't it?

If so, here is the suggested configuration:

!Host1 to Host2 traffic will go out VPN link and
!Host1 to ANY will go out Frame Relay link
access-list 101 permit ip host IP_HOST1 host IP_HOST2

!IF YOU WANT HOST1 to always go out VPN link then apply
! access list 102
!access-list 101 permit ip host IP_HOST1 any

route-map host1tohost2 permit 10
match ip address 101
set ip next-hop IP_NexHopVPN

interface ethernet0
ip policy route-map host1tohost2

hope it helps,

 

[lgarner]

Very good idea, thanks. As for the routing, router2 has this entry to get to host1:

olt-gate1#sh ip route 10.1.3.100
Routing entry for 10.1.3.100/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.5.2.200
Route metric is 0, traffic share count is 1

"10.2.1.200" is the vpn server, 10.5.2.0/24 is the dmz and 10.5.1.0/24 is the LAN. But, a traceroute shows:

olt-gate1#trace 10.1.1.100
Tracing the route to 10.1.3.100
1 10.0.4.5 20 msec 20 msec 20 msec
2 10.1.1.1 20 msec 20 msec 20 msec
3 10.1.3.100 20 msec * 16 msec
olt-gate1#

where "10.0.4.5" is the next hop via frame.

Anyway, it gets stranger. In order for router2 to ping locally-connected host2, after adding the static route on router1 for host2 via vpn (got that?), I had to add another static route to host2 via i/f eth0. Otherwise, router2 would use the eigrp learned route in preference to a locally-connected (cost 0) one! That has me scratching my head.

I'll try the policy routing that you provided after hours and let you know.

Thanks again.

 

[rcasta]

Perhaps posting your configuration and a global show ip route might help.

cheers,

 

[lgarner]

Found a problem. As I was reading through my routing table (editing for content & size), I found a route to my locally-connected vpn server via the frame relay. This is coming from a redistributed static route on the remote router to ensure that the vpn is up and accessable (really for the monitoring system's benefit). Even though 10.5.2.200 is locally connected to the interface with 10.5.2.11 bound to it, it wasn't seen as local until I added "ip route 10.5.2.200 255.255.255.255 eth0".

This issue can be corrected with route filters, but still the connected i/f should override an external eigrp route, no?

Below is my "sh run" and "sh ip route" output, with minor deletions. Thanks for your help.

Lee.



sh ru
Building configuration...

Current configuration : 2713 bytes
!
! Last configuration change at 13:19:01 PDT Wed Sep 3 2003
! NVRAM config last updated at 07:03:11 PDT Thu Jul 17 2003
!
version 12.2
service timestamps debug uptime
service timestamps log datetime
service password-encryption
!
hostname olt-gate1
!
logging buffered 4096 notifications
enable secret
enable password
!
clock timezone PST -8
clock summer-time PDT recurring
ip subnet-zero
no ip domain-lookup
!
!
!
interface Loopback0
ip address 10.5.0.5 255.255.255.252
!
interface Ethernet0
description Alternate route via vpn
ip address 10.5.2.11 255.255.255.0
half-duplex
standby 2 ip 10.5.2.10
standby 2 timers 5 15
standby 2 priority 110
standby 2 preempt
!
interface FastEthernet0
description Internal segment
ip address 10.5.1.11 255.255.255.0
speed auto
half-duplex
standby 1 ip 10.5.1.10
standby 1 timers 5 15
standby 1 priority 110
standby 1 preempt
interface Serial0
description Local DLCI
no ip address
encapsulation frame-relay
no fair-queue
service-module t1 timeslots 1-6
!
interface Serial0.1 point-to-point
description Frame to another office
bandwidth 384
ip address 10.0.4.18 255.255.255.252
frame-relay interface-dlci
!
interface Serial0.2 point-to-point
description PVC to Main Office
bandwidth 384
ip address 10.0.4.6 255.255.255.252
frame-relay interface-dlci
!
router eigrp 1
network 10.0.0.0
no auto-summary
no eigrp log-neighbor-changes
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.5.2.1
ip route 10.1.0.0 255.255.0.0 10.5.2.200 200
ip route 10.1.3.100 255.255.255.255 10.5.2.200
no ip http server
!
!
logging facility local6
logging source-interface FastEthernet0
logging 10.5.2.200
dialer-list 1 protocol ip permit
dialer-list 1 protocol ipx permit
snmp-server community 2sl8vah7 RO
snmp-server trap-source Ethernet0
snmp-server location DataCenter
snmp-server contact Comm 310-385-2250
snmp-server host 10.1.3.200 inform version 2c 2sl8vah7
!
line con 0
password 7
login
line aux 0
password 7
line vty 0 4
password 7
login
!
no scheduler allocate
sntp server 10.5.2.200
sntp server 192.168.1.1
end

olt-gate1#sh ip route 10.1.3.100
Routing entry for 10.1.3.100/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.5.2.200
Route metric is 0, traffic share count is 1

olt-gate1#trace 10.1.3.100

Type escape sequence to abort.
Tracing the route to 10.1.3.100

1 10.0.4.5 80 msec 76 msec 92 msec
2 10.1.1.1 84 msec 100 msec 100 msec
3 10.1.3.100 116 msec * 16 msec
olt-gate1#exit

sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 10.5.2.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 33 subnets, 6 masks
D 10.0.4.12/30 [90/7690496] via 10.0.4.17, 20:26:50, Serial0.1
D 10.0.4.8/30 [90/7690496] via 10.0.4.5, 20:26:50, Serial0.2
D 10.5.0.8/30 [90/156160] via 10.5.1.12, 20:26:50, FastEthernet0
D EX 10.2.0.0/16 [170/7194624] via 10.0.4.5, 20:26:50, Serial0.2
D 10.1.1.0/24 [90/7204096] via 10.0.4.5, 20:26:50, Serial0.2
C 10.0.4.4/30 is directly connected, Serial0.2
S 10.1.0.0/16 [200/0] via 10.5.2.200
C 10.5.0.4/30 is directly connected, Loopback0
C 10.5.2.0/24 is directly connected, Ethernet0
C 10.5.1.0/24 is directly connected, FastEthernet0
D 10.1.0.4/30 [90/7306496] via 10.0.4.5, 20:26:50, Serial0.2
D EX 10.5.0.0/16 [170/7194624] via 10.0.4.5, 20:26:50, Serial0.2
D 10.0.1.16/30 [90/7844096] via 10.0.4.5, 20:26:50, Serial0.2
C 10.0.4.16/30 is directly connected, Serial0.1
S 10.1.3.100/32 [1/0] via 10.5.2.200
D EX 10.1.130.0/24 [170/7204159] via 10.0.4.17, 20:26:51, Serial0.1
D EX 10.5.2.200/32 [170/7194624] via 10.0.4.5, 20:26:51, Serial0.2
S* 0.0.0.0/0 [1/0] via 10.5.2.1
olt-gate1#exit

 

[lgarner]

OK, I think that I can now explain the problem and the reason behind it.

Router A has a connected interface on 10.5.2.0/24. One of the devices connected there is 10.5.2.200.

Router B has a WAN link to router A, but needs a static route to 10.5.2.200 via the Internet VPN (This is because FreeS/WAN creates all static routes when it comes up). Router B is also redistributing static routes (it has several).

Therefore, router B has these routes in its routing table:
10.5.2.0/24 via EIGRP, learned from Router A
10.5.2.200/32 via Static, redistributed into EIGRP.

This means that router A has these:
10.5.2.0/24 connected, redistributed into EIGRP
10.5.2.200/32 via EIGRP from router B. <<<--- here's the problem.

Since 10.5.2.200/32 (via WAN) is more specific than the /24 (connected), it's used as the primary route even though its cost is higher. This apparently is not a bug, nor even a design flaw, but it sure seems weird to prefer a WAN route over a connected one.

I got around this by adding &quot;ip route 10.5.2.200 255.255.255.255 eth0&quot; to Router A's config, and things seem normal. I'll look around for a more elegant solution, like blocking the redistribution of that static route.

Lee.