[c-nsp] ISDN 2x64kbps

2008-10-29 Thread ambedkar
  
Hi,
This is Ambi from india. i am using ISDN connectivity between two 
remote places. i am having one ISDN number which is having 2x64kbps 
capability. when i am connecting with this ISDN number, i am able to 
connect only one B-channel and second B-channel is unable to 
establish.
i have configured the router with the following parameters.

interface BRI1/0
no ip address
encapsulation ppp
dialer pool-member 1
isdn switch-type basic-net3
.
.
.
.
interface Dialer1
ip address 192.168.1.2 255.255.255.0
encapsulation ppp
dialer pool 1
dialer idle-timeout 600
dialer string xx
dialer-group 1
!
and vice-versa.

please help me in this regard.
bye.
___
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] ISDN 2x64kbps

2008-10-29 Thread Muhammad Salman Zahid
configure the BRI inerface instead of dialer interface.



On Wed, Oct 29, 2008 at 12:42 PM, ambedkar [EMAIL PROTECTED]wrote:


 Hi,
 This is Ambi from india. i am using ISDN connectivity between two
 remote places. i am having one ISDN number which is having 2x64kbps
 capability. when i am connecting with this ISDN number, i am able to
 connect only one B-channel and second B-channel is unable to
 establish.
 i have configured the router with the following parameters.

 interface BRI1/0
 no ip address
 encapsulation ppp
 dialer pool-member 1
 isdn switch-type basic-net3
 .
 .
 .
 .
 interface Dialer1
 ip address 192.168.1.2 255.255.255.0
 encapsulation ppp
 dialer pool 1
 dialer idle-timeout 600
 dialer string xx
 dialer-group 1
 !
 and vice-versa.

 please help me in this regard.
 bye.
 ___
 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/




-- 
Death is no the greatest loss in life 
The greatest loss is what dies inside
 you while U live...!
___
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] Metro Ethernet CPE

2008-10-29 Thread FAHAD ALI KHAN
Guys...!

We are looking for good range of CPE (routers) for Home users  SMBs...and
wish if following features are supported.

   - FastEthernet port for WAN  LAN
   - 802.1Q Trunking support on both FEs
   - IPv4 support (IPv6 is optional)
   - PPPoE support on FastEthernet main/Sub-interface (didnt find it in 1800
   ISR)
   - Basic QoS feature set
   - GRE/IPSEC support
   - Static/RIP/OSPF/BGP support
   - Network Management support - SNMP
   - BFD or ELMI support
   - DHCP client


What will be the best suited  cost effective CPE for offering triple play
services over Metro Ethernet Network.

Input from Metro Ethernet Service provider will be highly appreciable.


*Regards*
**
*Fahad*
___
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] ISDN 2x64kbps

2008-10-29 Thread Salik Mobin
You can optionally use the following command to set up a threshold of load
on which the second channel (in a BRI link) becomes active. 

Router(config-if)#dialer load-threshold VVV either 

where VVV is a number between 1 and 255, 1 being the minimum load and 255
being %100 load on the first channel. This means that this command tells the
router to activate the second channel once the first one is VVV/255 loaded. 

Regards,
Salik 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ambedkar
Sent: Wednesday, October 29, 2008 12:43 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ISDN 2x64kbps

  
Hi,
This is Ambi from india. i am using ISDN connectivity between two 
remote places. i am having one ISDN number which is having 2x64kbps 
capability. when i am connecting with this ISDN number, i am able to 
connect only one B-channel and second B-channel is unable to 
establish.
i have configured the router with the following parameters.

interface BRI1/0
no ip address
encapsulation ppp
dialer pool-member 1
isdn switch-type basic-net3
.
.
.
.
interface Dialer1
ip address 192.168.1.2 255.255.255.0
encapsulation ppp
dialer pool 1
dialer idle-timeout 600
dialer string xx
dialer-group 1
!
and vice-versa.

please help me in this regard.
bye.
___
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] Router comparison scorecard

2008-10-29 Thread Hank Nussbacher

http://www.cisco.com/web/partners/downloads/765/tools/quickreference/isr.pdf

On the 3845 are listed 2 notes #7  #9 and I can't find those notes listed 
in this handy 4 page doc.


What am I missing?

Thanks,
Hank

___
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] MVPN

2008-10-29 Thread Christian Meutes

I just tested it in SM mode. What happens is that no more streams can be
send because of the exhaustion of all data-mdt's. Switchover to data-mdt
is configured to 1 and as soon as traffic arrives a data-mdt is tried
to open and unfortunately fails therefore.


Really? That's got to be a bug. What platform are you on?


What should be the behavior if no bug would be insolved? Continue to stream 
the new group to the default-mdt?



The only solution as far as I can see is to do SSM without a data-mdt.
Sure I could also use SM without a data-mdt but that would concentrate
everything on the RP which would be the worst case of all.


You seem to be mis-understanding how PIM-SM works. When a source starts
up, only the *first few* packets are tunneled via the RP; these few are
forwarded down the shared tree, which triggers the other PEs to do a join
to source, and the traffic then flows optimally; the RP will then send a
Register-Stop to the PE of the source, which stops the tunneling.


No Iam not mis-understanding how PIM-SM works :-)

What i tried to explain was that if no more than 255 data-mdt's can be 
created how can I stream to more than 255 multicast groups: Only solution 
would be to do it without a data-mdt which would result in forwarding 
everything over the Core-RP (default-mdt) with PIM-SM or to do it in 
PIM-SSM and forward everything to every PE but at least on the shortest 
reverse-path (SPT).





