IOS 2801 QoS and VPN

[Deepseadata]

Hey there,

Sorry. I've been reading and reading but I guess I'm doing an uncommon scenario.

I have a slow (256k) wan link. I need to push all WAN users aside when I dial in with my VPN client to do maint.

Can anyone give me some QoS options?

The other QoS needs I have are that I have a few vLAN's but I need to give one vlan all/most of the WAN bandwidth and push aside the other vlan traffic.

Have any tricks up your sleeve?

[Deepseadata]

class-map match-all crewdata

match access-group name crewdata

class-map match-all ownerdata

match access-group name ownerdata

!

!

policy-map QoS

class ownerdata

bandwidth remaining percent 99

class crewdata

bandwidth remaining percent 1

!

!

!

!

!

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

!

crypto ipsec profile madsummer_Profile1

set transform-set ESP-3DES-SHA

set isakmp-profile madsummer-ike-profile-1

!

!

!

!

!

interface Loopback0

ip address 255.255.255.255

!

interface FastEthernet0/0

no ip address

shutdown

duplex auto

speed auto

!

interface FastEthernet0/1

description Starboard Stratos VSAT$FW_OUTSIDE$

ip address 10.20.46.20 255.255.255.0

ip nat outside

ip virtual-reassembly

no ip mroute-cache

speed 100

full-duplex

service-policy output QoS

!

interface FastEthernet0/3/0

!

interface FastEthernet0/3/1

!

interface FastEthernet0/3/2

!

interface FastEthernet0/3/3

!

interface Virtual-Template1 type tunnel

ip unnumbered Loopback0

tunnel mode ipsec ipv4

tunnel protection ipsec profile madsummer_Profile1

!

interface Vlan1

description $FW_INSIDE$

ip address 192.168.49.1 255.255.255.0

ip nat inside

ip virtual-reassembly

!

!

!

ip http server

ip http authentication local

ip http secure-server

ip http timeout-policy idle 600 life 86400 requests 10000

ip nat pool madsummer_INTERNET 10.20.46.20 10.20.46.20 netmask 255.255.255.0

ip nat inside source list 1 pool madsummer_INTERNET overload

!

ip access-list extended crewdata

remark match crewdata source sebnet address

permit ip 192.168.54.0 0.0.0.255 any

remark match crewdata destination subnet address

permit ip any 192.168.54.0 0.0.0.255

ip access-list extended ownerdata

permit ip 192.168.51.0 0.0.0.255 any

remark match ownerdata source subnet address

remark match ownerdata destination subnet address

permit ip any 192.168.51.0 0.0.0.255

!

access-list 1 permit 192.168.0.0 0.0.255.255

The LAN's that are heading for the internet are:

192.168.54.0 (crewdata)

192.168.51.0 (ownerdata)

[Joseph W. Doherty]

You didn't apply the nested policy which includes the shaper. Without it, policy will only be effective when the Ethernet interface is congested (at either 10 or 100 Mbps) when we want it to manage 256 Kbps. See my prior post on what to do.

Second, didn't realise NAT was involved. This might impact policy, I don't recall order of operations. ACLs might not be seeing internal addresses, but instead see NAT addresses. This might account for lack of matches on outbound interface.

Not 100% what you do when NAT is active. I'm pretty sure we can mark outbound packets before they're NAT'ed, and then treat traffic on markings, but there might be a better method.

I'm pressed for time at the moment, won't be able to look again at this until tonight.

In the mean time, you might try just:

policy-map tmp

class class-default

shape average 225000

interface FastEthernet0/1

service-policy outbound tmp

[Deepseadata]

Hey! Thanks for lookin on a Sunday.

I'll give it a try and let you know what happens.

Have a nice day, Joe.