Re: [c-nsp] Giving customers access to your gear.

2008-06-04 Thread Daniel Hooper
Your large hotel chain techs sound like a bunch of gumbies, any tech
worth their salt would poll their own equipment and not the providers.

Provider: Lets feed them dummy snmp counters
Customer: hey your billing me for 500gb of traffic!!
Provider: yes.. don't your graphs reflect this? ;)

-Dan

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:cisco-nsp-
 [EMAIL PROTECTED] On Behalf Of Jon Lewis
 Sent: Wednesday, 4 June 2008 12:49 PM
 To: Richey
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] Giving customers access to your gear.
 
 On Tue, 3 Jun 2008, Richey wrote:
 
  I've got a customer with a T1.  They have been bought out by a large
 hotel
  chain.  They are pretty much demanding that they have SNMP full read
 access
  to our router that is at their location as well as a copy of the
 config for
  the router.   This is not their router, it is ours and we fully
 manage our
 
 As long as you don't give them the clear text version of the enable
 secret, they can't do any damage, so what's the concern?  Having been
 on
 the customer end of this sort of arrangement long ago, I can
understand
 their concern.  They may want SNMP access for traffic/health graphing,
 and
 a copy of the config simply for auditing purposes to satisfy
themselves
 that the config is secure enough.
 
 I'm sure _you_ wouldn't do this, but if you (as the ISP) were to make
 changes to your customer routes and break their internet connection,
 and
 then have all of your noc staff go fishing for the day, if they
 customer
 had enable, they could possibly fix their router...depending on
 how/where
 you broke things.  I've been there...didn't have access, couldn't fix
 it,
 and was not amused.
 
 If they want access bad enough, since they do have physical access,
 they
 could just reboot, change the config-register, and have a copy of the
 config.
 
  router and hand them  Ethernet. This seems a little odd that
they
 want
  access to our gear, and I am not too keen on giving them access
 unless they
  are willing to accept some responsibility.   They don't want to
 accept any
  responsibility for the access they would have to this box. They
 say that
  Verizion and ATT don't have any problems giving them this kind of
 access to
  their gear.
 
 If you give them enable, the rule is you break it, you pay us to fix
 it.
 I also highly recommend rancid, so when they do break it or monkey
with
 it
 in any way, you get notification, and can easily see and back out
their
 changes.
 
 --
   Jon Lewis   |  I route
   Senior Network Engineer |  therefore you are
   Atlantic Net|
 _ http://www.lewis.org/~jlewis/pgp for PGP public key_
 ___
 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] Giving customers access to your gear.

2008-06-04 Thread troy
I know that we have come across this a few times. Here is what we have in
place (policy wise) for these kind of customers.

1) If the router is owned by us, the customer does not get the passwords
or SNMP strings. Should the customer want to purchase said router from us,
we are more than happy to turn it over to them.

2) If the customer wants to provide a their own router, they may do so and
eliminate this issue. Basic configs are provided and any support beyond
that is billed at $150 per hour, minimum 1 hour.

Both 1 and 2 do have stipulations. If you are given access to the router
or if you supply your own router, you will be given basic config
information. Should you lock yourself out of or render the router useless,
we will bill you for a truck roll, time on site and if needed, replacement
parts/hardware at a rate of $150 per hour. Minimum 1 hour + truck roll of
$150.

We don't give out any information to hardware that serves multiple
customers for any reason.

Hope this is helpful.

-Troy

 I've got a customer with a T1.  They have been bought out by a large hotel
 chain.  They are pretty much demanding that they have SNMP full read
 access
 to our router that is at their location as well as a copy of the config
 for
 the router.   This is not their router, it is ours and we fully manage our
 router and hand them  Ethernet. This seems a little odd that they want
 access to our gear, and I am not too keen on giving them access unless
 they
 are willing to accept some responsibility.   They don't want to accept any
 responsibility for the access they would have to this box. They say
 that
 Verizion and ATT don't have any problems giving them this kind of access
 to
 their gear.



 Any thoughts from the group?



 Richey



 ___
 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] Giving customers access to your gear.

2008-06-04 Thread Gert Doering
Hi,

On Tue, Jun 03, 2008 at 08:40:42PM -0400, Sridhar Ayengar wrote:
 Do you have a written contract that covers any of these issues?  If so, 
 and they indeed still want that kind of access, they will have to accept 
 your terms.  Otherwise you're leaving yourself open to situations where 
 they repeatedly screw with the router and you have to repeatedly fix the 
 issues they generate without charge.

How exactly do you expect the customer to screw with the router if
they have a *read-only* account?

Nobody asked for read-write access.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany [EMAIL PROTECTED]
fax: +49-89-35655025[EMAIL PROTECTED]


pgp7ZHDTqkpj0.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] Giving customers access to your gear.

2008-06-04 Thread Michael K. Smith - Adhost
Hello Richey:

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:cisco-nsp-
 [EMAIL PROTECTED] On Behalf Of Richey
 Sent: Tuesday, June 03, 2008 4:38 PM
 To: cisco-nsp@puck.nether.net
 Subject: [c-nsp] Giving customers access to your gear.
 
 I've got a customer with a T1.  They have been bought out by a large hotel
 chain.  They are pretty much demanding that they have SNMP full read access
 to our router that is at their location as well as a copy of the config for
 the router.   This is not their router, it is ours and we fully manage our
 router and hand them  Ethernet. This seems a little odd that they want
 access to our gear, and I am not too keen on giving them access unless they
 are willing to accept some responsibility.   They don't want to accept any
 responsibility for the access they would have to this box. They say that
 Verizion and ATT don't have any problems giving them this kind of access to
 their gear.
 
I think RO SNMP access is fine, and just make sure you sanitize the 
configuration of all interesting data like passwords, dynamic routing 
protocol configurations, etc.  If you are worried that SNMP access will create 
performance issues, draft up a letter for them to sign indicating that any 
outages or performance issues that are a result of SNMP polling will not be 
credited against the customer's SLA.

By the way, I'm assuming they are the only customer on this box.  If that is 
not the case then I would say no to unfiltered SNMP and the config file, 
indicating to them that the device terminates services for other customer and 
cannot therefore be shared with them.

Regards,

Mike


PGP.sig
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] Giving customers access to your gear.

2008-06-04 Thread Tassos Chatzithomaoglou
We provide RO snmp views to specific customers, as long as they know which exactly oids they need to 
monitor. That way they're limited to specific portions of the snmp mibs.



--
Tassos


Michael K. Smith - Adhost wrote on 4/6/2008 10:13 πμ:

Hello Richey:


-Original Message-
From: [EMAIL PROTECTED] [mailto:cisco-nsp-
[EMAIL PROTECTED] On Behalf Of Richey
Sent: Tuesday, June 03, 2008 4:38 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Giving customers access to your gear.

I've got a customer with a T1.  They have been bought out by a large hotel
chain.  They are pretty much demanding that they have SNMP full read access
to our router that is at their location as well as a copy of the config for
the router.   This is not their router, it is ours and we fully manage our
router and hand them  Ethernet. This seems a little odd that they want
access to our gear, and I am not too keen on giving them access unless they
are willing to accept some responsibility.   They don't want to accept any
responsibility for the access they would have to this box. They say that
Verizion and ATT don't have any problems giving them this kind of access to
their gear.


I think RO SNMP access is fine, and just make sure you sanitize the configuration of all 
interesting data like passwords, dynamic routing protocol configurations, 
etc.  If you are worried that SNMP access will create performance issues, draft up a 
letter for them to sign indicating that any outages or performance issues that are a 
result of SNMP polling will not be credited against the customer's SLA.

By the way, I'm assuming they are the only customer on this box.  If that is 
not the case then I would say no to unfiltered SNMP and the config file, 
indicating to them that the device terminates services for other customer and 
cannot therefore be shared with them.

Regards,

Mike




___
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] difference between bandwidth and priority command inpolicy

2008-06-04 Thread Ziv Leyes
I've always had a problem with the semantics of this, perhaps I need to go back 
to highschool? Or perhaps Cisco programmers instead??

When I say this link will have this bandwidth it sounds to me like it's a 
dedicated bandwidth that limits the link to the given value.
When I say priority I think of a link with several clients where one of them 
gets priority over the others, but in case there are no others it can get more.

When I check the books it all looks to be the opposite way, why!?!?!?

Also, what about police?
Ziv


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Boehmer 
(oboehmer)
Sent: Wednesday, June 04, 2008 8:44 AM
To: Everton Diniz; cisco-nsp
Subject: Re: [c-nsp] difference between bandwidth and priority command 
inpolicy

Everton Diniz  wrote on Tuesday, June 03, 2008 8:20 PM:

 Hi all,

 What is the difference between bandwidth and priority command in
 policy-map?

 class REAL-TIME
   priority 722
 class SAP
   bandwidth 389

short answer:
priority configures a low-latency priority queue (along with a policer
dropping traffic above the configured rate). bandwidth configures the
queue weights to implement a minimum bandwidth guarantee for the class.
More traffic can be sent if BW is available..

more verbose:
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a
0080103eae.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/






This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals  computer 
viruses.







 
 

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals  computer 
viruses.




___
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] Giving customers access to your gear.

2008-06-04 Thread Nathan
On Wed, Jun 4, 2008 at 4:31 AM, Richey [EMAIL PROTECTED] wrote:
 Thanks for the replies.  I am getting the feeling that after talking to our
 sales guy who is dealing with them that they want to second guess everything
 I am doing because we are a small ISP and not the big billion dollar a year
 ISP of their choice.

Hi,

Do take into account the possibility that obtaining the configuration
of your CPE routers is just the first step to replacing them with CPE
routers from another ISP.

If that is it I'd actually recommend letting them go with the minimum
of fuss. I've had big clients (like $100,000/year in profits) come
back or recommend same-size friends of theirs to come to me because I
didn't make a mess of their transition to another ISP. That of course
doesn't mean giving them information that could be used against you
later or information that the client shouldn't need to know . . .

-- 
HTH
Nahan
___
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] ACL making me insane

2008-06-04 Thread Robert Blayzor

On Jun 3, 2008, at 1:23 PM, Skeeve Stevens wrote:

no ip access-list extended FWCUST_XXX_IN
ip access-list extended FWCUST_XXX_IN
remark Inbound Firewall rules for XXX Services
permit tcp any host PROTECTEDSERVER established
permit tcp host ALLOWEDREMOTE host PROTECTEDSERVER eq 3389
permit tcp any host PROTECTEDSERVER eq 80
permit icmp any any
deny   ip any any
!
no ip access-list extended FWCUST_XXX_OUT
ip access-list extended FWCUST_XXX_OUT
remark Outbound Firewall rules for XXX Services
permit tcp any any established
permit tcp PROTECTEDSERVER host SAFEMAIL eq smtp
permit tcp host PROTECTEDSERVER host SAFEMAIL eq pop3
permit icmp any any
permit tcp host PROTECTEDSERVER any eq domain
permit udp host PROTECTEDSERVER any eq domain
permit tcp host PROTECTEDSERVER any eq 80
permit tcp host PROTECTEDSERVER any eq 21
permit udp host PROTECTEDSERVER any eq 20





The deny ip any any are redundant and can be removed unless you want  
to log it all..


One point of note is that you're allowing UDP outbound for DNS, but  
you're not allowing UDP back in.  So I doubt you're able to resolve  
anything with these ACL's in place unless somehow you're using TCP for  
all your DNS queries. (possible but unlikely)  The same goes for any  
UDP type service.  Since ACL's are not stateful, you have to  
explicitly allow all packets to complete a bi-direction flow. (unless  
you can cheat by using established of course).


--
Robert Blayzor, BOFH
INOC, LLC
[EMAIL PROTECTED]
http://www.inoc.net/~rblayzor/



___
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] question about memory

2008-06-04 Thread Ziv Leyes
Hi,
Could somebody shortly explain or point me to some info about the different 
router memory types?
What are transient contiguous largest free, etc? I understand more or 
less what they areI've never had a proper explanation for all those concept, 
and if I need to explain this to someone I find it difficult, so if somebody 
can help me help others I'll be glad.
Thanks,

Ziv






 
 

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals  computer 
viruses.



___
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] ACL making me insane

2008-06-04 Thread Ziv Leyes
There's no way to use established for UDP though, so I can share what works 
for me, I call them operational rules because they suit everything I need to 
allow that is host initiated/related for its own functionality, of course you 
could add some more rules to permit other tcp/udp ports to reach the desired 
host/net.

ip access-list extended WHATEVER
 remark allow any icmp answers to get in
 permit icmp any {destination host/net} echo-reply
 permit icmp any {destination host/net} traceroute
 permit icmp any {destination host/net} time-exceeded
 permit icmp any {destination host/net} unreachable
 remark allow any dns answers to get in
 permit udp any eq domain {destination host/net}
 remark same for ntp
 permit udp any eq ntp {destination host/net} eq ntp
 remark this is for any other udp on high ports but a bit of too open
 permit udp any any gt 1024
 remark this is for any host initiated traffic
 permit tcp any {destination host/net} established
 remark if wanted deny all the rest with logs
 deny ip any {destination host/net} log

Hope this helps,
Ziv

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Blayzor
Sent: Wednesday, June 04, 2008 12:46 PM
To: [EMAIL PROTECTED]
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ACL making me insane

On Jun 3, 2008, at 1:23 PM, Skeeve Stevens wrote:
 no ip access-list extended FWCUST_XXX_IN
 ip access-list extended FWCUST_XXX_IN
 remark Inbound Firewall rules for XXX Services
 permit tcp any host PROTECTEDSERVER established
 permit tcp host ALLOWEDREMOTE host PROTECTEDSERVER eq 3389
 permit tcp any host PROTECTEDSERVER eq 80
 permit icmp any any
 deny   ip any any
 !
 no ip access-list extended FWCUST_XXX_OUT
 ip access-list extended FWCUST_XXX_OUT
 remark Outbound Firewall rules for XXX Services
 permit tcp any any established
 permit tcp PROTECTEDSERVER host SAFEMAIL eq smtp
 permit tcp host PROTECTEDSERVER host SAFEMAIL eq pop3
 permit icmp any any
 permit tcp host PROTECTEDSERVER any eq domain
 permit udp host PROTECTEDSERVER any eq domain
 permit tcp host PROTECTEDSERVER any eq 80
 permit tcp host PROTECTEDSERVER any eq 21
 permit udp host PROTECTEDSERVER any eq 20




The deny ip any any are redundant and can be removed unless you want
to log it all..

One point of note is that you're allowing UDP outbound for DNS, but
you're not allowing UDP back in.  So I doubt you're able to resolve
anything with these ACL's in place unless somehow you're using TCP for
all your DNS queries. (possible but unlikely)  The same goes for any
UDP type service.  Since ACL's are not stateful, you have to
explicitly allow all packets to complete a bi-direction flow. (unless
you can cheat by using established of course).

--
Robert Blayzor, BOFH
INOC, LLC
[EMAIL PROTECTED]
http://www.inoc.net/~rblayzor/



___
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 footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals  computer 
viruses.







 
 

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals  computer 
viruses.




___
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] Solution to %SPANTREE-2-RECV_PVID_ERR, except disable spanning tree?

2008-06-04 Thread Peter Olsson
On Mon, Jun 02, 2008 at 09:34:10PM -0600, Clinton Work wrote:

 I think that you need to speak with your service provider.  Based upon  
 the error message it looks like vlan 2412 at site #1 is connected to  
 vlan 2413 at site #2. There was a post six to 12 months ago on the same  
 topic and it was a service provider issue. 

I don't think the provider has got a bad configuration, partly
because we have spoken with them about this several times and
partly because of what I didn't include below, that we have the
same problem for every vlan they gave us (30 in all, 6 each to
5 locations). As long as we only use one vlan to each location,
everything works. When we add another vlan to one of the locations,
all 6 vlans to that location goes into blocking mode because of the
errors below. It could possibly be a systematic error somewhere.

 STP to L2 FTTx gear:
 http://puck.nether.net/pipermail/cisco-nsp/2008-January/046310.html

Great thread on the subject. I hadn't seen that, I will read it and
check for ideas.

Many thanks!

Peter Olsson


 Clinton. 

 Peter Olsson wrote:
 Two offices have a cisco 3750 each. They connect via a
 bridged fastethernet service, on non-cisco equipment,
 which offers six vlans on the line. When the 3750 only
 allow one vlan on the switch port toward the line,
 everything works fine.

 When we try to add another allowed vlan, we get this error
 and both vlans block:
 %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer
 vlan id 2412 on GigabitEthernet1/0/25 VLAN2413.
 %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/25 on
 VLAN2413. Inconsistent local vlan.
 %SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet1/0/25 on
 VLAN2412. Inconsistent peer vlan.



   


 -- 
 ===
 Clinton Work
 Airdrie, AB
___
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] 6500 NDE aging prematurely

2008-06-04 Thread Phil Mayers

All,

We use nfdump/nfsen to gather our flows. The nfcap daemon writes the 
flows to 5-minute-window files, the filename being the *start* of the 
5-minute window.


If I look at e.g. nfcapd.200806041235 I see the following distribution 
of flow *end* times:


732 2008-06-04 12:29
  16492 2008-06-04 12:30
  19769 2008-06-04 12:31
  22704 2008-06-04 12:32
  21701 2008-06-04 12:33
  91460 2008-06-04 12:34
 148540 2008-06-04 12:35
 153881 2008-06-04 12:36
 177542 2008-06-04 12:37
 184133 2008-06-04 12:38
 143340 2008-06-04 12:39

Given that we are running with the default aging parameters:

 enable timeout  packet threshold
 -- ---  
normal aging true   300N/A
fast aging   false  32 100
long aging   true   1920   N/A

...I'm puzzled; surely during the window 12:35:00 - 12:39:59 we should 
only ever receive flows with end time up to 12:35:00 (plus or minus a 
few tens of seconds, depending on the aging)


Why is the router exporting flows which have been inactive for only ~1 
minute?


The box isn't busy with regards netflow (considering we have fast aging 
disabled and lot of 1-packet flows) so I don't think that's the cause.


TCAM utilization:   Module   Created  Failed   %Used
1  72227   0 55%
2  65312   0 49%
5 75   0  0%
6 70   0  0%
8  71824   0 54%
9  37572   0 28%
ICAM utilization:   Module   Created  Failed   %Used
1  1   0  0%
2  3   0  2%
5  0   0  0%
6  0   0  0%
8  4   0  3%
9  0   0  0%

   Flowmasks:   Mask#   TypeFeatures
  IPv4: 0   reservednone
  IPv4: 1   Intf FulFM_GUARDIAN
  IPv4: 2   unused  none
  IPv4: 3   reservednone

  IPv6: 0   reservednone
  IPv6: 1   unused  none
  IPv6: 2   unused  none
  IPv6: 3   reservednone
___
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] ACL making me insane

2008-06-04 Thread Robert Blayzor

On Jun 4, 2008, at 7:25 AM, Ziv Leyes wrote:
There's no way to use established for UDP though, so I can share  
what works for me, I call them operational rules because they suit  
everything I need to allow that is host initiated/related for its  
own functionality, of course you could add some more rules to permit  
other tcp/udp ports to reach the desired host/net.




Of course not.. ACL's are very basic and are not stateful in any way.   
So if you're trying to use it in that way, it's very difficult and you  
end up with a lot of loose rules.  Of course for DNS you could just  
allow responses from the DNS server from UDP port 53 to any port   
1023, but it's loose.  If you have a recursive DNS server inside of  
that ACL, then you're going to have to allow from ALL IP's from port  
UDP port 53.


Keep your ACL's basic and to the point, trying to make them overly  
complicated to replace a stateful firewall kind of defeats the purpose  
and ends up being more trouble than it's worth. (IMHO)


--
Robert Blayzor, BOFH
INOC, LLC
[EMAIL PROTECTED]
http://www.inoc.net/~rblayzor/



___
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] 6500 NDE aging prematurely

2008-06-04 Thread Phil Mayers

Ben Hicks wrote:
Forgive me if I'm missing something but you are looking at the actual 
end times of the TCP flows, not the exports (which happen continuously 
in chunks anyway). The flows will be reported as they end. So a 30 
second connection will be reported once its finished, not at the end of 
the 5 minute period.


That was not my understanding. My understanding was that the flow start 
and end times were of the first and last packets seen, and that a flow 
should be exported when:


 now - last_packet = 300 seconds

...with default aging timers.

So, if we have 3 packets:

 12:35:00
 12:36:00
 12:37:00

...the flow should be exported at ~12:42 i.e. 300 seconds after the last 
packet.




Many thanks,

Ben


-Original Message-
From: [EMAIL PROTECTED] on behalf of Phil Mayers
Sent: Wed 04/06/2008 12:53
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 6500 NDE aging prematurely

All,

We use nfdump/nfsen to gather our flows. The nfcap daemon writes the
flows to 5-minute-window files, the filename being the *start* of the
5-minute window.

If I look at e.g. nfcapd.200806041235 I see the following distribution
of flow *end* times:

 732 2008-06-04 12:29
   16492 2008-06-04 12:30
   19769 2008-06-04 12:31
   22704 2008-06-04 12:32
   21701 2008-06-04 12:33
   91460 2008-06-04 12:34
  148540 2008-06-04 12:35
  153881 2008-06-04 12:36
  177542 2008-06-04 12:37
  184133 2008-06-04 12:38
  143340 2008-06-04 12:39

Given that we are running with the default aging parameters:

  enable timeout  packet threshold
  -- ---  
normal aging true   300N/A
fast aging   false  32 100
long aging   true   1920   N/A

...I'm puzzled; surely during the window 12:35:00 - 12:39:59 we should
only ever receive flows with end time up to 12:35:00 (plus or minus a
few tens of seconds, depending on the aging)

Why is the router exporting flows which have been inactive for only ~1
minute?

The box isn't busy with regards netflow (considering we have fast aging
disabled and lot of 1-packet flows) so I don't think that's the cause.

TCAM utilization:   Module   Created  Failed   %Used
 1  72227   0 55%
 2  65312   0 49%
 5 75   0  0%
 6 70   0  0%
 8  71824   0 54%
 9  37572   0 28%
ICAM utilization:   Module   Created  Failed   %Used
 1  1   0  0%
 2  3   0  2%
 5  0   0  0%
 6  0   0  0%
 8  4   0  3%
 9  0   0  0%

Flowmasks:   Mask#   TypeFeatures
   IPv4: 0   reservednone
   IPv4: 1   Intf FulFM_GUARDIAN
   IPv4: 2   unused  none
   IPv4: 3   reservednone

   IPv6: 0   reservednone
   IPv6: 1   unused  none
   IPv6: 2   unused  none
   IPv6: 3   reservednone
___
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] question about memory

