cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
937
Views
0
Helpful
1
Replies

CONFIGURING STATIC ROUTE TRACKING USING IP SLA ON ASR1000

julxu
Level 1
Level 1

Hi

 

I had alwasy configure on catxxx router for ip SLA using track, 

 

now I need configure a route on asr1004 which means if a interface down, the related route (static route) will not be send out to next hop.

 

I have looked the command on asr1004, and there is no similar command related. Could anyone advice me how can I achive a SLA configuration to monitor a interface and if it is down, will not send related static route out?

 

for example:

      the route is ip route 10.1.1.0 255.255.255.0 10.2.2.2 

      interface GigabitEthernet0/3/1

              ip address 10.2.2.1 255.255.255.0
              no ip redirects
              no ip unreachables
              no ip proxy-arp
              media-type rj45
              negotiation auto

I need if int g0/3/1 down, then the route 10.1.1.0 will not be advised to next hop.

 

I have configure the box as:

R1(config)# ip sla 1
R1(config)# icmp-echo 2.2.2.2 source-interface FastEthernet0/0
R1(config)# timeout 1000
R1(config)# threshold 2
R1(config)# frequency 3
R1(config)# ip sla schedule 1 life forever start-time now

R1(config)# track 1 ip sla 1 reachability

ip route 10.1.1.0 255.255.255.0 10.2.2.2 tag 2 track 1

 

the tag 2 is for redistribute from static to bgp, the tarck 1 is for monitoring the ip 10.2.2.2 if it is down, if so, stop route 10.1.1.0/24.

 

the configuration is wrong, because if I shutdown the interface with next hop is 10.2.2.2, the route 10.1.1.0/24 is still existed on routing table.

 

Any comments will be apprecaited

 

Thanks in advance

 

Julxu

 

1 Reply 1

Peter Paluch
Cisco Employee
Cisco Employee

Hi Julxu,

the configuration is wrong, because if I shutdown the interface with next hop is 10.2.2.2, the route 10.1.1.0/24 is still existed on routing table.

Let's verify one thing: Even if you shut down the inteface toward 10.2.2.2, there can possibly be another less specific route that matches the next hop 10.2.2.2, so the next hop appears to be still reachable. Can you please verify with show ip route 10.2.2.2 that this is the case?

Best regards,
Peter