how to manipulate OSPF routes using 2 links

[carl_townshend]

hi everybody

I have a question

I have a site whereby I have 2 wan links, back to a datacentre

I want certain traffic to go over 1 link and certain traffic over the other link.

How can I make 1 route to be prefererred to the other just for certain routes ?

cheers

Carl

[Bilal Nawaz]

Hello, with equal routes/metrics etc..., OSPF will share the load between both links. You can achieve the specific source to destination with policy based routing.

Please see: http://www.cisco.com/en/US/tech/tk364/technologies_configuration_example09186a00801f3b54.shtml

Hope this helps.

Please rate useful posts and remember to mark any solved questions as answered. Thank you.

[paul driver]

Hello,

Can you provide a show readout for the following

sh ip route x.x.x.x ( the network you want to manipulate)

sh ip ospf border-routers

sh ip route  ospf | in O

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Steven Clinton]

Policy based routing or HSRP (or any other FHRP) is the easiest.

Sent from Cisco Technical Support iPhone App

[carl_townshend]

Hi

The solution is not yet in place so I cant show any configs

So are you saying I cannot do this with OSPF?

The lines will both terminate on the same router so HSRP is not an option here.

If using PBR how do I get it to failover to the other link if the primary goes down ?

cheers

[Steven Clinton]

At what level do you want to segment traffic, For example do you want to separate the traffic based on the traffic's subnet?

Sent from Cisco Technical Support iPhone App

[carl_townshend]

Yes most likely, it maybe a few host ip addresses also

cheers

[Steven Clinton]

For OSPF to inherently change it's metric or next hop based on the subnet, nothing comes to mind. But in tandem with PBR you can identify your interesting traffic with either a prefix-list or ACL, then change it''s next hop, metric, metric type, default route, exiting interface. All but the last (exiting interface) would reroute in the event of a failure using normal the normal SPF algorithm.

Hope that makes sense, let me know if you have any questions.

[carl_townshend]

Hi

So you saying get it to learn the routes via ospf then set the next hop

ip

Ok how would it work if the next hop went down?

[blau grana]

Hello Carl,

You can run OSPF on both links and on top of that configure static routes with IP SLA to track if link is operational or you can configure PBR to direct traffic to destination.

Do you want to load balance based on destination or source IP addresses?

Best Regards

Please rate all helpful posts and close solved questions

[Adrian Coto]

OSPF + Static routes or PBR may work well in small scale.

For large scale deployments it is probably better to use OSPF(internal link routes) + BGP (edge routes), or even better MPLS Traffic Engineering.

[carl_townshend]

Hi

Can someone give me an example, using ospf and PBR? If the next hop went down would it automatically use the other path via ospf ?

[Bilal Nawaz · Accepted solution]

Hello, answer to your question is yes - I'll try to explain how, below.. You do not need static routes either, just an ospf environment with the correct tracking and PBR. I've quickly done an example here - I want any traffic going to 1.1.1.1 to go down fa0/1 on SITE_A where the next hop is 10.0.0.1 (DC) and anything for 2.2.2.2 next hop will be 20.0.0.1 which is fa0/0 path to router DC :

Here is the config for SITE A where the policy is set and also the tracking, our goal is to set tracking for paths that the router could take i.e. both interfaces on DC - if any of these are down or unreachable from the correct source interface on SITE_A then we will assume the ospf routing table to get us there. It gets interesting with policy based routing in the mix, and we'll see how that comes in to play with the tracking feature.:

SITE_A

ip sla monitor 1

type echo protocol ipIcmpEcho 10.0.0.1 source-interface FastEthernet0/1

ip sla monitor schedule 1 life forever start-time now

ip sla monitor 2

type echo protocol ipIcmpEcho 20.0.0.1 source-interface FastEthernet0/0

ip sla monitor schedule 2 life forever start-time now

!

track 1 rtr 1 reachability

!

track 2 rtr 2 reachability

