Policy Based Routing advice

Bill Fehring lists at billfehring.com
Thu Aug 12 14:10:07 CDT 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