Cisco IP SLA met Route MAP

[battler]

Ik gebruik route-maps om te bepalen welke data via welke route naar buiten mag. De route-maps bepalen op basis van IP SLA of de interfaces ook daadwerkelijk Up and Running zijn.

Nu wil ik switchen van IP SLA met ICMP naar IP SLA met een HTTP Get request. De ACL daarentegen die gehit moet worden op basis van de IP SLA laat geen hits zien. Cisco TAC case duurt erg lang en ik begin me af te vragen of iemand dit voormekaar heeft gekregen.

Twee verschillende IP-SLA (met source-ip en zonder).

code:

ip sla 1
 http get http://145.100.104.131 source-ip 10.0.201.188 source-port 60000 cache disable
 threshold 500
 timeout 1000
ip sla 2
 http get http://145.100.104.131 source-port 60001 cache disable
 threshold 500
 timeout 1000
ip sla schedule 2 life forever start-time now

De bijbehorende route map

code:

route-map LOCAL_POLICY permit 10
 match ip address HTTP-60000
 set ip next-hop 10.0.201.6
!
route-map LOCAL_POLICY permit 20
 match ip address HTTP-60001
 set ip next-hop 10.0.220.6
!

Twee verschillende ACLs (met dest. host en met source port).

code:

ip access-list extended HTTP-60000
 permit ip any host 145.100.104.131
ip access-list extended HTTP-60001
 permit tcp any eq 60001 any

Route-maps op de interface

code:

interface GigabitEthernet0/1
ip address 10.0.201.188 255.255.255.0
ip virtual-reassembly in
ip policy route-map LOCAL_POLICY

R1#sh run int Gi0/2
interface GigabitEthernet0/2
ip address 10.0.220.69 255.255.255.0
ip policy route-map LOCAL_POLICY

Dan is er nog een ip local policy waarvan ik heb gelezen dat ik die moet aanmaken als het zelf gegeneerde traffic betreft:

code:

ip local policy route-map LOCAL_POLICY

Hoevaak worden de ACLs gehit? Die 5 matches is een ICMP test die ik heb geprobeerd.

code:

R1#show ip access-lists 
Extended IP access list HTTP-60000
    10 permit ip any host 145.100.104.131 (5 matches)
Extended IP access list HTTP-60001
    10 permit tcp any eq 60001 any (1 match)

Wat debug informatie dat hij daadwerkelijk data verstuurd:

code:

Jan 31 15:43:55.061: IPSLA-OPER_TRACE:OPER:2 Dest: 145.100.104.131, Source address - 10.0.201.188
Jan 31 15:43:55.061: IPSLA-OPER_TRACE:OPER:2 DNS ok:Socket setup & register XDM, http=0x316FE404
Jan 31 15:43:55.061: IPSLA-OPER_TRACE:OPER:2 slaSocketConnect return =265
Jan 31 15:43:56.061: IPSLA-OPER_TRACE:OPER:2 Wait connection - timeout event
Jan 31 15:43:56.061: IPSLA-INFRA_TRACE:OPER:2 Updating result
Jan 31 15:44:55.061: IPSLA-INFRA_TRACE:OPER:2 slaSchedulerEventWakeup
Jan 31 15:44:55.061: IPSLA-INFRA_TRACE:OPER:2 Starting an operation
Jan 31 15:44:55.061: IPSLA-OPER_TRACE:OPER:2 Starting http operation
Jan 31 15:44:55.061: IPSLA-OPER_TRACE:OPER:2 Dest: 145.100.104.131, Source address - 10.0.201.188
Jan 31 15:44:55.061: IPSLA-OPER_TRACE:OPER:2 DNS ok:Socket setup & register XDM, http=0x316FE404
Jan 31 15:44:55.061: IPSLA-OPER_TRACE:OPER:2 slaSocketConnect return =265
Jan 31 15:44:56.061: IPSLA-OPER_TRACE:OPER:2 Wait connection - timeout event

Geen default route, dus geen Route-map is geen data naar buiten

code:

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
S        10.0.0.0/8 [1/0] via 10.0.201.6
C        10.0.201.0/24 is directly connected, GigabitEthernet0/1
L        10.0.201.188/32 is directly connected, GigabitEthernet0/1
C        10.0.220.0/24 is directly connected, GigabitEthernet0/2
L        10.0.220.69/32 is directly connected, GigabitEthernet0/2

De HTTP-get gaat naar een eigen webserver, een tcpdump aan die kant laat ook geen inkomende http requests zien.

Volgens mij is dit gewoon een bug of kan/hoort dit niet te werken, maar heb al drie verschillende TAC engineers gehad die er allemaal een paar keer naar kijken.

[ Voor 6% gewijzigd door battler op 31-01-2014 18:24 . Reden: update met info plizz ]

[plizz]

Je mist nog een deel van Pocily-Based Routing configuratie. Je moet nog de route-map (Policy) aan de interface koppelen waar de pakketjes binnenkomt. Ik zie alleen twee exit interface. Maar op welke interface komt de HTTP verkeer binnen? Op die interface zet je "ip policy route-map LOCAL_POLICY". De router routeert dan het pakketjes naar de juiste exit interface volgens de route-map.

[battler]

@plizz: Bedankt voor je oplettendheid, ik heb de post geupdate. Het is alleen niet zeker aan welke interface ik de route-map moet toekennen het is tenslotte zelf gegeneerde data.

[plizz]

Als ik op internet leest moet je "ip policy route-map LOCAL_POLICY" uit de interface Gi0/1 en Gi0/2 configuratie halen. Met commando "show ip policy" zie je de policy actief is op interface local.

code:

router#show ip policy
Interface      Route map
local          LOCAL_POLICY

Je IP sla 1 is nog niet actief, omdat je "ip sla schedule 1 life forever" mist. Klopt het? Of hoort het zo. De commando "show ip sla statistics" zie je de IP sla's actief zijn.

[battler]

Ik heb de route-map policy uit de interfaces gehaald. De eerste SLA was inderdaad niet gestart, deze draait nu weer.

code:

R1#sh ip policy
Interface Route map
local LOCAL_POLICY

Maar nog steeds worden de ACLs niet gehit

code:

R1#sh ip access
Extended IP access list HTTP-60000
10 permit ip any host 145.100.104.131 (5 matches)
Extended IP access list HTTP-60001
10 permit tcp any eq 60001 any (1 match)

Doordat de ACL niet hit wordt ook de next-hop niet geset. Met als gevolg de HTTP-get nooit naar buiten gaat (er is geen default route).

code:

R1#undebug all
All possible debugging has been turned off
R1#sh route-map
route-map LOCAL_POLICY, permit, sequence 10
Match clauses:
ip address (access-lists): HTTP-60000
Set clauses:
ip next-hop 10.0.201.6
Policy routing matches: 0 packets, 0 bytes
route-map LOCAL_POLICY, permit, sequence 20
Match clauses:
ip address (access-lists): HTTP-60001
Set clauses:
ip next-hop 10.0.220.6
Policy routing matches: 0 packets, 0 bytes

Daarentegen als ik een ping stuur dan hit de juiste ACL wel en werkt alles perfect.

[ Voor 3% gewijzigd door battler op 01-02-2014 00:06 ]

[pablo_p]

Is het niet zo dat je een bestaande (floating) route nodig hebt voor je destination. Dat zou bv een route met een AD van >200 kunnen zijn, zodat hij een lage prioriteit heeft, en destination null0 oid. Het kan zijn dat hij eerst wil dat iets gerouteerd kán worden (een next-hop heeft) voordat het je het met een route-map kan manipuleren.

Als je daarna statische routes injecteert met een lagere AD heb je daar toch geen last van. Uitgaande dat de routes die je daarna dmv een track activeert dezelfde mask hebben. Eventueel injecteer je dan een default én een host route.

ip route 145.100.104.131 255.255.255.255 null0 250

Als je als destination 1 van de next-hops neemt, kan je je route-map halveren, maar ik vind het duidelijker als je het zo expliciet maakt.

Ik geef geen garantie dat het werkt, maar het is het proberen waard.

[battler]

Zowel Pablo_P als plizz ontzettend bedankt! De null route werkte, hij moet dus uberhaupt iets kunnen routeren voordat hij dat gaat doen.

Nogmaals bedankt.