Re: [c-nsp] Field Notice: FN - 64110 - looking for an OID to monitor the NMI events

2016-05-23 Thread Stefan
On May 23, 2016 2:14 AM, "Lukas Tribus" <luky...@hotmail.com> wrote:
>
> > Been hit by this:
> >
> > http://www.cisco.com/c/en/us/support/docs/field-notices/641/fn64110.html
> >
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuw75381/?reffering_site=dumpcr
> >
> > and looking for an SNMP OID to establish monitoring and alerting across
all
> > models and code version, while planning for upgrades. Cisco TAC
provided no
> > feedback, so far, and we have no high hopes for throughout the weekend,
in
> > this regard, on their part (the severity is being addressed, from their
> > stand point, by upgrading)
>
> According to the field notice TAC has a workaround:
>
> > If an upgrade cannot be performed immediately, contact the Technical
> > Assistance Center (TAC) in order to load a debugging plugin. This grants
> > access to the Linux shell where the ports can be temporarily blocked via
> > the CLI. Note that this workaround does not survive a reload, and the
> > NX-OS upgrade is suggested as a long-term fix.
>
>
> So you should probably insist on that workaround.
>
> Lukas
>

It's the monitoring and alerting part I was interested in, necessary prior
to the blocking.

Stefan
___
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] Field Notice: FN - 64110 - looking for an OID to monitor the NMI events

2016-05-21 Thread Stefan
Been hit by this:

http://www.cisco.com/c/en/us/support/docs/field-notices/641/fn64110.html
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuw75381/?reffering_site=dumpcr

and looking for an SNMP OID to establish monitoring and alerting across all
models and code version, while planning for upgrades. Cisco TAC provided no
feedback, so far, and we have no high hopes for throughout the weekend, in
this regard, on their part (the severity is being addressed, from their
stand point, by upgrading), while we would like to try and put something in
place ASAP, while planning all the upgrades, across data centers (no
trivial task). If no OID, scripting this:

show system internal file /proc/interrupts | incl NMI

would probably be something to look into ...

Any suggestions?

BTW - anyone having seen/experienced the above? We still have no clear
trigger - we're assuming some odd pattern of traffic, but no smoking gun,
so far.

TIA,
Stefan
___
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] The Family of ASR902 - ASR903 - ASR907

2015-10-28 Thread Stefan Giera

On 28/10/15 13:12, Youssef Bengelloun-Zahr wrote:

+1 for the webinar.


yup, same here.

Cheers,
Stefan


___
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] Cisco ASR1002x + SPA Adapter (SPA-1X10GE-L-V2) Issues

2015-07-28 Thread Stefan Giera

Am 28.07.15 um 11:35 schrieb Troy Boutso:

Am I missing something obvious? Do I need to issue some commands on this
router to activate it this time round?
I shouldn't need to reload the router?


Hi Troy,

it happened to me once, that I have put an SPA-1XTENGE-XFP instead of 
the SPA-1X10GE-L-V2 SPA into an ASR1000. They look both the same, but 
the  SPA-1XTENGE-XFP is older and was not recognised. So maybe You have 
to check if the supplier shipped the right card (V2).



Best regards,
Stefan


___
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] 10Gb+ Core w/ Netflow

2015-03-16 Thread Stefan Baltus
What about the Cisco 6880-X in this respect? Does anybody use this box as a
BGP edge in an ethernet only environment? I’m curious about the real world
performance of this box, looking at number of BGP peers, convergence, etc.

Stefan

On Sat, Mar 14, 2015 at 10:52 PM, Nick Hilliard n...@foobar.org wrote:

 On 14/03/2015 06:03, Mark Tinka wrote:
  My only issue has been when Cisco will release an ASR9001 based on an x86
  CPU. The current models are Freescale P4040 systems, so a little quicker
  than the MX80's CPU.

 a good deal quicker, but the xr bgp engine is also much faster than rpd:
 an MX80 will take several minutes to converge a full dfz, including FDB
 programming; an asr9001 takes ~30s.

 Nick

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




