cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1014
Views
0
Helpful
19
Replies

OSPF - route issue

ronald.ramzy
Level 1
Level 1

Hi,

I have a weird situation,

There is a Webserver located on Site-Y, when users on Site-X try to access it ; the traffic goes

via VPN Tunnel (( site A )) and returns back same path.

I wanted all traffic for Site-Y initiating from Site-X should go via FR_RTR

How could I resolve it...

Attached is network diagram and config of Site-X and Site-Y

19 Replies 19

Joseph W. Doherty
Hall of Fame
Hall of Fame

You haven't posted enough information to be certain (e.g. VPN routers configs), but its likely if you're running OSPF both via frame-relay and via VPN, the VPN paths OSPF cost is less or the cost is the same. (If the cost is the same, traffic should normally alternate paths.)

Thanks for your reply.

I didnt get what you mean, my requirement is that "Traffic for site-Y initiated from Site-X should be via FR-RTR and traffic for Site-A initiated from Site-x should go via VPN Tunnel...

Plz help

Yes I understand, but you did not post enough information to be certain what the issue is. From what you did post, I suspect Site-X sees reaching Site-Y is "better" going via Site-A, and the same for the converse.

Hello Ronald,

Joseph is right we can only guess that the OSPF best path is via the vpn tunnel.

take two subnets as example and provide

sh ip route X

sh ip route Y

there are chances that the path over the VPN sees only LAN interfaces, instead the FR path sees a low bandwidth serial interface and so the cost via FR is higher.

How is the VPN made ? Are you using a GRE tunnel protected by IPSec ?

using sh ip ospf interface of all involved interfaces you can find a confirmation to our guess.

Another possible reason is a comparison between different types of OSPF routes

Hope to help

Giuseppe

Thank to all for your reply.

Yes we have GRE tunnel protected by IPSEC

when I do sh ip route 192.168.99.0 it goes via GRE-tunnel rather than FR_RTR

Frame_Relay connection is 1MB

GRE_IPSEC Tunnel is 2MB to site_A

From Site_Y GreIPSEC tunnel is 2MB to Site_A

Is it a good idea to run EIGRP for FRame_relay Router and OSPF with GRE_IPSEC...

can someone help with sample configuration on cisco_doc_link

Hello Ronald,

the FR path is less preferred for its lower bandwidth.

If you want to move only part of traffic you can use PBR to send some traffic over the FR link.

if you use EIGRP over the FR link all traffic will go via the FR link for the lower administrative distance.

I think you can achieve some load sharing using PBR

see

http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_prb_mult_track_ps6922_TSD_Products_Configuration_Guide_Chapter.html

the idea is to configure a route-map that invokes ACLs to define traffic to be redirected.

Hope to help

Giuseppe

Thank to all for your reply.

Yes we have GRE tunnel protected by IPSEC

when I do sh ip route 192.168.99.0 it goes via GRE-tunnel rather than FR_RTR

Frame_Relay connection is 1MB

GRE_IPSEC Tunnel is 2MB to site_A

From Site_Y GreIPSEC tunnel is 2MB to Site_A

Is it a good idea to run EIGRP for FRame_relay Router and OSPF with GRE_IPSEC...

can someone help with sample configuration on cisco_doc_link

You could tweak the OSPF cost of the FR cloud to make it the preferred route from X to Y. However, you may also have to tweak costs of GRE tunnels to site A to ensure that traffic from A to Y still uses the GRE.

If you provide the reference bandwidth being used in OSPF process then I could provide a solution as described above. Default RBW is 100Mb.

Thanks for your reply.

GRE Tunnel = 2MB

FR=1MB

I hope this is the informtaion you needed.

Plz can u provide the solution as u explained

Currently the cost from Site X to Site Y via FR cloud is 100 (assuming your using default reference bandwidth). The cost from Site X to Site A would be 50. The cost from Site A to Site Y would also be 50. So, you can see, there is actually equal path costs from X to Y right now. By default your traffic should be load balanced per flow (based on source/destination IP address). If from your Core device at Site X you issue a "show ip route y.y.y.y" for some network at Y, there should be two valid equal path routes. Do you get that?

If so, the following changes will correct this and allow Site X traffic to use the FR cloud as the primary route to Site Y, but failover to use the VPN should the FR cloud go down.

===============

Site X FR-RTR

===============

conf t

interface Serial0/0/0.2 point-to-point

ip ospf cost 80

end

wr

===============

Site Y FR-RTR

===============

conf t

interface Serial0/0/0.2 point-to-point

ip ospf cost 80

end

wr

Hi,

Today Cisco System Engineer try to tackle the issue but no luck and recommended to have EIGRP running on Frame-relay cloud only and OSPF on LAN & GRE with IPSEC.

what do you suggest.

Hello Ronald,

using two different routing protocols that offer comparable routes (same prefix and same prefix len) build a primary and backup path:

EIGRP is preferred over OSPF and this is different from what you want.

I think you should try the suggestions from Ryan.

OSPF metric is simply the sum of individual costs so if all links are in the same Area for OSPF you should be able to move traffic as you like.

if the paths are in different OSPF areas however, the OSPF hierarchy makes O routes preferred to O IA routes regardless of metric.

Edit:

I've reviewed the attached configurations and all paths are in OSPF area 0 so tayloring the metrics is possible.

Randy has given you an example of the approach to be used.

the cost of the FR link has to be less then going twice through the GRE tunnels

Hope to help

Giuseppe

Thanks Giuseppe & Ryan

But after trying the cost still it doesnt seems to work.

Can you provide the routing tables of your core devices? At least the routing entries we are concerned with...I am sure we can solve this problem.

Thanks,

Ryan

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco