Policy Based Routing advice
Bill Fehring
lists at billfehring.com
Thu Aug 12 19:10:07 UTC 2010
Andrey,
It looks like you're doing everything right here so this might seem
like a dumb question, but how sure are you that it's not working?
In my experience on the 4500, 6500, 3560/3750, those ACL/route-map
counters sometimes don't work because of CEF and friends, and at best
they count number of flows that matched the ACL, if even that. Before
knowing this, once upon a time I was absolutely convinced that my
policy routing wasn't working and it turns out that no, the counters
had fooled me. Perhaps try a SPAN session on g2/14 and see whether or
not the packets you expect are exiting that interface, or watch the
interface counters.
HTH,
Bill
On Thu, Aug 12, 2010 at 11:16, Andrey Khomyakov
<khomyakov.andrey at gmail.com> wrote:
> I bit more explanation: 172.25/16 is a hop away and the packets with that
> source IP will enter on Gi2/6 and need to exit Gi2/14.
> So it goes like that:
>
> 172.25/16 is vlan25 on the student router
> Gi0/1 has ip address 192.168.250.2 on the student router
> default route is towards 192.168.250.1 on the student router
>
>
>
>> On Thu, Aug 12, 2010 at 11:54 AM, Andrey Khomyakov <
>> khomyakov.andrey at gmail.com> wrote:
>>
>>> Hey all. I'm trying to setup a routing policy on a cat4503-E with Sup6-E
>>> and
>>> for some reason I can't see it taking effect. I'm definitely sourcing
>>> packets from 172.25.0.0/16 (the test machine had 172.25.24.25 address).
>>> For
>>> some reason the packets still go out towards the default gateway instead
>>> of
>>> what's specified in the route-map. The switch is running
>>> cat4500e-ENTSERVICESK9-M), Version 12.2(52)SG, RELEASE SOFTWARE (fc1)
>>> According to stats on the ACL and the route-map it's just not being hit
>>> for
>>> some reason. Applying the ACL directly to the interface (as an
>>> access-group)
>>> shows that the ACL is correct and I see hits, however, via the route map
>>> it's not being hit. I don't know what those "2 matches" are, but there
>>> definitely should be a lot more than 2. And in addition, I see the packets
>>> arriving on the firewall that is the "default gateway".
>>>
>>> Does anyone have any tips on why this might now work?
>>>
>>>
>>> ip access-list standard acl_Students
>>> permit 172.25.0.0 0.0.255.255
>>>
>>> route-map Students-Route-Map permit 10
>>> match ip address acl_Students
>>> set ip next-hop 192.168.168.22
>>>
>>> interface GigabitEthernet2/6
>>> no switchport
>>> ip address 192.168.250.1 255.255.255.252
>>> ip pim dense-mode
>>> ip policy route-map Students-Route-Map
>>>
>>> interface GigabitEthernet2/14
>>> no switchport
>>> ip address 192.168.168.21 255.255.255.252
>>> no ip redirects
>>> no ip mroute-cache
>>> flowcontrol send desired
>>>
>>> cat4503#sh access-lists acl_Students
>>> Standard IP access list acl_Students
>>> 10 permit 172.25.0.0, wildcard bits 0.0.255.255 (2 matches)
>>>
>>>
>>> cat4503#sh route-map
>>> route-map Students-Route-Map, permit, sequence 10
>>> Match clauses:
>>> ip address (access-lists): acl_Students
>>> Set clauses:
>>> ip next-hop 192.168.168.22
>>> Policy routing matches: 2 packets, 180 bytes
>>>
>>> cat4503#sh ip route 0.0.0.0
>>> Routing entry for 0.0.0.0/0, supernet
>>> Known via "static", distance 1, metric 0, candidate default path
>>> Redistributing via eigrp 179
>>> Advertised by eigrp 179
>>> Routing Descriptor Blocks:
>>> * 192.168.168.10
>>> Route metric is 0, traffic share count is 1
>>>
>>> --
>>> Andrey Khomyakov
>>> [khomyakov.andrey at gmail.com]
>>>
>>
>>
>
>
>
> --
> Andrey Khomyakov
> [khomyakov.andrey at gmail.com]
>
More information about the NANOG
mailing list