___
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] BGP policy accounting mib can only collect from real interfaces?

2008-10-29 Thread David Freedman
Question,

 in 7200/12.2(33)SRC2, configuring BGP policy accounting on a subinterface (and 
not any real interfaces) collects staticstics happily (show cef int X policy) 
but when attempting to walk the policy accounting mib it fails miserably with 
No Such Object available on this agent at this OID

If you configure policy accounting on a real interface (say, the main trunk 
interface) the mib tree magically becomes available , but is instead filled 
with nothing, which would lead me to believe the mib can only collect from real 
interfaces, is this the case? is it a known restriction?

A bit of googling suggests CSCds01865 could be to blame for this?



David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net

___
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] MVPN

2008-10-29 Thread Phil Mayers

Christian Meutes wrote:

I just tested it in SM mode. What happens is that no more streams can be
send because of the exhaustion of all data-mdt's. Switchover to data-mdt
is configured to 1 and as soon as traffic arrives a data-mdt is tried
to open and unfortunately fails therefore.


Really? That's got to be a bug. What platform are you on?


What should be the behavior if no bug would be insolved? Continue to 
stream the new group to the default-mdt?


Well, I'm beginning to doubt my own understanding now, but I was under 
the impression that the mapping of VPN group - data group was a hash, 
and that 1 VPN group could map to a data group; so when you reach ~255 
groups, some of the data MDTs would be re-used.


http://www.cisco.com/en/US/products/ps6604/products_qanda_item09186a00800a85be.shtml

Q. What happens if the throughput of a customer's stream surpasses the 
Data MDT threshold and all Data MDTs are being used?


A. If the maximum number of Data MDTs already exists, the group 
addresses are reused. This may mean that some PEs receive CE data to 
which they have not subscribed.







The only solution as far as I can see is to do SSM without a data-mdt.
Sure I could also use SM without a data-mdt but that would concentrate
everything on the RP which would be the worst case of all.


You seem to be mis-understanding how PIM-SM works. When a source starts
up, only the *first few* packets are tunneled via the RP; these few are
forwarded down the shared tree, which triggers the other PEs to do a join
to source, and the traffic then flows optimally; the RP will then send a
Register-Stop to the PE of the source, which stops the tunneling.


No Iam not mis-understanding how PIM-SM works :-)


Ok, sorry.



What i tried to explain was that if no more than 255 data-mdt's can be 
created how can I stream to more than 255 multicast groups: Only 
solution would be to do it without a data-mdt which would result in 
forwarding everything over the Core-RP (default-mdt) with PIM-SM or to 
do it in PIM-SSM and forward everything to every PE but at least on the 
shortest reverse-path (SPT).


Both PIM-SM and PIM-SSM will build an SPT for both default  data MDTs.

The only difference is that in PIM-SM, the first few packets from a PE 
are sent via shared tree, which triggers the other PEs to do the PIM 
join, whereas in PIM-SSM an out-of-band mechanism (either BGP type2 RDs 
or MDT SAFI) triggers the PIM join.


Am I being clear? Basically, the RP should not see any significant load 
even in PIM-SM - a couple of packets per PE per 90 seconds as PIM null 
registers are triggered.


We have this working - 10mbit/sec IPTV groups do *not* hit the RP.
___
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] CSCsl44301 - NVRAM corruption on GSR

2008-10-29 Thread David Freedman
Can anybody from cisco on here confirm that this is fixed in 12.0(33)S1 (bug 
does not mention a first-fixed-in but also does not mention (33)S1 being an 
affected version), and also how one would recover from this , 
tried erasing /all the nvram multiple times, physical reboots of the box etc.. 


David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net

___
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] MVPN

2008-10-29 Thread Phil Mayers

Christian Meutes wrote:

Hi Phil,


As far as I can see, SSM would only be of specific help if the 255
groups were coming from 1 PE. You'd still have problems with 255 groups
on 1 PE using SSM.


Even then I could use different data-mdt's for every PE in same VRF in
SM mode or not?


The traffic will not flow via the RP, since all the PEs should have
joined towards the other PEs for the default or data group in question.

The issue is that some traffic might be sent to PEs which have no
interest in it (if you have more active MVPN groups than data groups, or
if it's flowing in the mdt default) but it will still flow on the source
tree in the P-space, not the shared tree.

Whether that's actually a problem depends on the bit rate of the traffic,
number of PEs and types of links. Not the most helpful answer I'm afraid.


I just tested it in SM mode. What happens is that no more streams can be
send because of the exhaustion of all data-mdt's. Switchover to data-mdt
is configured to 1 and as soon as traffic arrives a data-mdt is tried
to open and unfortunately fails therefore.


Really? That's got to be a bug. What platform are you on?



The only solution as far as I can see is to do SSM without a data-mdt.
Sure I could also use SM without a data-mdt but that would concentrate
everything on the RP which would be the worst case of all.


You seem to be mis-understanding how PIM-SM works. When a source starts 
up, only the *first few* packets are tunneled via the RP; these few are 
forwarded down the shared tree, which triggers the other PEs to do a 
join to source, and the traffic then flows optimally; the RP will then 
send a Register-Stop to the PE of the source, which stops the tunneling.




Or do I miss something?

cheers,
Christian





___
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] Metro Ethernet CPE

