Mailing List Archive: Cisco: NSP

Re: 3560/3750 policy routing

Index | Next | Previous | View Threaded

peter at rathlev

Nov 2, 2009, 3:01 PM

Post #1 of 7 (252 views)
Permalink

Re: 3560/3750 policy routing

On Mon, 2009-11-02 at 17:21 -0500, Ryan West wrote:
> > We're using a couple of 3560s for PBR with no problems forwarding
> > 100 Mbps+. There's no CPU load from the forwarding itself. We
> > haven't tried actually pushing it yet but are planning to try
> > sometime soon.
> >
> > The 3560 needs the "routing" SDM template for this to work; I guess
> > the 3750 also needs this.
>
> What IOS version? I definitely had the proper SDM template applied, it
> won't work otherwise.

It has been running IOS 12.2(50)SE1 IP Services "all its life" (some
months).

When we started using it I was a little nervous if it would cope (and
posted on this list about it too) but it performs splendidly for us.

--
Peter

_______________________________________________
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/

tomas at soitron

Nov 2, 2009, 4:16 PM

Post #2 of 7 (242 views)
Permalink

Re: 3560/3750 policy routing [In reply to]

> -----Original Message-----
> From: cisco-nsp-bounces[at]puck.nether.net [mailto:cisco-nsp-
> bounces[at]puck.nether.net] On Behalf Of Peter Rathlev
> Sent: Tuesday, November 03, 2009 12:01 AM
> To: Ryan West
> Cc: cisco-nsp
> Subject: Re: [c-nsp] 3560/3750 policy routing
>
>
> It has been running IOS 12.2(50)SE1 IP Services "all its life" (some
> months).
>
> When we started using it I was a little nervous if it would cope (and
> posted on this list about it too) but it performs splendidly for us.
>

I second this, 12.2(50)SE3, doing some PBR-based VoIP spliting to
different SBCs, all done in HW.

Note that PBR on these platforms is very limited in supported route-map
match options, e.g. per cco:

********************
When configuring match criteria in a route map, follow these guidelines:

-Do not match ACLs that permit packets destined for a local address. PBR
would forward these packets, which could cause ping or Telnet failure or
route protocol flapping.

-Do not match ACLs with deny ACEs. Packets that match a deny ACE are
sent to the CPU, which could cause high CPU utilization.
********************

Did your matching ACLs meet the no-deny requirement?

--

deejay

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4565
(20091102) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk

_______________________________________________
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/

moua0100 at umn

Nov 2, 2009, 7:10 PM

Post #3 of 7 (240 views)
Permalink

Re: 3560/3750 policy routing [In reply to]

>> Note that PBR on these platforms is very limited in supported
route-map match options, e.g. per cco:

I concur; I can't seem to do anything beyond some basic match & set; the
IOS complained when I tried som SET commands with VRF parameters. I
suppose this is really a switch platform and not a true router platform.

Regards,
Ge Moua | Email: moua0100[at]umn.edu

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services

Daniska, Tomas wrote:
>> -----Original Message-----
>> From: cisco-nsp-bounces[at]puck.nether.net [mailto:cisco-nsp-
>> bounces[at]puck.nether.net] On Behalf Of Peter Rathlev
>> Sent: Tuesday, November 03, 2009 12:01 AM
>> To: Ryan West
>> Cc: cisco-nsp
>> Subject: Re: [c-nsp] 3560/3750 policy routing
>>
>>
>> It has been running IOS 12.2(50)SE1 IP Services "all its life" (some
>> months).
>>
>> When we started using it I was a little nervous if it would cope (and
>> posted on this list about it too) but it performs splendidly for us.
>>
>>
>
> I second this, 12.2(50)SE3, doing some PBR-based VoIP spliting to
> different SBCs, all done in HW.
>
>
> Note that PBR on these platforms is very limited in supported route-map
> match options, e.g. per cco:
>
> ********************
> When configuring match criteria in a route map, follow these guidelines:
>
> -Do not match ACLs that permit packets destined for a local address. PBR
> would forward these packets, which could cause ping or Telnet failure or
> route protocol flapping.
>
> -Do not match ACLs with deny ACEs. Packets that match a deny ACE are
> sent to the CPU, which could cause high CPU utilization.
> ********************
>
> Did your matching ACLs meet the no-deny requirement?
>
>
> --
>
> deejay
>
>
>
> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 4565
> (20091102) __________
>
> Tuto spravu preveril ESET NOD32 Antivirus.
>
> http://www.eset.sk
>
> _______________________________________________
> 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/
>
_______________________________________________
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/

adrian at creative

Nov 2, 2009, 7:35 PM

Post #4 of 7 (240 views)
Permalink

Re: 3560/3750 policy routing [In reply to]

Please read the Cisco 3750 IOS configuration guide. It specifically
states that PBR and VRF on the same interface is not permitted.

There is also apparently a PBR and fast-PBR mode which if i recall
does something akin to either software or hardware switching.
I'm not sure of the details. It is all in the IOS configuration
guide though!

2c,

Adrian

