[c-nsp] Sup1a MSFC2 Policy Based Routing

[Jason Ford]

Rudy,

Find my findings within..

Thank you for getting back to me as this problem is starting to be a 
major pain for our team.

Rudy Setiawan wrote:
> Hi Jason, 
>
> try this out modify the access-list using from a bigger prefixes such as /24
> -> /25 then so on until you hit the targets. (Just want to check pattern
> matching).
>
>   
I tried to put in the mask as 0.0.0.255 (or a /24) and it still doesn't 
match the packets correctly. Clearly this is the break down in the system..
> I don't see why the pattern would not match your access-list.
> Can you do a show ip route 1.1.1.0/28?
>   
Routing entry for 1.1.1.0/28
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via FastEthernet3/8
      Route metric is 0, traffic share count is 1

> Is that particular route-map applied to any interface other than the f3/0?
> And f3/0 has only that particular block (1.1.1.0/28) or it has secondaries?
>   
The route-map is only on int f 3/8 an no where else. Yes, f 3/8 has that 
block only on the interface and it does not have secondaries.
> If it's easier what you can do is to make that route-map dedicated to that
> specific interface (this will work if you do not have secondaries attach to
> that particular interface).
>
> So your route-map will look something like this:
>
> Route-map peer-out permit 10
> Set ip next-hop <next gateway>
>
> That route-map will see... I will forward any to that <next gateway> ...
> this will match everything and 1.1.1.0/28 will be routed to that <next
> gateway>
>
> The above is just a workaround.
>
>   
I would rather not do this but I see your point that it shouldn't 
matter. I was simply going to deny all of my local subnets from the 
access list so that all traffic (even if it was sent to other servers or 
clients on our core network) isn't forwarded out to another ISP to be 
rerouted back into our network. I will give this a try and reply later 
tonight with some results. It still doesn't make sense why the 
access-list isn't matching the traffic.
> Regards,
> Rudy
>
>
>   
Oddly enough it seems that the access-lists are broken. I don't quite 
understand why they wouldn't work in this case and seems to be the root 
of the problem here.
> ------------------------------
>
> Message: 4
> Date: Tue, 26 Dec 2006 23:42:53 -0500
> From: Jason Ford <jason at chatinara.com>
> Subject: Re: [c-nsp] Sup1a MSFC2 Policy Based Routing
> To: Rudy Setiawan <rudy at rudal.com>
> Cc: cisco-nsp at puck.nether.net
> Message-ID: <4591F9CD.1080800 at chatinara.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Rudy,
>
> It appears you got the issue. On the match permit 20, I see the packets 
> increase and the route-map must be working. Now how do we explain the 
> fact that the access-list isn't getting matched when I am trying to get 
> the source addresses directly attached to that port defined to any host? 
> It seems that:
>
> access-list 180 permit ip 1.1.1.0 0.0.0.15 any
>
> should get all of the ip addresses that flow from the severs to the 6500 
> then be routed out the next-hop I define.
>
> Seems you have identified where exactly the problem is however doesn't 
> explain why the packets aren't getting picked up.
>
> jason
>
>
>
>