[c-nsp] PBR two default gateway

Satish Patel satish.txt at gmail.com
Thu Jun 23 16:03:15 EDT 2016


Thank you so much, look like it's working.

On Thu, Jun 23, 2016 at 4:00 PM, Nick Cutting <ncutting at edgetg.com> wrote:
> Route map PBR counters have been broken for years in switches, probably
> because it is done in hardware.
>
> To get an accurate count you might need to send these packets to the CPU
> using no ip-route cache, disabling cef which should only every be done in a
> Lab or to catch a high cpu issue – not recommended ever in production.
>
>
>
> If you can, if this network is not in production – use debug ip policy to
> check each packet:
>
>
>
> This is an output using router generated traffic (local policy) but yours
> should be similar for “through the router traffic” (PBR applied to the
> incoming interface)
>
>
>
> IP: s=150.1.11.1 (local), d=8.8.8.8, len 100, policy match
>
> IP: route map PBR, item 10, permit
>
> IP: s=150.1.11.1 (local), d=8.8.8.8 (GigabitEthernet1.11), len 100, policy
> routed
>
> IP: local to GigabitEthernet1.11 150.1.11.7
>
> IP: s=150.1.11.1 (local), d=8.8.8.8, len 100, policy match
>
> IP: route map PBR, item 10, permit
>
> IP: s=150.1.11.1 (local), d=8.8.8.8 (GigabitEthernet1.11), len 100, policy
> routed
>
> IP: local to GigabitEthernet1.11 150.1.11.7
>
> IP: s=150.1.11.1 (local), d=8.8.8.8, len 100, policy match
>
> IP: route map PBR, item 10, permit
>
> IP: s=150.1.11.1 (local), d=8.8.8.8 (GigabitEthernet1.11), len 100, policy
> routed
>
> IP: local to GigabitEthernet1.11 150.1.11.7
>
> IP: s=150.1.11.1 (local), d=8.8.8.8, len 100, policy match
>
> IP: route map PBR, item 10, permit
>
> IP: s=150.1.11.1 (local), d=8.8.8.8 (GigabitEthernet1.11), len 100, policy
> routed
>
> IP: local to GigabitEthernet1.11 150.1.11.7
>
> IP: s=150.1.11.1 (local), d=8.8.8.8, len 100, policy match
>
> IP: route map PBR, item 10, permit
>
> IP: s=150.1.11.1 (local), d=8.8.8.8 (GigabitEthernet1.11), len 100, policy
> routed
>
> IP: local to GigabitEthernet1.11 150.1.11.7
>
>
>
> And here is traffic NOT being policy routed sourced from an another
> interface:
>
>
>
> IP: s=150.1.6.6 (local), d=8.8.8.8, len 100, policy rejected -- normal
> forwarding
>
> IP: s=150.1.6.6 (local), d=8.8.8.8, len 100, policy rejected -- normal
> forwarding
>
> IP: s=150.1.6.6 (local), d=8.8.8.8, len 100, policy rejected -- normal
> forwarding
>
> IP: s=150.1.6.6 (local), d=8.8.8.8, len 100, policy rejected -- normal
> forwarding
>
> IP: s=150.1.6.6 (local), d=8.8.8.8, len 100, policy rejected -- normal
> forwarding
>
>
>
>
>
> From: Satish Patel [mailto:satish.txt at gmail.com]
> Sent: Thursday, June 23, 2016 3:22 PM
> To: Nick Cutting
> Cc: Cisco Network Service Providers
>
>
> Subject: Re: [c-nsp] PBR two default gateway
>
>
>
> I applied policy without ACL and i see following command and see
> counter increased but after few second it stopped, what does that
> means?
>
> Does my policy work and because of Hardware base PBR it is not showing
> counter?
>
> R1#show route-map
> route-map FOO, permit, sequence 10
> Match clauses:
> Set clauses:
> ip next-hop xx.xxx.xxx.xxx
> Policy routing matches: 149 packets, 22718 bytes
>
> On Thu, Jun 23, 2016 at 3:12 PM, Nick Cutting <ncutting at edgetg.com> wrote:
>> The “match interface” route-map sub command command is for routing policy,
>> it will not work with PBR
>>
>>
>>
>> Many route map match entries will be accepted in the command interpreter,
>> but they will not work for the job you want the route-map to do.
>>
>> The same is true of various entries for IGP vs EGP protocols, when using
>> route-maps for routing policy.
>>
>>
>>
>> Just set the ACL to:
>>
>>
>>
>> ip access-list extended ACl-PBR-MATCH-ANY
>>
>> permit ip any any
>>
>>
>>
>>
>>
>>
>>
>> From: Satish Patel [mailto:satish.txt at gmail.com]
>> Sent: Thursday, June 23, 2016 2:24 PM
>> To: Nick Cutting; Cisco Network Service Providers
>> Subject: Re: [c-nsp] PBR two default gateway
>>
>>
>>
>> Why do i need ACL if i want to match all IPs behind same interface
>> like f0/1? I want to route any traffic coming from interface f0/1.
>>
>> On Thu, Jun 23, 2016 at 2:21 PM, Nick Cutting <ncutting at edgetg.com> wrote:
>>> You need to match the traffic of the source and destination, in an ACL in
>>> the route-map.
>>> Yours probably being :
>>>
>>> ACL-PBR-SUBNET-A
>>> Permit XX.xx.xx.xx 0.0.0.255 any
>>>
>>> route-map FOO permit 10
>>> match ip address ACL-PBR-SUBNET-A
>>> set ip next-hop x.x.x.x
>>>
>>> then "debug ip policy" to watch it firing, or not firing (if this is not
>>> in production yet)
>>>
>>> You must test from behind the router - from a host on the subnet ) - as
>>> self-generated traffic requires another type of PBR (local policy)
>>>
>>>
>>> -----Original Message-----
>>> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
>>> Satish Patel
>>> Sent: Thursday, June 23, 2016 1:46 PM
>>> To: Cisco Network Service Providers
>>> Subject: [c-nsp] PBR two default gateway
>>>
>>> I have router with two subnet A & B connected on related physical
>>> interface. and we have two ISP link so i want to send subnet A to ISP-A
>>> and
>>> subnet B to ISP-B.
>>>
>>> is it enough if i do this or do i need to use match interface F1/1?
>>> Because i want to do whatever coming from my source interface go to ISP-A
>>> and rest will use ip route 0.0.0.0 0.0.0.0 ISP-B
>>>
>>> !
>>> interface FastEthernet1/1
>>> description subnet-A
>>> ip address x.x.x.x 255.255.255.0
>>> ip policy route-map FOO
>>> !
>>> !
>>> route-map FOO permit 10
>>> set ip next-hop x.x.x.x
>>> !
>>> _______________________________________________
>>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>
>


More information about the cisco-nsp mailing list