On Mon, Nov 02, 2009, Ge Moua wrote:
> >> Note that PBR on these platforms is very limited in supported
> route-map match options, e.g. per cco:
>
> I concur; I can't seem to do anything beyond some basic match & set; the
> IOS complained when I tried som SET commands with VRF parameters. I
> suppose this is really a switch platform and not a true router platform.
>
>
> Regards,
> Ge Moua | Email: moua0100[at]umn.edu
>
> Network Design Engineer
> University of Minnesota | Networking & Telecommunications Services
>
>
>
> Daniska, Tomas wrote:
> >>-----Original Message-----
> >>From: cisco-nsp-bounces[at]puck.nether.net [mailto:cisco-nsp-
> >>bounces[at]puck.nether.net] On Behalf Of Peter Rathlev
> >>Sent: Tuesday, November 03, 2009 12:01 AM
> >>To: Ryan West
> >>Cc: cisco-nsp
> >>Subject: Re: [c-nsp] 3560/3750 policy routing
> >>
> >>
> >>It has been running IOS 12.2(50)SE1 IP Services "all its life" (some
> >>months).
> >>
> >>When we started using it I was a little nervous if it would cope (and
> >>posted on this list about it too) but it performs splendidly for us.
> >>
> >>
> >
> >I second this, 12.2(50)SE3, doing some PBR-based VoIP spliting to
> >different SBCs, all done in HW.
> >
> >
> >Note that PBR on these platforms is very limited in supported route-map
> >match options, e.g. per cco:
> >
> >********************
> >When configuring match criteria in a route map, follow these guidelines:
> >
> >-Do not match ACLs that permit packets destined for a local address. PBR
> >would forward these packets, which could cause ping or Telnet failure or
> >route protocol flapping.
> >
> >-Do not match ACLs with deny ACEs. Packets that match a deny ACE are
> >sent to the CPU, which could cause high CPU utilization.
> >********************
> >
> >Did your matching ACLs meet the no-deny requirement?
> >
> >
> >--
> >
> >deejay
> >
> >
> >
> >__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4565
> >(20091102) __________
> >
> >Tuto spravu preveril ESET NOD32 Antivirus.
> >
> >http://www.eset.sk
> >
> >_______________________________________________
> >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/
> >
> _______________________________________________
> 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/

--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
_______________________________________________
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/

metaliza at nithia

Nov 2, 2009, 11:57 PM

Post #5 of 7 (228 views)
Permalink

Re: 3560/3750 policy routing [In reply to]

Peter Rathlev wrote:
> On Mon, 2009-11-02 at 17:21 -0500, Ryan West wrote:
>
>>> We're using a couple of 3560s for PBR with no problems forwarding
>>> 100 Mbps+. There's no CPU load from the forwarding itself. We
>>> haven't tried actually pushing it yet but are planning to try
>>> sometime soon.
>>>
>>> The 3560 needs the "routing" SDM template for this to work; I guess
>>> the 3750 also needs this.
>>>
>> What IOS version? I definitely had the proper SDM template applied, it
>> won't work otherwise.
>>
>
> It has been running IOS 12.2(50)SE1 IP Services "all its life" (some
> months).
>

Hi guys,

I have a similar problem:

We have been using PBR for forwarding through an IP-in-IP tunnel:

interface Tunnel0
ip address 192.168.1.2 255.255.255.252
tunnel source 147.32.98.1
tunnel destination 147.32.127.190
tunnel mode ipip

ip access-list extended private-2-hill
permit ip 10.13.0.0 0.0.255.255 147.32.112.0 0.0.15.255
permit ip 10.13.0.0 0.0.255.255 147.32.30.0 0.0.1.255
permit ip 10.13.0.0 0.0.255.255 147.32.99.0 0.0.0.255
!
route-map private-2-hill permit 10
match ip address private-2-hill
set interface Tunnel0
!
interface Vlan201
ip address 10.13.0.1 255.255.0.0
ip policy route-map private-2-hill
!
local policy route-map private-2-hill

This had been all functional on 3560 with 12.2(44)SE. At first there had
been set ip next-hop, but that hadn't worked, so I've switched to set
interface.

After replacement of IOS to 12.2(52)SE the "set interface" command was
refused after appliance of route map to an SVI. But local PBR still
worked. So I've changed to set ip next-hop (which has been accepted by
IOS) but with no effect in forwarding (but the local PBR still have
worked - because of the SW-based traffic?).

After some debugging I've realized that there is broken PBR in the
12.2(52)SE for the 3560.

Or am I wrong and have missed something?

--
-----------------------------------------------------------

Metaliza @ NitHiA
icq #: 63193671
skype: metaliza001

_______________________________________________
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/

ml at kenweb

Nov 3, 2009, 5:27 AM

Post #6 of 7 (222 views)
Permalink

Re: 3560/3750 policy routing [In reply to]