2008-06-04 Thread Rodney Dunn
Transient is when you use memory for a brief amount of time and free it back.
Say during a large routing reconvergence event.

Contiguous is in regards to blocks. It means it's a block of memory in adjacent
locations in memory and not fragmented in different spots for the same block
of data.

Largest free is the largest block of memory that is contigious and free
to be used by a process.

Rodney

On Wed, Jun 04, 2008 at 02:14:16PM +0300, Ziv Leyes wrote:
 Hi,
 Could somebody shortly explain or point me to some info about the different 
 router memory types?
 What are transient contiguous largest free, etc? I understand more or 
 less what they areI've never had a proper explanation for all those concept, 
 and if I need to explain this to someone I find it difficult, so if somebody 
 can help me help others I'll be glad.
 Thanks,
 
 Ziv
 
 
 
 
 
 
  
  
 
 This footnote confirms that this email message has been scanned by
 PineApp Mail-SeCure for the presence of malicious code, vandals  computer 
 viruses.
 
 
 
 ___
 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] 6500 NDE aging prematurely

2008-06-04 Thread Tassos Chatzithomaoglou

A flow is exported when :

1) it is inactive for a specific time (default 15 secs)*
2) it is active and has lasted longer than a specific time (default 30 mins)*
3) a TCP flag (FIN/RST?) is received, indicating that the flow is terminated

(*) 6500 uses different timers, if i remember right..

--
Tassos

Phil Mayers wrote on 4/6/2008 3:42 μμ:

Ben Hicks wrote:
Forgive me if I'm missing something but you are looking at the actual 
end times of the TCP flows, not the exports (which happen continuously 
in chunks anyway). The flows will be reported as they end. So a 30 
second connection will be reported once its finished, not at the end 
of the 5 minute period.


That was not my understanding. My understanding was that the flow start 
and end times were of the first and last packets seen, and that a flow 
should be exported when:


 now - last_packet = 300 seconds

...with default aging timers.

So, if we have 3 packets:

 12:35:00
 12:36:00
 12:37:00

...the flow should be exported at ~12:42 i.e. 300 seconds after the last 
packet.




Many thanks,

Ben


-Original Message-
From: [EMAIL PROTECTED] on behalf of Phil Mayers
Sent: Wed 04/06/2008 12:53
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 6500 NDE aging prematurely

All,

We use nfdump/nfsen to gather our flows. The nfcap daemon writes the
flows to 5-minute-window files, the filename being the *start* of the
5-minute window.

If I look at e.g. nfcapd.200806041235 I see the following distribution
of flow *end* times:

 732 2008-06-04 12:29
   16492 2008-06-04 12:30
   19769 2008-06-04 12:31
   22704 2008-06-04 12:32
   21701 2008-06-04 12:33
   91460 2008-06-04 12:34
  148540 2008-06-04 12:35
  153881 2008-06-04 12:36
  177542 2008-06-04 12:37
  184133 2008-06-04 12:38
  143340 2008-06-04 12:39

Given that we are running with the default aging parameters:

  enable timeout  packet threshold
  -- ---  
normal aging true   300N/A
fast aging   false  32 100
long aging   true   1920   N/A

...I'm puzzled; surely during the window 12:35:00 - 12:39:59 we should
only ever receive flows with end time up to 12:35:00 (plus or minus a
few tens of seconds, depending on the aging)

Why is the router exporting flows which have been inactive for only ~1
minute?

The box isn't busy with regards netflow (considering we have fast aging
disabled and lot of 1-packet flows) so I don't think that's the cause.

TCAM utilization:   Module   Created  Failed   %Used
 1  72227   0 55%
 2  65312   0 49%
 5 75   0  0%
 6 70   0  0%
 8  71824   0 54%
 9  37572   0 28%
ICAM utilization:   Module   Created  Failed   %Used
 1  1   0  0%
 2  3   0  2%
 5  0   0  0%
 6  0   0  0%
 8  4   0  3%
 9  0   0  0%

Flowmasks:   Mask#   TypeFeatures
   IPv4: 0   reservednone
   IPv4: 1   Intf FulFM_GUARDIAN
   IPv4: 2   unused  none
   IPv4: 3   reservednone

   IPv6: 0   reservednone
   IPv6: 1   unused  none
   IPv6: 2   unused  none
   IPv6: 3   reservednone
___
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] question about memory

2008-06-04 Thread Ziv Leyes
That was short and simple enough to understand
Thanks!
Ziv


-Original Message-
From: Rodney Dunn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2008 3:49 PM
To: Ziv Leyes
Cc: cisco-nsp
Subject: Re: [c-nsp] question about memory

Transient is when you use memory for a brief amount of time and free it back.
Say during a large routing reconvergence event.

Contiguous is in regards to blocks. It means it's a block of memory in adjacent
locations in memory and not fragmented in different spots for the same block
of data.

Largest free is the largest block of memory that is contigious and free
to be used by a process.

Rodney

On Wed, Jun 04, 2008 at 02:14:16PM +0300, Ziv Leyes wrote:
 Hi,
 Could somebody shortly explain or point me to some info about the different 
 router memory types?
 What are transient contiguous largest free, etc? I understand more or 
 less what they areI've never had a proper explanation for all those concept, 
 and if I need to explain this to someone I find it difficult, so if somebody 
 can help me help others I'll be glad.
 Thanks,

 Ziv








 
 This footnote confirms that this email message has been scanned by
 PineApp Mail-SeCure for the presence of malicious code, vandals  computer 
 viruses.
 


 ___
 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 footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals  computer 
viruses.







 
 

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals  computer 
viruses.




___
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] 6500 NDE aging prematurely

2008-06-04 Thread Phil Mayers

Tassos Chatzithomaoglou wrote:

A flow is exported when :

1) it is inactive for a specific time (default 15 secs)*


I don't think that's correct. I think the default is 300 seconds.

2) it is active and has lasted longer than a specific time (default 30 
mins)*


Sure; that's not this

3) a TCP flag (FIN/RST?) is received, indicating that the flow is 
terminated


Really? Are you certain about that? I was under the impression that the 
PFC did not act on TCP flags.




(*) 6500 uses different timers, if i remember right..

--
Tassos

Phil Mayers wrote on 4/6/2008 3:42 μμ:

Ben Hicks wrote:
Forgive me if I'm missing something but you are looking at the actual 
end times of the TCP flows, not the exports (which happen 
continuously in chunks anyway). The flows will be reported as they 
end. So a 30 second connection will be reported once its finished, 
not at the end of the 5 minute period.


That was not my understanding. My understanding was that the flow 
start and end times were of the first and last packets seen, and that 
a flow should be exported when:


 now - last_packet = 300 seconds

...with default aging timers.

So, if we have 3 packets:

 12:35:00
 12:36:00
 12:37:00

...the flow should be exported at ~12:42 i.e. 300 seconds after the 
last packet.




Many thanks,

Ben


-Original Message-
From: [EMAIL PROTECTED] on behalf of Phil Mayers
Sent: Wed 04/06/2008 12:53
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 6500 NDE aging prematurely

All,

We use nfdump/nfsen to gather our flows. The nfcap daemon writes the
flows to 5-minute-window files, the filename being the *start* of the
5-minute window.

If I look at e.g. nfcapd.200806041235 I see the following distribution
of flow *end* times:

 732 2008-06-04 12:29
   16492 2008-06-04 12:30
   19769 2008-06-04 12:31
   22704 2008-06-04 12:32
   21701 2008-06-04 12:33
   91460 2008-06-04 12:34
  148540 2008-06-04 12:35
  153881 2008-06-04 12:36
  177542 2008-06-04 12:37
  184133 2008-06-04 12:38
  143340 2008-06-04 12:39

Given that we are running with the default aging parameters:

  enable timeout  packet threshold
  -- ---  
normal aging true   300N/A
fast aging   false  32 100
long aging   true   1920   N/A

...I'm puzzled; surely during the window 12:35:00 - 12:39:59 we should
only ever receive flows with end time up to 12:35:00 (plus or minus a
few tens of seconds, depending on the aging)

Why is the router exporting flows which have been inactive for only ~1
minute?

The box isn't busy with regards netflow (considering we have fast aging
disabled and lot of 1-packet flows) so I don't think that's the cause.

TCAM utilization:   Module   Created  Failed   %Used
 1  72227   0 55%
 2  65312   0 49%
 5 75   0  0%
 6 70   0  0%
 8  71824   0 54%
 9  37572   0 28%
ICAM utilization:   Module   Created  Failed   %Used
 1  1   0  0%
 2  3   0  2%
 5  0   0  0%
 6  0   0  0%
 8  4   0  3%
 9  0   0  0%

Flowmasks:   Mask#   TypeFeatures
   IPv4: 0   reservednone
   IPv4: 1   Intf FulFM_GUARDIAN
   IPv4: 2   unused  none
   IPv4: 3   reservednone

   IPv6: 0   reservednone
   IPv6: 1   unused  none
   IPv6: 2   unused  none
   IPv6: 3   reservednone
___
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/


___
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] ICMP PAT

2008-06-04 Thread Everton da Silva Marques
On Wed, Jun 04, 2008 at 12:23:32AM +0300, Ibrahim Abo Zaid wrote:
 Hi Oli
 
 I read that @
 http://www.cisco.com/en/US/technologies/tk648/tk361/tk438/technologies_white_paper09186a00801af2b9.html
 
 best regards
 --Abo Zaid
 
 On Tue, Jun 3, 2008 at 7:03 PM, Oliver Boehmer (oboehmer) 
 [EMAIL PROTECTED] wrote:
 
  Ibrahim Abo Zaid  wrote on Tuesday, June 03, 2008 10:46 AM:
 
   Hi All
  
   according to Cisco docs , if ICMP PAT  is configured , ICMP packets
   sequence numbers are associated to ports in NAT table means a
   continuous traffic between a source and
   a destination can create up to 65535 entries in NAT table !!!
  
   is that right , 65K entries for single flow ?
 
  no, a continuous ping creates a single entry in the NAT table (just
  checked).. where did you read the above?

Hi Oliver,

I recently saw the following under c1841-ipbasek9-mz.124-15.T5.bin:

interface FastEthernet0/0
 ip address 200.xxx.yyy.171 255.255.255.248
 ip nat outside

interface FastEthernet0/1
 ip address 10.0.0.1 255.255.255.0
 ip nat inside

ip nat inside source static 10.0.0.4 200.xxx.yyy.173

PING requests sent from 10.0.0.4 were translated with
one single static NAT entry.

However, every PING request from outside towards
200.xxx.yyy.173 would create a dynamic NAT entry.
Thus a continuous PING resulted in the NAT table
growing continuosly...

This behavior surprised me but I didn't have the
chance to investigate it further. Can you tell
whether this behavior is actually intended?

Cheers,
Everton
___
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] 6500 NDE aging prematurely

2008-06-04 Thread Phil Mayers

Ben Hicks wrote:
 From 
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/prod_white_paper0900aecd80406232.html


-The NetFlow cache is constantly filling with flows and software in the 
router or switch is searching the cache for flows that have terminated 
or expired and these flows are exported to the NetFlow collector server. 
Flows are terminated when the network communication has ended (ie: a 
packet contains the TCP FIN flag). The following steps are used to 


Ok, this appears to be the key.

I was under the impression that the 6500 PFC/DFC were not TCP-flag 
aware, however as you say, testing indicates they are.


Thanks all.
___
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] Solution to %SPANTREE-2-RECV_PVID_ERR, except disable spanning tree?

