[Cisco IOS] Policy-map voor VPN ?

[Verwijderd]

Ik heb een Cisco 1700-serie router welke een VPN site-site verbinding heeft met een andere router. Dit werkt allemaal naar behoren. Ik wil nu graag een beetje prioriteit op de VPN tunnel zetten. Ik heb hiervoor de volgende policy-map aangemaakt:

code:

class-map match-any CosTraffic
match access-group 110
!
policy-map Cos1
  class CosTraffic
   priority percent 50
  class class-default
   fair-queue
...
access-list 110 permit ip any 192.168.1.0 0.0.0.255

Verkeer naar de 192.168.1.0-reeks moet voorrang krijgen op ander verkeer. Deze policy map heb ik aan de serial0 gehangen. Deze serial0 heeft een leased line verbinding (128kbit/s) met het internet.

code:

interface Serial0
 bandwidth 128
 ip address 1.2.3.4 255.255.255.252
 ip access-group 104 in
 crypto map cm-cryptomap
 service-policy output Cos1

Nu is het probleem dat verkeer naar de 192.168.1.0 niet herkent wordt. Een show policy-map interface serial0 geeft al het verkeer in de class-default weer. Niks komt in "CosTraffic".

Is dit de juiste manier bij het gebruik bij een site-site VPN? Ik kan me zo voorstellen dat dit misschien niet werkt omdat het verkeer niet echt naar dat subnet gaat vanuit de serial0. Het gaat via de tunnel.

Iemand tips?

[digibaro]

Je zal je policmap moeten bouwen op je tunnel encapsulation die waarschijnlijk IPSEC of GRE is.

[TrailBlazer]

In principe is het matchen op IP voldoende hoewel niet heel erg specifiek. Je zal echter geen verkeer richting 192.168.1.0 naar het internet routeren. Dat komt namelijk nooit aan omdat dit niet routeerbaar is. Je zal inderdaad moeten matchen op het tunnel endpoint. Eventueel kan je dan nog het GRE op IPSEC protocol specificeren in plaats van al het IP verkeer hoewel het geen kwaad kan.

Verder is je policy map ook niet handig. priority percent 50 maakt wel een priority class aan maar alles wat boven de 50% komt zal meteen gedropped worden. Je kan beter gewoon een gegarandeerd bandbreedte specificeren met het bandwith statement.

[Verwijderd]

Maar de vraag is: hoe krijg ik die policy-map op de tunnel? Hij moet van de serial0 af? Het is een IPSEC tunnel.

Of moet ik met qos pre-classify werken op de crypto map cm-cryptomap 1 ipsec-isakmp?

[TrailBlazer]

Je moet de acl zo aanpassen dat enkel ESP/AH verkeer tussen de twee endpoints binnen je prio klasse komt.

[Verwijderd]

TrailBlazer schreef op vrijdag 24 augustus 2007 @ 11:54:
Je moet de acl zo aanpassen dat enkel ESP/AH verkeer tussen de twee endpoints binnen je prio klasse komt.

Ik wil binnen de tunnel verkeer prioriteit geven. Er gaat bv ook verkeer overheen naar een ander subnet. Dit verkeer heeft geen prio. De vpn tunnel is het enige verkeer wat over de serial0 gaat. Ook internet gaat door de tunnel. Dus verkeer binnen de tunnel naar 192.168.1.* moet voorrang krijgen boven bv verkeer naar 192.168.2.* wat ook door dezelfde tunnel gaat.

[TrailBlazer]

Ok ik dacht dat je een VPN tunnel had en de rest ging gewoon direct het net op.
Je hebt wel een GRE tunnel geconfigureerd? DIt is namelijk de meest gebruikte methode. Dan kan je volgens mij gewoon een policymap op de tunnel interface zetten. Deze pakketten encapsuleer je dan weer binnen IPSec paketten. Anders wordt het lastig denk ik. Immers de queeing gebeurt op de uitgaande interface. Hoewel je inderdaad wel binnen bepaalde IP paketten eerst een precendce bit zou kunnen zetten. Dit kan dan weer gekopieerd worden naar de IPSec IP header

[ Voor 43% gewijzigd door TrailBlazer op 24-08-2007 12:17 ]

[Verwijderd]

Geen GRE. Wat is het voordeel daarvan?

Ik heb nu de qos pre-classify erbij gezet en nu werkt het.

Nog even over die "priority percent 50". Wanneer er geen ander verkeer is, zal het verkeer naar de 192.168.1.* niet 100% pakken van de bandbreedte?

Ik wil graag een minimale bandbreedte aangeven. Op deze manier lukt dat niet?

[TrailBlazer]

Nee met het priority statement geef je in een keer een gegarandeerde en maximum bandbreedte aan. Je kan wel gewoon een bandwith van 50% percent geven. Dan heb je gegarandeerd 50%en max 100%
Het voordeel van GRE is dat je IPSec config wat makkelijker wordt. Je ACL waarin je aangeeft welk verkeer je encrypt bevat dan enkel het GRE verkeer tussen de 2 endpoints.
Vervolgens wordt automatisch al het verkeer wat door die tunnel gaat, onafhankelijk van de source en destination, geencrypt. Zeker bij complexe netwerken waarin nog wel eens een mutatie zit mbt ip adressering zou je gek worden als je elke keer je ACL aan moet passen.