2008-10-29 Thread Brian Raaen
Depending on the types of clients and price you can get.  If you want to offer 
something better than the SOHO Linksys variety, I have been pretty pleased 
with the Cisco 871 and 871W that I have.  I have also gotten a friend that I 
have done some consulting for to get one and he has been very pleased with 
it.  I am not sure about the exact price, but they are somewhere around $600 
for the wired and about $800 for the wireless.  Hope this helps.


--

Brian Raaen
Network Engineer
[EMAIL PROTECTED]


On Wednesday 29 October 2008, FAHAD ALI KHAN wrote:
 Guys...!
 
 We are looking for good range of CPE (routers) for Home users  SMBs...and
 wish if following features are supported.
 
- FastEthernet port for WAN  LAN
- 802.1Q Trunking support on both FEs
- IPv4 support (IPv6 is optional)
- PPPoE support on FastEthernet main/Sub-interface (didnt find it in 1800
ISR)
- Basic QoS feature set
- GRE/IPSEC support
- Static/RIP/OSPF/BGP support
- Network Management support - SNMP
- BFD or ELMI support
- DHCP client
 
 
 What will be the best suited  cost effective CPE for offering triple play
 services over Metro Ethernet Network.
 
 Input from Metro Ethernet Service provider will be highly appreciable.
 
 
 *Regards*
 **
 *Fahad*
 ___
 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] full BGP route in 7600

2008-10-29 Thread moshe mizrachi
hi ,
i have 7609s with RSP3CXL running SRC2 +  7600-ES20-10G3C(2*10Gig) +SIP400
with SPA-OC12 .
via the OC12  there is BGP peer that getting full route bgp , the problem is
that the ES20 is 3C
with DFC  with limition  of  memory, is there any creative idea how to solve
it without upgrading the
ES20-10G3C  to ES20-10G3CXL

regards moshe
___
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] OSPF fast hellos

2008-10-29 Thread Rodney Dunn
Why don't you use BFD instead. It's designed with something called
pseudo preemption from an OS scheduler perspective that helps
reduce false positives and the fact that BFD frames are handled
under interrupt and not process scheduled for rx/tx.

Rodney

On Wed, Oct 29, 2008 at 04:09:45PM +1030, Ben Steele wrote:
 Anyone currently using this in a fairly demanding environment? Ie 5-10Gbs+
 Campus/DC model.
 
  
 
 Curious as to whether you've had any/many false dead peers with such a short
 interval, subsecond dead peer detection does sound very temping though.
 
  
 
 Cheers
 
  
 
 Ben
 
  
 
  
 
 ___
 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] Bonded DSL with Cisco 1800/877's

2008-10-29 Thread Adam Greene

Skeeve,

Not sure if this completely fits your situation, but at least it will give 
you something to chew on ...


Multilink PPP working with ADSL (1841 IOS 12.4(17)). Configs below are based 
on getting direct pvc's from Verizon.


Thanks,
Adam



===
CONFIGS
===


---
ISP END
---

interface Multilink1
ip unnumbered Loopback0
ppp multilink
ppp multilink group 1
!
interface ATM1/0.2106 point-to-point
ip unnumbered Loopback0
pvc 2/106
 protocol ppp Virtual-Template2
!
!
interface ATM1/0.2107 point-to-point
ip unnumbered Loopback0
pvc 2/107
 protocol ppp Virtual-Template2
!
!
interface Virtual-Template2
no ip address
ppp multilink
ppp multilink group 1



--
CLIENT END
--

interface Multilink1
ip address x.x.x.x y.y.y.y
ip virtual-reassembly
ppp multilink
ppp multilink group 1
!
interface ATM0/0/0
no ip address
no ip mroute-cache
no atm ilmi-keepalive
dsl operating-mode auto
hold-queue 224 in
pvc 0/35
 protocol ppp Virtual-Template1
!
!
interface ATM0/1/0
no ip address
no ip mroute-cache
no atm ilmi-keepalive
dsl operating-mode auto
hold-queue 224 in
pvc 0/35
 protocol ppp Virtual-Template1
!
!
interface Virtual-Template1
no ip address
ppp multilink
ppp multilink group 1