2008-06-04 Thread Benjamin.Conconi
We had a similar problem a time ago. We did some tests with a cisco es20
linecard and eompls services. This card has a feature called
vlan-translation were you can translate one vlan to a other. So we had a
setup like this


|-||---||-|
|2960 |--Vlan 2412-|Eompls |--Vlan 2413-|2960 |
|-||---||-|

The problem is, that the PVSTP couples the vlan id with the bridge
priority. Means if you let your bridge priority by default, the bridge
priority of vlan 2412 is 32768 + 2412 = 35180. Hence the bridge priority
of vlan 2413 is 35181. You can verify this with the command sh
spanning-tree.

Both, the bridge priority and the vlan id are integrated in the bpdu of
the pvstp algorithm. If the left-hand switch sends a bpdu to the eompls
core, the vlan id 2412 will be translated to 2413, but the bridge
priority remains. Because the bridge priority and the vlan id are
coupled by a simple addition, the right-hand switch (2960) detects, that
something changed the vlan id. The Switch will then block the vlan and
it apperas with the message you got:

 %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/25 on
 VLAN2413. Inconsistent local vlan

So, I would mean it is the fault of your service provider rather than
yours.

Regards,
Benjamin Conconi



On Mon, Jun 02, 2008 at 09:34:10PM -0600, Clinton Work wrote:

 I think that you need to speak with your service provider.  Based upon

 the error message it looks like vlan 2412 at site #1 is connected to  
 vlan 2413 at site #2. There was a post six to 12 months ago on the
same  
 topic and it was a service provider issue. 

I don't think the provider has got a bad configuration, partly
because we have spoken with them about this several times and
partly because of what I didn't include below, that we have the
same problem for every vlan they gave us (30 in all, 6 each to
5 locations). As long as we only use one vlan to each location,
everything works. When we add another vlan to one of the locations,
all 6 vlans to that location goes into blocking mode because of the
errors below. It could possibly be a systematic error somewhere.

 STP to L2 FTTx gear:
 http://puck.nether.net/pipermail/cisco-nsp/2008-January/046310.html

Great thread on the subject. I hadn't seen that, I will read it and
check for ideas.

Many thanks!

Peter Olsson


 Clinton. 

 Peter Olsson wrote:
 Two offices have a cisco 3750 each. They connect via a
 bridged fastethernet service, on non-cisco equipment,
 which offers six vlans on the line. When the 3750 only
 allow one vlan on the switch port toward the line,
 everything works fine.

 When we try to add another allowed vlan, we get this error
 and both vlans block:
 %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer
 vlan id 2412 on GigabitEthernet1/0/25 VLAN2413.
 %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/25 on
 VLAN2413. Inconsistent local vlan.
 %SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet1/0/25 on
 VLAN2412. Inconsistent peer vlan.



   


 -- 
 ===
 Clinton Work
 Airdrie, AB
___
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] 6500 NDE aging prematurely

2008-06-04 Thread Tassos Chatzithomaoglou

The numbers/reasons given are for software platforms.

This is the default output from a 7200:

7200#sh ip cache flow | i timeout
  Active flows timeout in 30 minutes
  Inactive flows timeout in 15 seconds


On the 6500, the NDE is a different story, but according to Cisco:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/nde.html#wp1140433

-
NDE packets go to the external data collector either when the number of recently expired flows reaches a predetermined maximum or 
after:


.30 seconds for version 5 export.
.10 seconds for version 9 export.
-

I wish it was more clear...

--
Tassos

Phil Mayers wrote on 4/6/2008 4:06 μμ:

Tassos Chatzithomaoglou wrote:

A flow is exported when :

1) it is inactive for a specific time (default 15 secs)*


I don't think that's correct. I think the default is 300 seconds.

2) it is active and has lasted longer than a specific time (default 30 
mins)*


Sure; that's not this

3) a TCP flag (FIN/RST?) is received, indicating that the flow is 
terminated


Really? Are you certain about that? I was under the impression that the 
PFC did not act on TCP flags.




(*) 6500 uses different timers, if i remember right..

--
Tassos

Phil Mayers wrote on 4/6/2008 3:42 μμ:

Ben Hicks wrote:
Forgive me if I'm missing something but you are looking at the 
actual end times of the TCP flows, not the exports (which happen 
continuously in chunks anyway). The flows will be reported as they 
end. So a 30 second connection will be reported once its finished, 
not at the end of the 5 minute period.


That was not my understanding. My understanding was that the flow 
start and end times were of the first and last packets seen, and that 
a flow should be exported when:


 now - last_packet = 300 seconds

...with default aging timers.

So, if we have 3 packets:

 12:35:00
 12:36:00
 12:37:00

...the flow should be exported at ~12:42 i.e. 300 seconds after the 
last packet.




Many thanks,

Ben


-Original Message-
From: [EMAIL PROTECTED] on behalf of Phil Mayers
Sent: Wed 04/06/2008 12:53
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 6500 NDE aging prematurely

All,

We use nfdump/nfsen to gather our flows. The nfcap daemon writes the
flows to 5-minute-window files, the filename being the *start* of the
5-minute window.

If I look at e.g. nfcapd.200806041235 I see the following distribution
of flow *end* times:

 732 2008-06-04 12:29
   16492 2008-06-04 12:30
   19769 2008-06-04 12:31
   22704 2008-06-04 12:32
   21701 2008-06-04 12:33
   91460 2008-06-04 12:34
  148540 2008-06-04 12:35
  153881 2008-06-04 12:36
  177542 2008-06-04 12:37
  184133 2008-06-04 12:38
  143340 2008-06-04 12:39

Given that we are running with the default aging parameters:

  enable timeout  packet threshold
  -- ---  
normal aging true   300N/A
fast aging   false  32 100
long aging   true   1920   N/A

...I'm puzzled; surely during the window 12:35:00 - 12:39:59 we should
only ever receive flows with end time up to 12:35:00 (plus or minus a
few tens of seconds, depending on the aging)

Why is the router exporting flows which have been inactive for 
only ~1

minute?

The box isn't busy with regards netflow (considering we have fast aging
disabled and lot of 1-packet flows) so I don't think that's the cause.

TCAM utilization:   Module   Created  Failed   %Used
 1  72227   0 55%
 2  65312   0 49%
 5 75   0  0%
 6 70   0  0%
 8  71824   0 54%
 9  37572   0 28%
ICAM utilization:   Module   Created  Failed   %Used
 1  1   0  0%
 2  3   0  2%
 5  0   0  0%
 6  0   0  0%
 8  4   0  3%
 9  0   0  0%

Flowmasks:   Mask#   TypeFeatures
   IPv4: 0   reservednone
   IPv4: 1   Intf FulFM_GUARDIAN
   IPv4: 2   unused  none
   IPv4: 3   reservednone

   IPv6: 0   reservednone
   IPv6: 1   unused  none
   IPv6: 2   unused  none
   IPv6: 3   reservednone
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp

Re: [c-nsp] ACL making me insane

2008-06-04 Thread Fred Reimer
What platform is this on again?  If you want to use a Cisco IOS router
as a firewall, why don't you use the firewall features and configure
CBAC?


Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Blayzor
Sent: Wednesday, June 04, 2008 8:35 AM
To: Ziv Leyes
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ACL making me insane

On Jun 4, 2008, at 7:25 AM, Ziv Leyes wrote:
 There's no way to use established for UDP though, so I can share  
 what works for me, I call them operational rules because they suit  
 everything I need to allow that is host initiated/related for its  
 own functionality, of course you could add some more rules to permit  
 other tcp/udp ports to reach the desired host/net.



Of course not.. ACL's are very basic and are not stateful in any way.   
So if you're trying to use it in that way, it's very difficult and you  
end up with a lot of loose rules.  Of course for DNS you could just  
allow responses from the DNS server from UDP port 53 to any port   
1023, but it's loose.  If you have a recursive DNS server inside of  
that ACL, then you're going to have to allow from ALL IP's from port  
UDP port 53.

Keep your ACL's basic and to the point, trying to make them overly  
complicated to replace a stateful firewall kind of defeats the purpose  
and ends up being more trouble than it's worth. (IMHO)

-- 
Robert Blayzor, BOFH
INOC, LLC
[EMAIL PROTECTED]
http://www.inoc.net/~rblayzor/



___
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] Solution to %SPANTREE-2-RECV_PVID_ERR, except disable spanning tree?

2008-06-04 Thread Fred Reimer
The provider may not support PVST+ or Rapid PVST+.

Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2008 9:38 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Solution to %SPANTREE-2-RECV_PVID_ERR,except
disable spanning tree?

We had a similar problem a time ago. We did some tests with a cisco es20
linecard and eompls services. This card has a feature called
vlan-translation were you can translate one vlan to a other. So we had a
setup like this


|-||---||-|
|2960 |--Vlan 2412-|Eompls |--Vlan 2413-|2960 |
|-||---||-|

The problem is, that the PVSTP couples the vlan id with the bridge
priority. Means if you let your bridge priority by default, the bridge
priority of vlan 2412 is 32768 + 2412 = 35180. Hence the bridge priority
of vlan 2413 is 35181. You can verify this with the command sh
spanning-tree.

Both, the bridge priority and the vlan id are integrated in the bpdu of
the pvstp algorithm. If the left-hand switch sends a bpdu to the eompls
core, the vlan id 2412 will be translated to 2413, but the bridge
priority remains. Because the bridge priority and the vlan id are
coupled by a simple addition, the right-hand switch (2960) detects, that
something changed the vlan id. The Switch will then block the vlan and
it apperas with the message you got:

 %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/25 on
 VLAN2413. Inconsistent local vlan

So, I would mean it is the fault of your service provider rather than
yours.

Regards,
Benjamin Conconi



On Mon, Jun 02, 2008 at 09:34:10PM -0600, Clinton Work wrote:

 I think that you need to speak with your service provider.  Based upon

 the error message it looks like vlan 2412 at site #1 is connected to  
 vlan 2413 at site #2. There was a post six to 12 months ago on the
same  
 topic and it was a service provider issue. 

I don't think the provider has got a bad configuration, partly
because we have spoken with them about this several times and
partly because of what I didn't include below, that we have the
same problem for every vlan they gave us (30 in all, 6 each to
5 locations). As long as we only use one vlan to each location,
everything works. When we add another vlan to one of the locations,
all 6 vlans to that location goes into blocking mode because of the
errors below. It could possibly be a systematic error somewhere.

 STP to L2 FTTx gear:
 http://puck.nether.net/pipermail/cisco-nsp/2008-January/046310.html

Great thread on the subject. I hadn't seen that, I will read it and
check for ideas.

Many thanks!

Peter Olsson


 Clinton. 

 Peter Olsson wrote:
 Two offices have a cisco 3750 each. They connect via a
 bridged fastethernet service, on non-cisco equipment,
 which offers six vlans on the line. When the 3750 only
 allow one vlan on the switch port toward the line,
 everything works fine.

 When we try to add another allowed vlan, we get this error
 and both vlans block:
 %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer
 vlan id 2412 on GigabitEthernet1/0/25 VLAN2413.
 %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/25 on
 VLAN2413. Inconsistent local vlan.
 %SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet1/0/25 on
 VLAN2412. Inconsistent peer vlan.



   


 -- 
 ===
 Clinton Work
 Airdrie, AB
___
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] Giving customers access to your gear.

2008-06-04 Thread Rick Martin
Troy wrote in part;


