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@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@gmail.com]
-- Andrey Khomyakov [khomyakov.andrey@gmail.com]
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@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@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@gmail.com]
-- Andrey Khomyakov [khomyakov.andrey@gmail.com]
I did try an extended ACL and had the same result. The way I know that it's not working is that I see these packets arriving on a wrong interface on the firewall and therefor being dropped. I actually had to open a CR with Cisco and they verified the config and said nothing is wrong with it. They are escalating and will hopefully get back to me about this. Andrey
Have you tried "set interface" instead of "set ip"? Sent from my iPhone On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov <khomyakov.andrey@gmail.com> wrote:
I did try an extended ACL and had the same result. The way I know that it's not working is that I see these packets arriving on a wrong interface on the firewall and therefor being dropped. I actually had to open a CR with Cisco and they verified the config and said nothing is wrong with it. They are escalating and will hopefully get back to me about this.
Andrey
I dont' think this will work. Here is the formal description of "set interface" from cisco.com: This action specifies that the packet is forwarded out of the local interface. The interface must be a Layer 3 interface (no switchports), and the destination address in the packet must lie within the IP network assigned to that interface. If the destination address for the packet does not lie within that network, the packet is dropped. Since in my case the packets are destined to random addresses on the webz, my understanding that this will effectively be a drop statement for them. But, no, I have not tried it. On Thu, Aug 12, 2010 at 3:25 PM, Rogelio <rgamino@gmail.com> wrote:
Have you tried "set interface" instead of "set ip"?
Sent from my iPhone
On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov <khomyakov.andrey@gmail.com> wrote:
I did try an extended ACL and had the same result. The way I know that it's not working is that I see these packets arriving on a wrong interface on the firewall and therefor being dropped. I actually had to open a CR with Cisco and they verified the config and said nothing is wrong with it. They are escalating and will hopefully get back to me about this.
Andrey
-- Andrey Khomyakov [khomyakov.andrey@gmail.com]
A 'debug ip policy' should show if it's hitting or not... IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, len 100,FIB flow policy match IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, len 100,FIB PR flow accelerated! IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, g=10.0.0.8, len 100, FIB policy routed On Thu, Aug 12, 2010 at 2:33 PM, Andrey Khomyakov < khomyakov.andrey@gmail.com> wrote:
I dont' think this will work. Here is the formal description of "set interface" from cisco.com:
This action specifies that the packet is forwarded out of the local interface. The interface must be a Layer 3 interface (no switchports), and the destination address in the packet must lie within the IP network assigned to that interface. If the destination address for the packet does not lie within that network, the packet is dropped.
Since in my case the packets are destined to random addresses on the webz, my understanding that this will effectively be a drop statement for them.
But, no, I have not tried it.
On Thu, Aug 12, 2010 at 3:25 PM, Rogelio <rgamino@gmail.com> wrote:
Have you tried "set interface" instead of "set ip"?
Sent from my iPhone
On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov < khomyakov.andrey@gmail.com> wrote:
I did try an extended ACL and had the same result. The way I know that it's not working is that I see these packets arriving on a wrong interface on the firewall and therefor being dropped. I actually had to open a CR with Cisco and they verified the config and said nothing is wrong with it. They are escalating and will hopefully get back to me about this.
Andrey
-- Andrey Khomyakov [khomyakov.andrey@gmail.com]
Hmmm... The reason I recommended that is because I think I remember reading somewhere that the "set ip" command does not work on point-to-point interfaces. The outbound interface in your config has a /30 assigned to it so maybe it is seeing it as a p-t-p interface? Do you have a "less preferred" route via that interface for the destination ip's? If not, I don't think your pbr will work either. Sent from my iPhone On Aug 12, 2010, at 3:33 PM, Andrey Khomyakov <khomyakov.andrey@gmail.com> wrote:
I dont' think this will work. Here is the formal description of "set interface" from cisco.com:
This action specifies that the packet is forwarded out of the local interface. The interface must be a Layer 3 interface (no switchports), and the destination address in the packet must lie within the IP network assigned to that interface. If the destination address for the packet does not lie within that network, the packet is dropped.
Since in my case the packets are destined to random addresses on the webz, my understanding that this will effectively be a drop statement for them.
But, no, I have not tried it.
On Thu, Aug 12, 2010 at 3:25 PM, Rogelio <rgamino@gmail.com> wrote:
Have you tried "set interface" instead of "set ip"?
Sent from my iPhone
On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov <khomyakov.andrey@gmail.com> wrote:
I did try an extended ACL and had the same result. The way I know that it's not working is that I see these packets arriving on a wrong interface on the firewall and therefor being dropped. I actually had to open a CR with Cisco and they verified the config and said nothing is wrong with it. They are escalating and will hopefully get back to me about this.
Andrey
-- Andrey Khomyakov [khomyakov.andrey@gmail.com]
participants (4)
-
Andrey Khomyakov -
Bill Fehring -
Jeffrey Pazahanick -
Rogelio