- Original Message - 
From: Skeeve Stevens [EMAIL PROTECTED]
To: 'Moerman, Maarten' [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
cisco-nsp@puck.nether.net

Sent: Tuesday, October 28, 2008 11:06 PM
Subject: Re: [c-nsp] Bonded DSL with Cisco 1800/877's



Maarten, awesome configs and I thank you very much for those... great
resource.


From the other perspective... do you, or anyone else know, about what is

required on the ISP's end to do multi-link?

We take DSL tails from multiple providers and they land on our 7200 LNS. 
Is

there any specific config I have to do to allow/support ppp multi-link
services?

...Skeeve

-Original Message-
From: Moerman, Maarten [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 29 October 2008 11:13 AM
To: [EMAIL PROTECTED]; cisco-nsp@puck.nether.net; [EMAIL PROTECTED]
Subject: RE: [c-nsp] Bonded DSL with Cisco 1800/877's

The previous company i've worked for, i did setup bonding/bundling on 
cisco

1841's and cisco 28xx..

I've made templates of those configuration files, I see they did change 
some

things in those files, but here they are:
ftp://dl.solcon.nl/pub/dsl/configs/Cisco/

I think some people of solcon are also on this list (Rinse?) maybe they 
can

post an example of how the virtual-template is being done on the NRP's
(don't have access anymore :) )

Maarten


-Original Message-
From: [EMAIL PROTECTED] on behalf of Tony
Sent: Wed 10/29/2008 1:01 AM
To: cisco-nsp@puck.nether.net; [EMAIL PROTECTED]
Subject: Re: [c-nsp] Bonded DSL with Cisco 1800/877's

Skeeve,

Being in the same country as you, I know all about your problems with DSL
and what you're trying to achieve :)

We don't worry about an 1800, just have two 877 CPE's. On the 877 that is
the default gateway for the site, it has routes like this:

ip route 0/0 dialer1
ip route 0/0 lan_ip_of_other_877

The other 877 just has a single static route to the dialer interface.

In the central site, we have the same, two equal cost routes pointing to 
the

IP address of the dialer interface/IP of each the two 877's.

It seems to work ok and also has the benefit that if one link goes down 
you

can adjust a few routes and push everything onto the one remaining link.

As per the article linked by a previous poster:
http://blog.ioshints.info/2008/09/load-balancing-quirks.html

You need to remember that traffic between two hosts (on either end of the
link) will only be routed over ONE of the links at a time. This means that 
a

single host doing a large transfer will only max out ONE of the links and
not see the full bandwidth (make sure you are VERY clear to your customer
about this aspect).

We tend to use this a lot where we have branch offices that are doing
Citrix/MSTSC over the link and so there are lots of smaller bandwidth
traffic flows that balance fairly well across the two links. They outgrow 
a

512/512 link and as you well know, there is nothing to upgrade to in a lot
of cases.


regards,
Tony.



Not having the time/budget to research the full
implications myself I am
approaching the list for advice.


Making excuses for your laziness isn't a good way to start a request 
asking

for help ;)


--- On Wed, 29/10/08, Skeeve Stevens [EMAIL PROTECTED] wrote:


From: Skeeve Stevens [EMAIL PROTECTED]
Subject: [c-nsp] Bonded DSL with Cisco 1800/877's
To: cisco-nsp@puck.nether.net
Date: Wednesday, 29 October, 2008, 12:11 AM
Hey all,

Not having the time/budget to research the full
implications myself I am
approaching the list for advice.

In Australia we can do either ADSL, ADSL2/2+ or SHDSL for
the most part.

I have a client wanting more bandwidth than any single of
these connections
can provide, without the availability of any other
offering.

The aim - to provide as much bandwidth as possible using

[c-nsp] Quad FWSM

2008-10-29 Thread jcovini
Hi gents,

Little question about FWSM redundancy. I didn't attend the trainings :)

Scenario :
- Four 6500/Sup7203bxl
- Each one has a FWSM card.

Is it possible to have FWSM in an Active/Stby/Stby/Stby setup ?
Or does failover only works by pair ?

Jerome
___
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] Default Route behaviour on PIX

2008-10-29 Thread Nick Griffin
In your lab, on your interface on your router facing your fix, fas 0/0 for
example do show ip int fas0/0 | i Proxy and you'll see that proxy arp is
enabled. The pix is trying to forward to 1.1.1.1 and the router is probably
doing proxy arp, assuming your router thinks it knows how to get to 1.1.1.1.


http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094adb.shtml



On Tue, Oct 28, 2008 at 11:08 PM, Nic Passmore [EMAIL PROTECTED]wrote:

 All,

 This may be one of those things you know after working with PIX but I
 just can't seem to get my head around it. Say I have a PIX that is
 connected to a DSL router and is filtering traffic. The DSL connection
 has a ppp negotiated IP address from the ISP. The ISP is also routing
 a /30 via said address that is used to connect between the DSL router
 and the PIX (if it makes any difference, the DSL router in this case
 is an 827).

 The next-hop address set in the default route on this PIX is a
 nonsense address. It is definitely not a valid next-hop address.
 Despite this fact, the PIX still happily seems to forward traffic
 (this is working at the moment). I set the same configuration up in a
 lab and it exhibited the same behavior. The lab has a router connected
 to the Internet via the 30.30.30.0/30 network. The edge router and
 the PIX are connected via 30.30.40.0/30. If I set the next hop of the
 default route to 30.30.40.1 (the edge router side), traffic flows. If
 I set the next hop of the default route to 1.1.1.1, traffic flows?

 Is this a known thing? The PIX appears to just throw the traffic onto
 the outbound interface and hope for the best? Ive tried this with both
 PIXOS 6.x and 7.x, both of which same to exhibit the same behavior.
 Ive included a snippet of the PIX config from the lab... in the hopes
 that maybe it is something I am doing?

  I would appreciate any insight..

 Cheers,

 Nic

 --- PIX Config from Lab --

 interface Ethernet0
  description Link to EDGE FA0/1
  nameif Outside
  security-level 0
  ip address 30.30.40.2 255.255.255.252
 !
 interface Ethernet1
  description Link to CLIENT FA0/0
  nameif Inside
  security-level 100
  ip address 192.168.1.254 255.255.255.0
 !
 access-list Outside-IN extended permit ip any any
 access-list Outside-OUT extended permit ip any any
 access-list Inside-IN extended permit ip any any
 access-list Inside-OUT extended permit ip any any
 !
 global (Outside) 10 interface
 nat (Inside) 10 0.0.0.0 0.0.0.0
 access-group Outside-IN in interface Outside
 access-group Outside-OUT out interface Outside
 access-group Inside-IN in interface Inside
 access-group Inside-OUT out interface Inside
 route Outside 0.0.0.0 0.0.0.0 1.1.1.1 1
 ___
 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] OSPF fast hellos