2) If the customer wants to provide a their own router, they may do so
and
eliminate this issue. Basic configs are provided and any support beyond
that is billed at $150 per hour, minimum 1 hour.


 What is your routing policy when a customer owns their own router and
connects it to your network? In our case we discourage customer owned
routers but we do not totally ban it. Our policy is that we do not share
any dynamic routing protocol with routers not under our direct/sole
control. If a customer wants to install their own router we accommodate
that but use static routing only. 

 I am in a situation now where we will be sharing BGP (peer) with a
particular customer, this is completely outside our normal policy but in
this particular situation we pretty much have to accommodate this
request. At least with BGP we can manage what we are advertising to said
customer and what we will accept. 

Thanks
rick

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2008 1:16 AM
To: Richey
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Giving customers access to your gear.

I know that we have come across this a few times. Here is what we have
in
place (policy wise) for these kind of customers.

1) If the router is owned by us, the customer does not get the passwords
or SNMP strings. Should the customer want to purchase said router from
us,
we are more than happy to turn it over to them.

2) If the customer wants to provide a their own router, they may do so
and
eliminate this issue. Basic configs are provided and any support beyond
that is billed at $150 per hour, minimum 1 hour.

Both 1 and 2 do have stipulations. If you are given access to the router
or if you supply your own router, you will be given basic config
information. Should you lock yourself out of or render the router
useless,
we will bill you for a truck roll, time on site and if needed,
replacement
parts/hardware at a rate of $150 per hour. Minimum 1 hour + truck roll
of
$150.

We don't give out any information to hardware that serves multiple
customers for any reason.

Hope this is helpful.

-Troy

 I've got a customer with a T1.  They have been bought out by a large
hotel
 chain.  They are pretty much demanding that they have SNMP full read
 access
 to our router that is at their location as well as a copy of the
config
 for
 the router.   This is not their router, it is ours and we fully manage
our
 router and hand them  Ethernet. This seems a little odd that they
want
 access to our gear, and I am not too keen on giving them access unless
 they
 are willing to accept some responsibility.   They don't want to accept
any
 responsibility for the access they would have to this box. They
say
 that
 Verizion and ATT don't have any problems giving them this kind of
access
 to
 their gear.



 Any thoughts from the group?



 Richey



 ___
 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] Solution to %SPANTREE-2-RECV_PVID_ERR, except disable spanning tree?

2008-06-04 Thread Joe Freeman
The provider doesn't have to support it. In fact, from what the OP said, it
sounds like the provider has enabled control protocol tunneling across his
metro-e cloud. It also sounds like they are using a solution that requires
some form of cross-connect config in the cloud and have cross connected one
vlan to another, which is probably the root cause of this.

If the provider had cross-connected the same vlan on each C-UNI port, the OP
would probably not be seeing this issue.

Joe

On Wed, Jun 4, 2008 at 8:49 AM, Fred Reimer [EMAIL PROTECTED] wrote:

 The provider may not support PVST+ or Rapid PVST+.

 Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
 Senior Network Engineer
 Coleman Technologies, Inc.
 954-298-1697


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of
 [EMAIL PROTECTED]
 Sent: Wednesday, June 04, 2008 9:38 AM
 To: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] Solution to %SPANTREE-2-RECV_PVID_ERR,except
 disable spanning tree?

 We had a similar problem a time ago. We did some tests with a cisco es20
 linecard and eompls services. This card has a feature called
 vlan-translation were you can translate one vlan to a other. So we had a
 setup like this


 |-||---||-|
 |2960 |--Vlan 2412-|Eompls |--Vlan 2413-|2960 |
 |-||---||-|

 The problem is, that the PVSTP couples the vlan id with the bridge
 priority. Means if you let your bridge priority by default, the bridge
 priority of vlan 2412 is 32768 + 2412 = 35180. Hence the bridge priority
 of vlan 2413 is 35181. You can verify this with the command sh
 spanning-tree.

 Both, the bridge priority and the vlan id are integrated in the bpdu of
 the pvstp algorithm. If the left-hand switch sends a bpdu to the eompls
 core, the vlan id 2412 will be translated to 2413, but the bridge
 priority remains. Because the bridge priority and the vlan id are
 coupled by a simple addition, the right-hand switch (2960) detects, that
 something changed the vlan id. The Switch will then block the vlan and
 it apperas with the message you got:

  %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/25 on
  VLAN2413. Inconsistent local vlan

 So, I would mean it is the fault of your service provider rather than
 yours.

 Regards,
 Benjamin Conconi



 On Mon, Jun 02, 2008 at 09:34:10PM -0600, Clinton Work wrote:
 
  I think that you need to speak with your service provider.  Based upon

  the error message it looks like vlan 2412 at site #1 is connected to
  vlan 2413 at site #2. There was a post six to 12 months ago on the
 same
  topic and it was a service provider issue.

 I don't think the provider has got a bad configuration, partly
 because we have spoken with them about this several times and
 partly because of what I didn't include below, that we have the
 same problem for every vlan they gave us (30 in all, 6 each to
 5 locations). As long as we only use one vlan to each location,
 everything works. When we add another vlan to one of the locations,
 all 6 vlans to that location goes into blocking mode because of the
 errors below. It could possibly be a systematic error somewhere.

  STP to L2 FTTx gear:
  http://puck.nether.net/pipermail/cisco-nsp/2008-January/046310.html

 Great thread on the subject. I hadn't seen that, I will read it and
 check for ideas.

 Many thanks!

 Peter Olsson

 
  Clinton.
 
  Peter Olsson wrote:
  Two offices have a cisco 3750 each. They connect via a
  bridged fastethernet service, on non-cisco equipment,
  which offers six vlans on the line. When the 3750 only
  allow one vlan on the switch port toward the line,
  everything works fine.
 
  When we try to add another allowed vlan, we get this error
  and both vlans block:
  %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer
  vlan id 2412 on GigabitEthernet1/0/25 VLAN2413.
  %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/25 on
  VLAN2413. Inconsistent local vlan.
  %SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet1/0/25 on
  VLAN2412. Inconsistent peer vlan.
 
 
 
 
 
 
  --
  ===
  Clinton Work
  Airdrie, AB
 ___
 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/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at 

Re: [c-nsp] Solution to %SPANTREE-2-RECV_PVID_ERR, except disable spanning tree?

2008-06-04 Thread Tassos Chatzithomaoglou


Is the provider using some kind of 802.1q tunneling to pass your traffic across 
its network?
If yes, have they enabled L2PT for STP?

Can you check if STP is working fine (as a single domain) for a single vlan?
Do you see a common root in both edge switches?

Can you provide the config from your side on both edge switches?

--
Tassos

Peter Olsson wrote on 4/6/2008 2:31 μμ:

On Mon, Jun 02, 2008 at 09:34:10PM -0600, Clinton Work wrote:
I think that you need to speak with your service provider.  Based upon  
the error message it looks like vlan 2412 at site #1 is connected to  
vlan 2413 at site #2. There was a post six to 12 months ago on the same  
topic and it was a service provider issue. 


I don't think the provider has got a bad configuration, partly
because we have spoken with them about this several times and
partly because of what I didn't include below, that we have the
same problem for every vlan they gave us (30 in all, 6 each to
5 locations). As long as we only use one vlan to each location,
everything works. When we add another vlan to one of the locations,
all 6 vlans to that location goes into blocking mode because of the
errors below. It could possibly be a systematic error somewhere.


STP to L2 FTTx gear:
http://puck.nether.net/pipermail/cisco-nsp/2008-January/046310.html


Great thread on the subject. I hadn't seen that, I will read it and
check for ideas.

Many thanks!

Peter Olsson

Clinton. 


Peter Olsson wrote:

Two offices have a cisco 3750 each. They connect via a
bridged fastethernet service, on non-cisco equipment,
which offers six vlans on the line. When the 3750 only
allow one vlan on the switch port toward the line,
everything works fine.

When we try to add another allowed vlan, we get this error
and both vlans block:
%SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer
vlan id 2412 on GigabitEthernet1/0/25 VLAN2413.
%SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/25 on
VLAN2413. Inconsistent local vlan.
%SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet1/0/25 on
VLAN2412. Inconsistent peer vlan.



  


--
===
Clinton Work
Airdrie, AB

___
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] Giving customers access to your gear.

2008-06-04 Thread Justin M. Streiner

On Wed, 4 Jun 2008, Rick Martin wrote:


What is your routing policy when a customer owns their own router and
connects it to your network? In our case we discourage customer owned
routers but we do not totally ban it. Our policy is that we do not share
any dynamic routing protocol with routers not under our direct/sole
control. If a customer wants to install their own router we accommodate
that but use static routing only.

I am in a situation now where we will be sharing BGP (peer) with a
particular customer, this is completely outside our normal policy but in
this particular situation we pretty much have to accommodate this
request. At least with BGP we can manage what we are advertising to said
customer and what we will accept.


I've done BGP in the past with customers where they owned the CPE routers. 
That's OK, because BGP is easy to filter and generally clamp down so that 
the opportunities for bad things to happen through that router can be 
managed to keep the level of risk pretty low.  At my former employer, we 
had a standing policy not to run other routing protocols with customers if 
they had any access to the routers.


jms
___
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] ICMP PAT

2008-06-04 Thread Rodney Dunn
I couldn't make that happen in the lab:

R1_#
*Jun  4 14:40:55.344: NAT*: i: icmp (1.1.1.1, 6) - (2.2.2.2, 6) [25]
*Jun  4 14:40:55.344: NAT*: i: icmp (1.1.1.1, 6) - (2.2.2.2, 6) [25]
*Jun  4 14:40:55.344: NAT*: s=1.1.1.1-192.168.1.1, d=2.2.2.2 [25]
*Jun  4 14:40:55.348: NAT*: i: icmp (1.1.1.1, 6) - (2.2.2.2, 6) [26]
*Jun  4 14:40:55.348: NAT*: s=1.1.1.1-192.168.1.1, d=2.2.2.2 [26]
*Jun  4 14:40:55.352: NAT*: i: icmp (1.1.1.1, 6) - (2.2.2.2, 6) [27]
*Jun  4 14:40:55.352: NAT*: s=1.1.1.1-192.168.1.1, d=2.2.2.2 [27]
*Jun  4 14:40:55.360: NAT*: i: icmp (1.1.1.1, 6) - (2.2.2.2, 6) [28]
*Jun  4 14:40:55.360: NAT*: s=1.1.1.1-192.168.1.1, d=2.2.2.2 [28]
R1_#
R1_#debug ip nat det
R1_#sh ip nat trans 
Pro Inside global  Inside local   Outside local  Outside global
icmp 192.168.1.1:6 1.1.1.1:6  2.2.2.2:6  2.2.2.2:6
--- 192.168.1.11.1.1.1------
R1_#
R1_#

interface Ethernet0/0
ip address 1.1.1.2 255.255.255.0
 ip nat inside
interface Ethernet1/0
 ip address 2.2.2.1 255.255.255.0
 ip nat outside
R1_#  
ip nat inside source static 1.1.1.1 192.168.1.1
R1_#

Those are pings from out to in matching a static nat entry.

Can you elaborate or show us an example of where you are seeing
it and try:

R1_(config)#no ip nat create ?
  flow-entries  NAT create flow based entries



