cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1906
Views
10
Helpful
6
Replies

Throttling DR Replication Traffic

Lucas Phelps
Level 5
Level 5

Hi all, I need some help.

I'm doing planning for a DR site that we are going to build at a data center.  Luckily, Internet bandwidth is very cheap and can get 100 Mb for $200.

We have a 25 Mb Internet connection at our headquarters (HQ) site and will be replicating over it to the Internet connection at the DR site all within a VPN tunnel from Cisco ASA to Cisco ASA.

               (25 Mb) HQ-----------------[Internet Cloud]-------------DR Site (100 Mb)

Are there any neat tricks or bandwidth throttling techniques I can use at my headquarters site to prevent the DR replication traffic from consuming the entire 25 Mb of Internet bandwidth I've got at the headquarters?   I don't want my users to be able to be affected by the replication traffic?

Thanks!

1 Accepted Solution

Accepted Solutions

Eugene Lau
Cisco Employee
Cisco Employee

Hey Lucas,

There's a few ways of doing it but overall, you could be looking at a QoS strategy.

CBWFQ is a good mechanism to manage congestion on the WAN during times of congestion.

eg.

- Restrict bandwidth for a class of traffic (DR traffic class)

- Allow usage of unused bandwidth when there is no contention

- prioritise classes of traffic to ensure critical traffic is always queued first.

Other things can be done within the DC etc so there's a lot of options. Have a squizz at the Enterprise QoS design giude for ideas.

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html

HTH

Eugene.

View solution in original post

6 Replies 6

Eugene Lau
Cisco Employee
Cisco Employee

Hey Lucas,

There's a few ways of doing it but overall, you could be looking at a QoS strategy.

CBWFQ is a good mechanism to manage congestion on the WAN during times of congestion.

eg.

- Restrict bandwidth for a class of traffic (DR traffic class)

- Allow usage of unused bandwidth when there is no contention

- prioritise classes of traffic to ensure critical traffic is always queued first.

Other things can be done within the DC etc so there's a lot of options. Have a squizz at the Enterprise QoS design giude for ideas.

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html

HTH

Eugene.

Hi, So you are terminating a VPN tunnel over the Internet between the ASAs?

If so I suggest you consult these two guides:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008080dfa7.shtml?referring_site=smartnavRD

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008084de0c.shtml

Please remember to rate all posts that are helpful.

gkuzmowycz
Level 1
Level 1

We do pretty much what you describe, with an ASA-to-ASA tunnel using policy m
aps on the ASA, like this:

class-map DR-QoS-class
description Qos to DR
match flow ip destination-address
match tunnel-group nnn.nnn.nnn.nnn

policy-map DR-QoS-policy
class DR-QoS-class
police output 5000000 20000

Lucas Phelps
Level 5
Level 5

Thanks for all of your suggestions.

A follow up question I might ask:  If I am using site-to-site VPN tunnels over Internet connections between my headquarters offices and branch offices, how much does QOS really help?

More than likely the Internet provider does not honor any QOS markings over the circuit, so what can be gained by doing QOS on the edge routers/switches?

I'm a newbie into the QOS realm, be easy on me

Hi,  I just did a quick test between a head office router and a remote branch router that are over the Internet via a VPN tunnel to to see if the QoS values are preserved. The tests involved the head office router pinging Branch A using two diffierent QoS markings, DSCP 0 and DSCP EF.

As you can see the QoS markings are being preserved by the tunnel.

Note that Netflow is enabled on the Branch A router.

See below fthe Netflow data from Branch A. No QoS markings have been applied to the ping packet as they leave the head office router.

Therefore the TOS marking of the ping packets are 0.


Branch_A#sh ip cache verbose flow | i W.X.Y.Z |SrcIf
SrcIf          SrcIPaddress    DstIf          DstIPaddress    Pr TOS Flgs  Pkts
Fa0            W.X.Y.Z          Local         A.B.C.D            01 00   10     39

See below if I do an extended ping from head office marking the packets with a TOS value of 184 (DSCP EF). 184 converts to a hex value of B8.

TOS data in Netflow is shown in hex values.


Branch_A#sh ip cache verbose flow | i W.X.Y.Z |SrcIf
SrcIf          SrcIPaddress    DstIf          DstIPaddress    Pr TOS Flgs  Pkts
Fa0            W.X.Y.Z           Local        A.B.C.D            01 B8  10      33

Please rememeber to rate all posts that are helpful.

You don't really care about preserving the QoS markings over the ISP's network, what you c

are about is the policing action on your egress interface. Since it's data replication traffic, it doesn't matter how it's prioritized over the link -- it gets there when it gets there.

Review Cisco Networking for a $25 gift card