2008-10-29 Thread Tim Jackson
When is BFD going to not be limited to 7600/12k/CRS?

And when can we get BFD on an SVI (or back on an SVI, iirc SRB supports
this, but SRC doesn't?) or a port-channel?

Until Cisco actually has BFD working on more than a few platforms, I'll
stick with fast hellos since it seems to work on more platforms and in more
configurations...

--
Tim

On Wed, Oct 29, 2008 at 8:10 AM, Rodney Dunn [EMAIL PROTECTED] wrote:

 Why don't you use BFD instead. It's designed with something called
 pseudo preemption from an OS scheduler perspective that helps
 reduce false positives and the fact that BFD frames are handled
 under interrupt and not process scheduled for rx/tx.

 Rodney

 On Wed, Oct 29, 2008 at 04:09:45PM +1030, Ben Steele wrote:
  Anyone currently using this in a fairly demanding environment? Ie
 5-10Gbs+
  Campus/DC model.
 
 
 
  Curious as to whether you've had any/many false dead peers with such a
 short
  interval, subsecond dead peer detection does sound very temping though.
 
 
 
  Cheers
 
 
 
  Ben
 
 
 
 
 
  ___
  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] full BGP route in 7600

2008-10-29 Thread Hank Nussbacher

At 03:07 PM 29-10-08 +0200, moshe mizrachi wrote:

hi ,
i have 7609s with RSP3CXL running SRC2 +  7600-ES20-10G3C(2*10Gig) +SIP400
with SPA-OC12 .
via the OC12  there is BGP peer that getting full route bgp , the problem is
that the ES20 is 3C
with DFC  with limition  of  memory, is there any creative idea how to solve
it without upgrading the
ES20-10G3C  to ES20-10G3CXL


Single BGP peer?  So use an ACL to trim the RIB.  Others have done it and I 
believe listed it here.  You lose granularity but all should work if it is 
a single BGP peer.


-Hank

___
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] CSCsl44301 - NVRAM corruption on GSR

2008-10-29 Thread David Freedman
Well, have replaced the NVRAM by replacing the PRP and all is now well,
have discovered that the problem occured when writing the ifIndex-table
which was being truncated by 337 bytes , disabling ifIndex persistance
made the problem go away until the PRP was replaced.

Am concerned that somehow this bug causes permanent changes to the NVRAM
which requires it to be replaced, if anybody knowing more could comment
would be greatful but have opened a TAC case for the time being.

Dave.

David Freedman wrote:
 Can anybody from cisco on here confirm that this is fixed in 12.0(33)S1 (bug 
 does not mention a first-fixed-in but also does not mention (33)S1 being an 
 affected version), and also how one would recover from this , 
 tried erasing /all the nvram multiple times, physical reboots of the box 
 etc.. 
 
 
 David Freedman
 Group Network Engineering 
 Claranet Limited
 http://www.clara.net
 
 ___
 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] OSPF fast hellos

2008-10-29 Thread Rodney Dunn
On Wed, Oct 29, 2008 at 08:40:16AM -0500, Tim Jackson wrote:
 When is BFD going to not be limited to 7600/12k/CRS?


It's on the ISR's.
Other support (ie: WAN interfaces) are in the works.
 
 And when can we get BFD on an SVI (or back on an SVI, iirc SRB supports this,
 but SRC doesn't?) or a port-channel?

Haven't checked on that.

 
 Until Cisco actually has BFD working on more than a few platforms, I'll stick
 with fast hellos since it seems to work on more platforms and in more
 configurations...

That's fair.

Rodney


 
 --
 Tim
 
 On Wed, Oct 29, 2008 at 8:10 AM, Rodney Dunn [EMAIL PROTECTED] wrote:
 
 Why don't you use BFD instead. It's designed with something called
 pseudo preemption from an OS scheduler perspective that helps
 reduce false positives and the fact that BFD frames are handled
 under interrupt and not process scheduled for rx/tx.

 Rodney

 On Wed, Oct 29, 2008 at 04:09:45PM +1030, Ben Steele wrote:
  Anyone currently using this in a fairly demanding environment? Ie
 5-10Gbs+
  Campus/DC model.
 
 
 
  Curious as to whether you've had any/many false dead peers with such a
 short
  interval, subsecond dead peer detection does sound very temping though.
 
 
 
  Cheers
 
 
 
  Ben
 
 
 
 
 
  ___
  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/


[c-nsp] 12000 SIP-401: datasheet typo?

2008-10-29 Thread Pete Templin

http://www.cisco.com/en/US/prod/collateral/routers/ps167/product_data_sheet0900aecd80465682.html

In Table 2, the SIP-401 uses Engine 5, but is compatible with the 12000 
series.  Is it actually Engine 3?  Does it work in 120xx chassis?


Thanks,

Pete
___
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] full BGP route in 7600

2008-10-29 Thread David Granzer
Hello,

with non-XL card you will be limited run non-XL mode, it means you
will not be able to get full BGP. One
workaround might be filter some routes from your upstream and get
default route from him.

David

On Wed, Oct 29, 2008 at 2:07 PM, moshe mizrachi [EMAIL PROTECTED] wrote:
 hi ,
 i have 7609s with RSP3CXL running SRC2 +  7600-ES20-10G3C(2*10Gig) +SIP400
 with SPA-OC12 .
 via the OC12  there is BGP peer that getting full route bgp , the problem is
 that the ES20 is 3C
 with DFC  with limition  of  memory, is there any creative idea how to solve
 it without upgrading the
 ES20-10G3C  to ES20-10G3CXL

 regards moshe
 ___
 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] 12000 SIP-401: datasheet typo?