-- 
Stefan Baltus - CPS Internetworking
___
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] CCNA certification training recommendations

2015-02-11 Thread Stefan Giera

Am 11.02.15 um 00:09 schrieb Eric Louie:

Would anyone like to recommend a CCNA certification training course?
Preferably one that you took that helped you with your certification.


Hi Eric,

recently I have taken part in a Video Boot Camp for preparation on a 
CCNP exam. It was from Chris Bryant and offered via www.udemy.com


Chris Bryant in my opinion is an excellent teacher and brings the 
certification-relevant things into focus. He has got a similar Video 
Boot Camp for CCNA as well on the mentioned website.



-- Stefan


--
Stefan Giera, BelWü NOC
BelWü-Koordination, Universität Stuttgart
Industriestr. 28, 70565 Stuttgart

Tel: +49 711/685-65797 | Durchwahl
Tel: +49 711/685-88030 | NOC, Netzbetrieb, Router
Tel: +49 711/685-88020 | (Schul)Hotline
Fax: +49 711/678 83 63
E-Mail: i...@belwue.de - http://www.belwue.de

___
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] Dynamic output buffer allocation on Cisco 4948

2013-09-26 Thread Stefan
... which reminded me of an issue about which I forgot to further research
- maybe someone here knows the answer and is kind enough to share: are
these variables whose values one could obtain via platform command(s), also
available over SNMP, and would you happen to know the OIDs, if so?

Thank you,
***Stefan


On Thu, Sep 26, 2013 at 9:38 AM, John Neiberger jneiber...@gmail.comwrote:

 Thanks! I talked to our Cisco NCE about this and he gave me these commands:

 show qos  interface gigabitEthernet x/y- will show you 4 queues and also
 whether QoS is disabled or not

 sh int gi x/y counters detail -you will see packet counters in queue #1-4
 incrementing

 Sh platform hardware interface g x/y stat | in TxB


 I'm nearly certain that this big buffer issue is the answer to my high
 variable latency problem, but there is still one mystery about this that
 has me completely perplexed. The high variable latency was only occurring
 in one direction (from VLAN A to VLAN B) but not in the other (from VLAN B
 to VLAN A). What really makes that weird is that because of some hsrp
 differences, we really had a circular topology for a bit. The path was
 *exactly* the same no matter which direction you were pinging. The ICMP
 packets had to travel around the same circle through the same devices and
 interfaces. So if we have big buffers on congested interfaces that are
 introducing variable latency, why would we only see it in one direction?


 When VLAN A pings VLAN B, it is the initial ICMP packet that would have
 been delayed, while the response would come in on a different interface
 that wasn't congested. When VLAN B pings VLAN A, the initial ping would not
 hit congested interfaces but the ping reply would. The total round trip
 time should have been similar, but it never was. I'm completely stumped by
 that. I even had Cisco HTTS on this for a couple of days and they couldn't
 figure it out.


 Thanks,

 John


 On Thu, Sep 26, 2013 at 1:50 AM, Terebizh, Evgeny etereb...@amt.ru
 wrote:

  Try also
  show platform hardware interface gigabitEthernet 1/1 tx-queue.
  I guess it's gonna show the actual values for queue utilisation.
  Please let me know if this helps.
 
  /ET
 
 
 
 
  On 9/24/13 11:17 PM, John Neiberger jneiber...@gmail.com wrote:
 
  I've been helping to troubleshoot an interesting problem with variable
  latency through a 4948. I haven't run into this before. I usually have
  seen
  really low latency through 4948s, but this particular application
 requires
  consistent low latency and they've been noticing that latency goes up on
  average as load goes up. It didn't seem to be a problem on their
 servers,
  but communication through busy interfaces seemed to dramatically
 increase
  the latency. They were used to 1ms latency and it was bouncing up to
 20+
  ms at times. I'm starting to think this is due to the shared output
 buffer
  in the 4948 causing the output buffer on the uplink to dynamically get
  bigger.
  
  I've been trying to find more details on how the 4948 handles its shared
  output queue space, but I haven't been able to find anything. Do any of
  you
  know more about how this works and what commands I could use to
  troubleshoot? I can't find anything that might show how much buffer
 space
  a
  particular interface is using at any given time, or if it even makes
 sense
  to think of it that way. If I knew the size of the buffer at any given
  moment, I could calculate the expected latency and prove whether or not
  that was the problem.
  
  Thanks!
  John
  ___
  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] Q on multicast specific info via SNMP

