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 ?
Answer:
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 Cisco Switches side down too.
没有评论:
发表评论