2008-10-29 Thread Aaron
401, 501, and 601 are all based of the same engine 5. They are bw limited to
the speeds (2.5/5/10).

Aaron

On Wed, Oct 29, 2008 at 10:52 AM, Pete Templin [EMAIL PROTECTED]wrote:


 http://www.cisco.com/en/US/prod/collateral/routers/ps167/product_data_sheet0900aecd80465682.html

 In Table 2, the SIP-401 uses Engine 5, but is compatible with the 12000
 series.  Is it actually Engine 3?  Does it work in 120xx chassis?

 Thanks,

 Pete
 ___
 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] Bulk Cisco Device Prep

2008-10-29 Thread Rupert Finnigan
Hi All,
 
I'm looking into various ways to prep Cisco devices, based on an existing 
template, so they can be configured and deployed by technical, but non-cisco 
people.
 
I'm either thinking about a Perl script that generates a file based on a couple 
of fill in the blanks, that can be accessed via TFTP when the vanilla device 
firstboots, or a .NET app that talks directly to the console port and applies 
the config as if it were typed.
 
There must be a number of guys on this list that have to deploy a large number 
devices, Routers or Switches, that follow a core config with only a minor 
change here for there (ie, VTP Domain, or Management IP).. I'd be very 
interested to hear how you do this, or is you've got any pointers.
 
And, if the finished product would be of any use to someone, I'll gladly send 
the source over!
 
Thanks,
 
Rupert

Please consider the environment before printing this email.

CONFIDENTIALITY: This email (and any attachments) is confidential and is 
intended only
for the attention of the addressee(s). Its unauthorised use, disclosure, 
storage or 
copying is not permitted. The material may also be the subject of copyright 
protection.
If you are not the named recipient, please notify the sender immediately and 
delete
the message from your computer. Do not disclose the contents to another person,
use it for any purpose, or store or copy the information in any medium.
Disclosure to anyone other than the named recipient, whether inadvertent or
otherwise is not intended to waive privilege or confidentiality. If this
message is encrypted only the named recipient is authorised to decrypt the
message. Unauthorised decryption is prohibited and may be unlawful.
Unauthorised decryption will not waive privilege or confidentiality.

DISCLAIMER: The views expressed in this email are those of the originator and 
do 
not necessarily represent the views of Horsatack Saddlery Limited.
Internet communications are not secure. Any reply to this message could be 
intercepted and read by someone else. Please bear that in mind when deciding 
whether to send material in response to this message by email. We do not accept
responsibility for any changes made to this message after it was sent. We 
cannot accept any liability for any loss or damage sustained as a result of 
software viruses.

Horsatack Saddlery Limited - Registered in England  Wales No. 6393070. 
Registered Office: Greenway House, Sugarswell Business Park, Shenington, 
Banbury, Oxon, OX15 6HW, UK.
VAT No. GB 929699352.

___
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] Quad FWSM

2008-10-29 Thread Mathias Spoerr
only Failover pairs are supported.

Mathias




From:
[EMAIL PROTECTED]
To:
cisco-nsp@puck.nether.net
Date:
29.10.2008 14:37
Subject:
[c-nsp] Quad FWSM



Hi gents,

Little question about FWSM redundancy. I didn't attend the trainings :)

Scenario :
- Four 6500/Sup7203bxl
- Each one has a FWSM card.

Is it possible to have FWSM in an Active/Stby/Stby/Stby setup ?
Or does failover only works by pair ?

Jerome
___
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/




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] OSPF fast hellos

2008-10-29 Thread Pete S.
Changing the hello/dead timers combined with ispf, and tuning spf
throttle/lsa throttle timers, works extremely well to bring down the
convergence time of OSPF to around what eigrp does natively.  You dont want
to adjust the timers without the throttle control.   There should be a best
practices document on the timer values somewhere on cisco.com.  Can't seem
to find it at the moment.  I was using that formula on a large, mixed
OC-48/10G ospf routed network without any issues.


--Pete




On Wed, Oct 29, 2008 at 1:39 AM, Ben Steele [EMAIL PROTECTED]wrote:

 Anyone currently using this in a fairly demanding environment? Ie 5-10Gbs+
 Campus/DC model.



 Curious as to whether you've had any/many false dead peers with such a
 short
 interval, subsecond dead peer detection does sound very temping though.



 Cheers



 Ben





 ___
 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] 12000 SIP-401: datasheet typo?

2008-10-29 Thread Pete Templin

Aaron wrote:
401, 501, and 601 are all based of the same engine 5. They are bw 
limited to the speeds (2.5/5/10).


The datasheet says the 401 is compatible with 120xx, 124xx, and 128xx. 
The datasheet says the 501 and 601 are OK with 124xx and 128xx.


Does the 401 work in a 120xx as an Engine 5?

pt

On Wed, Oct 29, 2008 at 10:52 AM, Pete Templin [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:



http://www.cisco.com/en/US/prod/collateral/routers/ps167/product_data_sheet0900aecd80465682.html

In Table 2, the SIP-401 uses Engine 5, but is compatible with the
12000 series.  Is it actually Engine 3?  Does it work in 120xx chassis?


___
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] acess-list