On Wed, Jun 04, 2008 at 10:11:11AM -0300, Everton da Silva Marques wrote:
 On Wed, Jun 04, 2008 at 12:23:32AM +0300, Ibrahim Abo Zaid wrote:
  Hi Oli
  
  I read that @
  http://www.cisco.com/en/US/technologies/tk648/tk361/tk438/technologies_white_paper09186a00801af2b9.html
  
  best regards
  --Abo Zaid
  
  On Tue, Jun 3, 2008 at 7:03 PM, Oliver Boehmer (oboehmer) 
  [EMAIL PROTECTED] wrote:
  
   Ibrahim Abo Zaid  wrote on Tuesday, June 03, 2008 10:46 AM:
  
Hi All
   
according to Cisco docs , if ICMP PAT  is configured , ICMP packets
sequence numbers are associated to ports in NAT table means a
continuous traffic between a source and
a destination can create up to 65535 entries in NAT table !!!
   
is that right , 65K entries for single flow ?
  
   no, a continuous ping creates a single entry in the NAT table (just
   checked).. where did you read the above?
 
 Hi Oliver,
 
 I recently saw the following under c1841-ipbasek9-mz.124-15.T5.bin:
 
 interface FastEthernet0/0
  ip address 200.xxx.yyy.171 255.255.255.248
  ip nat outside
 
 interface FastEthernet0/1
  ip address 10.0.0.1 255.255.255.0
  ip nat inside
 
 ip nat inside source static 10.0.0.4 200.xxx.yyy.173
 
 PING requests sent from 10.0.0.4 were translated with
 one single static NAT entry.
 
 However, every PING request from outside towards
 200.xxx.yyy.173 would create a dynamic NAT entry.
 Thus a continuous PING resulted in the NAT table
 growing continuosly...
 
 This behavior surprised me but I didn't have the
 chance to investigate it further. Can you tell
 whether this behavior is actually intended?
 
 Cheers,
 Everton
 ___
 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] Solution to %SPANTREE-2-RECV_PVID_ERR, except disable spanning tree?

2008-06-04 Thread Clinton Work


Cisco PVST+ / RPVST do integrate the vlan ID into the bridge priority 
(bit stealing), but that is a function of MAC reduction to support 4096 
VLANs rather than PVST+ proper.  MAC reduction will do the same thing 
with regular 802.1d BPDU priority values and you can interconnection two 
Vlans with 802.1D without causing problems.  The PVST+/RPVST BPDU format 
has an extra TLV added onto the end with an attribute called PVID.  The 
PVID attribute is simply the vlan that the STP BPDU is intended for.  
All the Spanning-Tree PVID error detection and messages are based upon 
the PVID TLV. 

Clinton. 


[EMAIL PROTECTED] wrote:

We had a similar problem a time ago. We did some tests with a cisco es20
linecard and eompls services. This card has a feature called
vlan-translation were you can translate one vlan to a other. So we had a
setup like this


|-||---||-|
|2960 |--Vlan 2412-|Eompls |--Vlan 2413-|2960 |
|-||---||-|

The problem is, that the PVSTP couples the vlan id with the bridge
priority. Means if you let your bridge priority by default, the bridge
priority of vlan 2412 is 32768 + 2412 = 35180. Hence the bridge priority
of vlan 2413 is 35181. You can verify this with the command sh
spanning-tree.

Both, the bridge priority and the vlan id are integrated in the bpdu of
the pvstp algorithm. If the left-hand switch sends a bpdu to the eompls
core, the vlan id 2412 will be translated to 2413, but the bridge
priority remains. Because the bridge priority and the vlan id are
coupled by a simple addition, the right-hand switch (2960) detects, that
something changed the vlan id. The Switch will then block the vlan and
it apperas with the message you got:

  




--

=
Clinton Work
Airdrie, AB

___
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] Source failure in PIM SSM

2008-06-04 Thread alaerte.vidali
Hi,

Any recommendation for docs handling source failure when PIM SSM is
used?

Example:

Source 1.1.1.1, group 239.1.1.1 -R1R2--PC_joined 239.1.1.1
using IGMPv2

R2 has SSM mapping group 239.1.1.1 to sorce 1.1.1.1

I have seem 2 options: Anycast and Prioritycast. Would like to here
other opinion.

Tks,
Alaerte 
___
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] Giving customers access to your gear.

2008-06-04 Thread John Osmon
On Wed, Jun 04, 2008 at 09:12:33AM -0500, Rick Martin wrote:
[...]
  What is your routing policy when a customer owns their own router and
 connects it to your network?

We try to stick to the idea that everyone gets s single connection
to us (ethernet, T1, DSL, whatever).  We expect a layer 3 device
on on that connection, and we'll route them any/all address space
that they can justify.

So -- our customers have either a single host, or a router touching
us at all times.

Back to the original question -- customer access to our routers is
limited to packets they want routed.  BGP is a legitimate exception.

When customers have been adamant about having access to the other
end of the connection, I've offered to co-lo a router for them, and
let them run their own access circuit.  I don't recall anyone
ever taking us up on that offer.
___
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] Setting weight on import into vrf

2008-06-04 Thread Pshem Kowalczyk
Hi,

Should the following work on a 6500 (12.2(18)SXF10):

ip vrf custxxx
 rd :110118
 import map IMPORT-INTO-CUSTXXX
 route-target import yyy:110
 route-target export yyy:110

route-map IMPORT-INTO-CUSTXXX permit 10
 match extcommunity 110
 set weight 100

ip extcommunity-list 110 permit RT::110

The routes get imported, but the weight remains unset.

The whole setup looks like this:

   ---session 1---
CUSTPE1
   ---session 2---

   ---session 3---
CUSTPE2
   ---session 4---

Due to existing arrangements sessions 1  3 are supposed to be the
primary ones, 24 backup ones (links that carry primary sessions have
higher cir guarantees through third-party metro provider) . So if one
of the primary sessions on the PE(1/2) goes down the other primary
session (on the other PE) should be used. And only if both primary
ones go off - local secondary one. So far we only had one set of
sessions (only PE1 and sessions 1  2) and that worked quite well with
the weight. Is there a way to make it work with weight or should I use
something else to influence the decision?

kind regards
Pshem
___
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] Setting weight on import into vrf

2008-06-04 Thread David Barak
 Original Message 
From: Pshem Kowalczyk [EMAIL PROTECTED]

 Is there a way to make it work with weight or should I use
something else to influence the decision?

Given that weight won't be communicated between the PE routers, I wouldn't 
recommend using it in this case - local_preference is next in the algorithm, 
and it should do what you want.
David Barak
Need Geek Rock? Try The Franchise: 
http://www.listentothefranchise.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/


[c-nsp] bgp router

2008-06-04 Thread Rossella Mariotti-Jones
Hello all, we're looking to buy a router on which to run BGP that can
take full BGP routes, I know all Cisco routers (1800 up) with Advanced
IP services IOS will do BGP and I've been told that if we max out the
memory we'll be fine with any router. We're going to need some ports (up
to 24) in this router. We're looking at a 7604 with sup720-3b and 1gb of
memory, a 2821 or 2851 with an nme and 1gb of memory, or another
possibility is the ASR platform, but I haven't looked into this well
yet. Any recommendations? Thanks in advance.

***
Rossella Mariotti-Jones
[EMAIL PROTECTED]


Network Analyst, SS - SPIR - IT TAC
desk 503-589-7775 - cell 503-480-4255

 PRIVILEGED AND CONFIDENTIAL COMMUNICATION   This electronic
transmission, and any documents attached hereto, may contain
confidential and/or legally privileged information.  The information is
intended only for use by the recipient named above.  If you have
received this electronic message in error, please notify the sender and
delete the electronic message.  Any disclosure, copying, distribution,
or use of the contents of information received in error is strictly
prohibited.

___
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] Giving customers access to your gear.

2008-06-04 Thread Sam Stickland

Richey wrote:

I've got a customer with a T1.  They have been bought out by a large hotel
chain.  They are pretty much demanding that they have SNMP full read access
to our router that is at their location as well as a copy of the config for
the router.   This is not their router, it is ours and we fully manage our
router and hand them  Ethernet. This seems a little odd that they want
access to our gear, and I am not too keen on giving them access unless they
are willing to accept some responsibility.   They don't want to accept any
responsibility for the access they would have to this box. They say that
Verizion and ATT don't have any problems giving them this kind of access to
their gear.   

 


Any thoughts from the group
Well, from another angle, we've asked for - and been given - this access 
from major providers without incident. At my current place of employment 
we have a large MPLS L3 VPN provided by Cable  Wireless and we have 
SNMP RO and SSH access on all of the deployed PEs. The SSH access is 
command authorisation limited - there is no show run for example - and 
we use CW provided RSA tokens.


Telstra (one of our upstream providers) actually asked to have SNMP RO 
access to our end of the BGP handoff.


Sam
___
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] Giving customers access to your gear.

2008-06-04 Thread Sam Stickland

Rick Martin wrote:

 What is your routing policy when a customer owns their own router and
connects it to your network? In our case we discourage customer owned
routers but we do not totally ban it. Our policy is that we do not share
any dynamic routing protocol with routers not under our direct/sole
control. If a customer wants to install their own router we accommodate
that but use static routing only. 


 I am in a situation now where we will be sharing BGP (peer) with a
particular customer, this is completely outside our normal policy but in
this particular situation we pretty much have to accommodate this
request. At least with BGP we can manage what we are advertising to said
customer and what we will accept. 
  
If you were providing MPLS L3 VPNs then you would be running BGP with 
most of your customers routers. Likewise if you were selling BGP transit 
(by definition). There's nothing wrong with running BGP with your 
customers - just make sure you have adequate prefix-filters and 
max-prefix-counts set.


Sam

___
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] bgp router

2008-06-04 Thread Jon Lewis

On Wed, 4 Jun 2008, Rossella Mariotti-Jones wrote:


Hello all, we're looking to buy a router on which to run BGP that can
take full BGP routes, I know all Cisco routers (1800 up) with Advanced
IP services IOS will do BGP and I've been told that if we max out the
memory we'll be fine with any router. We're going to need some ports (up
to 24) in this router. We're looking at a 7604 with sup720-3b and 1gb of
memory, a 2821 or 2851 with an nme and 1gb of memory, or another
possibility is the ASR platform, but I haven't looked into this well
yet. Any recommendations? Thanks in advance.


7600 and 2800 series are very different beasts.  Figure out what sort of 
throughput/backplane capacity you need and that should point you towards 
the apropriate platform.  If you go 7600, don't buy less than the 
sup720-3bxl.  The older sup720-3b, regardless of how much RAM you put on 
it, won't properly handle full routes.


--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_
___
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] Source failure in PIM SSM

2008-06-04 Thread Jeff Tantsura
Hi,

I don't think there's much more than that, any other technology would be
some kind of prioritycast, it's just about how to make one route more
preferable than the other, different metrics, different prefix length etc.

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:cisco-nsp-
 [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
 Sent: woensdag 4 juni 2008 16:56
 To: cisco-nsp@puck.nether.net
 Subject: [c-nsp] Source failure in PIM SSM
 
 Hi,
 
 Any recommendation for docs handling source failure when PIM SSM is
 used?
 
 Example:
 
 Source 1.1.1.1, group 239.1.1.1 -R1R2--PC_joined 239.1.1.1
 using IGMPv2
 
 R2 has SSM mapping group 239.1.1.1 to sorce 1.1.1.1
 
 I have seem 2 options: Anycast and Prioritycast. Would like to here
 other opinion.
 
 Tks,
 Alaerte
 ___
 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] Cisco Security Advisory: Multiple Vulnerabilities in Cisco PIX and Cisco ASA