2012-05-17 Thread Stefan
Need to centralize info ref membership of ports subscribed to a
specific multicast group (and which) at any time (polling every x
min is fine)- and I'm hoping to be able to leverage SNMP (maybe w/IGMP
snooping group membershi?!?) specific OIDs. Has anybody done this, and
care to share which OIDs?

TIA,
***Stefan
___
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] %HARDWARE-1-TCAM_ERROR: Found error in HFTM TCAM Space and not able to recover the error + server losing default GW

2012-03-10 Thread Stefan
Problem: solaris server connected to a port on a 3750 switch.

Reported problem: solaris server lost capability to communicate over
the network (checks performed from remote location / different VLAN -
important to know!)

Immediate reaction - network folks engaged: switch investigation
reveals error from $subj:

%HARDWARE-1-TCAM_ERROR: Found error in HFTM TCAM Space and not able to
recover the error

so decision taken to immediately reload the switch

Phase II: switch recovers, no more errors, server still reported
unreachable from monitoring tool; a quick test from within switch
reveals reachability of server from within its own VLAN, though (all
tests = ICMP)!

Phase III: finally server folks involved - reached out to down
server via another one, on the same VLAN, connected to the same switch
- found missing gateway on the down server (allegedly there for the
last 4xx days of uptime)

Phase III - post-mortem monitoring: no more TCAM errors but also no
more problems (obviously) after re-adding the default GW on the server

What we are missing: test at the time of reported failure in
communication with server did not include an ICMP from within its own
VLAN (as the apparent problem was the error reported on the switch
TCAM)

My question to the audience: having done a little research on old
solaris behavior (as we have it), I found this:

http://www.tek-tips.com/viewthread.cfm?qid=211132

and now I wonder - is it possible that solaris mechanisms of spewing
whatever traffic, in missing the default GW, caused the TCAM issue, or
(and how come) the TCAM issue causing the disappearance of the
solaris default GW.

Anybody having experienced the problem described?

***Stefan
___
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] %HARDWARE-1-TCAM_ERROR: Found error in HFTM TCAM Space and not able to recover the error + server losing default GW

2012-03-10 Thread Stefan
Thanks for reply, James. I assume you meant proxy arp shouldn't, right?

Will get more details form the server folks on Monday (if willing top
share ;-)). To me the interesting part was all but one functional
ports (1) + TCAM errors (2) + one port w/a server having lost its
default GW (3) - I could see (2) and (3), as (2) = (3), but then why
(1)? ... unless (3) = (2)

***Stefan

