Forcing a specific subnet to route across a backup link

[Steve Coady]

Hello

I have a DR site located apprx 50 miles away.

I have (2) links to this site.

The primary link is used for regular production traffic which uses approx 80% of the link throughtout the day and is included in my EIGRP process

I need to send replication data  between the (2) sites.

I want to use a backup link just for the replication. How can I accomplish this?

Is it a matter of implementing statics pushing traffic destined for a specific subnet through specific interfaces from both sides?

See diagram

[Bilal Nawaz · Accepted solution]

Hello, I would put in specific static routes in this scenario, it will accomplish what you want to achieve. Especially if the traffic is flowing one way, i.e. towards DR from your SiteB. Ensure the link from Site_B-Core-A to Site_B-Core-A will not get saturated by this traffic (replication traffic + normal production traffic), if the production traffic uses that path to servers.

hth

Bilal - CCIE #45032

[paul driver · Accepted solution]

Hello

The only issue with static routing is its hardcoded - you would want to use some form of resilience to monitor the remote network ( floating static via  ip sla or object tracking etc..)

PBR would also be an option and with verification for the same as above

res

Paul

[Bilal Nawaz]

Yes Paul i also agree with you there - however it depends what the exact requirement is. After all, we may not want to end up saturating the production links when they are already at 80%.

I would prefer static routing because it is much more apparent and can be argued more deterministic, perhaps with ip sla if required :)

[Steve Coady]

Bilal

Thank you for the response.

The Production link to the DR site is across the Microwave. That link is at approx 80%

This is why we want to use the IRHN secondary link for the replication data.

Based on both of your responses, I see that you agree that static routes would be best solution.

I may only want Specific servers using that secondary link as opposed to defining the whole subnet

A little more info on current routing for that subnet.

The ASR_Main Campus shows the following:

ASR_Main Campus#sh ip eigrp top 10.x.67.0/24
EIGRP-IPv4 Topology Entry for AS(170)/ID(10.0.25.78) for 10.x.67.0/24
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 3840
  Descriptor Blocks:
  100.x.15.3 (Tunnel1), from 100.x.15.3, Send flag is 0x0
      Composite metric is (3840/3072), route is Internal
      Vector metric:
        Minimum bandwidth is 900000 Kbit
        Total delay is 40 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1400
        Hop count is 2
      ECMP Mode: Advertise by default
  10.0.25.1 (Site_A-Core-A)  (GigabitEthernet0/0/1), from 10.0.25.1, Send flag is 0x0
      Composite metric is (3840/3584), route is Internal
      Vector metric:
        Minimum bandwidth is 800000 Kbit
        Total delay is 30 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

The Site_A-Core-A shows the following:

Site_A-CORE-A# sh ip eigrp top 10.x.67.0/24

IP-EIGRP (AS 170): Topology entry for 10.x.67.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3712
  Routing Descriptor Blocks:
  10.x.87.10 (6506 at DR) (Ethernet7/11), from 10.x.87.10, Send flag is 0x0
      Composite metric is (3712/2816), Route is Internal
      Vector metric:
        Minimum bandwidth is 800000 Kbit
        Total delay is 20 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.x.8.245 (Site_B-Core-A) (Ethernet7/10), from 10.x.8.245, Send flag is 0x0
      Composite metric is (3893/3637), Route is Internal
      Vector metric:
        Minimum bandwidth is 819200 Kbit
        Total delay is 30 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
  10.x.16.5 (Current DR site - Being replaced)(Ethernet7/9), from 10.x.16.5, Send flag is 0x0
      Composite metric is (3893/3637), Route is Internal
      Vector metric:
        Minimum bandwidth is 819200 Kbit
        Total delay is 30 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

Are there any drawbacks/problems that could arise by using statics

[Bilal Nawaz]

I can't really see any draw backs using static routes to be honest, its most easy and simple solution to implement, and not complicated at all. I guess the only concern is not have IP SLA - you may want to get rid of this route if your link fails so it can go via the primary link. But if that is not wanted then your fine with just only simple statics.

Specific host routes i.e. ip route x.y.z.a 255.255.255.255 b.c.d.e will be just fine. Longest prefix wins and in any case the admin distance is superior over eigrp.

hth.

[Steve Coady]

Paul

Thank you for your response. I responded to Bilal concerning both of your suggestions

[Steve Coady]

Paul

PBR to define communication between specific hosts or subnets. How would that look?

[Bilal Nawaz]

The other option which is PBR as mentioned. But to be honest, i don't see much point.

Here's an example with the IP SLA feature.

R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo x.x.x.x
R1(config-ip-sla)# frequency 4
R1(config-ip-sla)# timeout 2000
R1(config-ip-sla)# threshold 100
R1(config-ip-sla)# ip sla schedule 1 life forever start-time now

R1(config)# track 1 ip sla 1 reachability

R1(config)# ip access-list extended ACL_REP
R1(config)# permit ip host x.x.x.x host y.y.y.y  <-------- match your replication traffic

R1(config)# route-map RM_REP permit 1
R1(config-route-map)# match ip address ACL_REP
R1(config-route-map)# set ip next-hop verify-availability 192.168.150.2 1 track 1

R1(config)# interface gi0/0/0 <--------- Internal interface (client side)
R1(config-int)# ip policy route-map RM_REP

Im still of the opinion that static routes will do just fine in this scenario, theres not a need for routing source traffic down a certain direction, the destination host routes can do a more better more clean job in my view.

hth

[paul driver]

Hello

PBR example:
 - network 192.168.1.0/24
 - remote network 1.1.1.1
 - next-hop 172.16.1.254
 

ip sla 1
icmp-echo 1.1.1.1
fre 5
ip sla schedule 10 life forever start-time now

track 1 sla 1 reachability

access-list 10 permit 192.168.1.0

route-map PBR permit 10
match ip address 10
set ip next-hop verify-availability 172.16.1.254 1 track 1

(Note: The next-hop address is considered reachable if the tracked object is up
then it will PBR otherwise it should be rib routed.)
 

data plane PBR

int x/x (interface facing source) -
ip policy route-map PBR

Control-plane PBR (no interface)
ip local policy route-map PBR

res

Paul

 

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

A possible solution would be to use PBR.

I would also recommend QoS to deprioritize the replication traffic.