2008-06-04 Thread Cisco Systems Product Security Incident Response Team
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cisco Security Advisory: Multiple Vulnerabilities in Cisco PIX and
Cisco ASA

Document ID: 105444

Advisory ID: cisco-sa-20080604-asa

http://www.cisco.com/warp/public/707/cisco-sa-20080604-asa.shtml

Revision 1.0

For Public Release 2008 June 04 1600 UTC (GMT)

- -

Summary
===

Multiple vulnerabilities exist in the Cisco ASA 5500 Series Adaptive
Security Appliances and Cisco PIX Security Appliances. This security
advisory outlines details of these vulnerabilities:

  * Crafted TCP ACK Packet Vulnerability
  * Crafted TLS Packet Vulnerability
  * Instant Messenger Inspection Vulnerability
  * Vulnerability Scan Denial of Service
  * Control-plane Access Control List Vulnerability

The first four vulnerabilities may lead to a denial of service (DoS)
condition and the fifth vulnerability may allow an attacker to bypass
control-plane access control lists (ACL).

Note:  These vulnerabilities are independent of each other. A device
may be affected by one vulnerability and not affected by another.

Cisco has released free software updates that address these
vulnerabilities. Workarounds that mitigate some of these
vulnerabilities are available.

This advisory is posted at 
http://www.cisco.com/warp/public/707/cisco-sa-20080604-asa.shtml

Affected Products
=

Vulnerable Products
+--

The following are the details about each vulnerability described
within this advisory.

Crafted TCP ACK Packet Vulnerability
+---

Cisco ASA and Cisco PIX devices are affected by a crafted TCP
acknowledgment (ACK) packet vulnerability. Software versions prior to
7.1(2)70 on the 7.1.x release, 7.2(4) on the 7.2.x release, and 8.0
(3)10 on the 8.0.x release are affected. Cisco ASA or Cisco PIX
security appliances running software version 7.0.x, or 8.1.x are not
vulnerable.

Cisco ASA and Cisco PIX devices running versions 7.1.x and 7.2.x with
WebVPN, SSL VPN, or ASDM enabled are affected by this vulnerability.
Devices running software versions on the 8.0 release that are
configured for Telnet, Secure Shell (SSH), WebVPN, SSL VPN, or ASDM
enabled are affected by this vulnerability.

Note: Devices running IPv4 and IPv6 are affected by this
vulnerability.

Crafted TLS Packet Vulnerability
+---

Cisco ASA and Cisco PIX devices are affected by a crafted TLS request
vulnerability if the HTTPS server on the Cisco ASA or Cisco PIX
device is enabled and is running software versions prior to 8.0(3)9
on the 8.0.x release or prior to version 8.1(1)1 on the 8.1.x
release. Cisco ASA and Cisco PIX appliances running software versions
7.x are not vulnerable.

Instant Messenger Inspection Vulnerability
+-

Cisco ASA and Cisco PIX devices are affected by a crafted packet
vulnerability if Instant Messaging Inspection is enabled and the
device is running software versions prior to 7.2(4) on the 7.2.x
release, 8.0(3)10 on the 8.0.x release, or 8.1(1)2 on the 8.1.x
release. Devices running software versions in the 7.0.x and 7.1.x
releases are not vulnerable. Additionally, devices that do not have
Instant Messaging Inspection enabled are not vulnerable.

Note:  Instant Messaging Inspection is disabled by default.

Vulnerability Scan Denial of Service
+---

Cisco ASA and Cisco PIX devices are affected by a vulnerability
(port) scan denial of service vulnerability if the device is running
software versions prior to 7.2(3)2 on the 7.2.x release or 8.0(2)17
on the 8.0.x release. Cisco ASA and Cisco PIX devices running
software versions 7.0.x, 7.1.x, or 8.1.x are not vulnerable.

Control-plane Access Control List Vulnerability
+--

Cisco ASA and Cisco PIX devices are affected by a vulnerability if
the device is configured to use control-plane ACLs and if it is
running software versions prior to 8.0(3)9 on the 8.0.x release.
Devices running software versions 7.x or 8.1.x are not vulnerable.

Note:  Control-plane ACLs were first introduced in software version
8.0(2). The control-plane ACLs are not enabled by default.

The show version command-line interface (CLI) command can be used to
determine if a vulnerable version of the Cisco PIX or Cisco ASA
software is running. The following example shows a Cisco ASA Security
Appliance that runs software release 8.0(2):

ASA# show version

Cisco Adaptive Security Appliance Software Version 8.0(2)
Device Manager Version 6.0(1)

[...]

Customers who use the Cisco Adaptive Security Device Manager (ASDM)
to manage their devices can find the version of the software
displayed in the table in the login window or in the upper left
corner of the ASDM window.

Products Confirmed Not Vulnerable
+

The Cisco Firewall Services Module (FWSM) is not affected

Re: [c-nsp] Giving customers access to your gear.

2008-06-04 Thread Justin Shore

Richey wrote:

I've got a customer with a T1.  They have been bought out by a large hotel
chain.  They are pretty much demanding that they have SNMP full read access
to our router that is at their location as well as a copy of the config for
the router.   This is not their router, it is ours and we fully manage our
router and hand them  Ethernet. This seems a little odd that they want
access to our gear, and I am not too keen on giving them access unless they
are willing to accept some responsibility.   They don't want to accept any
responsibility for the access they would have to this box. They say that
Verizion and ATT don't have any problems giving them this kind of access to
their gear.   


I have one situation where we lease a router to the customer and let 
their outsourced IT company manage it.  We still have full access to it 
but they officially manage it.  I gave it a basic, hardened config and 
gave their IT folks enable access to it.  I pull down the config hourly 
with RANCID.  Other than that we are hands-off with that router.  We 
pull down the config for 2 reasons: 1) to be able to quickly deploy a 
spare router in the event of a hardware failure, and 2) to cover our own 
asses in case their outsourced IT folks screw it up.  So far we haven't 
had any problems.  The customer in this particular case wanted to 
maintain a VPN tunnel to their outsourced IT company.  The router would 
also be a router on a stick for their LAN.  Neither task is something 
that we were willing to take on.  By letting the outsourced IT company 
take on the responsibility we can effectively wash our hands of any 
future problems that may arise, short of actual connectivity issues.


If the router served more than one customer then none of the customers 
would have any level of access to the device.  If they want to graph I/O 
then they can do it with their own hardware on their side of the demarc, 
no exceptions.  We're more than happy to sell a customer a router if 
they want to manage it themselves.  We'll even set it up for them at our 
hourly rate.  However if they want ongoing managed services then they 
will 1) have restricted access to the device and 2) will be purchasing 
an analog modem on a expansion card for us to get in remotely.


Sometimes is better to simplify your operations and not get drug into a 
lose/lose situation with a customer.  You have to have clear lines of 
division between the customer and the provider.


Justin

___
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] Forcing routes

2008-06-04 Thread Gary Roberton
I have a customer who is multihomed to my network.  He has RouterX.  I have
R1 and R2 connected to his RouterX.  My R1 is in AS1 and my R2 is in AS2.  I
want to sent him a BGP advertisement in such a way that he always prefers to
use R1.

I cannot use MEDs as the AS numbers of my R1 and R2 are different.
I cannot use local preference as I am not allowed to change anything on his
route (don't ask just take it as a given).
My path lengths are the same.

How can I force his router to always choose my R1 path as the best one?


Once I have done this I then want to be able to turn this on or off based on
a Tunnel on R1 being up (which I guess will be object tracking) but until I
know how to solve the first part - I can't tackle the second part.

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] Forcing routes

2008-06-04 Thread Gary Roberton
How do you mean?

On Wed, Jun 4, 2008 at 5:38 PM, Maarten Moerman [EMAIL PROTECTED] wrote:

 Hi Gary,

 AS-path prepending?

 Maarten


 --
 Sr. Network Engineer | eBay / Marktplaats.nl
 Wibautstraat 224 | 1097 DN | Amsterdam
 E-mail: [EMAIL PROTECTED] | Mobile: +31 6 55 1 222 47


 On 6/4/08 6:35 PM, Gary Roberton [EMAIL PROTECTED] wrote:

  I have a customer who is multihomed to my network.  He has RouterX.  I
 have
  R1 and R2 connected to his RouterX.  My R1 is in AS1 and my R2 is in AS2.
  I
  want to sent him a BGP advertisement in such a way that he always prefers
 to
  use R1.
 
  I cannot use MEDs as the AS numbers of my R1 and R2 are different.
  I cannot use local preference as I am not allowed to change anything on
 his
  route (don't ask just take it as a given).
  My path lengths are the same.
 
  How can I force his router to always choose my R1 path as the best one?
 
 
  Once I have done this I then want to be able to turn this on or off based
 on
  a Tunnel on R1 being up (which I guess will be object tracking) but until
 I
  know how to solve the first part - I can't tackle the second part.
 
  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] Forcing routes

2008-06-04 Thread Gary Roberton
I assume you mean to prepend AS2 on R2 so that RouterX receives the path
AS2, AS2, from R2, therefore making the path seem longer and following the
normal BGP algorithm.

Is this what you meant?

