[c-nsp] PBR or ABF on XR for 12000 series
Hello all, I have a need to be able to do policy based routing for next hop set, but can't find anything that works in XR. We presently are doing this with VRFs but need to move away from the VRFs because this causes the ipv6_io to crash over and over when doing this for IPv6 traffic. Are there any options on the 12000 besides the VRFs? This is on a 12410 chassis. LC/0/2/CPU0:Feb 15 13:23:18.287 : dumper[52]: %OS-DUMPER-7-DUMP_REQUEST : Dump request for process pkg/bin/ipv6_io LC/0/2/CPU0:Feb 15 13:23:18.300 : dumper[52]: %OS-DUMPER-7-DUMP_ATTRIBUTE : Dump request with attribute 7 for process pkg/bin/ipv6_io LC/0/2/CPU0:Feb 15 13:23:18.306 : dumper[52]: %OS-DUMPER-4-SIGSEGV : Thread 4 received SIGSEGV - Segmentation Fault LC/0/2/CPU0:Feb 15 13:23:18.306 : dumper[52]: %OS-DUMPER-4-SIGSEGV_INFO : Accessed BadAddr 0x7c479003 at PC 0x7831e254. Signal code 1 - SEGV_MAPPER. Address not mapped. LC/0/2/CPU0:Feb 15 13:23:18.306 : dumper[52]: %OS-DUMPER-4-CRASH_INFO : Crashed pid = 6045792 (pkg/bin/ipv6_io) Thank in advance, -Lee ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR advice
You should think about maybe using local policy routing for an IP sla that checks the availability, that plugs into the through traffic (normal) policy routing for the availability. Policy route each tracked IP out the correct upstream next hop. You don't want locally sourced IP SLA traffic using the normal routing table after a failure, unless what your are testing for in the IP SLA is only reachable via one of the providers. Track IP SLA, local policy routed Normal PBR using the availability of the policy routed Track -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Hefin James [ahj] Sent: Thursday, November 3, 2016 12:33 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] PBR advice We are just about to get an additional routed internet link that we intend to setup as active/active with failover with our current link, and split the traffic using PBR. We will be terminating the links internally (after firewalling, etc) in a VSS chassis which will see 2 default routes of equal cost. I've setup a lab that I can test PBR that uses the 'set ip default next-hop' settings so that local routing continues to work as currently set. However, the problem arises when if we get a failure which isn't local (Say 2 routers away). I can track the availability of 2 IP address that's deep inside our providers network, but I can only apply tracking to 'set ip next-hop' and not 'set ip default next-hop verify-availability' Is there any other way of doing this or am I stuck with using 'set ip next-hop verify-availability' and have an ACL that excludes all locally routed traffic? Thanks, Hefin ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR advice
We are just about to get an additional routed internet link that we intend to setup as active/active with failover with our current link, and split the traffic using PBR. We will be terminating the links internally (after firewalling, etc) in a VSS chassis which will see 2 default routes of equal cost. I've setup a lab that I can test PBR that uses the 'set ip default next-hop' settings so that local routing continues to work as currently set. However, the problem arises when if we get a failure which isn't local (Say 2 routers away). I can track the availability of 2 IP address that's deep inside our providers network, but I can only apply tracking to 'set ip next-hop' and not 'set ip default next-hop verify-availability' Is there any other way of doing this or am I stuck with using 'set ip next-hop verify-availability' and have an ACL that excludes all locally routed traffic? Thanks, Hefin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR two default gateway
There is one use case where PBR is useful and not much else will work. This is specific to monitoring. Where you want a specific IP to only use a specific carrier for egress. This usually involve getting a block from that carrier and then using PBR to ensure that ip segment gets routed out the specified carrier. This is a very narrow use case and generally other routing methods are preferred for practically anything else. This is the only use case where I would recommend PBR. Another very critical thing to note is that PBR will cause a ACL explosions under some circumstance. This can cause the router to crash. Mack McBride | Senior Network Architect | ViaWest, Inc. O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Cutting Sent: Thursday, June 23, 2016 3:06 PM To: Paul; Satish Patel; Cisco Network Service Providers Subject: Re: [c-nsp] PBR two default gateway The old saying goes, if you have to implement PBR, either you need more money (BGP), or your design is wrong (use VRFs) -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Sent: Thursday, June 23, 2016 4:31 PM To: Satish Patel; Cisco Network Service Providers Subject: Re: [c-nsp] PBR two default gateway PBR is a huge PITA, I prefer using VRF and leaking between the VRF's to adjust what i want. it's much safer than PBR imo :) On 6/23/2016 1:46 PM, Satish Patel wrote: > 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@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ This message contains information that may be confidential, privileged or otherwise protected by law from disclosure. It is intended for the exclusive use of the addressee(s). Unless you are the addressee or authorized agent of the addressee, you may not review, copy, distribute or disclose to anyone the message or any information contained within. If you have received this message in error, please contact the sender by electronic reply and immediately delete all copies of the message. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR two default gateway
The old saying goes, if you have to implement PBR, either you need more money (BGP), or your design is wrong (use VRFs) -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Sent: Thursday, June 23, 2016 4:31 PM To: Satish Patel; Cisco Network Service Providers Subject: Re: [c-nsp] PBR two default gateway PBR is a huge PITA, I prefer using VRF and leaking between the VRF's to adjust what i want. it's much safer than PBR imo :) On 6/23/2016 1:46 PM, Satish Patel wrote: > 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@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR two default gateway
PBR is a huge PITA, I prefer using VRF and leaking between the VRF's to adjust what i want. it's much safer than PBR imo :) On 6/23/2016 1:46 PM, Satish Patel wrote: 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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR two default gateway
Thank you so much, look like it's working. On Thu, Jun 23, 2016 at 4:00 PM, Nick Cutting <ncutt...@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@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 <ncutt...@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@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 <ncutt...@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 addre
Re: [c-nsp] PBR two default gateway
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@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 <ncutt...@edgetg.com><mailto:ncutt...@edgetg.com%3e> 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@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 > <ncutt...@edgetg.com><mailto:ncutt...@edgetg.com%3e> 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-boun...@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
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 <ncutt...@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@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 <ncutt...@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-boun...@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR two default gateway
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@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 <ncutt...@edgetg.com><mailto:ncutt...@edgetg.com%3e> 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-boun...@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@puck.nether.net<mailto:cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
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 <ncutt...@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-boun...@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR two default gateway
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-boun...@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR Limits for Nexus 7k
I was doing some research and found the Nexus listed a limit of 23 entries for PBR. I have some situations that require source based routing for more than that many pairings(more like 200-300). Does this mean I will need to look for a solution other than a Nexus 7k or am I misunderstanding what this limit means? The datasheet I found it here http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/verified_scalability/b_Cisco_Nexus_7000_Series_NX-OS_Verified_Scalability_Guide.html#reference_DF4FD746AB1145838991CE0BDE9DE621 -- Brian Christopher Raaen Network Architect Zcorum ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR Limits for Nexus 7k
Hi Brian, please see inline below: At 09:06 AM 2/3/2015 Tuesday, Brian Christopher Raaen quipped: I was doing some research and found the Nexus listed a limit of 23 entries for PBR. This is a limit on number of PBR route-map sequences. Each sequence can have a match statement pointing to an ACL of arbitrary size. I have some situations that require source based routing for more than that many pairings(more like 200-300). This limitation would essentially restrict you to 23 unique sets of next-hops (ie, each sequence can set 1 or more next-hops) for each set of match criteria (ACL). Let me know if you have any questions. Thanks, Tim Does this mean I will need to look for a solution other than a Nexus 7k or am I misunderstanding what this limit means? The datasheet I found it here http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/verified_scalability/b_Cisco_Nexus_7000_Series_NX-OS_Verified_Scalability_Guide.html#reference_DF4FD746AB1145838991CE0BDE9DE621 -- Brian Christopher Raaen Network Architect Zcorum ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Distinguished Engineer, Technical Marketing Data Center Switching Cisco - http://www.cisco.com +1(408)526-6759 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR Limits for Nexus 7k
At 10:17 AM 2/3/2015 Tuesday, Tim Stevenson quipped: Hi Brian, please see inline below: At 09:06 AM 2/3/2015 Tuesday, Brian Christopher Raaen quipped: I was doing some research and found the Nexus listed a limit of 23 entries for PBR. This is a limit on number of PBR route-map sequences. Each sequence can have a match statement pointing to an ACL of arbitrary size. I have some situations that require source based routing for more than that many pairings(more like 200-300). This limitation would essentially restrict you to 23 unique sets of next-hops (ie, each sequence can set 1 or more next-hops) for each set of match criteria (ACL). Let me clarify/reword that: This limitation would essentially restrict you to 23 unique sets of next-hops (ie, each sequence can set 1 or more next-hops), each with its own set of match criteria (ACL). Thanks, Tim Let me know if you have any questions. Thanks, Tim Does this mean I will need to look for a solution other than a Nexus 7k or am I misunderstanding what this limit means? The datasheet I found it here http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/verified_scalability/b_Cisco_Nexus_7000_Series_NX-OS_Verified_Scalability_Guide.html#reference_DF4FD746AB1145838991CE0BDE9DE621 -- Brian Christopher Raaen Network Architect Zcorum ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Distinguished Engineer, Technical Marketing Data Center Switching Cisco - http://www.cisco.com +1(408)526-6759 Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Distinguished Engineer, Technical Marketing Data Center Switching Cisco - http://www.cisco.com +1(408)526-6759 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR on sup720
Hi Arie, i heard there should depend on which ios version and which kind of configirations u use will impact the action about hw or software switching. On Nov 1, 2012 12:56 AM, Arie Vayner (avayner) avay...@cisco.com wrote: Yes, same concept. Better run on SXI or later to avoid issues with punting to the RP if the next-hop is down... Another option is to use something like that: track 1 interface GigabitEthernet3/1 line-protocol delay up 15 ! track 2 interface GigabitEthernet3/2 line-protocol delay up 15 ! route-map test2 permit 10 match ip address 100 set ip next-hop verify-availability 10.2.3.3 10 track 1 set ip next-hop verify-availability 10.2.2.3 20 track 2 Arie -Original Message- From: Paul Magee [mailto:pma...@williamhill.co.uk] Sent: Wednesday, October 31, 2012 09:13 To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.net Subject: RE: PBR on sup720 Hi Arie, Does this also apply to the SX version? Thanks, Paul -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: 31 October 2012 15:59 To: Paul Magee; cisco-nsp@puck.nether.net Subject: RE: PBR on sup720 Paul, Nop... All packets are handled in HW assuming your actions are supported... Performance should be the same as regular routing as long as it's done in HW and you do not exceed TCAM resources. In some older IOS versions there were issues with what happens when the next hop is not available... Packets were punted to the RP. This is not the case after SRD (I think). Check out: http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/cef.html http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/layer3.html#wp1027016 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Magee Sent: Wednesday, October 31, 2012 08:40 To: cisco-nsp@puck.nether.net Subject: [c-nsp] PBR on sup720 Hello, Does anyone have any experience of using policy based routing with vrf-lite on a Sup 720? I gather that the first packet is handled in software and from that point on the route exists in the cef table. Is that a big performance hit? What sort of throughput/number of connections can I expect to be able to handle before everything comes crashing to its knees? Do Cisco have any figures on this hidden away anywhere? Thanks, Paul --- -- * Confidentiality: The contents of this e-mail and any attachments transmitted with it are intended to be confidential to the intended recipient; and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. This e-mail is sent by a William Hill PLC group company. The William Hill group companies include, among others, William Hill PLC (registered number 4212563), William Hill Organization Limited (registered number 278208), William Hill US HoldCo Inc, WHG (International) Limited (registered number 99191) and WHG Trading Limited (registered number 101439). Each of William Hill PLC, William Hill Organization Limited is registered in England and Wales and has its registered office at Greenside Hou! se, 50 Station Road, Wood Green, London N22 7TP. William Hill U.S. HoldCo, Inc. is 160 Greentree Drive, Suite 101, Dover 19904, Kent, Delaware, United States of America. Each of WHG (International) Limited and WHG Trading Limited is registered in Gibraltar and has its registered office at 6/1 Waterport Place, Gibraltar. Unless specifically indicated otherwise, the contents of this e-mail are subject to contract; and are not an official statement, and do not necessarily represent the views, of William Hill PLC, its subsidiaries or affiliated companies. Please note that neither William Hill PLC, nor its subsidiaries and affiliated companies can accept any responsibility for any viruses contained within this e-mail and it is your responsibility to scan any emails and their attachments. William Hill PLC, its subsidiaries and affiliated companies may monitor e-mail traffic data and also the content of e-mails for effective operation of the e-mail system, or for security, purpose! s. * ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp
Re: [c-nsp] PBR on sup720
Basically, any 7600/6500 with Sup720 would be able to do PBR in hardware as long as you follow the feature restrictions (see links below). Older releases may have older issues, but the more recent software versions should be fine. The below issue that was fixed in SRD for 7600 was fixed in SXI for 6500. Arie From: Xu Hu [mailto:jstuxuhu0...@gmail.com] Sent: Sunday, November 04, 2012 00:55 To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.net; Paul Magee Subject: Re: [c-nsp] PBR on sup720 Hi Arie, i heard there should depend on which ios version and which kind of configirations u use will impact the action about hw or software switching. On Nov 1, 2012 12:56 AM, Arie Vayner (avayner) avay...@cisco.commailto:avay...@cisco.com wrote: Yes, same concept. Better run on SXI or later to avoid issues with punting to the RP if the next-hop is down... Another option is to use something like that: track 1 interface GigabitEthernet3/1 line-protocol delay up 15 ! track 2 interface GigabitEthernet3/2 line-protocol delay up 15 ! route-map test2 permit 10 match ip address 100 set ip next-hop verify-availability 10.2.3.3 10 track 1 set ip next-hop verify-availability 10.2.2.3 20 track 2 Arie -Original Message- From: Paul Magee [mailto:pma...@williamhill.co.ukmailto:pma...@williamhill.co.uk] Sent: Wednesday, October 31, 2012 09:13 To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: RE: PBR on sup720 Hi Arie, Does this also apply to the SX version? Thanks, Paul -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.commailto:avay...@cisco.com] Sent: 31 October 2012 15:59 To: Paul Magee; cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: RE: PBR on sup720 Paul, Nop... All packets are handled in HW assuming your actions are supported... Performance should be the same as regular routing as long as it's done in HW and you do not exceed TCAM resources. In some older IOS versions there were issues with what happens when the next hop is not available... Packets were punted to the RP. This is not the case after SRD (I think). Check out: http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/cef.html http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/layer3.html#wp1027016 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Magee Sent: Wednesday, October 31, 2012 08:40 To: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: [c-nsp] PBR on sup720 Hello, Does anyone have any experience of using policy based routing with vrf-lite on a Sup 720? I gather that the first packet is handled in software and from that point on the route exists in the cef table. Is that a big performance hit? What sort of throughput/number of connections can I expect to be able to handle before everything comes crashing to its knees? Do Cisco have any figures on this hidden away anywhere? Thanks, Paul --- -- * Confidentiality: The contents of this e-mail and any attachments transmitted with it are intended to be confidential to the intended recipient; and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. This e-mail is sent by a William Hill PLC group company. The William Hill group companies include, among others, William Hill PLC (registered number 4212563), William Hill Organization Limited (registered number 278208), William Hill US HoldCo Inc, WHG (International) Limited (registered number 99191) and WHG Trading Limited (registered number 101439). Each of William Hill PLC, William Hill Organization Limited is registered in England and Wales and has its registered office at Greenside Hou! se, 50 Station Road, Wood Green, London N22 7TP. William Hill U.S. HoldCo, Inc. is 160 Greentree Drive, Suite 101, Dover 19904, Kent, Delaware, United States of America. Each of WHG (International) Limited and WHG Trading Limited is registered in Gibraltar and has its registered office at 6/1 Waterport Place, Gibraltar. Unless specifically indicated otherwise, the contents of this e-mail are subject to contract; and are not an official statement, and do not necessarily represent the views, of William Hill PLC, its subsidiaries or affiliated companies. Please note that neither William Hill PLC, nor its subsidiaries and affiliated companies can accept any responsibility for any viruses contained within this e-mail and it is your responsibility to scan any emails and their attachments
[c-nsp] PBR on sup720
Hello, Does anyone have any experience of using policy based routing with vrf-lite on a Sup 720? I gather that the first packet is handled in software and from that point on the route exists in the cef table. Is that a big performance hit? What sort of throughput/number of connections can I expect to be able to handle before everything comes crashing to its knees? Do Cisco have any figures on this hidden away anywhere? Thanks, Paul --- -- * Confidentiality: The contents of this e-mail and any attachments transmitted with it are intended to be confidential to the intended recipient; and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. This e-mail is sent by a William Hill PLC group company. The William Hill group companies include, among others, William Hill PLC (registered number 4212563), William Hill Organization Limited (registered number 278208), William Hill US HoldCo Inc, WHG (International) Limited (registered number 99191) and WHG Trading Limited (registered number 101439). Each of William Hill PLC, William Hill Organization Limited is registered in England and Wales and has its registered office at Greenside Hou! se, 50 Station Road, Wood Green, London N22 7TP. William Hill U.S. HoldCo, Inc. is 160 Greentree Drive, Suite 101, Dover 19904, Kent, Delaware, United States of America. Each of WHG (International) Limited and WHG Trading Limited is registered in Gibraltar and has its registered office at 6/1 Waterport Place, Gibraltar. Unless specifically indicated otherwise, the contents of this e-mail are subject to contract; and are not an official statement, and do not necessarily represent the views, of William Hill PLC, its subsidiaries or affiliated companies. Please note that neither William Hill PLC, nor its subsidiaries and affiliated companies can accept any responsibility for any viruses contained within this e-mail and it is your responsibility to scan any emails and their attachments. William Hill PLC, its subsidiaries and affiliated companies may monitor e-mail traffic data and also the content of e-mails for effective operation of the e-mail system, or for security, purpose! s. * ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR on sup720
Paul, Nop... All packets are handled in HW assuming your actions are supported... Performance should be the same as regular routing as long as it's done in HW and you do not exceed TCAM resources. In some older IOS versions there were issues with what happens when the next hop is not available... Packets were punted to the RP. This is not the case after SRD (I think). Check out: http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/cef.html http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/layer3.html#wp1027016 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Magee Sent: Wednesday, October 31, 2012 08:40 To: cisco-nsp@puck.nether.net Subject: [c-nsp] PBR on sup720 Hello, Does anyone have any experience of using policy based routing with vrf-lite on a Sup 720? I gather that the first packet is handled in software and from that point on the route exists in the cef table. Is that a big performance hit? What sort of throughput/number of connections can I expect to be able to handle before everything comes crashing to its knees? Do Cisco have any figures on this hidden away anywhere? Thanks, Paul --- -- * Confidentiality: The contents of this e-mail and any attachments transmitted with it are intended to be confidential to the intended recipient; and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. This e-mail is sent by a William Hill PLC group company. The William Hill group companies include, among others, William Hill PLC (registered number 4212563), William Hill Organization Limited (registered number 278208), William Hill US HoldCo Inc, WHG (International) Limited (registered number 99191) and WHG Trading Limited (registered number 101439). Each of William Hill PLC, William Hill Organization Limited is registered in England and Wales and has its registered office at Greenside Hou! se, 50 Station Road, Wood Green, London N22 7TP. William Hill U.S. HoldCo, Inc. is 160 Greentree Drive, Suite 101, Dover 19904, Kent, Delaware, United States of America. Each of WHG (International) Limited and WHG Trading Limited is registered in Gibraltar and has its registered office at 6/1 Waterport Place, Gibraltar. Unless specifically indicated otherwise, the contents of this e-mail are subject to contract; and are not an official statement, and do not necessarily represent the views, of William Hill PLC, its subsidiaries or affiliated companies. Please note that neither William Hill PLC, nor its subsidiaries and affiliated companies can accept any responsibility for any viruses contained within this e-mail and it is your responsibility to scan any emails and their attachments. William Hill PLC, its subsidiaries and affiliated companies may monitor e-mail traffic data and also the content of e-mails for effective operation of the e-mail system, or for security, purpose! s. * ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR on sup720
Hi Arie, Does this also apply to the SX version? Thanks, Paul -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: 31 October 2012 15:59 To: Paul Magee; cisco-nsp@puck.nether.net Subject: RE: PBR on sup720 Paul, Nop... All packets are handled in HW assuming your actions are supported... Performance should be the same as regular routing as long as it's done in HW and you do not exceed TCAM resources. In some older IOS versions there were issues with what happens when the next hop is not available... Packets were punted to the RP. This is not the case after SRD (I think). Check out: http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/cef.html http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/layer3.html#wp1027016 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Magee Sent: Wednesday, October 31, 2012 08:40 To: cisco-nsp@puck.nether.net Subject: [c-nsp] PBR on sup720 Hello, Does anyone have any experience of using policy based routing with vrf-lite on a Sup 720? I gather that the first packet is handled in software and from that point on the route exists in the cef table. Is that a big performance hit? What sort of throughput/number of connections can I expect to be able to handle before everything comes crashing to its knees? Do Cisco have any figures on this hidden away anywhere? Thanks, Paul --- -- * Confidentiality: The contents of this e-mail and any attachments transmitted with it are intended to be confidential to the intended recipient; and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. This e-mail is sent by a William Hill PLC group company. The William Hill group companies include, among others, William Hill PLC (registered number 4212563), William Hill Organization Limited (registered number 278208), William Hill US HoldCo Inc, WHG (International) Limited (registered number 99191) and WHG Trading Limited (registered number 101439). Each of William Hill PLC, William Hill Organization Limited is registered in England and Wales and has its registered office at Greenside Hou! se, 50 Station Road, Wood Green, London N22 7TP. William Hill U.S. HoldCo, Inc. is 160 Greentree Drive, Suite 101, Dover 19904, Kent, Delaware, United States of America. Each of WHG (International) Limited and WHG Trading Limited is registered in Gibraltar and has its registered office at 6/1 Waterport Place, Gibraltar. Unless specifically indicated otherwise, the contents of this e-mail are subject to contract; and are not an official statement, and do not necessarily represent the views, of William Hill PLC, its subsidiaries or affiliated companies. Please note that neither William Hill PLC, nor its subsidiaries and affiliated companies can accept any responsibility for any viruses contained within this e-mail and it is your responsibility to scan any emails and their attachments. William Hill PLC, its subsidiaries and affiliated companies may monitor e-mail traffic data and also the content of e-mails for effective operation of the e-mail system, or for security, purpose! s. * ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR on sup720
Yes, same concept. Better run on SXI or later to avoid issues with punting to the RP if the next-hop is down... Another option is to use something like that: track 1 interface GigabitEthernet3/1 line-protocol delay up 15 ! track 2 interface GigabitEthernet3/2 line-protocol delay up 15 ! route-map test2 permit 10 match ip address 100 set ip next-hop verify-availability 10.2.3.3 10 track 1 set ip next-hop verify-availability 10.2.2.3 20 track 2 Arie -Original Message- From: Paul Magee [mailto:pma...@williamhill.co.uk] Sent: Wednesday, October 31, 2012 09:13 To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.net Subject: RE: PBR on sup720 Hi Arie, Does this also apply to the SX version? Thanks, Paul -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: 31 October 2012 15:59 To: Paul Magee; cisco-nsp@puck.nether.net Subject: RE: PBR on sup720 Paul, Nop... All packets are handled in HW assuming your actions are supported... Performance should be the same as regular routing as long as it's done in HW and you do not exceed TCAM resources. In some older IOS versions there were issues with what happens when the next hop is not available... Packets were punted to the RP. This is not the case after SRD (I think). Check out: http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/cef.html http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/layer3.html#wp1027016 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Magee Sent: Wednesday, October 31, 2012 08:40 To: cisco-nsp@puck.nether.net Subject: [c-nsp] PBR on sup720 Hello, Does anyone have any experience of using policy based routing with vrf-lite on a Sup 720? I gather that the first packet is handled in software and from that point on the route exists in the cef table. Is that a big performance hit? What sort of throughput/number of connections can I expect to be able to handle before everything comes crashing to its knees? Do Cisco have any figures on this hidden away anywhere? Thanks, Paul --- -- * Confidentiality: The contents of this e-mail and any attachments transmitted with it are intended to be confidential to the intended recipient; and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. This e-mail is sent by a William Hill PLC group company. The William Hill group companies include, among others, William Hill PLC (registered number 4212563), William Hill Organization Limited (registered number 278208), William Hill US HoldCo Inc, WHG (International) Limited (registered number 99191) and WHG Trading Limited (registered number 101439). Each of William Hill PLC, William Hill Organization Limited is registered in England and Wales and has its registered office at Greenside Hou! se, 50 Station Road, Wood Green, London N22 7TP. William Hill U.S. HoldCo, Inc. is 160 Greentree Drive, Suite 101, Dover 19904, Kent, Delaware, United States of America. Each of WHG (International) Limited and WHG Trading Limited is registered in Gibraltar and has its registered office at 6/1 Waterport Place, Gibraltar. Unless specifically indicated otherwise, the contents of this e-mail are subject to contract; and are not an official statement, and do not necessarily represent the views, of William Hill PLC, its subsidiaries or affiliated companies. Please note that neither William Hill PLC, nor its subsidiaries and affiliated companies can accept any responsibility for any viruses contained within this e-mail and it is your responsibility to scan any emails and their attachments. William Hill PLC, its subsidiaries and affiliated companies may monitor e-mail traffic data and also the content of e-mails for effective operation of the e-mail system, or for security, purpose! s. * ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR within MPLS VPN
This was actually useful, but only to the extent that I've determined that no you really can't do that - show tcam int confirmed that using set ip vrf X next-hop recursive Y is software-punted, and the combinations that do create a hdw forward entry send packets into some random black hole. I suppose I can see this - the packet is already part-way through the switching path and it's probably already missed the turn-off that would allow the switch to stick an MPLS label on it - it'd have to be recirc'ed, and Cisco would be understandably not keen to create too many recirc paths. it would appear - though I haven't tried it - that set ip next-hop recursive _is_ supported in hdw on the sup2t which I have in the primary POP, not the secondary POP. And I can't justify a full-on upgrade just for this... I wonder if the ME3600Xs support it? Hm Thanks -bacon From: Xu Hu [mailto:jstuxuhu0...@gmail.com] Sent: Tuesday, August 28, 2012 11:24 PM To: Jeff Bacon Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] PBR within MPLS VPN Hi Bacon, For the PBR hardware switched or software switched, it depends, please check the detail as below website https://supportforums.cisco.com/thread/2017902 For the question which you raised Or can you not policy-route to a non-directly-connected PE over MPLS using PBR? The answer is, of course, you can do. HTH Hu Xu 2012/8/29 Jeff Bacon ba...@walleyesoftware.commailto:ba...@walleyesoftware.com As I sit and write this, this starts to sound stupid even to me. Just stick with it, please, THEN tell me I'm being stupid. :) So, device A is a cat6500/sup720, global IP 172.31.1.1/32http://172.31.1.1/32, a PE device in an MPLS mesh. device B is a cat6500/sup720, global IP 172.31.1.14/32http://172.31.1.14/32, PE device in another city. there is a VRF fred defined. There's device C, also with VRF fred, global IP 172.31.2.3/32http://172.31.2.3/32, publishing a default route. host1 (172.30.250.40) - int vlan 49/vrf-fred/device-A - MPLS mesh - int g3/1/vrf-fred/device-B - INTERNET | - device-C-publishing-default-route - OTHERINTERNET so, the route table in VRF fred on device A looks like: C172.31.250.32 is directly connected, Vlan49 host1 is here 200.3.3.0/24http://200.3.3.0/24 is variably subnetted, 3 subnets, 3 masks B 200.3.3.32/29http://200.3.3.32/29 [200/0] via 172.31.1.14, 3d18h B* 0.0.0.0/0http://0.0.0.0/0 [20/8192] via 64.1.1.1, 5d23h now, please don't ask why, but I want to be able to policy-route host1's traffic to make it use device-B and not follow the default route, e.g.: int vlan 49 ip policy route-map source-route-map route-map source-route-map permit 10 match ip address ACL-matching-172.30.250.40/32 set ip next-hop something-making-it-go-to-B I have no idea what something should be. Now, I can do set ip next-hop recursive X where X is a real IP in VRF fred on device B. Works fine. It's also software-switched - fast-path, show ip cef switching stat feat increments showing PBR is working via CEF, but show int vlan49 switching tells me that the packets are being fast-path-switched, not hardware-switched. Release notes say that set ip next-hop is supported in hardware. But that presumes I give it the right IP address. The problem is this: so what's the next-hop that I *can* use to specify CEF adjacency of that specific other PE device over there, VRF fred? It doesn't appear to be 172.31.1.14. Or can you not policy-route to a non-directly-connected PE over MPLS using PBR? (I can hear it now - that's what TE is for or can't you split the traffic into separate VRFs and use source selection... ok, yes, well... ) Thanks for your indulgence, -bacon ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR within MPLS VPN
As I sit and write this, this starts to sound stupid even to me. Just stick with it, please, THEN tell me I'm being stupid. :) So, device A is a cat6500/sup720, global IP 172.31.1.1/32, a PE device in an MPLS mesh. device B is a cat6500/sup720, global IP 172.31.1.14/32, PE device in another city. there is a VRF fred defined. There's device C, also with VRF fred, global IP 172.31.2.3/32, publishing a default route. host1 (172.30.250.40) - int vlan 49/vrf-fred/device-A - MPLS mesh - int g3/1/vrf-fred/device-B - INTERNET | - device-C-publishing-default-route - OTHERINTERNET so, the route table in VRF fred on device A looks like: C172.31.250.32 is directly connected, Vlan49 host1 is here 200.3.3.0/24 is variably subnetted, 3 subnets, 3 masks B 200.3.3.32/29 [200/0] via 172.31.1.14, 3d18h B* 0.0.0.0/0 [20/8192] via 64.1.1.1, 5d23h now, please don't ask why, but I want to be able to policy-route host1's traffic to make it use device-B and not follow the default route, e.g.: int vlan 49 ip policy route-map source-route-map route-map source-route-map permit 10 match ip address ACL-matching-172.30.250.40/32 set ip next-hop something-making-it-go-to-B I have no idea what something should be. Now, I can do set ip next-hop recursive X where X is a real IP in VRF fred on device B. Works fine. It's also software-switched - fast-path, show ip cef switching stat feat increments showing PBR is working via CEF, but show int vlan49 switching tells me that the packets are being fast-path-switched, not hardware-switched. Release notes say that set ip next-hop is supported in hardware. But that presumes I give it the right IP address. The problem is this: so what's the next-hop that I *can* use to specify CEF adjacency of that specific other PE device over there, VRF fred? It doesn't appear to be 172.31.1.14. Or can you not policy-route to a non-directly-connected PE over MPLS using PBR? (I can hear it now - that's what TE is for or can't you split the traffic into separate VRFs and use source selection... ok, yes, well... ) Thanks for your indulgence, -bacon ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR within MPLS VPN
Hi Bacon, For the PBR hardware switched or software switched, it depends, please check the detail as below website https://supportforums.cisco.com/thread/2017902 For the question which you raised Or can you not policy-route to a non-directly-connected PE over MPLS using PBR? The answer is, of course, you can do. HTH Hu Xu 2012/8/29 Jeff Bacon ba...@walleyesoftware.com As I sit and write this, this starts to sound stupid even to me. Just stick with it, please, THEN tell me I'm being stupid. :) So, device A is a cat6500/sup720, global IP 172.31.1.1/32, a PE device in an MPLS mesh. device B is a cat6500/sup720, global IP 172.31.1.14/32, PE device in another city. there is a VRF fred defined. There's device C, also with VRF fred, global IP 172.31.2.3/32, publishing a default route. host1 (172.30.250.40) - int vlan 49/vrf-fred/device-A - MPLS mesh - int g3/1/vrf-fred/device-B - INTERNET | - device-C-publishing-default-route - OTHERINTERNET so, the route table in VRF fred on device A looks like: C172.31.250.32 is directly connected, Vlan49 host1 is here 200.3.3.0/24 is variably subnetted, 3 subnets, 3 masks B 200.3.3.32/29 [200/0] via 172.31.1.14, 3d18h B* 0.0.0.0/0 [20/8192] via 64.1.1.1, 5d23h now, please don't ask why, but I want to be able to policy-route host1's traffic to make it use device-B and not follow the default route, e.g.: int vlan 49 ip policy route-map source-route-map route-map source-route-map permit 10 match ip address ACL-matching-172.30.250.40/32 set ip next-hop something-making-it-go-to-B I have no idea what something should be. Now, I can do set ip next-hop recursive X where X is a real IP in VRF fred on device B. Works fine. It's also software-switched - fast-path, show ip cef switching stat feat increments showing PBR is working via CEF, but show int vlan49 switching tells me that the packets are being fast-path-switched, not hardware-switched. Release notes say that set ip next-hop is supported in hardware. But that presumes I give it the right IP address. The problem is this: so what's the next-hop that I *can* use to specify CEF adjacency of that specific other PE device over there, VRF fred? It doesn't appear to be 172.31.1.14. Or can you not policy-route to a non-directly-connected PE over MPLS using PBR? (I can hear it now - that's what TE is for or can't you split the traffic into separate VRFs and use source selection... ok, yes, well... ) Thanks for your indulgence, -bacon ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR within MPLS VPN
Hi Jeff, In some cases that we have required to do something like this we have used the command set vrf xyz within the route-map to push the traffic into a different VRF that then has a different routing table. regards, Tony. From: Jeff Bacon ba...@walleyesoftware.com To: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Sent: Wednesday, 29 August 2012 10:17 AM Subject: [c-nsp] PBR within MPLS VPN As I sit and write this, this starts to sound stupid even to me. Just stick with it, please, THEN tell me I'm being stupid. :) So, device A is a cat6500/sup720, global IP 172.31.1.1/32, a PE device in an MPLS mesh. device B is a cat6500/sup720, global IP 172.31.1.14/32, PE device in another city. there is a VRF fred defined. There's device C, also with VRF fred, global IP 172.31.2.3/32, publishing a default route. host1 (172.30.250.40) - int vlan 49/vrf-fred/device-A - MPLS mesh - int g3/1/vrf-fred/device-B - INTERNET | - device-C-publishing-default-route - OTHERINTERNET so, the route table in VRF fred on device A looks like: C 172.31.250.32 is directly connected, Vlan49 host1 is here 200.3.3.0/24 is variably subnetted, 3 subnets, 3 masks B 200.3.3.32/29 [200/0] via 172.31.1.14, 3d18h B* 0.0.0.0/0 [20/8192] via 64.1.1.1, 5d23h now, please don't ask why, but I want to be able to policy-route host1's traffic to make it use device-B and not follow the default route, e.g.: int vlan 49 ip policy route-map source-route-map route-map source-route-map permit 10 match ip address ACL-matching-172.30.250.40/32 set ip next-hop something-making-it-go-to-B I have no idea what something should be. Now, I can do set ip next-hop recursive X where X is a real IP in VRF fred on device B. Works fine. It's also software-switched - fast-path, show ip cef switching stat feat increments showing PBR is working via CEF, but show int vlan49 switching tells me that the packets are being fast-path-switched, not hardware-switched. Release notes say that set ip next-hop is supported in hardware. But that presumes I give it the right IP address. The problem is this: so what's the next-hop that I *can* use to specify CEF adjacency of that specific other PE device over there, VRF fred? It doesn't appear to be 172.31.1.14. Or can you not policy-route to a non-directly-connected PE over MPLS using PBR? (I can hear it now - that's what TE is for or can't you split the traffic into separate VRFs and use source selection... ok, yes, well... ) Thanks for your indulgence, -bacon ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR on traffic originating from the router
Let's say a router is setup with connection to ISP 1 and ISP 2, which are both non-BGP connection and traffic coming in from ISP 1 can't go out ISP 2 and visa versa. Default route is set on ISP 1, with IP SLA, failover to ISP 2. I can configure NAT so it will NAT on the correct IP for each egress connection. This is not the issue. Is there a way, for example, a ping to the router coming into ISP2 can be sent back out ISP2 when ISP2 is not the default route? Normal PBR applied to ingress traffic on the interface so I wasn't sure what could be done with traffic originating on the router. Thanks! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR on traffic originating from the router
Hello Jay, you can a apply a route-map that would do PBR on the traffic generated by the router like this: route-map LocalPolicy permit 10 match ip address PingISP_A set interface Serial0/0/0 ip local policy route-map LocalPolicy Seems like your scenario perfectly matches the one described by Ivan on http://www.nil.com/ipcorner/RedundantMultiHoming/ -pavel On Thu, Jul 28, 2011 at 8:29 AM, Jay Nakamura zeusda...@gmail.com wrote: Let's say a router is setup with connection to ISP 1 and ISP 2, which are both non-BGP connection and traffic coming in from ISP 1 can't go out ISP 2 and visa versa. Default route is set on ISP 1, with IP SLA, failover to ISP 2. I can configure NAT so it will NAT on the correct IP for each egress connection. This is not the issue. Is there a way, for example, a ping to the router coming into ISP2 can be sent back out ISP2 when ISP2 is not the default route? Normal PBR applied to ingress traffic on the interface so I wasn't sure what could be done with traffic originating on the router. Thanks! ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR on traffic originating from the router
Thanks everyone! I got it working with the ip local policy. On Thu, Jul 28, 2011 at 6:08 AM, Pavel Skovajsa pavel.skova...@gmail.com wrote: Hello Jay, you can a apply a route-map that would do PBR on the traffic generated by the router like this: route-map LocalPolicy permit 10 match ip address PingISP_A set interface Serial0/0/0 ip local policy route-map LocalPolicy Seems like your scenario perfectly matches the one described by Ivan on http://www.nil.com/ipcorner/RedundantMultiHoming/ -pavel On Thu, Jul 28, 2011 at 8:29 AM, Jay Nakamura zeusda...@gmail.com wrote: Let's say a router is setup with connection to ISP 1 and ISP 2, which are both non-BGP connection and traffic coming in from ISP 1 can't go out ISP 2 and visa versa. Default route is set on ISP 1, with IP SLA, failover to ISP 2. I can configure NAT so it will NAT on the correct IP for each egress connection. This is not the issue. Is there a way, for example, a ping to the router coming into ISP2 can be sent back out ISP2 when ISP2 is not the default route? Normal PBR applied to ingress traffic on the interface so I wasn't sure what could be done with traffic originating on the router. Thanks! ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR on traffic originating from the router
Hi, On Thu, Jul 28, 2011 at 02:29:59AM -0400, Jay Nakamura wrote: Is there a way, for example, a ping to the router coming into ISP2 can be sent back out ISP2 when ISP2 is not the default route? Normal PBR applied to ingress traffic on the interface so I wasn't sure what could be done with traffic originating on the router. ip local policy route-map PBR for traffic originated by the router. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpGgDD7J343K.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR
Hi, The 2811 has two connections coming in on ATM0/2/0 (binding to Di1) and ATM0/3/0 (binding to Di0). I've got a small gaggle of VLANs. I'm trying to get VLAN10 sending/receiving everything over Di1 and everything else over Di0. just as a personal preference I would suggest using vrf-lite instead of pbr in your case. Other guys saying about tcp in pbr are of course right. Beste ragards, Jan signature.asc Description: OpenPGP digital signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR
I'm inclined to agree. VRF's are much easier to troubleshoot than PBR when you have problems, as they use standard destination-based routing. When you use PBR, looking at the routing table is virtually meaningless. GG On 7/28/10, Jan Gregor jan.gre...@chronix.org wrote: Hi, The 2811 has two connections coming in on ATM0/2/0 (binding to Di1) and ATM0/3/0 (binding to Di0). I've got a small gaggle of VLANs. I'm trying to get VLAN10 sending/receiving everything over Di1 and everything else over Di0. just as a personal preference I would suggest using vrf-lite instead of pbr in your case. Other guys saying about tcp in pbr are of course right. Beste ragards, Jan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR
Hi - I'm struggling to get PBR working on a 2811, wonder if someone can show me with where I'm being special. The 2811 has two connections coming in on ATM0/2/0 (binding to Di1) and ATM0/3/0 (binding to Di0). I've got a small gaggle of VLANs. I'm trying to get VLAN10 sending/receiving everything over Di1 and everything else over Di0. If I do ip route 0.0.0.0 0.0.0.0 Dialer0, everything goes over Di0, as expected. If I cancel that and change it to ip route 0.0.0.0 0.0.0.0 Dialer1, then everything goes via that. So, I know that my connections are good. It's something internal I'm not getting right. So, to start setting this up - everything is currently running over Dialer0. ATM0/2/0 is up over Di1, but there's no route for it. VLAN10 is 192.168.10.0/24, so creating an access list as per this: ip access-list extended Network10 permit tcp any 192.168.10.0 0.0.0.255 permit tcp 192.168.10.0 0.0.0.255 any Then... route-map PBR_Network10 permit 10 match ip address Network10 set interface Dialer1 interface Fa0/0.10 description Network10Uplink ip policy route-map PBR_Network10 ip route 0.0.0.0 0.0.0.0 Dialer1 10 As I understand it, this should work - however, from the outside, trying to ping the address of Di1 results in no replies. Also, VLAN10 can't route over the connection, instead still routing over Di0. What am I doing wrong? Thanks! Gary ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR
Depending on the IOS you may need a numbered ACL instead of a named one. It's an IOS quirk, a little like VRF-aware NAT requiring a route-map sometimes :-) --Dan Holme On 25 Jul 2010, at 20:38, Gary Smith li...@l33t-d00d.co.uk wrote: Hi - I'm struggling to get PBR working on a 2811, wonder if someone can show me with where I'm being special. The 2811 has two connections coming in on ATM0/2/0 (binding to Di1) and ATM0/3/0 (binding to Di0). I've got a small gaggle of VLANs. I'm trying to get VLAN10 sending/receiving everything over Di1 and everything else over Di0. If I do ip route 0.0.0.0 0.0.0.0 Dialer0, everything goes over Di0, as expected. If I cancel that and change it to ip route 0.0.0.0 0.0.0.0 Dialer1, then everything goes via that. So, I know that my connections are good. It's something internal I'm not getting right. So, to start setting this up - everything is currently running over Dialer0. ATM0/2/0 is up over Di1, but there's no route for it. VLAN10 is 192.168.10.0/24, so creating an access list as per this: ip access-list extended Network10 permit tcp any 192.168.10.0 0.0.0.255 permit tcp 192.168.10.0 0.0.0.255 any Then... route-map PBR_Network10 permit 10 match ip address Network10 set interface Dialer1 interface Fa0/0.10 description Network10Uplink ip policy route-map PBR_Network10 ip route 0.0.0.0 0.0.0.0 Dialer1 10 As I understand it, this should work - however, from the outside, trying to ping the address of Di1 results in no replies. Also, VLAN10 can't route over the connection, instead still routing over Di0. What am I doing wrong? Thanks! Gary ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR
On 7/25/10 12:38 PM, Gary Smith wrote: So, to start setting this up - everything is currently running over Dialer0. ATM0/2/0 is up over Di1, but there's no route for it. VLAN10 is 192.168.10.0/24, so creating an access list as per this: ip access-list extended Network10 permit tcp any 192.168.10.0 0.0.0.255 permit tcp 192.168.10.0 0.0.0.255 any Then... route-map PBR_Network10 permit 10 match ip address Network10 set interface Dialer1 interface Fa0/0.10 description Network10Uplink ip policy route-map PBR_Network10 ip route 0.0.0.0 0.0.0.0 Dialer1 10 As I understand it, this should work - however, from the outside, trying to ping the address of Di1 results in no replies. Also, VLAN10 can't route over the connection, instead still routing over Di0. What am I doing wrong? Your access list matches TCP. Your ping is ICMP. If you want all traffic on that interface to go via PBR change the ACL to match IP and not TCP. As you're matching on source IP you can use a standard ACL. If everything coming in on Fa0/0.10 is to go to dialer1, you may not need a match statement in the route-map at all. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR
On Sun, 2010-07-25 at 20:38 +0100, Gary Smith wrote: ip access-list extended Network10 permit tcp any 192.168.10.0 0.0.0.255 permit tcp 192.168.10.0 0.0.0.255 any [...] As I understand it, this should work - however, from the outside, trying to ping the address of Di1 results in no replies. Also, VLAN10 can't route over the connection, instead still routing over Di0. What am I doing wrong? The access list matches only TCP traffic? -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR
Peter Rathlev wrote: The access list matches only TCP traffic? You should've included the line about me doing something incredibly stupid in your quote. Thanks for the suggestions so far everyone - going to give them a bash and hopefully get it working. Cheers, Gary ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR support on 6500 w/ VSS and on 4500 Sup6L-E
Anyone, Been looking around on Cisco's web site, trying to find out if PBR (policy based routing) is supported on a VSS pair of 6500s and also on the new 4500 Sup6L-E. What I'm trying to accomplish is based on source address, send traffic either via a normal path or use an alternate next hop (I need to force certain traffic types through a FW, security mandate). The 4500 is on the other side, and needs to PBR the return traffic, using opposite source/dest pairs. I didn't find anything that definitively said yes or no. Software advisor leads me to believe it exists in Enterprise Services for the 4500, but that image is for the Sup6-E as well, not sure if the feature is really there for the 'L' version. Just want to make sure. Thanks, Chuck smime.p7s Description: S/MIME cryptographic signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR support on 6500 w/ VSS and on 4500 Sup6L-E
Chuck, For 6500 (with or without VSS) you can find some PBR information here: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/con figuration/guide/layer3.html For 4500, look here: http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/53SG/conf iguration/pbroute.html (It has some specific references to SUP6E, but not only). One thing you should do on the 6500 at least (never tested it on a 4500) is to use something like this for next-hop tracking (track could be not just for line-protocol, but other things): track 1 interface GigabitEthernet3/1 line-protocol delay up 15 ! track 2 interface GigabitEthernet3/2 line-protocol delay up 15 ! route-map test2 permit 10 match ip address 100 set ip next-hop verify-availability 10.2.3.3 10 track 1 set ip next-hop verify-availability 10.2.2.3 20 track 2 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Church, Charles Sent: Wednesday, March 24, 2010 21:16 To: nsp-cisco Subject: [c-nsp] PBR support on 6500 w/ VSS and on 4500 Sup6L-E Anyone, Been looking around on Cisco's web site, trying to find out if PBR (policy based routing) is supported on a VSS pair of 6500s and also on the new 4500 Sup6L-E. What I'm trying to accomplish is based on source address, send traffic either via a normal path or use an alternate next hop (I need to force certain traffic types through a FW, security mandate). The 4500 is on the other side, and needs to PBR the return traffic, using opposite source/dest pairs. I didn't find anything that definitively said yes or no. Software advisor leads me to believe it exists in Enterprise Services for the 4500, but that image is for the Sup6-E as well, not sure if the feature is really there for the 'L' version. Just want to make sure. Thanks, Chuck ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR on virtual-access interfaces with easy-vpn
Hello, I am using easy-vpn on my routers. I want to be able to PBR inbound traffic (coming from the IPSec tunnel) to force it down a different path than the one in the routing table. I have applied PBR on the virtual-template, based on the different show commands I issued, it is taken into account. However, I do not see any hits on the route-map (even though I see them on the ACL). Does anyone know if PBR is supported on that kind of interface? Thank you Laurent _ Tchattez en direct en en vidéo avec vos amis ! http://www.windowslive.fr/messenger/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR v VRF for source-based routing
Phil, Can you explain a bit more about your specific requirement? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Philip Davis Sent: Friday, October 23, 2009 17:34 To: 'Cisco-nsp' Subject: [c-nsp] PBR v VRF for source-based routing Hello, From reading documentation, it appears that PBR and VRF-lite can both be used to implement cases of source-based routing. I have only used PBR for this, and most VRF documentation seems to be in the context of MPLS or L3VPNs. What are the pros and cons of one vs the other? Am I all wet that VRF can do this at all? Thanks, Phil ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR v VRF for source-based routing
Hi, On Fri, Oct 23, 2009 at 11:34:05AM -0400, Philip Davis wrote: From reading documentation, it appears that PBR and VRF-lite can both be used to implement cases of source-based routing. I have only used PBR for this, and most VRF documentation seems to be in the context of MPLS or L3VPNs. What are the pros and cons of one vs the other? Am I all wet that VRF can do this at all? Well, what VRF gives you is completely de-coupled routing tables between interfaces. So for one ingress interface into the router, you use routing table A, and for another ingress interface, routing table B. All interfaces belong to *one* VRF only, so if you want to share an interface between traffic of sort A and sort B, things with VRFs get tricky. You can do this with VRF select (match an access-list, and depending on the result, go to VRF routing table A or B or C...), but that's a lot of configuration stuff if all you need to do is sort incoming traffic on one interface. PBR will give you a lever to sort incoming traffic according to some rules you define in a route-map, bypassing(!) normal routing tables. PBR is more powerful than VRFs, if the point is sorting traffic coming in on *one* interface, but if you need to scale this to dozens of routers, and hundreds of interfaces, PBR will just be too complex to get right. So it really depends what you need to achieve. Tell us your goals, we tell you why you want PBR or VRF :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgptcmciky0EB.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR in hardware on RSP720
According to Cisco's doc's ( http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/layer3.html ), policy routing can be done in hardware with the following restrictions: http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/layer3.html The Policy Feature Card (PFC) and any Distributed Feature Cards (DFCs) provide hardware support for policy-based routing (PBR) for route-map sequences that use the match ip address, set ip next-hop, and ip default next-hop PBR keywords. How do I have to read this rule ? Only if I use these 3 commands, the traffic will be policy routed through the PFC ? And what about other rules. It looks like other Policy Routing rules don't even get processed. So the only way the get these rules matched is disabling mls ip on the interface where the route-map is set ? regards Rinse ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR in hardware on RSP720
On Wed, 2009-09-30 at 12:45 +0200, Rinse Kloek wrote: The Policy Feature Card (PFC) and any Distributed Feature Cards (DFCs) provide hardware support for policy-based routing (PBR) for route-map sequences that use the match ip address, set ip next-hop, and ip default next-hop PBR keywords. How do I have to read this rule ? Only if I use these 3 commands, the traffic will be policy routed through the PFC ? That is as I understand it yes. And what about other rules. It looks like other Policy Routing rules don't even get processed. So the only way the get these rules matched is disabling mls ip on the interface where the route-map is set ? That also seems right, though I thought it was mls switching unicast; the commands seem to enable/disable each other though. The switch might process the traffic in software even without disabling hardware switching, but that wouldn't always be a good idea, considering the perfomance impact. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR in hardware on RSP720
Hmm looks like I discovered some incompatibily. If I disable the used private hosts layer3 feature, policy routing works. Looks like privates hosts blocks the traffic for policy routing: #sh tcam int gi2/1 acl in other module 5 deny other host 0200..0001 any deny other host 0023.5ed9.7140 any permit other any .. .. permit other any 0100.5e00. .ff80. permit other any host 0200..0001 (7 matches) permit other any host 0023.5ed9.7140 redirect other any host .. deny other any any #no private-hosts layer3 sh tcam int gi2/1 acl in other module 5 empty regards Rinse Peter Rathlev schreef: On Wed, 2009-09-30 at 12:45 +0200, Rinse Kloek wrote: The Policy Feature Card (PFC) and any Distributed Feature Cards (DFCs) provide hardware support for policy-based routing (PBR) for route-map sequences that use the match ip address, set ip next-hop, and ip default next-hop PBR keywords. How do I have to read this rule ? Only if I use these 3 commands, the traffic will be policy routed through the PFC ? That is as I understand it yes. And what about other rules. It looks like other Policy Routing rules don't even get processed. So the only way the get these rules matched is disabling mls ip on the interface where the route-map is set ? That also seems right, though I thought it was mls switching unicast; the commands seem to enable/disable each other though. The switch might process the traffic in software even without disabling hardware switching, but that wouldn't always be a good idea, considering the perfomance impact. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR, order of operations for set directives ?
Hi all, We have an small issue here and we have over the table some workarounds and one them is related with the order of operations of the set directives under a route-map used for policy routing. In fact we would like to apply a code like this: route-map selectvrf permit 10 match ip address foo set ip next-hop verify-availability 10.53.0.37 1 track 10 set vrf vrf_backup4foo We know that we could use set ip next-hop verify-availability and then set ip next-hop but we can't do that because under vrf vrf_backup4foo there is another 10.53.0.37. And we have some redistribution between VRFs and BGP... So it is not possible. So, the question is... Is there anyone here with information about the order of operations of the set directives under a route-map used for policy routing? Regards. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR + ACL is not working as expected in a 7600
Hi all, We have here this configuration in the ACL: ip access-list extended AM_Pilotos_vuelta_acelerada permit tcp 88.84.89.240 0.0.0.3 any gt 1024 permit tcp 88.84.89.240 0.0.0.3 any eq ftp www With this config, the www traffic received on Gi1/1 doesn't match the acl (ftp www ACL) so the traffic is not being forwarded as expected by PBR Changed the access list to: permit tcp 88.84.89.240 0.0.0.3 any gt 1024 permit tcp 88.84.89.240 0.0.0.3 any eq www permit tcp 88.84.89.240 0.0.0.3 any eq ftp and it works!! c7600rsp72043-advipservicesk9-mz.122-33.SRC1.bin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR + NAT route-map issue
Hi All, Im kinda new to the list and hope someone can help me an issue. I'm trying to do some PBR with nat and am having an issue understanding how the route-maps apply in combination with the nat process. I would like to send my Phone based vlan traffic out of the T1 and the Data traffic out of the DSL. IF possible, I'd like them to failover for each other (which makes the config even more confusing). I have the ability to route a few/30's to this router over the dsl or the t1. Any help with the nat statements and route-maps would be greatly appreciated. Relevent config so far is posted. The 64.x.x.x and 208.x.x.x are my phone servers. Thanks for any help!!! 2651-XM 12.4.(23) ip dhcp excluded-address 172.16.0.1 172.16.0.99 ip dhcp excluded-address 192.168.1.1 192.168.1.100 ip dhcp excluded-address 192.168.1.113 ! ip dhcp pool PHONES network 172.16.0.0 255.255.255.0 default-router 172.16.0.1 dns-server 208.66.61.109 208.66.61.110 option 150 ip 208.83.93.113 lease 3 ! ip dhcp pool Computers network 192.168.1.0 255.255.255.0 default-router 192.168.1.1 dns-server 208.66.61.109 208.66.61.110 lease 3 ! ! ! track 1 interface Dialer0 ip routing delay up 15 ! interface FastEthernet0/0 no ip address duplex auto speed auto ! interface FastEthernet0/0.150 description To Phones encapsulation dot1Q 150 ip address 172.16.0.1 255.255.255.0 ip nat inside ! interface FastEthernet0/0.200 description Computers encapsulation dot1Q 200 ip address 192.168.1.1 255.255.255.0 ip nat inside ! interface Serial0/0 ip address 74.113.88.62 255.255.255.252 ip nat outside priority-group 1 ! interface ATM0/1 no ip address no ip redirects no ip unreachables no ip proxy-arp ip route-cache flow shutdown no atm ilmi-keepalive dsl operating-mode auto ! interface ATM0/1.1 point-to-point pvc 1/100 pppoe-client dial-pool-number 1 ! ! interface FastEthernet0/1 no ip address shutdown duplex auto speed auto ! interface Dialer0 ip address negotiated no ip redirects no ip unreachables no ip proxy-arp ip nat outside encapsulation ppp ip route-cache flow ip tcp adjust-mss 1412 dialer pool 1 dialer-group 1 no cdp enable ppp authentication chap pap callin ppp chap hostname rubenst...@authcall.net ppp chap password 0 ppp pap sent-username rubenst...@authcall.net password 0 x ! ip route 0.0.0.0 0.0.0.0 Dialer0 track 1 ip route 0.0.0.0 0.0.0.0 74.113.88.61 254 ip route 64.193.113.0 255.255.255.0 74.113.88.61 101 ip route 64.193.113.0 255.255.255.0 Dialer0 120 ip route 208.83.93.0 255.255.252.0 74.113.88.61 101 ip route 208.83.93.0 255.255.252.0 Dialer0 120 ! no ip http server ip nat inside source list 10 interface Serial0/0 overload access-list 10 permit 192.168.1.0 0.0.0.255 access-list 10 permit 172.16.0.0 0.0.0.255 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR + NAT route-map issue
Hi Max, You might want to combine pbr with object tracking (and add some nat statements to this mix). To make a long story short, you can configure ip sla and object tracking to monitor your gateway(s) availability and use a route-map with the verify-availability statement to select the preferred/available route. I've described it in my blog [1] a couple of months ago. Sorry, it's still in portuguese only :( ... Well, since the configs have been written in a universal language (aka ios commands) there should be no problem trying to figure out the portuguese part (or use the google translator to do the trick). :) [1] http://blog.nexthop.com.br/2009/02/um-roteador-dois-provedores-e-alguma.html Gustavo. On Tue, Jul 28, 2009 at 4:13 PM, Max Piersonmax.pier...@mycallis.com wrote: Hi All, Im kinda new to the list and hope someone can help me an issue. I'm trying to do some PBR with nat and am having an issue understanding how the route-maps apply in combination with the nat process. I would like to send my Phone based vlan traffic out of the T1 and the Data traffic out of the DSL. IF possible, I'd like them to failover for each other (which makes the config even more confusing). I have the ability to route a few/30's to this router over the dsl or the t1. Any help with the nat statements and route-maps would be greatly appreciated. Relevent config so far is posted. The 64.x.x.x and 208.x.x.x are my phone servers. Thanks for any help!!! 2651-XM 12.4.(23) ip dhcp excluded-address 172.16.0.1 172.16.0.99 ip dhcp excluded-address 192.168.1.1 192.168.1.100 ip dhcp excluded-address 192.168.1.113 ! ip dhcp pool PHONES network 172.16.0.0 255.255.255.0 default-router 172.16.0.1 dns-server 208.66.61.109 208.66.61.110 option 150 ip 208.83.93.113 lease 3 ! ip dhcp pool Computers network 192.168.1.0 255.255.255.0 default-router 192.168.1.1 dns-server 208.66.61.109 208.66.61.110 lease 3 ! ! ! track 1 interface Dialer0 ip routing delay up 15 ! interface FastEthernet0/0 no ip address duplex auto speed auto ! interface FastEthernet0/0.150 description To Phones encapsulation dot1Q 150 ip address 172.16.0.1 255.255.255.0 ip nat inside ! interface FastEthernet0/0.200 description Computers encapsulation dot1Q 200 ip address 192.168.1.1 255.255.255.0 ip nat inside ! interface Serial0/0 ip address 74.113.88.62 255.255.255.252 ip nat outside priority-group 1 ! interface ATM0/1 no ip address no ip redirects no ip unreachables no ip proxy-arp ip route-cache flow shutdown no atm ilmi-keepalive dsl operating-mode auto ! interface ATM0/1.1 point-to-point pvc 1/100 pppoe-client dial-pool-number 1 ! ! interface FastEthernet0/1 no ip address shutdown duplex auto speed auto ! interface Dialer0 ip address negotiated no ip redirects no ip unreachables no ip proxy-arp ip nat outside encapsulation ppp ip route-cache flow ip tcp adjust-mss 1412 dialer pool 1 dialer-group 1 no cdp enable ppp authentication chap pap callin ppp chap hostname rubenst...@authcall.net ppp chap password 0 ppp pap sent-username rubenst...@authcall.net password 0 x ! ip route 0.0.0.0 0.0.0.0 Dialer0 track 1 ip route 0.0.0.0 0.0.0.0 74.113.88.61 254 ip route 64.193.113.0 255.255.255.0 74.113.88.61 101 ip route 64.193.113.0 255.255.255.0 Dialer0 120 ip route 208.83.93.0 255.255.252.0 74.113.88.61 101 ip route 208.83.93.0 255.255.252.0 Dialer0 120 ! no ip http server ip nat inside source list 10 interface Serial0/0 overload access-list 10 permit 192.168.1.0 0.0.0.255 access-list 10 permit 172.16.0.0 0.0.0.255 ___ cisco-nsp mailing list cisco-...@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR on ME3400
Has anyone on the list tried to perform PBR on the ME3400 while setting next hop to an IP at the far end of a GRE tunnel? I was attempting this today and the ME3400 seemed to ignore my PBR wishes. If the next hop was an IP off a routed port everything was ok. I had sdm prefer default IOS is: 12.2(44)SE2 IPACCESS ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR on ME3400
My guess is it would require set ip next-hop recursive to work even on an hypothetical platform that support such thing. Rubens On Mon, Jul 27, 2009 at 9:12 PM, MLm...@kenweb.org wrote: Has anyone on the list tried to perform PBR on the ME3400 while setting next hop to an IP at the far end of a GRE tunnel? I was attempting this today and the ME3400 seemed to ignore my PBR wishes. If the next hop was an IP off a routed port everything was ok. I had sdm prefer default IOS is: 12.2(44)SE2 IPACCESS ___ cisco-nsp mailing list cisco-...@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR/VRF sanity check...
Hello Jeff. I just implemented VRF and PBR on a 6500 720-CXL running SXI code, and have pushed 600Mb so far with switch CPU and Router CPU showing no increase. Jeff Fitzwater OIT Network Systems Princeton University On Mar 12, 2009, at 10:20 PM, Jeff Kell wrote: Aren't PBR and VRF mutually exclusive on all Catalysts, or are they possible concurrently on a 4500 or 6500? Jeff ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR/VRF sanity check...
I might mention that the set vrf is also in the SXI code and works on 6500 with 720-CXL. Jeff Fitzwater OIT Network Systems Princeton University On Mar 13, 2009, at 1:42 AM, Lincoln Dale wrote: Jeff Kell wrote: Aren't PBR and VRF mutually exclusive on all Catalysts, or are they possible concurrently on a 4500 or 6500? Catalyst 6500: see http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_mltvrf_slct_pbr.html Nexus 7000: you can certainly do 'set vrf' on PBR with it remaining in hardware switching path. cheers, lincoln. ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR/VRF sanity check...
Aren't PBR and VRF mutually exclusive on all Catalysts, or are they possible concurrently on a 4500 or 6500? Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR/VRF sanity check...
Hi Jeff, I've tested both PBR VRF on a 3550 with extended match routing SDM. It works, but adding VRF's when using PBR forced it to use software/CPU instead of hardware/ASIC forwarding. This caused max PBR + VRF throughput to be just over 30Mbps with 100% CPU. Don't know about the higher end platforms you've mentioned. regards, Tony. --- On Fri, 13/3/09, Jeff Kell jeff-k...@utc.edu wrote: From: Jeff Kell jeff-k...@utc.edu Subject: [c-nsp] PBR/VRF sanity check... To: 'NSP List' cisco-nsp@puck.nether.net Date: Friday, 13 March, 2009, 1:20 PM Aren't PBR and VRF mutually exclusive on all Catalysts, or are they possible concurrently on a 4500 or 6500? Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR/VRF sanity check...
Jeff Kell wrote: Aren't PBR and VRF mutually exclusive on all Catalysts, or are they possible concurrently on a 4500 or 6500? Catalyst 6500: see http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_mltvrf_slct_pbr.html Nexus 7000: you can certainly do 'set vrf' on PBR with it remaining in hardware switching path. cheers, lincoln. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR on a 6.5K
I have done some work on this recently under the 12.2(33)SRC2 codebase, and as far as I can tell it is a hardware limitation that putting a PBR to a tunnel is a software switched traffic path. This does hit the control-plane for every packet and without some other configuration there is no way around it - and Cisco has so far told me it is not in the planned list of improvements for the SR(x) train. However, I found an interesting work around, in that PBR-VRF is hardware switched. So pushing the traffic to a VRF, and having that VRF with a default route to the tunnel endpoint effectively pushes the traffic to the tunnel. The downside is that this is not truly bidirectional for the tunnel, so it depends on your application on if this work around would apply. - Eric Lent On Feb 26, 10:12 am, Tim Stevenson tstev...@cisco.com wrote: My sentence should have continued: ..., if you want it to do hardware-switched PBR. As Rodney pointed out, more recent s/w releases may have added this support, so could depend on what release you are running whether it is hw or sw switched. Tim At 12:29 AM 2/26/2009, Dan Pinkard stated: Thanks! It certainly happily accepts the command, and even does the right thing for the first few kpps. After that, not so much, which is where the whole question began. It just does so poorly that it never catches up… -- From: Tim Stevenson [mailto:tstev...@cisco.com] Sent: Wednesday, February 25, 2009 12:24 PM To: Dan Pinkard; cisco-...@puck.nether.net Subject: Re: [c-nsp] PBR on a 6.5K IIRC, 6500 does not support PBR with the recursive next hops, you must specify a directly connected next hop that you have a resolved adj for. Tim At 11:47 AM 2/25/2009, Dan Pinkard stated: What are the resource limitations on policy routing on SUP720s/MSFC3? Are the flows ultimately process switched every time or will it draw from the route-cache? We were toying with a very simple route-map that called for both a next-hop and a recursive next-hop route. A moderate (20mbps/14kpps) traffic level pegged the cpu and send IQD counters sky-high. Which leads to the basic question of what went wrong? Any ideas or observations from your own tests? Thanks! ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Technical Marketing Engineer, Cisco Nexus 7000 Cisco -http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Technical Marketing Engineer, Cisco Nexus 7000 Cisco -http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ cisco-nsp mailing list cisco-...@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsp archive athttp://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR on a 6.5K
Thanks! It certainly happily accepts the command, and even does the right thing for the first few kpps. After that, not so much, which is where the whole question began. It just does so poorly that it never catches up... From: Tim Stevenson [mailto:tstev...@cisco.com] Sent: Wednesday, February 25, 2009 12:24 PM To: Dan Pinkard; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] PBR on a 6.5K IIRC, 6500 does not support PBR with the recursive next hops, you must specify a directly connected next hop that you have a resolved adj for. Tim At 11:47 AM 2/25/2009, Dan Pinkard stated: What are the resource limitations on policy routing on SUP720s/MSFC3? Are the flows ultimately process switched every time or will it draw from the route-cache? We were toying with a very simple route-map that called for both a next-hop and a recursive next-hop route. A moderate (20mbps/14kpps) traffic level pegged the cpu and send IQD counters sky-high. Which leads to the basic question of what went wrong? Any ideas or observations from your own tests? Thanks! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com http://www.cisco.com/IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR on a 6.5K
My sentence should have continued: ..., if you want it to do hardware-switched PBR. As Rodney pointed out, more recent s/w releases may have added this support, so could depend on what release you are running whether it is hw or sw switched. Tim At 12:29 AM 2/26/2009, Dan Pinkard stated: Thanks! It certainly happily accepts the command, and even does the right thing for the first few kpps. After that, not so much, which is where the whole question began. It just does so poorly that it never catches up -- From: Tim Stevenson [mailto:tstev...@cisco.com] Sent: Wednesday, February 25, 2009 12:24 PM To: Dan Pinkard; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] PBR on a 6.5K IIRC, 6500 does not support PBR with the recursive next hops, you must specify a directly connected next hop that you have a resolved adj for. Tim At 11:47 AM 2/25/2009, Dan Pinkard stated: What are the resource limitations on policy routing on SUP720s/MSFC3? Are the flows ultimately process switched every time or will it draw from the route-cache? We were toying with a very simple route-map that called for both a next-hop and a recursive next-hop route. A moderate (20mbps/14kpps) traffic level pegged the cpu and send IQD counters sky-high. Which leads to the basic question of what went wrong? Any ideas or observations from your own tests? Thanks! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR on a 6.5K
What are the resource limitations on policy routing on SUP720s/MSFC3? Are the flows ultimately process switched every time or will it draw from the route-cache? We were toying with a very simple route-map that called for both a next-hop and a recursive next-hop route. A moderate (20mbps/14kpps) traffic level pegged the cpu and send IQD counters sky-high. Which leads to the basic question of what went wrong? Any ideas or observations from your own tests? Thanks! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR on a VRF interface?
Just trying to setup a simple next hop PBR on an interface in a VRF and I get the following output: % Policy Based Routing is NOT supported for VRF interfaces % IP-Policy can be used ONLY for marking (set/clear DF bit) on VRF interfaces Is this a version of code problem I'm having? IOS (tm) 7200 Software (C7200-IS-M), Version 12.2(40), RELEASE SOFTWARE (fc1) c7200-is-mz.122-40.bin What gives? Router#show route-map CUSTA2 route-map CUSTA2, permit, sequence 10 Match clauses: ip address (access-lists): 191 Set clauses: ip next-hop 172.16.1.194 Policy routing matches: 0 packets, 0 bytes Router#show access-list 191 Extended IP access list 191 permit ip 10.1.1.0 0.0.0.255 10.28.2.0 0.0.0.255 Router# Router#show run int gi4/0.37 Building configuration... Current configuration : 130 bytes ! interface GigabitEthernet4/0.37 encapsulation dot1Q 37 ip vrf forwarding CUSTA ip address 172.16.1.198 255.255.255.252 end Router#config t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface GigabitEthernet4/0.37 Router(config-subif)#ip policy route-map CUSTA2 % Policy Based Routing is NOT supported for VRF interfaces % IP-Policy can be used ONLY for marking (set/clear DF bit) on VRF interfaces Router(config-subif)#end Router# Brandon Price Network Engineer | Sterling Communications, Inc. 503.968.8908 x248 | 503.270.5285 fax | www.sterling.net Voice | Internet | Fax | CoLocation Learn more | www.sterling.net/video ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR on 6500
Hello All, I have a question about policy based routing on Cat6500. I want to split HTTP traffic and route it through proxy and route rest of the traffic straight to the internet. The only thing that worries me is will 6500 with sup720 be powerful enough to route 1-10Gbps of traffic with PBR. I know that sup720 does PBR in hardware (PFC) but I want to mach with acl on destination port so it will be L4 decision and I'm not sure will it forward in hardware or will fallback to process switching. My configuration would look like this: Access-list 123 permit tcp any any eq 80 Access-list 123 permit tcp any any eq 443 Access-list 123 permit tcp any any eq ftp ! Route-map WEB permit 10 Match ip address 123 Set ip netx-hop 1.2.3.4 ! Interface vlan123 Ip vrf TESTS1 Ip address 2.3.4.5 255.255.255.0 Ip policy route-map WEB Ip route-cache policy ! I thought I would add another VRF in front of FWSM in 6500 and will put PBR on it. My physical design looks like this: IP Cloud) =(Cisco SCE2020) = (Cat6513Sup720-FWSM-VRF-ACE-(OUT VRF)[rt import/export](VRF Intenet))=ASA55xx Maybe it's worth to mark interesting traffic on SCE with DSCP or something but I checked that on Cat6500 I can only do mach in route-map on access-list … All suggestions appreciated. Regards, Darius ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR noob question
Sorry for the late reply ... Nick's ip local policy route-map suggestion was exactly what I needed. Thanks! Adam - Original Message - From: Nick Griffin To: Adam Greene Cc: cisco-nsp@puck.nether.net Sent: Thursday, June 19, 2008 5:58 PM Subject: Re: [c-nsp] PBR noob question You can source traces from any interface on the router, try trace enter for extended options. You won't be able to test this from the router itself unless you configure ip local policy, to perform local policy routing. Nick Griffin On Thu, Jun 19, 2008 at 4:49 PM, Adam Greene [EMAIL PROTECTED] wrote: Hi, I'm setting up basic PBR on a remote router (3640, IOS 12.3(26)) and am having some problems testing whether it's working. access-list 20 permit 10.10.60.1 0.0.1.255 ! route-map Special_Subnet match ip address 20 set ip default next-hop 10.10.34.2 ! int f1/0 ip address 192.168.2.1 255.255.255.252 ! int f2/0 ip address 10.10.34.1 255.255.255.252 ! int f3/0 ip address 172.20.20.1 255.255.255.0 ip address 10.10.60.1 255.255.254.0 secondary ip policy route-map Special_Subnet ! ip route 0.0.0.0 0.0.0.0 192.168.2.2 I guess the main question is, when I ping from the router CLI, to an IP address not in the routing table, with a source address of 10.10.60.1, will the ping packets be sent to 10.10.34.2? Or will only the packets sent by hosts in the 10.10.60.0/23 range, connected to int f3/0, be sent to 10.10.34.2? Unfortunately, the IOS doesn't support the /source option on traceroute commands, so I can't test in that way, and at the moment, I have nothing connected to int f3/0 in the 10.10.60.1/23 range Thanks for your help, Adam ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR noob question
Hi, I'm setting up basic PBR on a remote router (3640, IOS 12.3(26)) and am having some problems testing whether it's working. access-list 20 permit 10.10.60.1 0.0.1.255 ! route-map Special_Subnet match ip address 20 set ip default next-hop 10.10.34.2 ! int f1/0 ip address 192.168.2.1 255.255.255.252 ! int f2/0 ip address 10.10.34.1 255.255.255.252 ! int f3/0 ip address 172.20.20.1 255.255.255.0 ip address 10.10.60.1 255.255.254.0 secondary ip policy route-map Special_Subnet ! ip route 0.0.0.0 0.0.0.0 192.168.2.2 I guess the main question is, when I ping from the router CLI, to an IP address not in the routing table, with a source address of 10.10.60.1, will the ping packets be sent to 10.10.34.2? Or will only the packets sent by hosts in the 10.10.60.0/23 range, connected to int f3/0, be sent to 10.10.34.2? Unfortunately, the IOS doesn't support the /source option on traceroute commands, so I can't test in that way, and at the moment, I have nothing connected to int f3/0 in the 10.10.60.1/23 range Thanks for your help, Adam ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR noob question
You can source traces from any interface on the router, try trace enter for extended options. You won't be able to test this from the router itself unless you configure ip local policy, to perform local policy routing. Nick Griffin On Thu, Jun 19, 2008 at 4:49 PM, Adam Greene [EMAIL PROTECTED] wrote: Hi, I'm setting up basic PBR on a remote router (3640, IOS 12.3(26)) and am having some problems testing whether it's working. access-list 20 permit 10.10.60.1 0.0.1.255 ! route-map Special_Subnet match ip address 20 set ip default next-hop 10.10.34.2 ! int f1/0 ip address 192.168.2.1 255.255.255.252 ! int f2/0 ip address 10.10.34.1 255.255.255.252 ! int f3/0 ip address 172.20.20.1 255.255.255.0 ip address 10.10.60.1 255.255.254.0 secondary ip policy route-map Special_Subnet ! ip route 0.0.0.0 0.0.0.0 192.168.2.2 I guess the main question is, when I ping from the router CLI, to an IP address not in the routing table, with a source address of 10.10.60.1, will the ping packets be sent to 10.10.34.2? Or will only the packets sent by hosts in the 10.10.60.0/23 range, connected to int f3/0, be sent to 10.10.34.2? Unfortunately, the IOS doesn't support the /source option on traceroute commands, so I can't test in that way, and at the moment, I have nothing connected to int f3/0 in the 10.10.60.1/23 range Thanks for your help, Adam ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR with NAT/PAT - strange (non-deterministic) behaviour
G'day oli, On Fri, Mar 7, 2008 at 7:02 PM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: Can you try adding match interface to the NAT route-maps? I.e. route-map App01-NAT-FOO1 permit 10 match ip address 125 match interface Serial0/1.742 Sigh! Thanks -- that was it. I was under the mistaken impression match interface was a match on the source/input interface. I blame a colleague :-) Can you explain why match interface works but match ip next-hop didn't? Is match ip next-hop not applicable to NAT route-maps? cheers, Dale ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR with NAT/PAT - strange (non-deterministic) behaviour
I have a PBR policy-map applied on each router's Fa0/0 interface (ingress). The route-map references an ACL that matches traffic I want to send in a direction the routing table would not otherwise have it go (i.e. S0/1.x instead of S0/0.x). To ensure symmetric routing, I want to source NAT (PAT) traffic leaving the interface to that interface's IP. All pretty straight-forward. Another requirement: if the interface specified by the 'set ip next-hop' parameter in the PBR route-map is down (e.g. S0/1.x), I want traffic to be routed as normal via S0/0.x (as I understand it should), but I want to do the same source NAT/PAT on the other interface -- in other words, if the traffic leaves S0/1.x, it should be source NATed to S0/1.x's IP and if it leaves S0/0.x, it should leave with S0/0.x's IP. [...] Here is the (annotated) config from the first router. The other router is configured in exactly the same way, apart from interface IPs, subint/DLCIs, and the 'set ip next-hop' value in the App01-PBR route-map. [...] ip nat inside source route-map App01-NAT-FOO1 interface Serial0/1.742 overload ip nat inside source route-map App01-NAT-FOO2 interface Serial0/0.740 overload ! access-list 125 remark ** match HTTP to server 1 ** access-list 125 permit tcp any host 192.168.91.67 eq www access-list 125 remark ** match HTTP to server 2 ** access-list 125 permit tcp any host 192.168.91.3 eq www Can you try adding match interface to the NAT route-maps? I.e. route-map App01-NAT-FOO1 permit 10 match ip address 125 match interface Serial0/1.742 and route-map App01-NAT-FOO2 permit 10 match ip address 125 match interface Serial0/0.740 a similar config is used in an example at http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_e xample09186a0080950834.shtml oli ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR with NAT/PAT - strange (non-deterministic) behaviour
Dale Shaw wrote on Friday, March 07, 2008 9:26 AM: G'day oli, On Fri, Mar 7, 2008 at 7:02 PM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: Can you try adding match interface to the NAT route-maps? I.e. route-map App01-NAT-FOO1 permit 10 match ip address 125 match interface Serial0/1.742 Sigh! Thanks -- that was it. I was under the mistaken impression match interface was a match on the source/input interface. I blame a colleague :-) Can you explain why match interface works but match ip next-hop didn't? Is match ip next-hop not applicable to NAT route-maps? match ip next-hop should also work. Not sure why it didn't, would need to see the full config.. but in your case, I'd work with interfaces (also use set interface in PBR route-map).. oli ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR with NAT/PAT - strange (non-deterministic) behaviour
Hi oli, On Fri, Mar 7, 2008 at 7:41 PM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: match ip next-hop should also work. Not sure why it didn't, would need to see the full config.. but in your case, I'd work with interfaces (also use set interface in PBR route-map).. I started off using 'set interface' in the PBR route-map -- I must've changed it during the troubleshooting process. I've changed it back now because I find it more 'readable'. Are there any other good reasons to use 'set interface' over 'set ip next-hop'? My 'match ip next-hop' config would've looked something like this: interface Serial0/0.740 point-to-point ip address 192.168.91.138 255.255.255.252 ! interface Serial0/1.742 point-to-point ip address 192.168.91.142 255.255.255.252 ! access-list 51 permit 192.168.91.137 ! access-list 52 permit 192.168.91.141 ! access-list 125 remark ** match HTTP to server 1 ** access-list 125 permit tcp any host 192.168.91.67 eq www access-list 125 remark ** match HTTP to server 2 ** access-list 125 permit tcp any host 192.168.91.3 eq www ! route-map App01-NAT-FOO1 permit 10 match ip address 125 match ip next-hop 51 ! route-map App01-NAT-FOO2 permit 10 match ip address 125 match ip next-hop 52 ! ip nat inside source route-map App01-NAT-FOO1 interface Serial0/1.742 overload ip nat inside source route-map App01-NAT-FOO2 interface Serial0/0.740 overload ! end cheers, Dale ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR with NAT/PAT - strange (non-deterministic) behaviour
Hi all, I'm trying to configure two 2611XMs to do PBR and NAT. The relevant config snippet is included below, but essentially one of the routers is doing what I want, and the other isn't. I suspect I'm hitting an IOS bug, or my config isn't quite right (hmmm, thanks captain obvious.) I have a PBR policy-map applied on each router's Fa0/0 interface (ingress). The route-map references an ACL that matches traffic I want to send in a direction the routing table would not otherwise have it go (i.e. S0/1.x instead of S0/0.x). To ensure symmetric routing, I want to source NAT (PAT) traffic leaving the interface to that interface's IP. All pretty straight-forward. Another requirement: if the interface specified by the 'set ip next-hop' parameter in the PBR route-map is down (e.g. S0/1.x), I want traffic to be routed as normal via S0/0.x (as I understand it should), but I want to do the same source NAT/PAT on the other interface -- in other words, if the traffic leaves S0/1.x, it should be source NATed to S0/1.x's IP and if it leaves S0/0.x, it should leave with S0/0.x's IP. The results: On one router, it works fine -- 'sh ip nat trans', 'sh ip cache flow' and 'sh policy int out' all show me what I want to see. On the other router (configured in exactly the same way aside from the obvious interface IP/next-hop differences), PBR is working and the traffic leaves the correct interface (S0/1.x), but it leaves the interface with S0/0.x's IP as a source! Asymmetric routing ensues. I think the two ip nat inside source route-map .. commands are clobbering each other, and it was probably just dumb luck that one router is working as intended and the other isn't. Both lines appear in the config, but perhaps only the last one entered actually works? Is there something I can do, perhaps in the NAT route-maps, to nail the config down and make it more deterministic? Upgrading the IOS is only really an option if I can pin this behaviour to a documented bug. Here is the (annotated) config from the first router. The other router is configured in exactly the same way, apart from interface IPs, subint/DLCIs, and the 'set ip next-hop' value in the App01-PBR route-map. ! IOS (tm) C2600 Software (C2600-IPBASE-M), Version 12.3(6c), RELEASE SOFTWARE (fc1) ! interface FastEthernet0/0 ! -- this is the ingress interface ! ip address 192.168.90.30 255.255.255.224 no ip redirects no ip proxy-arp ip nat inside ip flow ingress ip policy route-map App01-PBR ! interface Serial0/0 bandwidth 256 no ip address encapsulation frame-relay load-interval 30 frame-relay lmi-type ansi ! interface Serial0/0.740 point-to-point ! -- this is the way traffic would go under normal !conditions (no PBR). if S0/1.742 is down, traffic !should leave via this interface and be src !NAT'd to 192.168.91.138. ! bandwidth 128 ip address 192.168.91.138 255.255.255.252 no ip redirects no ip proxy-arp ip nat outside ip flow ingress frame-relay interface-dlci 740 ! interface Serial0/1 bandwidth 256 no ip address encapsulation frame-relay load-interval 30 frame-relay lmi-type ansi ! interface Serial0/1.742 point-to-point ! -- this is where I want policy-routed traffic !to go. Traffic should leave with a src !IP of 192.168.91.142. ! bandwidth 128 ip address 192.168.91.142 255.255.255.252 no ip redirects no ip proxy-arp ip nat outside ip flow ingress frame-relay interface-dlci 742 ! ip nat inside source route-map App01-NAT-FOO1 interface Serial0/1.742 overload ip nat inside source route-map App01-NAT-FOO2 interface Serial0/0.740 overload ! access-list 125 remark ** match HTTP to server 1 ** access-list 125 permit tcp any host 192.168.91.67 eq www access-list 125 remark ** match HTTP to server 2 ** access-list 125 permit tcp any host 192.168.91.3 eq www ! route-map App01-PBR permit 10 match ip address 125 set ip next-hop 192.168.91.141 ! ! -- even though the following route-maps are essentially the same, !I found I needed to use two, otherwise only one ip nat inside source .. !command was supported (each one needs/wants its own route-map?). ! route-map App01-NAT-FOO1 permit 10 match ip address 125 ! route-map App01-NAT-FOO2 permit 10 match ip address 125 ! ! -- I tried using match ip next-hop .. in the NAT route-maps above but !I couldn't make it work. I thought this might be a way to 'nail down' !the config a bit. ! end ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR and BGP Question
All, I have a need to direct traffic from within our core routers out a specific BGP peer unless that peer is down. Here is the setup.. customer network --- core router 03 and core router 04 border router 01 and border router 02 - our bgp peers.. Basically, the customer is connected to two 6500's running eigrp sessions with the border routers. The border routers are running BGP and eigrp. Border router 01 has a BGP connection to ISP A and Border router 02 has a BGP connection to ISP B. All routers are meshed together via GE. Core Routers are 6500's with sup1a/msfc2's fully upgraded with memory (yeah.. I know it should be upgraded to a sup2) and the border routers are 6500's with sup2/msfc2 also fully upgraded with memory. Ok, here is the question. If we would like to route all of the customer's traffic out ISP B unless it is down, is a PBR on the border routers identifying the source address and setting a next hop the best way of doing this? We don't care which ISP the incoming traffic goes to but want to control the outgoing traffic. Hopefully that gets the question across without a network diagram. Thanks for all who read and respond. jason ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR and BGP Question
How are you getting the default route into your core? If your ISP border routers, and core are running iBGP, simply use the local preference variable in BGP to send out the prefered ISP. If that ISP connection goes down, the next highest local pref will become the default. Depending on the routes you're receiving, and redistributing...If you're redistributing your BGP into an IGP, you can announce two default routes into your IGP, one with a higher metric, from each border router running BGP. in case of ISP failure, your traffic will get up to the ISP border routers, and then hopefully have a more specific route between iBGP, if one ISP connection were down. Traffic would then take its course back to the ISP border router with the active ISP connection. You can also play with EEM(I can't recall if its in the Sup1 or 2, but I'd wager no) to pull the default route from the isp border router, if the BGP session were to drop on that router, and then re-insert it when BGP session reconnects. --Pete On Jan 21, 2008 1:28 PM, Jason Ford [EMAIL PROTECTED] wrote: All, I have a need to direct traffic from within our core routers out a specific BGP peer unless that peer is down. Here is the setup.. customer network --- core router 03 and core router 04 border router 01 and border router 02 - our bgp peers.. Basically, the customer is connected to two 6500's running eigrp sessions with the border routers. The border routers are running BGP and eigrp. Border router 01 has a BGP connection to ISP A and Border router 02 has a BGP connection to ISP B. All routers are meshed together via GE. Core Routers are 6500's with sup1a/msfc2's fully upgraded with memory (yeah.. I know it should be upgraded to a sup2) and the border routers are 6500's with sup2/msfc2 also fully upgraded with memory. Ok, here is the question. If we would like to route all of the customer's traffic out ISP B unless it is down, is a PBR on the border routers identifying the source address and setting a next hop the best way of doing this? We don't care which ISP the incoming traffic goes to but want to control the outgoing traffic. Hopefully that gets the question across without a network diagram. Thanks for all who read and respond. jason ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR and BGP Question
We are sending the default routes via eigrp. BGP only runs on the border routers so using the BGP method probably won't work. I was looking at filtering out a subset of customer outgoing traffic and sending it over a cheaper bandwidth provider but I did not want to send all traffic out one or the other ISP. With that said, that was why I was looking at PBR or route maps to make this work. The selected traffic would be within a /28 or /29 subnet if that helps. Thanks for the response! jason Pete S. wrote: How are you getting the default route into your core? If your ISP border routers, and core are running iBGP, simply use the local preference variable in BGP to send out the prefered ISP. If that ISP connection goes down, the next highest local pref will become the default. Depending on the routes you're receiving, and redistributing...If you're redistributing your BGP into an IGP, you can announce two default routes into your IGP, one with a higher metric, from each border router running BGP. in case of ISP failure, your traffic will get up to the ISP border routers, and then hopefully have a more specific route between iBGP, if one ISP connection were down. Traffic would then take its course back to the ISP border router with the active ISP connection. You can also play with EEM(I can't recall if its in the Sup1 or 2, but I'd wager no) to pull the default route from the isp border router, if the BGP session were to drop on that router, and then re-insert it when BGP session reconnects. --Pete On Jan 21, 2008 1:28 PM, Jason Ford [EMAIL PROTECTED] wrote: All, I have a need to direct traffic from within our core routers out a specific BGP peer unless that peer is down. Here is the setup.. customer network --- core router 03 and core router 04 border router 01 and border router 02 - our bgp peers.. Basically, the customer is connected to two 6500's running eigrp sessions with the border routers. The border routers are running BGP and eigrp. Border router 01 has a BGP connection to ISP A and Border router 02 has a BGP connection to ISP B. All routers are meshed together via GE. Core Routers are 6500's with sup1a/msfc2's fully upgraded with memory (yeah.. I know it should be upgraded to a sup2) and the border routers are 6500's with sup2/msfc2 also fully upgraded with memory. Ok, here is the question. If we would like to route all of the customer's traffic out ISP B unless it is down, is a PBR on the border routers identifying the source address and setting a next hop the best way of doing this? We don't care which ISP the incoming traffic goes to but want to control the outgoing traffic. Hopefully that gets the question across without a network diagram. Thanks for all who read and respond. jason ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR performance gotchas
Hi, On 9/6/07, Andrew Milner [EMAIL PROTECTED] wrote: Greetings We're contemplating a design that would make extensive use of policy based routing on our 7600 RSP720/WS-6704's.. Back in the day, you'd never do something like that because of performance but now it seems like that is fixed? I don't have the means to test in a lab environment, so I'm just wondering if anyone has any experience with this and might be able to help me determine if/when this will fall over. Thanks in advance for any help, Andrew PBR on 7600 is done in PFC (DFC) in CEF path, but PBR is just an ugly hack, i would rather use VRs. There are some restrictions that you should be aware of: –The PFC does not provide hardware support for PBR configured with the *set ip next-hop* keywords if the next hop is a tunnel interface. –If the MSFC address falls within the range of a PBR ACL, traffic addressed to the MSFC is policy routed in hardware instead of being forwarded to the MSFC. To prevent policy routing of traffic addressed to the MSFC, configure PBR ACLs to deny traffic addressed to the MSFC. –Any options in Cisco IOS ACLs that provide filtering in a PBR route-map that would cause flows to be sent to the MSFC to be switched in software are ignored. For example, logging is not supported in ACEs in Cisco IOS ACLs that provide filtering in PBR route-maps. - PBR traffic through switching module ports where PBR is configured is routed in software if the switching module resets. (CSCee92191) should be fixed in SXE -- iso ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR to change default gateway for an IP?
Can you help a dead-tired engineer? ;) We've got an IP pon our network that needs to use a different route out to the world, but for lots of reasons, we can't change it on the device itself.. it's currently pointed at an interface on a 6509. From what I recall, we can set up PBR to say that anything from the source IP of this device should go out a different path than the default - am I remembering right? Anyone got an example? My google-fu is being seriously hampered by too many 15 hour days lately. ;( So, here's an example with some IP's: Device info: IP address: 10.0.0.1/24 Default gateway: 10.0.0.254 6509 config: IP address: 10.0.0.254/24, 172.16.1.1 Default gateway: 172.16.1.254 From 10.0.0.1, we need traffic to 192.168.0.0/16 to go via the 6509's standard default gateway (172.16.1.254), but need the rest of the traffic to go out via a vendor-provided gateway (10.0.0.2). Unfortunately, the device does not allow us to add any routes (all we can have is a default gateway). Normally my solution would be to point the gateway at 10.0.0.2 and add routes on it back to our internal network, but that device is a PIX running 6.3, and it won't allow traffic to route back out the same interface. ;( I'd appreciate any examples!! -Nate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR on 3750
Hi, I am trying to implement the following PBR on 3750 but somehow when i issue the command 'ip policy route-map hpc' on the routed port of the switch it accept it but in sh running it doesn't appear, details are below. Plz suggest what can be wrong. Regards -Azher L3#sh runn ip routing .. route-map hpc permit 10 match ip address 21 set ip next-hop 10.10.4.70 . interface GigabitEthernet1/0/25 no switchport ip address 192.168.10.17 255.255.255.248 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR Strange behavior
--- [EMAIL PROTECTED] wrote: Bear in mind 'ip policy route-map BLAH' has no effect on self generated packets. ...though 'ip local policy route-map BLAH' will; not the ideal way to test, but often will do. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR Strange behavior
Bear in mind 'ip policy route-map BLAH' has no effect on self generated packets. In your test, are the packets matching the ACL sourced from 172.20.0.49 (router itself) or 172.20.0.50? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of omar parihuana Sent: 03 July 2007 00:17 To: nsp Subject: [c-nsp] PBR Strange behavior Hi List, I've configured an policy routing, however the packets don't match the policy. I re-checked the configuration and all seems fine, I don't know why that configuration don't work!!! (the packets traverse by default route and not by Next-hop configured into route-map. I've paste my configuration: ! interface FastEthernet0/0.73 encapsulation dot1Q 73 ip address 172.20.0.49 255.255.255.252 no ip redirects no ip proxy-arp ip policy route-map NEXT-HOP no cdp enable arp timeout 300 end ! ! route-map NEXT-HOP permit 10 match ip address 160 set interface Serial1/0:0 set ip next-hop 172.16.1.134 ! ! access-list 160 permit ip 172.20.0.48 0.0.0.3 any ! Thanks *The router is a Cisco 3640 with CEF Enabled that works like MPLS-PE router. -- Omar E.P.T - Certified Networking Professionals make better Connections! ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR Strange behavior [NC]
Which Ios version are you using ? I know there is a bug in the 12.4 , i have experienced it myself .. Rgds David [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 03/07/07 00:17 To cisco-nsp@puck.nether.net cc Subject [c-nsp] PBR Strange behavior Hi List, I've configured an policy routing, however the packets don't match the policy. I re-checked the configuration and all seems fine, I don't know why that configuration don't work!!! (the packets traverse by default route and not by Next-hop configured into route-map. I've paste my configuration: ! interface FastEthernet0/0.73 encapsulation dot1Q 73 ip address 172.20.0.49 255.255.255.252 no ip redirects no ip proxy-arp ip policy route-map NEXT-HOP no cdp enable arp timeout 300 end ! ! route-map NEXT-HOP permit 10 match ip address 160 set interface Serial1/0:0 set ip next-hop 172.16.1.134 ! ! access-list 160 permit ip 172.20.0.48 0.0.0.3 any ! Thanks *The router is a Cisco 3640 with CEF Enabled that works like MPLS-PE router. -- Omar E.P.T - Certified Networking Professionals make better Connections! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ * This message and any attachments (the message) are confidential and intended solely for the addressee(s). Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Ce message et toutes les pieces jointes (ci-apres le message) sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. * ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PBR Strange behavior
Hi List, I've configured an policy routing, however the packets don't match the policy. I re-checked the configuration and all seems fine, I don't know why that configuration don't work!!! (the packets traverse by default route and not by Next-hop configured into route-map. I've paste my configuration: ! interface FastEthernet0/0.73 encapsulation dot1Q 73 ip address 172.20.0.49 255.255.255.252 no ip redirects no ip proxy-arp ip policy route-map NEXT-HOP no cdp enable arp timeout 300 end ! ! route-map NEXT-HOP permit 10 match ip address 160 set interface Serial1/0:0 set ip next-hop 172.16.1.134 ! ! access-list 160 permit ip 172.20.0.48 0.0.0.3 any ! Thanks *The router is a Cisco 3640 with CEF Enabled that works like MPLS-PE router. -- Omar E.P.T - Certified Networking Professionals make better Connections! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PBR Strange behavior
Hi Omar, verify the source address of your packets. Your configuration is correct. Is possible that your packets didn't have a source address from 172.20.0.48/30 subnet. Try change the 'match ip address 160' by the following command: 'match interface FastEthernet0/0.73' This will match all packets coming from interface FastEthernet0/0.73. Another way is to rebuild your ACL 160 with the correct source address of your packets. Regards, Diogo On 7/2/07, omar parihuana [EMAIL PROTECTED] wrote: Hi List, I've configured an policy routing, however the packets don't match the policy. I re-checked the configuration and all seems fine, I don't know why that configuration don't work!!! (the packets traverse by default route and not by Next-hop configured into route-map. I've paste my configuration: ! interface FastEthernet0/0.73 encapsulation dot1Q 73 ip address 172.20.0.49 255.255.255.252 no ip redirects no ip proxy-arp ip policy route-map NEXT-HOP no cdp enable arp timeout 300 end ! ! route-map NEXT-HOP permit 10 match ip address 160 set interface Serial1/0:0 set ip next-hop 172.16.1.134 ! ! access-list 160 permit ip 172.20.0.48 0.0.0.3 any ! Thanks *The router is a Cisco 3640 with CEF Enabled that works like MPLS-PE router. -- Omar E.P.T - Certified Networking Professionals make better Connections! ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