2008-10-29 Thread adrian kok
Hi

1/ What is the different between line vty 0 4 and line
vty 5 15

how can I deny one ip to access vty? I tried both but
all are not working. and deny all ip to access

access-list 10 deny 192.168.0.10 0.0.0.0 or
access-list 10 deny 192.168.0.10 255.255.255.255


router(config)#line vty 0 4
router(config-line)#access-class 10 in
router(config-line)#

Thank you

Send instant messages to your online friends http://uk.messenger.yahoo.com 
___
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] acess-list

2008-10-29 Thread Valentin Stoicescu
Hi,
There's no difference ,just that you can configure different lines with
different passwords.
For your access-class put in your access list the ips you want to grant
access to vty and everything else is denied.
Ex:
access-list 10 permit your ip 
line vty 0 15
access-class 10 in

adrian kok wrote:
 Hi

 1/ What is the different between line vty 0 4 and line
 vty 5 15

 how can I deny one ip to access vty? I tried both but
 all are not working. and deny all ip to access

 access-list 10 deny 192.168.0.10 0.0.0.0 or
 access-list 10 deny 192.168.0.10 255.255.255.255


 router(config)#line vty 0 4
 router(config-line)#access-class 10 in
 router(config-line)#

 Thank you

 Send instant messages to your online friends http://uk.messenger.yahoo.com 
 ___
 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] OSPF fast hellos

2008-10-29 Thread Ben Steele
Because I couldn't see bfd support for 3750's, best it can do is UDLD,
otherwise that would be my preferred method.

Are you advising against fast hello's? Have you seen many issues with people
using them?

-Original Message-
From: Rodney Dunn [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 29 October 2008 11:41 PM
To: Ben Steele
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] OSPF fast hellos

Why don't you use BFD instead. It's designed with something called
pseudo preemption from an OS scheduler perspective that helps
reduce false positives and the fact that BFD frames are handled
under interrupt and not process scheduled for rx/tx.

Rodney

On Wed, Oct 29, 2008 at 04:09:45PM +1030, Ben Steele wrote:
 Anyone currently using this in a fairly demanding environment? Ie 5-10Gbs+
 Campus/DC model.
 
  
 
 Curious as to whether you've had any/many false dead peers with such a
short
 interval, subsecond dead peer detection does sound very temping though.
 
  
 
 Cheers
 
  
 
 Ben
 
  
 
  
 
 ___
 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/

No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.175 / Virus Database: 270.8.4/1752 - Release Date: 28/10/2008
10:04 AM

___
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] acess-list

2008-10-29 Thread Dave Weis


On Thu, 30 Oct 2008, adrian kok wrote:

how can I deny one ip to access vty? I tried both but
all are not working. and deny all ip to access
access-list 10 deny 192.168.0.10 0.0.0.0 or
access-list 10 deny 192.168.0.10 255.255.255.255


You need an explicit allow all at the end, there's an implicit deny all.

--
Dave Weis
[EMAIL PROTECTED]
http://www.internetsolver.com/

___
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] ctr+break sequence and Cisco 3500

2008-10-29 Thread Marty Adkins

On 10/28/2008 9:07 PM, snort bsd wrote:

never mind, it is 3500, pushed the little button and I had what I wanted.


On the lower IOS-based switches, the BREAK signal won't work
unless you have at some time in the past issued this in config mode:
  boot enable-break

Use show boot to see the current setting.

- Marty
___
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] Bulk Cisco Device Prep

2008-10-29 Thread Mathias Spoerr
Hi,