On Wed, Jun 4, 2008 at 5:38 PM, Maarten Moerman [EMAIL PROTECTED] wrote:

 Hi Gary,

 AS-path prepending?

 Maarten


 --
 Sr. Network Engineer | eBay / Marktplaats.nl
 Wibautstraat 224 | 1097 DN | Amsterdam
 E-mail: [EMAIL PROTECTED] | Mobile: +31 6 55 1 222 47


 On 6/4/08 6:35 PM, Gary Roberton [EMAIL PROTECTED] wrote:

  I have a customer who is multihomed to my network.  He has RouterX.  I
 have
  R1 and R2 connected to his RouterX.  My R1 is in AS1 and my R2 is in AS2.
  I
  want to sent him a BGP advertisement in such a way that he always prefers
 to
  use R1.
 
  I cannot use MEDs as the AS numbers of my R1 and R2 are different.
  I cannot use local preference as I am not allowed to change anything on
 his
  route (don't ask just take it as a given).
  My path lengths are the same.
 
  How can I force his router to always choose my R1 path as the best one?
 
 
  Once I have done this I then want to be able to turn this on or off based
 on
  a Tunnel on R1 being up (which I guess will be object tracking) but until
 I
  know how to solve the first part - I can't tackle the second part.
 
  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/


[c-nsp] interrupt cpu // processor routed packets

2008-06-04 Thread bill fumerola
folks,

at $WORK we use 7301s as border routers at our sites. recently,
we've seen an uptick in cpu. it's too difficult to isolate the change
that was made, but it's our belief that some feature or option has caused
a majority of packets to be run through the processor as opposed to
through cef/caches. this is happening on several routers, but i'll limit
the output to one of them.

rtr1.ash#sh int stats 
GigabitEthernet0/0
 Switch pathPkts In   Chars In   Pkts Out  Chars Out
   Processor 2784467772 2512553561 3619252418   92352609
 Route cache 1983176953 3753638533 1446323093 1223073183
   Total  472677429 1971224798  770608215 1315425792
Tunnel1004
 Switch pathPkts In   Chars In   Pkts Out  Chars Out
   Processor 3025559230 32886251643990521  311834632
 Route cache  238098300 2332344373 2454903224 3851240155
   Total 3263657530 1326002241 2458893745 4163074787

there are more tunnels than tu1004. some of them are key'd, but most are
not. 

rtr1.ash# sh int | i key|checksum
  Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
  Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
  Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
  Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
  Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
  Tunnel protocol/transport GRE/IP, key 0x138B, sequencing disabled
  Tunnel protocol/transport GRE/IP, key 0x138D, sequencing disabled
rtr1.ash#

gi0/0 has a few .1q subints.  one is the local machines, three more are
transit providers. the unicast/multicast filter tables are not full.

i'm most familiar with the cat6k series and i'm unable to find what
is causing the processor path to be tripped. we use GRE tunnels
fairly heavily in our setup and it's possible that is what is causing
such a surge.


the counters wrap from time to time.

rtr1.ash#sh proc cpu | e 0.0 
CPU utilization for five seconds: 52%/46%; one minute: 53%; five minutes: 57%
 PID Runtime(ms)   Invoked  uSecs   5Sec   1Min   5Min TTY Process 
   535199292  87282048403  0.47%  0.32%  0.52%   0 Pool Manager 
  46   5504888562337240730235  4.79%  2.40%  3.62%   0 IP Input 
rtr1.ash#

all the cpu seems to be in interrupt context.

what i'm looking for from the list is a plethora of commands to investigate
what forwarding path is causing this. i've reached the end of my knowledge
on this platform.

plenty more output after my .sig

-- bill fumerola 






interface Tunnel1004
 description ASH - PAO
 bandwidth 1048576
 ip address
 ip mtu 1500
 ip pim sparse-dense-mode
 keepalive 5 3
 ipv6 enable
 ipv6 ospf 36692 area 0
 tunnel source 
 tunnel destination 
 no clns route-cache
!

interface GigabitEthernet0/0
 description trunk to sw1.ash
 no ip address
 no ip proxy-arp
 duplex full
 speed 1000
 media-type rj45
 no negotiation auto
 no clns route-cache
!
interface GigabitEthernet0/0.1
 description ash management subnet
 encapsulation dot1Q 1 native
 ip address secondary
 ip address secondary
 ip address 
 ip access-group PRODUCTION out
 no ip proxy-arp
 ntp broadcast
 ntp multicast ttl 1
 ipv6 address XXX::/64 eui-64
 ipv6 enable
 ipv6 nd prefix XXX::/64
 ipv6 ospf network broadcast
 ipv6 ospf 36692 area yyy.yy.yy.y
!


these two commands were fired one right after another:
rtr1.ash#sh ip cef switching  st

Path   Reason  Drop   Punt  Punt2Host
RP RIB Packet destined for us 0 2740402100  0
RP RIB Total  0 2740402100  0

RP LES Packet destined for us 0 2852377644  0
RP LES Encapsulation resource 07056820  0
RP LES Total  0 2859434464  0

RP PAS Packet destined for us   130 2852377644  0
RP PAS No adjacency47098437  07291703
RP PAS Incomplete adjacency9582  0 57
RP PAS TTL expired0  0   28060459
RP PAS IP options set 0  0502
RP PAS Bad IP packet length  50  0  0
RP PAS Routed to Null0505265584  02740520
RP PAS Features  623282  0 519123
RP PAS IP redirects   0  0 112010
RP PAS Total  552997065 2852377644   38724374

AllTotal  552997065 4157246912   38724374
rtr1.ash#sh ip cef switching  st

Path   Reason  Drop   Punt  Punt2Host
RP RIB Packet destined for us 0 2740402151  0
RP RIB Total  0 2740402151  0

RP LES Packet destined for us 0 2852377695  0
RP LES Encapsulation resource 07056820  0
RP LES 

[c-nsp] Cisco IOS recommendation: 3750G

2008-06-04 Thread Deepak Jain


Any recommendations on a version of IP advanced services (i.e. without 
memory leaks)?


Thanks in advance,

Deepak

___
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] WS-X6608-T1 for data?

2008-06-04 Thread Alex Moya

It Is supported on ios and it runs ios code

Sent from my iPhone

On Jun 4, 2008, at 4:02 PM, Asbjorn Hojmark - Lists  
[EMAIL PROTECTED] wrote:



My question is basically, can the WS-X6608-T1 support
traditional data T1's?


No. It's a dedicated voice gateway for Call Manager.


Does it require a specific IOS version (such as a voice image)
to come online?


It isn't supported in IOS, only CatOS.

-A

___
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] Forcing routes

2008-06-04 Thread Diogo Montagner
Hi Gary,

you can use bgp always-compare-med.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094925.shtml

Regards,
Diogo

On Wed, Jun 4, 2008 at 1:35 PM, Gary Roberton [EMAIL PROTECTED]
wrote:

 I have a customer who is multihomed to my network.  He has RouterX.  I have
 R1 and R2 connected to his RouterX.  My R1 is in AS1 and my R2 is in AS2.
  I
 want to sent him a BGP advertisement in such a way that he always prefers
 to
 use R1.

 I cannot use MEDs as the AS numbers of my R1 and R2 are different.
 I cannot use local preference as I am not allowed to change anything on his
 route (don't ask just take it as a given).
 My path lengths are the same.

 How can I force his router to always choose my R1 path as the best one?


 Once I have done this I then want to be able to turn this on or off based
 on
 a Tunnel on R1 being up (which I guess will be object tracking) but until I
 know how to solve the first part - I can't tackle the second part.

 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/




-- 
./diogo -montagner
___
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] WS-X6608-T1 for data?

2008-06-04 Thread Fred Reimer
You're thinking of the CMM, not the 6608.  It is not supported in Native
IOS.  It must run on a box running Hybrid - CatOS on the SP and IOS on
the RP.

Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alex Moya
Sent: Wednesday, June 04, 2008 5:56 PM
To: Asbjorn Hojmark - Lists
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] WS-X6608-T1 for data?

It Is supported on ios and it runs ios code

Sent from my iPhone

On Jun 4, 2008, at 4:02 PM, Asbjorn Hojmark - Lists  
[EMAIL PROTECTED] wrote:

 My question is basically, can the WS-X6608-T1 support
 traditional data T1's?

 No. It's a dedicated voice gateway for Call Manager.

 Does it require a specific IOS version (such as a voice image)
 to come online?

 It isn't supported in IOS, only CatOS.

 -A

 ___
 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] IOS JUNOS MPLS-TE interoperability

2008-06-04 Thread Rubens Kuhl Jr.
Hi,

Does anyone has experience with MPLS-TE interoperability between IOS
(specifically ME6500, but it's probably like any other 12.2SX IOS) and
JUNOS (recent/stable/good-for-service-providers version) ?

I was wondering about 2 cenarios in particular:
1) JUNOS as head-end or tail-end, but not middle-point
2) JUNOS as head-end, tail-end and middel-point

All routers would be in the same OSPF area 0, within the same AS #; TE
is done by explicit naming of both primary, secondary paths, and a
dynamic backup path. AUTOBW is desired. On IOS, traffic is injected on
the tunnel using static route to the loopback address; OSPF contains
only link states and loopbacks, directly-connected, customer static
routes or customer dynamic routes are propagated via IBGP.


Tks,
Rubens
___
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] CPU FLOPS Performance / Utilization

2008-06-04 Thread Mehmet Suzen
Hi All,

I'm after the information on conventional floating point operation per
second (FLOPS) of Cisco Routers, let say mid-range to
enterprise models. Pointer to detailed documents will be appreciated
greatly.

Greetings,

Mehmet Suzen
___
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] rspan from a cat 2950

2008-06-04 Thread Daniel Hooper
Hi,

Can someone explain the role of the reflector port when configuring an
rspan session on a 2950 switch?

Does the port need to be up?

From what I can work out from the doco the port is put into a loopback
state so no device connected to it will pass any packets.

I have a remote switch, 70 metre's up a tower, it's a logistical
nightmare to get to, I need to capture traffic on trunk port Fas 0/10,
from my readings this should be enough to achieve what I want:

Fas 0/10 - The interface I want to monitor
VLAN 66 - an unused VLAN I want to send the output to
Fas 0/11 - An unused interface

Monitor session 1 source interface FastEthernet 0/10 both
Monitor session 1 destination remote vlan 66 reflector-port FastEthernet
0/11

I'm hoping I can then configure an access-port for vlan 66 on another
switch upstream and capture frames from Fas0/10 on the 2950.

Thanks

-Dan
___
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] OT: Broadcast segment on provider customer edge

2008-06-04 Thread roy
Hi List,

Apologies. Off-topic [probably not even one of BCPs], but, I'll push my
luck anyways.

What are gotcha's of implementing a broadcast network on provider 
customer edge?

Your thoughts please.

Thanks,

Roy

___
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] EoMPLS - 6509

2008-06-04 Thread Daniel Hooper
Hi,

I've been offered some cheap 6509's with the following kit (this is all
the info I have at the moment on them)

WS-C6509 Chassis 9 Slots
Dual Redundant AC Power Maximum Uptime
Supervisor 2 Engine with PFC2 and MSFC2 Dual Gig Uplink Port MultiLayer
96 10/100 Fast Ethernet Switching Ports
8 Gigabit Ethernet Ports 1000BaseX
Bonus Switch Fabric 2 Module to provide dedicated bandwidth to each slot
up to 256 Gbps per system

I currently have a network composed of 6 site's connected to each other
via microwave, the network is basically one large ring. Our customers
purchase transit through us, some of them are now asking for a VPLS
based service, at the moment each customer is just switched through a
VLAN to their nominated access ports.

We're beginning to look at MPLS, particulary EoMPLS, is the above kit
enough to achieve this? We will be doing no more then 155mbit of
traffic.

I have no prior expeirence with the 6500 platform or MplS, any info
would be appreciated.

Thanks

-Dan 



___
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] configuring RFC1948 on the ASA 5505

2008-06-04 Thread Jerry Kemp
Is it possible to configure to configure RFC 1948 sequence number 
generation on a Cisco ASA 5505 firewall?  A recent nmap port scan shows 
TCP sequence prediction to be Difficulty=0 (Trivial joke).


I did RTFM both Cisco and did several Yahoo searches, and did not turn 
up anything of value.


Below is an (abbreviated) nmap scan sample of an internal port on my ASA.

In case my question is not obvious, I have also included (very bottom) 
the RFC 1948 configuration from a standard Unix (Solaris) set up.


TIA for any replies,

Jerry K


# nmap -v -sT -O 1.1.1.1
Starting Nmap 4.20 ( http://insecure.org ) at 2008-06-04 23:27 CDT
Initiating ARP Ping Scan at 23:27
Scanning 1.1.1.1 [1 port]
Completed ARP Ping Scan at 23:27, 0.20s elapsed (1 total hosts)
Initiating Connect() Scan at 23:27
Scanning 1.1.1.1 (1.1.1.1) [1697 ports]
Completed Connect() Scan at 23:27, 30.77s elapsed (1697 total ports)
Host 1.1.1.1 (1.1.1.1) appears to be up ... good.
Interesting ports on 1.1.1.1 (1.1.1.1):
Not shown: 1694 filtered ports
PORTSTATE SERVICE
22/tcp  open  ssh
23/tcp  open  telnet
443/tcp open  https
MAC Address: 00:19:7:24:AD:67 (Cisco Systems)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=0 (Trivial joke)
--

# TCP_STRONG_ISS sets the TCP initial sequence number generation parameters.
# Set TCP_STRONG_ISS to be:
#   0 = Old-fashioned sequential initial sequence number generation.
#   1 = Improved sequential generation, with random variance in 
increment.

#   2 = RFC 1948 sequence number generation, unique-per-connection-ID.
#
TCP_STRONG_ISS=2


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