On Sat, Mar 10, 2012 at 9:40 PM, James S. Smith jsm...@windmobile.ca wrote:
 Did the Solaris system have the gateway in the defaultrouter file, or did it 
 need to be added?

 It's possible that it never did have a default gateway, and your local router 
 was doing proxy arp.  I've run into that a few times where a server isn't 
 given the proper gateway but still ends up getting connectivity because the 
 local router is responding to the arps.  Or perhaps someone had added the 
 default route by cli and never added it to the defaultrouter file, and then 
 it somehow got lost.

 It's an odd chain of events, but proxy arp should cause issues with the TCAM.


 - Original Message -
 From: Stefan [mailto:netfort...@gmail.com]
 Sent: Saturday, March 10, 2012 05:30 PM
 To: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net
 Subject: [c-nsp] %HARDWARE-1-TCAM_ERROR: Found error in HFTM TCAM Space and 
 not able to recover the error + server losing default GW

 Problem: solaris server connected to a port on a 3750 switch.

 Reported problem: solaris server lost capability to communicate over
 the network (checks performed from remote location / different VLAN -
 important to know!)

 Immediate reaction - network folks engaged: switch investigation
 reveals error from $subj:

 %HARDWARE-1-TCAM_ERROR: Found error in HFTM TCAM Space and not able to
 recover the error

 so decision taken to immediately reload the switch

 Phase II: switch recovers, no more errors, server still reported
 unreachable from monitoring tool; a quick test from within switch
 reveals reachability of server from within its own VLAN, though (all
 tests = ICMP)!

 Phase III: finally server folks involved - reached out to down
 server via another one, on the same VLAN, connected to the same switch
 - found missing gateway on the down server (allegedly there for the
 last 4xx days of uptime)

 Phase III - post-mortem monitoring: no more TCAM errors but also no
 more problems (obviously) after re-adding the default GW on the server

 What we are missing: test at the time of reported failure in
 communication with server did not include an ICMP from within its own
 VLAN (as the apparent problem was the error reported on the switch
 TCAM)

 My question to the audience: having done a little research on old
 solaris behavior (as we have it), I found this:

 http://www.tek-tips.com/viewthread.cfm?qid=211132

 and now I wonder - is it possible that solaris mechanisms of spewing
 whatever traffic, in missing the default GW, caused the TCAM issue, or
 (and how come) the TCAM issue causing the disappearance of the
 solaris default GW.

 Anybody having experienced the problem described?

 ***Stefan
 ___
 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] [j-nsp] Firewalls as-a-service in an MPLS infrastructure...

2011-07-08 Thread Stefan Fouant

On 7/8/2011 12:28 AM, Keegan Holley wrote:

Could be interesting.  I've rarely seen firewall as a service done right
though.  It's hard to keep, cpu, memory usage, DDOS attacks,
misconfiguration, etc. of one customers from affecting the other customers
that share hardware.  That being said there are better platforms to run the
firewall instances on that are available now, checkpoint VSX comes to mind.


Years ago when I had to develop a Network Based Firewall solution for a 
particular ISP in order to comply with the Federal Government's NetworX 
bid, we chose Juniper's NS-5400 for precisely this reason.  In ScreenOS 
you have the concept of resource profiles with which you can limit the 
amount of CPU, Sessions, Policies, MIPs and DIPs (used for NAT), and 
other user defined objects such as address book entries, etc. that each 
VSYS can avail.


These are essential elements of any multi-tenant firewall solution and 
evaluated platforms should likewise have similar offerings to contain 
resource usage for individual customers.


Stefan Fouant
JNCIE-ER #70, JNCIE-M #513, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant
___
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] [j-nsp] Firewalls as-a-service in an MPLS infrastructure...

2011-07-08 Thread Stefan Fouant

On 7/8/2011 9:15 AM, Keegan Holley wrote:

I never said it's not possible, just that I've rarely seen it done
correctly.  Not everyone has your level of skill.  Just for arguments
sake how did you handle shared bandwidth?  In other words how did you
keep a DDOS attack on one customers's segment from using up all
available bandwidth in some shared segment upstream from the firewall.


Oh no worries Keegan, I was just pointing out that it can in fact be done...

In my case, the way we designed it was that individual customers were 
assigned to unique VLANs on the ingress interface on the Firewall.  Each 
VLAN was mapped to a unique customer VSYS.  Upstream routers had 
specific routes for each customer pointing to those unique VLANs. 
Rate-limiters were applied on said upstream router for each customer 
VLAN to restrict starvation of the entire pipe.