I wrote a small tool, called wktools, which can do this. It's for Windows 
and free. You can download it at www.spoerr.org/wktools
The configs are generated out of a template and a csv file with all the 
variable data. 
For an example please take a look at the Tutorial section on the website. 
(http://spoerr.org/wktools/tut.htm)
It can also handle templates with varaible length, i.e. an object-group 
which has a different number of entries on each firewall.

Mathias





From:
Rupert Finnigan [EMAIL PROTECTED]
To:
cisco-nsp@puck.nether.net
Date:
29.10.2008 18:29
Subject:
[c-nsp] Bulk Cisco Device Prep



Hi All,
 
I'm looking into various ways to prep Cisco devices, based on an existing 
template, so they can be configured and deployed by technical, but 
non-cisco people.
 
I'm either thinking about a Perl script that generates a file based on a 
couple of fill in the blanks, that can be accessed via TFTP when the 
vanilla device firstboots, or a .NET app that talks directly to the 
console port and applies the config as if it were typed.
 
There must be a number of guys on this list that have to deploy a large 
number devices, Routers or Switches, that follow a core config with only a 
minor change here for there (ie, VTP Domain, or Management IP).. I'd be 
very interested to hear how you do this, or is you've got any pointers.
 
And, if the finished product would be of any use to someone, I'll gladly 
send the source over!
 
Thanks,
 
Rupert

Please consider the environment before printing this email.

CONFIDENTIALITY: This email (and any attachments) is confidential and is 
intended only
for the attention of the addressee(s). Its unauthorised use, disclosure, 
storage or 
copying is not permitted. The material may also be the subject of 
copyright protection.
If you are not the named recipient, please notify the sender immediately 
and delete
the message from your computer. Do not disclose the contents to another 
person,
use it for any purpose, or store or copy the information in any medium.
Disclosure to anyone other than the named recipient, whether inadvertent 
or
otherwise is not intended to waive privilege or confidentiality. If this
message is encrypted only the named recipient is authorised to decrypt the
message. Unauthorised decryption is prohibited and may be unlawful.
Unauthorised decryption will not waive privilege or confidentiality.

DISCLAIMER: The views expressed in this email are those of the originator 
and do 
not necessarily represent the views of Horsatack Saddlery Limited.
Internet communications are not secure. Any reply to this message could be 

intercepted and read by someone else. Please bear that in mind when 
deciding 
whether to send material in response to this message by email. We do not 
accept
responsibility for any changes made to this message after it was sent. We 
cannot accept any liability for any loss or damage sustained as a result 
of 
software viruses.

Horsatack Saddlery Limited - Registered in England  Wales No. 6393070. 
Registered Office: Greenway House, Sugarswell Business Park, Shenington, 
Banbury, Oxon, OX15 6HW, UK.
VAT No. GB 929699352.

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




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/

[c-nsp] reflexive ACL on 6500

2008-10-29 Thread Michael Malitsky
Hello,

Does anyone have any experience using reflexive ACLs on a 6500?  I am
having trouble finding definitive information as to the manner these are
processed.  One document indicates the first packet of a flow is punted
to the MSFC, the rest are hardware-switched.  Another says that the
first packet of a flow is always punted to the MSFC, while for the rest
of the flow to be switched in hardware, mls netflow has to be enabled,
otherwise it's all software.
For the time being, we don't have a huge load on the box, so
software/hardware path selection isn't causing a lot of grief, but I'd
rather not wait until this becomes a pain point.
In addition, every so often (2-3 months) a particular ACL will stop
reflecting.  As in the SYN packets will go through, will show up in
the reflected list, but the response packets won't be allowed through.
Only one list (out of a dozen or two) at a time, and not necessarily the
same list every time.  The solution is to remove the list and recreate
it.
We are running a 6509/Sup720 with 12.2(18)SXF.

Any suggestions/experiences appreciated.

Michael
___
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] reflexive ACL on 6500

2008-10-29 Thread Gabriel Kuri
We've been using reflexive ACLs on the 6500s for many years, in my own 
experience I'd recommend against it, unless it's absolutely your only choice. 
We use reflexive ACLs on the SVIs and it just doesn't scale very well.  You're 
better off purchasing a couple FWSMs or some real firewalls to get the job 
done. 

The basic downfall of the reflexive ACLs is that it knows nothing about session 
state of the underlying protocol (ie TCP session state). The moment you have an 
infected box or a box port scanning, expect the CPU to spike on the supervisor, 
while it sits in the Racl Ager process, aging out all the reflexive access list 
entries. We have the reflexive timeout set fairly low, but most of the time 
we're still hammered with chatty boxes generating tons of states and the CPU 
spiking while it ages them out.

In terms of CPU hits, here's been my experience:

- chatty boxes creating tons of unnecessary states spikes the CPU in the RACL 
Ager process. lately the HP Jetdirect print servers with SLP enabled has given 
us some grief in this arena (disable SLP on the Jetdirect print servers unless 
you absolutely need it). for boxes on the outside of the reflexive ACL that 
your boxes on the inside always talk to (ie DNS servers), save yourself the 
headache and create stateless entries on the access-lists to avoid unnecessary 
states to those boxes.

- enabling logging on a reflexive ACL punts it to the CPU (don't log on the 
reflexive ACL unless you want everything to be software switched)

- depending on the number of vLANs and ACEs for your ACLs, you need to watch 
your TCAM resources, although on a Sup720 you'd be pretty hard pressed to 
exhaust them unless you have a lot of entries.

- there seems to be a bug when generating a reflexive ACL on GRE traffic (and 
perhaps other IP - non TCP/UDP traffic). The GRE traffic doesn't seem to fall 
into the catch all rule 'permit ip subnet wildcard any reflect 
my-reflexive-acl'. for whatever reason we're stuck with creating a separate 
entry 'permit gre subnet wildcard any reflect my-reflexive-acl'.


Just my 2 cents ...


-
Gabriel Kuri | Sr. Network Engineer
Instructional and Information Technology Division
California State Polytechnic University, Pomona
http://www.csupomona.edu/~iit | +1 909 979 6363



-Original Message-
From: [EMAIL PROTECTED] on behalf of Michael Malitsky
Sent: Wed 10/29/2008 7:07 PM
To: cisco-nsp@puck.nether.net
Cc: Michael Malitsky
Subject: [c-nsp] reflexive ACL on 6500
 
Hello,

Does anyone have any experience using reflexive ACLs on a 6500?  I am
having trouble finding definitive information as to the manner these are
processed.  One document indicates the first packet of a flow is punted
to the MSFC, the rest are hardware-switched.  Another says that the
first packet of a flow is always punted to the MSFC, while for the rest
of the flow to be switched in hardware, mls netflow has to be enabled,
otherwise it's all software.
For the time being, we don't have a huge load on the box, so
software/hardware path selection isn't causing a lot of grief, but I'd
rather not wait until this becomes a pain point.
In addition, every so often (2-3 months) a particular ACL will stop
reflecting.  As in the SYN packets will go through, will show up in
the reflected list, but the response packets won't be allowed through.
Only one list (out of a dozen or two) at a time, and not necessarily the
same list every time.  The solution is to remove the list and recreate
it.
We are running a 6509/Sup720 with 12.2(18)SXF.

Any suggestions/experiences appreciated.

Michael
___
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/