Metal�za wrote:
> Peter Rathlev wrote:
>> On Mon, 2009-11-02 at 17:21 -0500, Ryan West wrote:
>>>> We're using a couple of 3560s for PBR with no problems forwarding
>>>> 100 Mbps+. There's no CPU load from the forwarding itself. We
>>>> haven't tried actually pushing it yet but are planning to try
>>>> sometime soon.
>>>>
>>>> The 3560 needs the "routing" SDM template for this to work; I guess
>>>> the 3750 also needs this.
>>>>
>>> What IOS version? I definitely had the proper SDM template applied, it
>>> won't work otherwise.
>>>
>>
>> It has been running IOS 12.2(50)SE1 IP Services "all its life" (some
>> months).
>>
>
> Hi guys,
>
> I have a similar problem:
>
> We have been using PBR for forwarding through an IP-in-IP tunnel:
>
> interface Tunnel0
> ip address 192.168.1.2 255.255.255.252
> tunnel source 147.32.98.1
> tunnel destination 147.32.127.190
> tunnel mode ipip
>
> ip access-list extended private-2-hill
> permit ip 10.13.0.0 0.0.255.255 147.32.112.0 0.0.15.255
> permit ip 10.13.0.0 0.0.255.255 147.32.30.0 0.0.1.255
> permit ip 10.13.0.0 0.0.255.255 147.32.99.0 0.0.0.255
> !
> route-map private-2-hill permit 10
> match ip address private-2-hill
> set interface Tunnel0
> !
> interface Vlan201
> ip address 10.13.0.1 255.255.0.0
> ip policy route-map private-2-hill
> !
> local policy route-map private-2-hill
> This had been all functional on 3560 with 12.2(44)SE. At first there had
> been set ip next-hop, but that hadn't worked, so I've switched to set
> interface.
>
> After replacement of IOS to 12.2(52)SE the "set interface" command was
> refused after appliance of route map to an SVI. But local PBR still
> worked. So I've changed to set ip next-hop (which has been accepted by
> IOS) but with no effect in forwarding (but the local PBR still have
> worked - because of the SW-based traffic?).
>
> After some debugging I've realized that there is broken PBR in the
> 12.2(52)SE for the 3560.
>
> Or am I wrong and have missed something?
>

I had the same problem on an ME3400. I could not use the remote end of
a GRE tunnel for PBR.

_______________________________________________
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/

metaliza at nithia

Nov 17, 2009, 9:25 PM

Post #7 of 7 (89 views)
Permalink

Re: 3560/3750 policy routing [In reply to]

ML wrote:
> Metalíza wrote:
>> Peter Rathlev wrote:
>>> On Mon, 2009-11-02 at 17:21 -0500, Ryan West wrote:
>>>>> We're using a couple of 3560s for PBR with no problems forwarding
>>>>> 100 Mbps+. There's no CPU load from the forwarding itself. We
>>>>> haven't tried actually pushing it yet but are planning to try
>>>>> sometime soon.
>>>>>
>>>>> The 3560 needs the "routing" SDM template for this to work; I guess
>>>>> the 3750 also needs this.
>>>>>
>>>> What IOS version? I definitely had the proper SDM template applied, it
>>>> won't work otherwise.
>>>>
>>>
>>> It has been running IOS 12.2(50)SE1 IP Services "all its life" (some
>>> months).
>>>
>>
>> Hi guys,
>>
>> I have a similar problem:
>>
>> We have been using PBR for forwarding through an IP-in-IP tunnel:
>>
>> interface Tunnel0
>> ip address 192.168.1.2 255.255.255.252
>> tunnel source 147.32.98.1
>> tunnel destination 147.32.127.190
>> tunnel mode ipip
>>
>> ip access-list extended private-2-hill
>> permit ip 10.13.0.0 0.0.255.255 147.32.112.0 0.0.15.255
>> permit ip 10.13.0.0 0.0.255.255 147.32.30.0 0.0.1.255
>> permit ip 10.13.0.0 0.0.255.255 147.32.99.0 0.0.0.255
>> !
>> route-map private-2-hill permit 10
>> match ip address private-2-hill
>> set interface Tunnel0
>> !
>> interface Vlan201
>> ip address 10.13.0.1 255.255.0.0
>> ip policy route-map private-2-hill
>> !
>> local policy route-map private-2-hill
>> This had been all functional on 3560 with 12.2(44)SE. At first there
>> had been set ip next-hop, but that hadn't worked, so I've switched to
>> set interface.
>>
>> After replacement of IOS to 12.2(52)SE the "set interface" command
>> was refused after appliance of route map to an SVI. But local PBR
>> still worked. So I've changed to set ip next-hop (which has been
>> accepted by IOS) but with no effect in forwarding (but the local PBR
>> still have worked - because of the SW-based traffic?).
>>
>> After some debugging I've realized that there is broken PBR in the
>> 12.2(52)SE for the 3560.
>>
>> Or am I wrong and have missed something?
>>
>
> I had the same problem on an ME3400. I could not use the remote end
> of a GRE tunnel for PBR.

Finally I have solved it!

It's simple:-)

set ip next-hop 192.168.1.1 192.168.1.2

More generallly:

set ip next-hop <remote end-point> <local end-point>

--
-----------------------------------------------------------

Metaliza @ NitHiA
icq #: 63193671
skype: metaliza001

_______________________________________________
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/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com