Make sense?

Stefan Fouant
JNCIE-ER #70, JNCIE-M #513, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant
___
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] vrf-lite over a layer3 link

2009-10-06 Thread Stefan Juon
 Hi all
This is my first post to this list, so I guess I should say hello ;-)
We are considering an advanced network design which allows us to separate
several services or customers using vrf-lite. There are some local sites
which are connected by our own cabling. Nevertheless there are also some
remote sites which are connected over a provider which provides common
layer3 links. I understand that vrf-lite uses vlan's to separate the
customers between ce and pe, I have seen these in all the examples I already
read. As supposely no provider supports vlan's but rather layer 3 lines the
big question is: How to span a network using vrf-lite over a provider?

Thanks for any ideas.
___
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] DPD dead peer detection

2008-08-01 Thread Stefan Hegger
Hi,

probably someone can help me to answer the following question.


I have a VPN router (Router_a) with 2 interfaces connected to 2 ISP's with 2 
IP's and I have a homeoffice with a small VPN router (Router_b) connected to 
one ISP with one interface and one IP.

Now I want to use DPD to check which route to use to connect from Router_b to 
Router_a. ISP1 is the default, ISP2 is backup.

As far as I understand DPD is a keepalive to check if a peer is up and 
switches between peers and does not do anything with the routing. So it 
checks only if the key exchange works and peer is established within same 
tunnel. If it is like that, I can not use DPD to solve my problem and should 
use track and ip sla monitor.

Best Stefan 
-- 
Stefan Hegger
Internet System Engineer

Lycos Europe GmbH
Carl-Bertelsmann Str. 29
Postfach 315
33312 Gütersloh 

Phone:
Tel: +49 5241 8071 334
Fax: +49 5241 80671 334
Mobile: +49 170 1892720

Sitz der Gesellschaft: Gütersloh
Amtsgericht Gütersloh, HRB 2157
Geschäftsführer: Christoph Mohn 

  http://www.lycos-europe.com/L/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/


[c-nsp] ipflow/netflow appliance

2008-01-11 Thread Stefan Hegger
Hi,

I'm looking for a device that can provide us with ipflow/netflow data. Our 
router isn't able to manage the netflows for a 10G connection. We have a 
catalyst 6500 with a sup 720. As far as I know it supports up to 128000 table 
entries. This is too small. So we are looking for a device that sniffer the 
traffic via SPAN and than generates the tables we need for analysis. Does 
someone know about such a device?


Best Stefan
-- 
Stefan Hegger
Internet System Engineer

Lycos Europe GmbH
Carl-Bertelsmann Str. 29
Postfach 315
33312 Gütersloh 

Phone:
Tel: +49 5241 8071 334
Fax: +49 5241 80671 334
Mobile: +49 170 1892720

Sitz der Gesellschaft: Gütersloh
Amtsgericht Gütersloh, HRB 2157
Geschäftsführer: Christoph Mohn 

  http://www.lycos-europe.com/L/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/


[c-nsp] mtu size GRE tunnel

2007-05-25 Thread Stefan Hegger
Hi,

hope you can help me to solve my problem. We are running some GSR's (cisco 
12008/GRP) with IOS Version 12.0(26)S6. We opened a GRE tunnel to another 
location and have problems with the MTU size.

It seems that the GSR's does not  return an ICMP message 
indicating fragmentation needed.

When we decrease the MTU to 1400 on host, everything works fine.

Best Stefan
-- 
Stefan Hegger
Internet System Engineer

Lycos Europe GmbH
Carl-Bertelsmann Str. 29
Postfach 315
33312 Gütersloh 

Phone:
Tel: +49 5241 8071 334
Fax: +49 5241 80671 334
Mobile: +49 170 1892720



Sitz der Gesellschaft: Gütersloh
Amtsgericht Gütersloh, HRB 2157
Geschäftsführer: Christoph Mohn 
___
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/