!

!

interface FastEthernet0/0

ip address 20.0.0.2 255.255.255.252

ip ospf network point-to-point

ip ospf 1 area 0

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 10.0.0.2 255.255.255.252

ip ospf network point-to-point

ip ospf 1 area 0

duplex auto

speed auto

!

interface FastEthernet1/0

no switchport

ip address 172.16.1.1 255.255.255.0

ip policy route-map TEST

duplex full

speed 100

!

router ospf 1

log-adjacency-changes

redistribute connected subnets

!

ip access-list extended TEST

permit ip any host 1.1.1.1

ip access-list extended TEST2

permit ip any host 2.2.2.2

!

!

route-map TEST permit 10

match ip address TEST

set ip next-hop verify-availability 10.0.0.1 1 track 1

!

route-map TEST permit 20

match ip address TEST2

set ip next-hop verify-availability 20.0.0.1 2 track 2

config on DC:

interface Loopback1

ip address 1.1.1.1 255.255.255.0

!

interface Loopback2

ip address 2.2.2.2 255.255.255.0

!

interface FastEthernet0/0

ip address 20.0.0.1 255.255.255.252

ip ospf network point-to-point

ip ospf 1 area 0

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 10.0.0.1 255.255.255.252

ip ospf network point-to-point

ip ospf 1 area 0

duplex auto

speed auto

!

router ospf 1

log-adjacency-changes

redistribute connected subnets

So now we will do some traceroutes from LAN to see which way our traffic is going:

LAN#show ip route

Codes: C - connected, S - static, 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

       i - IS-IS, su - IS-IS summary, 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 172.16.1.1 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 1 subnets

C       172.16.1.0 is directly connected, FastEthernet0/0

S*   0.0.0.0/0 [1/0] via 172.16.1.1

LAN#traceroute 1.1.1.1

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 172.16.1.1 24 msec 36 msec 16 msec

  2 10.0.0.1 28 msec *  60 msec

LAN#traceroute 2.2.2.2

Type escape sequence to abort.

Tracing the route to 2.2.2.2

  1 172.16.1.1 28 msec 24 msec 20 msec

  2 20.0.0.1 44 msec *  44 msec

We are able to see our policy routing - working with the trace-routes matching the ACL as seen here:

So now we know that our policy based routing is working since they are taking the correct paths, lets go and shut the interface fa0/0 on SITE_A to see if the route goes the other way, we should see a change. Note below that the TRACKING STATE has gone from up to down (we could have done this from DC as well but would have had same effect). Hence the policy based routing for packets matching to 2.2.2.2 will be de-activated and treated as normal, because the monitor state changed to down. So it will take the 10.0.0.1 route as we should see after.

Now we go to the LAN and do the trace routes again....

They are both going via 10.0.0.1 through fa0/1 which is working perfectly. Same will work if we was to shut the other side down too.

Hope this helps

Please rate useful posts and remember to mark any solved questions as answered. Thank you.

[carl_townshend]

this is perfect....really appreciate your help with this, I really like this command ,set ip next-hop verify-availability 10.0.0.1 1 track 1

thats what i was looking for, so basically it wont use the PBR if the track went down.

one question if we didnt use ip sla track, and still used PBR, what would happen if the next hop went down that i used in the set ip next hop object?

would it still fail over ?

[Bilal Nawaz]

Yes you are correct, it won't use the PBR if the tracking state went to down.

If you didn't use the tracking, ip sla, and you had PBR enabled, then all the packets will be following the policy, it has no idea of the next hop logic (whether its up or not) and traffic would just be black holed somewhere on its way to the 'next hop' - the next hop isn't reachable.

The router would still send it with the policy in place. Remember where you set the policy, on the inside LAN interface, so the policy will kick in before the routing happens. So it would not fail over.

That's why we use PBR with tracking ;-)

Hope this helps

Sent from Cisco Technical Support iPhone App