[c-nsp] Replacement for Cisco ACE load balancers

[Matthew Huff]

We have a pair of Cisco ACE-20 blades in our core 6500 data center switches. 
Since Cisco has EOL the ACE blades and we are retiring
our 6500s (moving to Nexus 5000), we are looking for a replacement load 
balancing hardware. This is for high-availability rather
than scalability. Our throughput needs are very low so we are looking at the 
bottom end of vendors appliances.

We are looking at F5, Foundry (Brocade), and Citrix Netscaler. Anyone else go 
through this and have recommendations/horror
stories/info they would like to share? Thanks.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139




smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Replacement for Cisco ACE load balancers

[Matthew Huff]

Heh. I hate the ACE gui mode. I think I used it once...

L2 load balancing is a big plus for us. We are currently using the ACE with 
inline mode (L2 bridging). Most of our traffic is not
HTTP, but a combination of internal application and commercial ones (Exchange, 
etc...), so some HTTP, but not a majority.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil
> Mayers
> Sent: Monday, February 04, 2013 1:10 PM
> To: Chris Marlatt
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Replacement for Cisco ACE load balancers
> 
> On 04/02/13 17:56, Chris Marlatt wrote:
> 
> > The Foundry/Brocade ServerIron's/ADX line work's quite well in a L2 or
> > L3 environment without NAT or being in-line. Enabling DSR (direct server
> > return, in an L2 environment) means the LB doesn't have to be within the
> > path of the normal switching/routing and their ADX line has support for
> > true multi-10Gb throughputs. DSR also means you're not burning up the
> 
> Interesting. Is it particularly / prohibitively expensive? Several other
> vendors hinted that a 10gig SLB device was "way out of proportion to our
> needs" and "very expensive".
> 
> > "Application Throughput" limits of the device on other traffic patterns.
> > Stability is stellar when it comes to these units, I've some of my
> > ServerIron 4G's online for over 1,200 days (1,277 and counting) without
> > blinking.
> 
> This is an excellent point. We run several services in DSR mode, which
> the ACE obviously handles fine, and I'd encourage everyone that can do
> this, on whatever platform, to do so.
> 
> However, DSR is fairly simplistic, and requires config on the server
> (provision of the virtual IP) which often can be a pain, depending on
> your platform and level of network/server team integration.
> 
> We also find that port rewriting, SSL termination and header/cookie
> insertion are pretty common requirements, which pretty much means inline
> (either on packet path, or source NAT to direct return traffic back to SLB).
> 
> > Each vendor has it's strengths and weaknesses and whereas I'm quite
> > pleased with the Foundry/Brocade models the only area I would say they
> > need work in a robust API interface to help automate changes. However
> > they have made recent improvements in their multi-tendency support.
> 
> One thing I will note - the Cisco ACE management product (ANM) is... not
> great, to put it politely. If GUI management is a concern, then factor
> that in ;o)
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Next step-up from 7206VXR

[Matthew Huff]

Once corporate networks decide they need IPv6 and they look at SHIM6, NPTv6, 
and multihoming and see how many apps break out of the box, they are going to 
request /48 Provider Independent (PI) spaces  and advertise them via BGP. Many 
if not most have been burned by PHB signing telco deals without any buy-in, so 
they aren't going to want to have to renumber every time some contract is 
signed/broken. Easy IPv6 corporate prefix renumbering is a myth. Too many 
one-off embedded devices that barely speak IPv6 and monitoring systems that 
aren't dynamic and other issues (ACL rewrites, etc...)

The explosion in ipv6 prefixes is coming

Unless you need the hardware switching capabilities of the 7600/6500 
(microbursts, etc), why not use the software routers like the ASR 1000/9000 
that have no fixed TCAM limits?




-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Seth Mattinen
Sent: Wednesday, February 20, 2013 11:20 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Next step-up from 7206VXR

On 2/20/13 6:13 AM, Mikael Abrahamsson wrote:
> On Wed, 20 Feb 2013, Mack McBride wrote:
> 
>> At 768k you are effectively limiting your IPv6 table to 128k (you
>> can't really go more than that if you expect to use IPv6). I recommend
>> a 640k/192k split.
> 
> Well, I believe IPv4 will hit 640k before IPv6 will hit 128k, so I'd
> recommend 768k/128k instead.
> 

That's what I think too, unless there are too many unchecked idiots that
decide to deaggregate their /30-32 into /48s.

~Seth
___
cisco-nsp 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] VS-S2T-10G card with WS-X6748-SFP Card => DFC Problems

[Matthew Huff]

Yes, except for the ones that aren't :)

The 6708 has the DFC integrated and isn't upgradable.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hardware/Module_Installation/Mod_Install_Guide/0adtrcrd.html

There are listed as upgradeable with the WS-F6K-DFC4-A / WS-F6K-DFC4-AXL

.WS-X6724-SFP 
.WS-X6748-SFP 
.WS-X6748-GE-TX

----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dan
> Brisson
> Sent: Monday, March 25, 2013 1:52 PM
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] VS-S2T-10G card with WS-X6748-SFP Card => DFC Problems
> 
> Is it correct that DFC4s are field upgradeable?
> 
> -dan
> 
> 
> Sent from a mobile phone with a tiny keyboard
> 
> On Mar 25, 2013, at 1:46 PM, Phil Mayers  wrote:
> 
> > On 25/03/13 17:35, Olivier CALVANO wrote:
> >> Hi
> >>
> >> i have a Cisco 6504E with a VS-S2T-10G and a small problems with two card:
> >>
> >> *Mar 25 17:20:06.375: %C6KENV-2-DFCMISMATCH: Module 2 DFC incompatible
> >> with Supervisor DFC.  Power denied
> >> *Mar 25 17:20:09.299: %C6KENV-2-DFCMISMATCH: Module 3 DFC incompatible
> >> with Supervisor DFC.  Power denied
> >>
> >> Anyone know a solution to this problems ?
> >
> > Sup2T cannot run with DFC3 linecards.
> >
> > You *MUST* either downgrade to CFC, or upgrade to DFC4 on the linecard.
> > ___
> > cisco-nsp 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] 3560g switch - tagged vlans and untagged frames

[Matthew Huff]

I've started looking at this thread in mid-conversation, but I think that 
original config is correct. If you have "switchport mode trunk", the 
"switchport access-vlan ..." won't take effect. It will only use the 
access-vlan if the interface fails to trunk. If you are trunking a non-cisco 
switch, you should disable CDP and DTP via the following config. If this fails 
to work, then there may be some incompatibles with the dot1q protocol between 
switches, or some spanning tree issue.

 interface GigabitEthernet0/10
description testing cisco vlans
switchport trunk encapsulation dot1q
switchport trunk native vlan 6
switchport trunk allowed vlan 6,306
switchport mode trunk
switchport access vlan 6
switchport nonegotiate
no cdp enable
 
 
 interface GigabitEthernet0/11
description testing cisco vlans
switchport trunk encapsulation dot1q
switchport trunk native vlan 7
switchport trunk allowed vlan 7,306
switchport mode trunk
switchport access vlan 7
   switchport nonegotiate
    no cdp enable



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Damian
> Higgins
> Sent: Tuesday, April 09, 2013 3:33 PM
> To: Mike
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] 3560g switch - tagged vlans and untagged frames
> 
> Hi Mike,
> 
> How about this scenario. Let's say you want a VLAN tagged on all the ports,
> but also want different untagged VLANs on those ports (e.g. port 10 tagged
> vlan 306 and untagged vlan 6, port 11 tagged vlan 306 and untagged vlan 7).
> So native VLAN is out of question here since all ports would be untagged in
> the same VLAN ID.
> 
> 
> Can you please test the following setup and tell me if it works? :
> 
> interface GigabitEthernet0/10
>description testing cisco vlans
>switchport trunk encapsulation dot1q
>switchport trunk allowed vlan 306
>switchport mode trunk
>switchport access vlan 6
> 
> 
> interface GigabitEthernet0/11
>description testing cisco vlans
>switchport trunk encapsulation dot1q
>switchport trunk allowed vlan 306
>switchport mode trunk
>switchport access vlan 7
> 
> 
> I don't have any cisco switches at the moment that I could do this test on,
> but I can tell you for sure that this setup is possibile on other switches
> (HP procurve for example, and they're way cheaper :)
> 
> Regards,
> 
> 
> 
> On Tue, Apr 9, 2013 at 8:21 PM, Mike
> wrote:
> 
> > On 04/08/2013 09:48 PM, sth...@nethelp.no wrote:
> >
> >> I would like to be able to accept both tagged and untagged frames
> >>> on my
> >>> 3560g. For the untagged frames, I'd like to be able to say these are a
> >>> member of some vlan - say 100 - otherwise I want to be able to allow
> >>> tagged frames from some list.
> >>>
> >>> In testing, it doesn't appear that "switchport trunk native vlan
> >>> "
> >>> is doing the job; anything I send untagged is dropped and doesn't show
> >>> up in the switch mac address tables.  Here is my config:
> >>>
> >>>
> >> Similar configs work for us.
> >>
> >>
> >>
> >>> interface GigabitEthernet0/45
> >>>description testing cisco vlans
> >>>switchport trunk encapsulation dot1q
> >>>switchport trunk native vlan 6
> >>>switchport trunk allowed vlan 306
> >>>switchport mode trunk
> >>>
> >>>
> >>> It it helps. I do also have dot1q native vlan tagging enabled.
> >>>
> >>>
> >> I believe you need to drop that - it tells the switch that the native
> >> VLAN should be tagged.
> >>
> >> Also, add the native VLAN to the list of allowed VLANs (so you'd get
> >> "switchport trunk allowed vlan 6,306" here).
> >>
> >>
> >
> >
> > I removed dot1q tag native and that seems to have worked. Unfortunately,
> > it caused other problems requiring me to set the native vlans on some ports
> > to something other than default. In the end it's working but I just don't
> > see why I can't say 'hey, got an untagged frame? throw it into this vlan
> > for me...'. Maybe I need more expensive switches.
> >
> > Thanks all.
> >
> > Mike-
> >
> > 

Re: [c-nsp] cisco buffer misses

[Matthew Huff]

Generally switch qos will hurt rather than help output drops. When you turn on 
QOS you carve up the output queues into multiple smaller queues. You can tag 
low priority traffic and shape it out to one of the queues, but even then you 
will actually end up with more discards, albeit discarding stuff which has a 
lower interest.

Most likely the problem is data going into the switch, unless you have 
multicast/broadcast traffic that aggregates into ports that are overloaded. 
These problems are hard to diagnose since over a 3 minute interval (or 30 
seconds if you change the load-interval) the traffic can look smooth and lower 
bandwidth, but under shorter intervals it can overload the output buffers.




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039


> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
> Michael Sprouffske
> Sent: Thursday, April 18, 2013 1:47 PM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] cisco buffer misses
> 
> I'm thinking that some switch qos needs to be put in place to resolve this 
> issue.  What does everyone
> think?  We currently don't have qos running in the switched network.  We only 
> have qos running on the
> routers for the uplinks.
> 
> 
> 
> 
> 
>  From: Michael Sprouffske 
> To: "cisco-nsp@puck.nether.net" 
> Sent: Thursday, April 18, 2013 9:40 AM
> Subject: cisco buffer misses
> 
> 
> 
> Could someone give me some insight as to what is causing the misses?  I'm 
> currently researching this
> on the inter webs.  I also notice an interface with several drops as well.
> 
> 
> 
> 
> model: WS-C3750X-24T-S
> 
> 
> 
> Buffer elements:
>  1061 in free list (500 max allowed)
>  3479036431 hits, 0 misses, 1024 created
> 
> Public buffer pools:
> Small buffers, 104 bytes (total 50, permanent 50, peak 119 @ 7w0d):
>  49 in free list (20 min, 150 max allowed)
>  1712506149 hits, 23 misses, 69 trims, 69 created
>  0 failures (0 no memory)
> Middle buffers, 600 bytes (total 25, permanent 25, peak 85 @ 7w0d):
>  23 in free list (10 min, 150 max allowed)
>  167702 hits, 58 misses, 174 trims, 174 created
>  0 failures (0 no memory)
> Big buffers, 1536 bytes (total 50, permanent 50,
>  peak 119 @ 7w0d):
>  50 in free list (5 min, 150 max allowed)
>  244703400 hits, 39 misses, 117 trims, 117 created
>  0 failures (0 no memory)
> VeryBig buffers, 4520 bytes (total 16, permanent 10, peak 16 @ 7w0d):
>  0 in free list (0 min, 100 max allowed)
>  59 hits, 3 misses, 1429 trims, 1435 created
>  0 failures (0 no memory)
> Large buffers, 5024 bytes (total 0, permanent 0):
>  0 in free list (0 min, 10 max allowed)
>  0 hits, 0 misses, 0 trims, 0 created
>  0 failures (0 no memory)
> Huge buffers, 18024 bytes (total 4, permanent 0, peak 7 @ 7w0d):
>  4 in free list (0 min, 4 max allowed)
>  145363512 hits, 412449 misses, 822729 trims, 822733
>  created
>  0 failures (0 no memory)
> 
> 
> 
> 
> GigabitEthernet1/0/11 is up, line protocol is up (connected)
>   Hardware is Gigabit Ethernet, address is 649e.f3e2.7b8b (bia 649e.f3e2.7b8b)
>   Description: server ports
>   MTU 9000 bytes, BW 10 Kbit, DLY 100 usec,
>  reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loopback not set
>   Keepalive set (10 sec)
> 
>  Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
>   input flow-control is off, output flow-control is unsupported
>   ARP type: ARPA, ARP Timeout 04:00:00
>   Last input 00:00:16, output 00:00:01, output hang never
>   Last clearing of "show interface" counters never
>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 54011
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   5 minute input rate 0 bits/sec, 0 packets/sec
>   5 minute output rate 49000 bits/sec, 28 packets/sec
>  837676 packets input, 118543994 bytes, 0 no buffer
>  Received 492811 broadcasts (481207 multicasts)
>  0 runts, 0 giants, 0 throttles
>  0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>  0 watchdog, 481207 multicast, 0 pause input
> 
>  0 input packets with dribble condition detected
>  670450255 packets output, 115399962776 bytes, 0 underruns
>  0 output errors, 0 collisions, 1 interface resets
>  0 babbles, 0 late collision, 0 deferred
>  0 lost carrier, 0 no carrier, 0 PAUSE output
>  0 output buffer failures, 0 output buffers swapped out
> ___
> ci

Re: [c-nsp] cisco buffer misses

[Matthew Huff]

Output drops are usually cause by microburst or by larger->smaller aggregation 
bursts. The drop is a tail-drop caused by buffer overflows during output 
serialization resulting in tail drops. 

Microburst happen when data is very irregular especially udp based (multicast, 
ipvtv, etc..) and traffic hits an interface faster it can queue it outbound. 
Also, when you have larger pipes sending data your way the bandwidth will cause 
the traffic to "bunch-up" when it hits the lower speed interfaces causing the 
same thing.

The only solution is to either shape the traffic heading to the device or 
replace the device/linecard with something that has larger buffers like a Cisco 
49xx or Nexus3/4/5k.



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
> Michael Sprouffske
> Sent: Thursday, April 18, 2013 12:40 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] cisco buffer misses
> 
> Could someone give me some insight as to what is causing the misses?  I'm 
> currently researching this
> on the inter webs.  I also notice an interface with several drops as well.
> 
> 
> 
> 
> model: WS-C3750X-24T-S
> 
> 
> 
> Buffer elements:
>  1061 in free list (500 max allowed)
>  3479036431 hits, 0 misses, 1024 created
> 
> Public buffer pools:
> Small buffers, 104 bytes (total 50, permanent 50, peak 119 @ 7w0d):
>  49 in free list (20 min, 150 max allowed)
>  1712506149 hits, 23 misses, 69 trims, 69 created
>  0 failures (0 no memory)
> Middle buffers, 600 bytes (total 25, permanent 25, peak 85 @ 7w0d):
>  23 in free list (10 min, 150 max allowed)
>  167702 hits, 58 misses, 174 trims, 174 created
>  0 failures (0 no memory)
> Big buffers, 1536 bytes (total 50, permanent 50, peak 119 @ 7w0d):
>  50 in free list (5 min, 150 max allowed)
>  244703400 hits, 39 misses, 117 trims, 117 created
>  0 failures (0 no memory)
> VeryBig buffers, 4520 bytes (total 16, permanent 10, peak 16 @ 7w0d):
>  0 in free list (0 min, 100 max allowed)
>  59 hits, 3 misses, 1429 trims, 1435 created
>  0 failures (0 no memory)
> Large buffers, 5024 bytes (total 0, permanent 0):
>  0 in free list (0 min, 10 max allowed)
>  0 hits, 0 misses, 0 trims, 0 created
>  0 failures (0 no memory)
> Huge buffers, 18024 bytes (total 4, permanent 0, peak 7 @ 7w0d):
>  4 in free list (0 min, 4 max allowed)
>  145363512 hits, 412449 misses, 822729 trims, 822733 created
>  0 failures (0 no memory)
> 
> 
> 
> 
> GigabitEthernet1/0/11 is up, line protocol is up (connected)
>   Hardware is Gigabit Ethernet, address is 649e.f3e2.7b8b (bia 649e.f3e2.7b8b)
>   Description: server ports
>   MTU 9000 bytes, BW 10 Kbit, DLY 100 usec,
>  reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loopback not set
>   Keepalive set (10 sec)
>   Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
>   input flow-control is off, output flow-control is unsupported
>   ARP type: ARPA, ARP Timeout 04:00:00
>   Last input 00:00:16, output 00:00:01, output hang never
>   Last clearing of "show interface" counters never
>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 54011
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   5 minute input rate 0 bits/sec, 0 packets/sec
>   5 minute output rate 49000 bits/sec, 28 packets/sec
>  837676 packets input, 118543994 bytes, 0 no buffer
>  Received 492811 broadcasts (481207 multicasts)
>  0 runts, 0 giants, 0 throttles
>  0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>  0 watchdog, 481207 multicast, 0 pause input
>  0 input packets with dribble condition detected
>  670450255 packets output, 115399962776 bytes, 0 underruns
>  0 output errors, 0 collisions, 1 interface resets
>  0 babbles, 0 late collision, 0 deferred
>  0 lost carrier, 0 no carrier, 0 PAUSE output
>  0 output buffer failures, 0 output buffers swapped out
> ___
> cisco-nsp 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] 10GE WAN options for 7606 for market data / micro-bursting

[Matthew Huff]

___
cisco-nsp 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 Supervisor redundancy

[Matthew Huff]

I agree with Chuck example of how to do it. That's how I would do it.

However, as Chuck says "cross your fingers". I've had too many "bus stalls" 
and/or sup crashes that I would only do this during a maintenance interval.

As per Cisco Tech, I've "put it in too slowly" and "put it in too fast". Too 
hard to be Goldilocks and get it perfect.



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Chuck 
> Church
> Sent: Wednesday, May 29, 2013 12:28 PM
> To: 'Edward Salonia'; 'Ben Hammadi, Kayssar (NSN - TN/Tunis)'
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] 6500 Supervisor redundancy
> 
> If you've got a compact flash card (either a spare, or the one from the
> running sup), you could put that in the new sup (if a spare, format it in
> the existing sup, and copy that image file to it).  Get your console
> cable/PC ready, and attach to the new sup.  In the existing sup, set the
> redundancy mode to SSO.  Cross your fingers, and push the new sup in.  Break
> into ROMMON, and manually boot it off the disk0: card.  'boot
> disk0:s72033-' .  That should get the new sup up on the correct IOS, and
> SSO should enable itself.  Set your boot statement on the existing sup, and
> write it, and verify (show bootvar) that both sups agree on the boot image
> and confreg.  Of course make sure boot images are in the right places now.
> 
> Chuck
> 
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Edward Salonia
> Sent: Wednesday, May 29, 2013 11:28 AM
> To: Ben Hammadi, Kayssar (NSN - TN/Tunis)
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] 6500 Supervisor redendancy
> 
> While your mileage may vary I have has great success in doing this exact
> thing. RMA sups don't necessarily come with the same code as what you are
> running. Put the new sup in (same hardware, right?) and it should boot up
> into RPR standby cold due to the mid matched code. At this point copy the
> code from the flash of one sup to the other 'wr mem', check 'show red' to
> ensure config reg and boot var are correct and a 'redundancy reload peer'
> should do the trick.
> 
> Out of curiosity, what code are you running on this?
> 
> Also is your box configured for SSO mode currently and is running in
> simplex, or is it configured for RPR. If the latter, I think it may require
> a reload to change modes, but I don't recall.
> 
> Good luck.
> 
> - Ed
> 
> 
> On May 28, 2013, at 5:10 PM, "Ben Hammadi, Kayssar (NSN - TN/Tunis)"
>  wrote:
> 
> > Hi,
> >
> >   My major concern is about the IOS difference , should I find a way to
> check what is the IOS on the new Supervisor or this will not make difference
> , I read the successful stories in Cisco websites but here I am asking
> people who really did that on live Switchs.
> >
> > Br.
> >
> > BEN HAMMADI Kayssar
> >
> > NOKIA SIEMENS NETWORKS
> > Lead Engineer -BroadBand Connectivity
> > JNCIE-M (#471), JNCIE-SP (#1147), CCIP
> >
> >
> > -Original Message-
> > From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf
> > Of ext Justin M. Streiner
> > Sent: Tuesday, May 28, 2013 9:58 PM
> > To: cisco-nsp@puck.nether.net
> > Subject: Re: [c-nsp] 6500 Supervisor redendancy
> >
> > On Tue, 28 May 2013, Ben Hammadi, Kayssar (NSN - TN/Tunis) wrote:
> >
> >>  I have a 6509 with a standalone Sup720 and I am preparing to add a
> >> redundant one, I don't know the software on the new Supervisor and my
> >> final goal is to make both work on SSO mode. Can someone propose a
> >> procedure with happy end :) ?
> >
> > There are numerous resources online that talk about how to configure
> > dual supervisors in a Cat6500 switch.
> >
> > You might be better off asking specific questions, based on things
> > you've tried or read through, rather than asking other people to do
> > the majority of the work for you.
> >
> > 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/
> >
> > ___
> > cisco-nsp mailing list  cisco-nsp@puck.nether.net
> > https://puck

Re: [c-nsp] Possible spanning tree issue

[Matthew Huff]

My guess is that you don't have a root switch defined and the new switch became 
root

On Jun 4, 2013, at 7:41 PM, "Michael Sprouffske"  wrote:

> This was most definitely a topology change.  Happened when this outage 
> occured.
> 
> 
> 
> 
> 
> From: Pete Templin 
> To: Michael Sprouffske  
> Cc: "cisco-nsp@puck.nether.net"  
> Sent: Tuesday, June 4, 2013 4:24 PM
> Subject: Re: [c-nsp] Possible spanning tree issue
> 
> 
> On 6/4/13 3:56 PM, Michael Sprouffske wrote:
>> I attached a new switch to the network and it took down our contact
>> center that doesn't touch this switch nor does the phone system.  Is
>> this spanning tree doing this?  I don't see anything in the logs that
>> show a change in spanning tree.
>> 
>> I also had an employee unplug a switch by accident and it took down
>> our contact center.  This switch is all by itself and does not
>> directly touch the phone system nor is it in the path of the phone
>> system.  I feel like this shouldn't have happened.
> 
> You won't see anything in the logs regarding STP changes unless you're 
> running a debug before/during/after and you are logging at the debug 
> level.  Do "sh spann det | inc gy changes" on a switch and see if one or 
> more VLANs had a topology change about the time this event happened.  If 
> it's more recent than that, the commands after the next paragraph may 
> become quite important.
> 
> At this very moment, I would highly suggest that you stop whatever else 
> you're doing and embark on a priority-1 project to assess and define 
> your STP root placement.  I suspect, reading between the lines of your 
> post, that you haven't done much to select where it is, and you're 
> experiencing a change in root placement.  I'd strongly suggest assessing 
> whether any of the following make sense in your environment:
> 
> Global:
> spanning-tree vlan 1-4094 pri 8192
> spanning-tree portfast default
> spanning-tree portfast bpdufilter default
> 
> Interface:
> no spanning-tree portfast
> spanning-tree portfast trunk
> spanning-tree bpduguard enable
> spanning-tree guard root
> 
> pt
> ___
> cisco-nsp 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] Weird IPv6 problem passing Layer3 traffic

[Matthew Huff]

Trying to bring up a new BGP peering session with a ISP. IPv4 peering is 
working fine on the same interface. The BGP peering fails early in trying to go 
active. Using "debug tcp transactions", I see the SYN going out, but no ACK 
ever returning. I can't telnet to their box on port 179 either (debug packet 
shows it doing the same, SYN begin sent, but no packets, including ACK). 
However, I can ping their interface.

The interface config has been stripped, and still doesn't work. I've reset the 
interface, and even rebooted our router, with no change in behavior.

We have a Cisco 7204VXR with NPE-G2, running 15.2(4)S1. I have an identical 
router with same version connected to another ISP and a tunnel to HE.net. It's 
not my first time at the rodeo. We are connected via metro Ethernet to a 
sub-interface on a JunOS box (model and version unknown). My suspicion is that 
either they have an ACL that's blocking it, or their BGP process isn't 
listening on that sub-interface. But they claim that it isn't their problem. I 
have zero JunOS experience and they seem to be flopping around.

Anyone have any idea what else the problem might be?

>From our side (simplied config to test):


interface FastEthernet2/1
 ip address 162.211.110.2 255.255.255.252
 speed auto
 duplex auto
 ipv6 address 2607:F518:15F::2/126
 ipv6 enable
end

rtr-inet2#show ipv6 cef 2607:F518:15F::1 
2607:F518:15F::1/128
  attached to FastEthernet2/1

rtr-inet2#show ipv6 cef exact-route 2607:F518:15F::2 2607:F518:15F::1
2607:F518:15F::2 -> 2607:F518:15F::1 => IPV6 adj out of FastEthernet2/1, addr 
2607:F518:15F::1

rtr-inet2#show ipv6 neighbors
IPv6 Address  Age Link-layer Addr State Interface
2607:F518:15F::10 0021.5903.1367  REACH Fa2/1

rtr-inet2#ping  2607:F518:15F::1 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2607:F518:15F::1, timeout is 2 seconds:
!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039


___
cisco-nsp 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] Weird IPv6 problem passing Layer3 traffic

[Matthew Huff]

No, I don't have any CoPP defined (at least at the moment trying to debug it). 
No ACLs or anything else like that. The ISP keeps wanting me to send them my 
BGP configuration (which I've sent to at least 3 different people), rarther 
than looking at the obvious that BGP won't ever come up if we can't get a TCP 
session established.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039

From: John Neiberger [mailto:jneiber...@gmail.com]
Sent: Friday, June 28, 2013 10:56 AM
To: Matthew Huff
Cc: cisco-nsp (cisco-nsp@puck.nether.net); ipv6-...@lists.cluenet.de
Subject: Re: [c-nsp] Weird IPv6 problem passing Layer3 traffic

Do you have CoPP configured? I've seen this exact behavior when I didn't have a 
permit statement for my neighbor or link address in the right ACL, so it was 
getting rate-limited to death.

On Fri, Jun 28, 2013 at 8:33 AM, Matthew Huff 
mailto:mh...@ox.com>> wrote:
Trying to bring up a new BGP peering session with a ISP. IPv4 peering is 
working fine on the same interface. The BGP peering fails early in trying to go 
active. Using "debug tcp transactions", I see the SYN going out, but no ACK 
ever returning. I can't telnet to their box on port 179 either (debug packet 
shows it doing the same, SYN begin sent, but no packets, including ACK). 
However, I can ping their interface.

The interface config has been stripped, and still doesn't work. I've reset the 
interface, and even rebooted our router, with no change in behavior.

We have a Cisco 7204VXR with NPE-G2, running 15.2(4)S1. I have an identical 
router with same version connected to another ISP and a tunnel to HE.net. It's 
not my first time at the rodeo. We are connected via metro Ethernet to a 
sub-interface on a JunOS box (model and version unknown). My suspicion is that 
either they have an ACL that's blocking it, or their BGP process isn't 
listening on that sub-interface. But they claim that it isn't their problem. I 
have zero JunOS experience and they seem to be flopping around.

Anyone have any idea what else the problem might be?

>From our side (simplied config to test):


interface FastEthernet2/1
 ip address 162.211.110.2 255.255.255.252
 speed auto
 duplex auto
 ipv6 address 2607:F518:15F::2/126
 ipv6 enable
end

rtr-inet2#show ipv6 cef 2607:F518:15F::1
2607:F518:15F::1/128
  attached to FastEthernet2/1

rtr-inet2#show ipv6 cef exact-route 2607:F518:15F::2 2607:F518:15F::1
2607:F518:15F::2 -> 2607:F518:15F::1 => IPV6 adj out of FastEthernet2/1, addr 
2607:F518:15F::1

rtr-inet2#show ipv6 neighbors
IPv6 Address  Age Link-layer Addr State Interface
2607:F518:15F::10 0021.5903.1367  REACH Fa2/1

rtr-inet2#ping  2607:F518:15F::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2607:F518:15F::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039


___
cisco-nsp mailing list  
cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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

[c-nsp] RESOLVED: Weird IPv6 problem passing Layer3 traffic

[Matthew Huff]

The issue was a CoPP filter on the ISP side. The session is up now. 

Been working on them with them for 3 days, and each engineer kept coming back 
to our BGP configuration. 


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039


> -Original Message-
> From: Matthew Huff
> Sent: Friday, June 28, 2013 10:34 AM
> To: 'cisco-nsp (cisco-nsp@puck.nether.net)'; 'ipv6-...@lists.cluenet.de'
> Subject: Weird IPv6 problem passing Layer3 traffic
> 
> Trying to bring up a new BGP peering session with a ISP. IPv4 peering is 
> working fine on the same
> interface. The BGP peering fails early in trying to go active. Using "debug 
> tcp transactions", I see
> the SYN going out, but no ACK ever returning. I can't telnet to their box on 
> port 179 either (debug
> packet shows it doing the same, SYN begin sent, but no packets, including 
> ACK). However, I can ping
> their interface.
> 
> The interface config has been stripped, and still doesn't work. I've reset 
> the interface, and even
> rebooted our router, with no change in behavior.
> 
> We have a Cisco 7204VXR with NPE-G2, running 15.2(4)S1. I have an identical 
> router with same version
> connected to another ISP and a tunnel to HE.net. It's not my first time at 
> the rodeo. We are connected
> via metro Ethernet to a sub-interface on a JunOS box (model and version 
> unknown). My suspicion is that
> either they have an ACL that's blocking it, or their BGP process isn't 
> listening on that sub-
> interface. But they claim that it isn't their problem. I have zero JunOS 
> experience and they seem to
> be flopping around.
> 
> Anyone have any idea what else the problem might be?
> 
> From our side (simplied config to test):
> 
> 
> interface FastEthernet2/1
>  ip address 162.211.110.2 255.255.255.252
>  speed auto
>  duplex auto
>  ipv6 address 2607:F518:15F::2/126
>  ipv6 enable
> end
> 
> rtr-inet2#show ipv6 cef 2607:F518:15F::1
> 2607:F518:15F::1/128
>   attached to FastEthernet2/1
> 
> rtr-inet2#show ipv6 cef exact-route 2607:F518:15F::2 2607:F518:15F::1
> 2607:F518:15F::2 -> 2607:F518:15F::1 => IPV6 adj out of FastEthernet2/1, addr 
> 2607:F518:15F::1
> 
> rtr-inet2#show ipv6 neighbors
> IPv6 Address  Age Link-layer Addr State Interface
> 2607:F518:15F::10 0021.5903.1367  REACH Fa2/1
> 
> rtr-inet2#ping  2607:F518:15F::1
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 2607:F518:15F::1, timeout is 2 seconds:
> !
> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
> 
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039


___
cisco-nsp 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] NTP message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0).

[Matthew Huff]

Some ntp configurations will remain under certain conditions.

To clear, remove all ntp configurations including "ntp server ",
Then do "no ntp"

Then re-add configuration



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039


> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
> Victor Sudakov
> Sent: Tuesday, July 02, 2013 12:31 PM
> To: Aaron; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] NTP message sent to 224.0.1.1, from interface 'NULL' 
> (0.0.0.0).
> 
> Aaron wrote:
> > Have you set your ntp source interface by any chance?
> 
> No.
> 
> In fact, now I have removed all NTP configuration except 2 ntp servers,
> but the multicast packets are still being sent:
> 
> orlov#
> orlov#sh running-config | i ntp
> ntp server 10.14.129.71
> ntp server 10.14.140.125
> orlov#
> NTP message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0).
> orlov#
> 
> 
> 
> 
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
> ___
> cisco-nsp 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] NTP message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0).

[Matthew Huff]

I've seen it happen a number of hardware/versions. Especially when you setup a 
peer on one router, and it will auto-add on another, and the only way to remove 
it is to do a "no ntp". This kills the NTP process

----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039

From: Aaron [mailto:dudep...@gmail.com]
Sent: Tuesday, July 02, 2013 12:41 PM
To: Matthew Huff
Cc: Victor Sudakov; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] NTP message sent to 224.0.1.1, from interface 'NULL' 
(0.0.0.0).

Hmm.
What version of sw are you running?

On Tue, Jul 2, 2013 at 12:38 PM, Matthew Huff 
mailto:mh...@ox.com>> wrote:
Some ntp configurations will remain under certain conditions.

To clear, remove all ntp configurations including "ntp server ",
Then do "no ntp"

Then re-add configuration



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039


> -Original Message-
> From: cisco-nsp 
> [mailto:cisco-nsp-boun...@puck.nether.net<mailto:cisco-nsp-boun...@puck.nether.net>]
>  On Behalf Of Victor Sudakov
> Sent: Tuesday, July 02, 2013 12:31 PM
> To: Aaron; cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> Subject: Re: [c-nsp] NTP message sent to 224.0.1.1, from interface 'NULL' 
> (0.0.0.0).
>
> Aaron wrote:
> > Have you set your ntp source interface by any chance?
>
> No.
>
> In fact, now I have removed all NTP configuration except 2 ntp servers,
> but the multicast packets are still being sent:
>
> orlov#
> orlov#sh running-config | i ntp
> ntp server 10.14.129.71
> ntp server 10.14.140.125
> orlov#
> NTP message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0).
> orlov#
>
>
>
>
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru<mailto:sip%3asuda...@sibptus.tomsk.ru>
> ___
> cisco-nsp mailing list  
> cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] RESOLVED: Weird IPv6 problem passing Layer3 traffic

[Matthew Huff]

In this case, the BGP never came up at all. I never received an ACK from
the initial SYN, so the BGP session never was established at all. The
other side was a JunOS box, so I don't know the details.

On 7/5/13 1:59 PM, "Nick Hilliard"  wrote:

>On 05/07/2013 18:13, Chuck Church wrote:
>> Yeah, that actually seems worse than dropping all traffic.  I suppose
>>your
>> CoPP rules could group 'unknown BGP' into its own class, rather than
>>falling
>> into class default.  Seeing the drops in the unknown BGP section might
>>be a
>> little more obvious than the class default drops.
>
>s/your/their/, but otherwise yes, that would be sensible.
>
>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/


___
cisco-nsp 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] WARNING: Netflow & Hardware assisted NAT not supported on 65xx on the same interface even with Sup2T

[Matthew Huff]

FYI,

At least cisco went back end and added caveats to the documentation about this 
limitation. Since I had combed through all the documentation beforehand, had 
the caveat been there, it would have been likely we would have purchased a 
different set of hardware. 


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
> oldnick
> Sent: Friday, October 11, 2013 2:46 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] WARNING: Netflow & Hardware assisted NAT not supported on 
> 65xx on the
> same interface even with Sup2T
> 
> Hi all,
> 
> I leave it here JFTR, to prevent someone else to make the same error as I did 
> with NAT,
> Netflow and
> Sup2T (just as Matthew Huff did before me with Sup720).
> 
> According to Cisco because of CSCud36118, enabling NAT (ip nat outside) and 
> Flexible
> NetFlow (ip
> flow monitor MonitorFlow input) on the same interface force NAT traffic to be 
> software
> switched even
> with Sup2T.
> 
> Although TAC states that this is software limitation, I've been told that 
> there it no plan
> to
> support this feature combination in hardware.
> 
> HTH
> 
> -Original Message-
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at 
> puck.nether.net]
> On Behalf
> Of Matthew Huff
> Sent: Friday, August 26, 2011 10:26 AM
> To: 'cisco-nsp at puck.nether.net'
> Subject: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not 
> supported on
> 76xx/65xx on
> the same interface
> 
> Last winter we purchased a pair of 7606 routers to use out at the NYSE colo 
> facility. We
> connect via
> a 1gb fiber to the SFTI LCN for market data and FIX traffic. We fully 
> expected to be able
> to use
> hardware assisted NAT and NDE to monitor the traffic. The netflow output we 
> get is random,
> sporadic
> and very incomplete. After dealing with our Sales team and TAC, we have 
> finally got them
> to admit
> that it doesn't work when NAT and NDE are configured on the same interface.
> 
> Nowhere in the Cisco marketing literature, Cisco Documentation, or even Cisco 
> bug lists
> does it
> mention this. There are some caveats listed regarding NDE and NAT (flow mask 
> conflicts,
> and
> fragments), but even given that, the caveats imply that it will work if the 
> caveats don't
> apply or
> the flowmask conflicts are resolved. Also, there are no warnings when 
> configuring it. The
> feature
> manager shows no errors or conflicts, etc...
> 
> At every step, in my opinion, cisco has been reluctant to admit that it 
> doesn't work. Only
> when
> confronted with the evidence, they did finally admit it. Had we known of this 
> limitation,
> we would
> have purchased different hardware including possibly another vendor's 
> solution.
> 
> I'm looking at using SPAN to replicate the data and send it to a linux box to 
> then create
> netflow
> data exports, however, given the nature of the data (high bandwidth and 
> microburst), I'm
> not sure
> that the Linux box will work accurately. I assumed the PFC would be doing the 
> exports in
> hardware
> giving us the most accurate realtime look at the market data. Evidently I was 
> wrong.
> 
> I'm sending this so that no one else will make the same mistake we did as 
> well as being in
> the nsp
> archives.
> 
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff| Fax:   914-460-4139
> ___
> cisco-nsp 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] WARNING: Netflow & Hardware assisted NAT not supported on 65xx on the same interface even with Sup2T

[Matthew Huff]

No idea. I didn't check at the time. Since the document is updated regularly, I 
doubt they needed any subterfuge. The last modified date is now July 30th, 
2013. It's in "Configuring NetFlow and NDE" in the "Cisco 7600 Series Router 
Software Configuration Guide Cisco IOS Release 15S" documentation.

This is what was added:



Note NDE and NAT configuration on the same interface is not supported. NDE 
requires flows to age out periodicaly for it to export its statistics. NAT 
installs hardware shortcuts that do not age. Hence, NDE for NAT'd flows does 
not work correctly.
 
--------




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil 
> Mayers
> Sent: Friday, October 11, 2013 11:24 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] WARNING: Netflow & Hardware assisted NAT not supported 
> on 65xx on the
> same interface even with Sup2T
> 
> On 11/10/13 14:11, Matthew Huff wrote:
> > FYI,
> >
> > At least cisco went back end and added caveats to the documentation
> > about this limitation. Since I had combed through all the
> > documentation beforehand, had the caveat been there, it would have
> > been likely we would have purchased a different set of hardware.
> 
> Have they pulled that great Cisco trick of updating the docs but not
> updating the "last edited" timestamp, fooling you into thinking it's
> always been there?
> ___
> cisco-nsp 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] How to prevent https facebook from the cisco router 1841

[Matthew Huff]

How about setting up a squid proxy for http and https and disallow all
port 80/443 traffic except via the proxy. In the proxy, you can control
exactly what websites are accessible then.


On 11/14/13 12:45 PM, "Pierre Emeriaud"  wrote:

>> i need to prevent users to open Facebook https traffic from my router
>>cisco
>> 1841
>>
>> i can put it as ip but is there any thing else because the ip way not
>> efficient
>
>What about null-routing all advertised prefixes (32) from Facebook AS?
>
>$ whois -h asn.shadowserver.org prefix 32934 | awk -F" " '{print "ip
>route " $1 " null0"}'
>ip route 31.13.24.0/21 null0
>ip route 31.13.64.0/24 null0
>...
>
>Rinse & repeat every couple of months.
>
>
>
>--
>pierre
>___
>cisco-nsp 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] ASA 5505 doesn't like itself

[Matthew Huff]

Cisco PIX/ASA are not routers. For example, you cannot ping from the inside 
network to the outside interface, or any other simular type of test.

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tom
> Sutherland
> Sent: Friday, February 25, 2011 4:01 PM
> To: Michael Loether
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] ASA 5505 doesn't like itself
> 
> as a test, you might try:
> 
> icmp permit any inside
> icmp permit any outside
> 
> from cisco command reference:
> 
> "To configure access rules for ICMP traffic that terminates at a
> adaptive security appliance interface, use the icmp command."
> 
> 
> On Thu, 2011-02-17 at 16:53 -0500, Michael Loether wrote:
> 
> > I have a ASA 5505 I am setting up at a small branch office.  Working 
> > towards a site to site VPN but
> first I need to get it to talk to itself.  Traffic is not passing from inside 
> to outside.
> >
> > interface Vlan1
> >  nameif inside
> >  security-level 100
> >  ip address 172.19.1.1 255.255.255.0
> > !
> > interface Vlan2
> >  nameif outside
> >  security-level 0
> >  ip address 64.183.175.22 255.255.255.252
> > !
> > interface Ethernet0/0
> >  switchport access vlan 2
> > !
> > interface Ethernet0/1
> > !
> > nat (inside,outside) after-auto source dynamic any interface
> >
> > DHCPd is running on VL 1 and it is handing out IPs as expected.
> >
> > ping inside 64.183.175.21
> > Type escape sequence to abort.
> > Sending 5, 100-byte ICMP Echos to 64.183.175.21, timeout is 2 seconds:
> > ?
> > Success rate is 0 percent (0/5)
> >
> > ACLs are any any ip on both inside and outside.
> >
> > Any suggestion would be appreciated.
> >
> > 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] Sup720, multicast bothers the CPU

[Matthew Huff]

Anything in the 224.0.0.0/24 subnet is equivalent to a broadcast address in the 
local subnet and will be punted to the CPU.

http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml


I've seen some software that has used 224.0.0.1 for the multicast destination 
address and will hose your network. Nothing other than control protocols should 
use 224.0.0.0-224.0.0.255.



The 224.0.1.40 is for Cisco RP discovery and is normal
The 239.255.255.250 is SSDP and is a Microsoft Thing and is normal
The 239.255.255.253 is SLP and is normal




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Peter Rathlev
Sent: Friday, March 25, 2011 6:00 AM
To: John Neiberger
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Sup720, multicast bothers the CPU

On Wed, 2011-03-23 at 20:55 +0100, Peter Rathlev wrote:
> Thanks. We'll try just adding "ip igmp snooping querier" to the specific
> SVI to see if this in itself would be enough. Next up we try "ip pim
> sparse-mode" on the SVI and "ip multicast-routing" in global.
> 
> I'll keep the list updated on how it went. :-)

We now tried both adding an IGMP Querier and enabling multicast-routing
and PIM. None of these things stopped the multicast traffic from hitting
the CPU.

I'm a little puzzled that we actually saw _some_ sources:

xxx#sh ip igmp membership 
[...]
 *,239.255.255.253  10.26.46.78 00:02:41 02:46 2A Vl46
 *,239.255.255.250  10.26.46.77 00:02:43 02:46 2A Vl46
 *,224.0.1.40   10.26.46.25400:02:43 02:53 2LAVl46
xxx#

Just not from the "interesting" groups. We tried restarting both a
receiver and a source to see if anything changed, and we never saw joins
or "*,".

So a few questions more:

 1) Could "offset != 0" somehow mean that the flows cannot be hardware
switched at all? Every single packet has offset != 0, i.e. no packet
observed with offset == 0. We were looking at both an RP SPAN
session and a SPAN session covering the VLAN in question.

 2) Could 224.0.0.0/24, which they use for this purpose though that's
wrong, somehow be treated specially by a Sup720? Any chance it would
help using 239.255.255.0/24 instead?

Thanks in advance.

-- 
Peter



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

___
cisco-nsp 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] IP GRE tunnel up/down

[Matthew Huff]

If it cannot make the original connection it will show up/down

Can you route from the source to the tunnel destination and are there any 
firewalls that would block the GRE protocol?
Can the destination route back to the source loopback1?



-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Drew Weaver
Sent: Wednesday, July 13, 2011 11:20 AM
To: cisco-nsp
Subject: [c-nsp] IP GRE tunnel up/down

Howdy,

I am trying to establish a GRE/IP tunnel over the Internet:

interface Tunnel1
description GRE-Tunnel
ip unnumbered GigabitEthernet7/0/0
no ip directed-broadcast
tunnel source Loopback1
tunnel destination x.x.x.x
end

Pretty much no matter what I do the interface status is always:

Tunnel1 is up, line protocol is down

I've read that tunnels should be up/up unless you are using keepalives and it 
detects a failure.

Does anyone have any insight they can share on this?

thanks,
-Drew


___
cisco-nsp 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] 7600 HFIB bug?

[Matthew Huff]

It's very possible the fib is correct, but should be correctable by doing a 
"clear arp" and a "clear ip route *". What IOS are you running and what sup 
engine do you have? Also, what does "show ip cef exact-route source_ip dest_ip" 
show?

Are there anything else "interesting" configured? MPLS, PBR, i.e., what does 
the interface config look like?


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Persio Pucci
Sent: Thursday, July 28, 2011 3:23 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 7600 HFIB bug?

Hi all. I am new to the list and this is my first post. :)

Trying to get to the bottom of a situation, sans-TAC. Long story short, for
context sake, I had a 7300 that was replaced by a 7600 at my Rio de Janeiro
site connecting to SP and NY.

(SP --- RIO --- NY)

Everything was working fine by the time we were finishing replacing the box,
when our circuit to Sao Paulo was hit and stayed down for about 6 hours.
When the circuit came back up, some communication to NY was just simply not
working, the SP rotuer could not reach, for whatever reason, IP addresses
that were reachable after replacing the box, before the hit. It used to work
on a TE tunnel I had to remove and make Rio a BGP hop to put it to work
while I tried to figure wtf was going on. Ever since, I can ping NY's IP
address from Rio, but cannot from SP, altough all routing is in place
(ISIS), all CEF entries are there.

Well, after a few weeks working on this when time was allowed, I came to a
intriguing situation today, while working with the help of a friend. I was
trying to debug this by using a permit ACL with log-input on the Rio
interfaces and see what was going on. When I applied the ACL on the
interfaces (ip permit x x log-input, ip permit any any), things started
working, and I was again able to ping from SP to NY. If I remove the ACL, I
cease to ping NY from SP.

I seems like something is borked at the 7600, cause the packets won't go
through if they are CEF switched, but they will when they are punted to the
CPU for the logging. Lookis like some FIB/HFIB issue that is beyond
my comprehension.

Any ideas besides going to TAC? Tks!
___
cisco-nsp 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] 7600 HFIB bug?

[Matthew Huff]

I'm not an mpls person, but I know how I would start to debug it. I would save 
the current config, and then setup the simplest possible configuration (no nat, 
minimum mpls, no hold-queues, no rsvp, no pim, no routing, just a single p2p 
link. Test the hell out of it. Then setup some static routes and push some 
traffic through it. Then add feature by feature back testing heavily each step.

If you run into a bug, you might want to look at the latest SRE train.



From: Persio Pucci [mailto:per...@gmail.com]
Sent: Thursday, July 28, 2011 3:53 PM
To: Matthew Huff
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 7600 HFIB bug?

Matthew,

clear arp, clear ip route, clear cef, nothing helps, I have even reloaded SP 
and Rio routers during a window, tired of this, and still it won't work.

I am running 12.2(33r)SRB4 on a RSP720-3CXL-GE. Interfaces have MPLS running. 
And Multicast, but so they did before when it worked.

Before it broke, MPLS was on both to_SP and to_NY interfaces, and I had a 
MPLS-TE tunnel from SP to NY. When it broke, the tunnel would not work and I 
had to remove it, remove MPLS from the to_NY interface, and make Rio a BGP hop 
for both SP and NY to resume communications.

The weirdest part is that when we first brought up the 7600, it was working OK. 
But then we had a hit on our Rio/SP circuit, and when it cam back, it never 
worked again.

This is the to_SP interface

interface POS4/1/0
 description * TO SPO * ACTIVE
 ip address X.X.X.X 255.255.255.252
 ip nat outside
 ip router isis
 ip pim sparse-dense-mode
 mpls traffic-eng tunnels
 mpls ldp discovery transport-address X.X.X.X
 mpls label protocol ldp
 mpls ip
 crc 32
 pos framing sdh
 pos scramble-atm
 aps group 20
 aps working 1
 hold-queue 4096 in
 hold-queue 4096 out
 ip rsvp bandwidth 10 10
end

This is to NY

interface GigabitEthernet1/2
 description * TO NY*1 *
 ip address X.X.X.X 255.255.255.252 secondary
 ip address X.X.X.X 255.255.255.240
 ip access-group 123 out
 no ip redirects
 ip router isis
 load-interval 30
 mpls mtu 1524
 mpls traffic-eng tunnels
 mpls ldp discovery transport-address X.X.X.X
 mpls label protocol ldp
 mpls ip
 spanning-tree link-type point-to-point
 hold-queue 4096 in
 ip rsvp bandwidth 10 10
end

ACL 123 is the one I have in place in the meanwhile punting the packets I 
really need to go through:

access-list 123 permit ip any X.X.XX 0.0.0.255 log
access-list 123 permit ip X.X.X.X 0.0.0.255 any log
access-list 123 permit ip any host X.X.X.X log
access-list 123 permit ip host X.X.X.X any log
access-list 123 permit ip any X.X.X.X 0.0.0.3 log
access-list 123 permit ip X.X.X.X 0.0.0.3 any log
access-list 123 permit ip any any


On Thu, Jul 28, 2011 at 4:37 PM, Matthew Huff 
mailto:mh...@ox.com>> wrote:
It's very possible the fib is correct, but should be correctable by doing a 
"clear arp" and a "clear ip route *". What IOS are you running and what sup 
engine do you have? Also, what does "show ip cef exact-route source_ip dest_ip" 
show?

Are there anything else "interesting" configured? MPLS, PBR, i.e., what does 
the interface config look like?


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff| Fax:   914-460-4139


-Original Message-
From: 
cisco-nsp-boun...@puck.nether.net<mailto:cisco-nsp-boun...@puck.nether.net> 
[mailto:cisco-nsp-boun...@puck.nether.net<mailto:cisco-nsp-boun...@puck.nether.net>]
 On Behalf Of Persio Pucci
Sent: Thursday, July 28, 2011 3:23 PM
To: cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
Subject: [c-nsp] 7600 HFIB bug?

Hi all. I am new to the list and this is my first post. :)

Trying to get to the bottom of a situation, sans-TAC. Long story short, for
context sake, I had a 7300 that was replaced by a 7600 at my Rio de Janeiro
site connecting to SP and NY.

(SP --- RIO --- NY)

Everything was working fine by the time we were finishing replacing the box,
when our circuit to Sao Paulo was hit and stayed down for about 6 hours.
When the circuit came back up, some communication to NY was just simply not
working, the SP rotuer could not reach, for whatever reason, IP addresses
that were reachable after replacing the box, before the hit. It used to work
on a TE tunnel I had to remove and make Rio a BGP hop to put it to work
while I tried to figure wtf was going on. Ever since, I can ping NY's IP
address from Rio, but cannot from SP, altough all routing is in place
(ISIS), all CEF entries are there.

Well, after a few weeks working on this when time was allowed, I came to a
intriguing situation today, while working with the help of a friend. I was
trying to debug this by using a permit ACL with log-input on the Rio
interfaces and see what was going on. When I applied the ACL on the
interfaces (ip permit x x log-input, ip permit any any),

Re: [c-nsp] ios based FW

[Matthew Huff]

Check out the new Zone Based Firewall configuration for IOS Fw feature set.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott Voll
Sent: Tuesday, August 02, 2011 12:03 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ios based FW

So I'm new to IOS based Firewalls.

Can someone kind of check my thinking with them.

IOS based firewalls use ACL's to firewall with.  To make it stateful, you
use the IP inspect commands.

Is that that general idea?

Scott
___
cisco-nsp 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] Incomplete netflow on 7606/RSP720/MSFC4 L3 hardware switched interface with NAT & ACLs

[Matthew Huff]

isabled in netflow table
  WCCP Redirect outbound is disabled
  WCCP Redirect inbound is disabled
  WCCP Redirect exclude is disabled

>From the config
-
mls aging long 64
mls aging normal 32
mls flow ip interface-destination-source
mls nde sender version 5

ip flow-export source Loopback0
ip flow-export version 9
ip flow-export destination xx.xx.xx.xx 2055



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


___
cisco-nsp 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] A bit of 6513-E confusion

[Matthew Huff]

Only with a Sup2T.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/qa_c67-621410.html

Q. Will you get 80 Gbps per slot with the Cisco Catalyst 6500 Series Supervisor 
Engine 720?
 
A. No. The Cisco Catalyst 6513-E chassis with the future Sup2T will support 80 
Gbps per slot on all 13 slots. The Cisco Catalyst 6513-E with Cisco Catalyst 
6500 Series Supervisor Engine 720 will have the same bandwidth caveats that 
exist on the current non-E 6513 chassis. With a Cisco Catalyst 6500 Series 
Supervisor Engine 720, the fabric channel connections for the Cisco Catalyst 
6513-E and 6513 (non-E) are distributed the same: that is, slots 1 through 8 
are single channel with 20 Gbps capacity, and slots 9 through 13 are dual 
channel, providing 40 Gbps/slot. So with the Cisco Catalyst 6500 Series 
Supervisor Engine 720, a Cisco Catalyst 6513-E will only support the 67xx line 
cards in slots 9 through 13.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Drew Weaver
Sent: Wednesday, August 17, 2011 2:28 PM
To: cisco-nsp
Subject: [c-nsp] A bit of 6513-E confusion

With a 6513-E would you be able run it with:

2xSUP720-3BXLs
10xWS-6748(/w DFCs)
1x WS-6708?

I don't need the 10/100/1000 ports to be "line rate" either.

I know in the regular 6513 you can only put the higher-end cards in the last 
few slots, but I can't really find out if that is still true on the 6513-E.

Has anyone been brave enough to try it and could you share your results?

thanks,
-Drew


___
cisco-nsp 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] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface

[Matthew Huff]

Last winter we purchased a pair of 7606 routers to use out at the NYSE colo 
facility. We connect via a 1gb fiber to the SFTI LCN for market data and FIX 
traffic. We fully expected to be able to use hardware assisted NAT and NDE to 
monitor the traffic. The netflow output we get is random, sporadic and very 
incomplete. After dealing with our Sales team and TAC, we have finally got them 
to admit that it doesn't work when NAT and NDE are configured on the same 
interface.

Nowhere in the Cisco marketing literature, Cisco Documentation, or even Cisco 
bug lists does it mention this. There are some caveats listed regarding NDE and 
NAT (flow mask conflicts, and fragments), but even given that, the caveats 
imply that it will work if the caveats don't apply or the flowmask conflicts 
are resolved. Also, there are no warnings when configuring it. The feature 
manager shows no errors or conflicts, etc...

At every step, in my opinion, cisco has been reluctant to admit that it doesn't 
work. Only when confronted with the evidence, they did finally admit it. Had we 
known of this limitation, we would have purchased different hardware including 
possibly another vendor's solution.

I'm looking at using SPAN to replicate the data and send it to a linux box to 
then create netflow data exports, however, given the nature of the data (high 
bandwidth and microburst), I'm not sure that the Linux box will work 
accurately. I assumed the PFC would be doing the exports in hardware giving us 
the most accurate realtime look at the market data. Evidently I was wrong.

I'm sending this so that no one else will make the same mistake we did as well 
as being in the nsp archives.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139



___
cisco-nsp 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] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface

[Matthew Huff]

> I would instead consider moving the NAT somewhere else, and leaving the 
> Netflow on the box. The hardware-assisted NAT feature in the 6500/7600 
> has the feel of an "abandoned" feature; one that Cisco would rather you 
> didn't use, and are sorry they ever implemented.

Yes, I get that feeling also. However, since the monitoring has a less of a 
priority than the low latency of the packets, moving the NAT to another box 
which adds another layer of complexity and another latency hop, it's likely we 
will either replace the entire hardware or leave it the way it is. Having to 
increase latency to add monitoring is the tail wagging the dog.

As far as requirements, on the marketing literature for the 7600/RSP720 the 
hardware assisted nat and NDE are both prominent features advertised. There are 
no disclaimers stating they won't work together. In fact, I've yet to see any 
published documentation, internal or external from Cisco that states that it 
won't work. Just a good explanation from TAC why it won't (The NAT inserts a 
special Netflow entry that doesn't follow the mls aging timeout, so NDE doesn't 
work).

We have been promised a formal statement from Cisco in regards to this. Once we 
have that, we will had it over to our legal department and see where it goes 
from there.


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: Saturday, August 27, 2011 6:47 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not 
supported on 76xx/65xx on the same interface

On 08/26/2011 05:25 PM, Matthew Huff wrote:

> I'm looking at using SPAN to replicate the data and send it to a
> linux box to then create netflow data exports, however, given the

I would instead consider moving the NAT somewhere else, and leaving the 
Netflow on the box. The hardware-assisted NAT feature in the 6500/7600 
has the feel of an "abandoned" feature; one that Cisco would rather you 
didn't use, and are sorry they ever implemented.
___
cisco-nsp 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] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface

[Matthew Huff]

If it was made apparent, could you point to any public documentation that 
states that? I've scoured Cisco's site, google, and mail archives, and can't 
find any mention (other than specific caveats) that state that NDE and hardware 
assisted nat are not supported on the same interface. In fact, it took TAC 
almost two weeks of escalation before anyone would state it wasn't supported 
and they couldn't find any documentation that stated that. 

As far as speaking to a TME, I work in small trading firm. We don't have the 
luxury of long, involved RFP with detailed descriptions or time to work with a 
TME to discuss every detail of every configuration we use. We expect if a 
vendor advertise features, that they should work, except when they are 
documented (like caveats). Having two major features (and they are both listed 
as major features in Cisco's marketing literature for the RSP720) that won't 
coexist should be pointed out very obviously in their literature. 



-Original Message-
From: Dale W. Carder [mailto:dwcar...@wisc.edu] 
Sent: Saturday, August 27, 2011 5:13 PM
To: Matthew Huff
Cc: 'cisco-nsp@puck.nether.net'
Subject: Re: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not 
supported on 76xx/65xx on the same interface


On Aug 26, 2011, at 11:25 AM, Matthew Huff wrote:

> Last winter we purchased a pair of 7606 routers to use out at the NYSE colo 
> facility. We connect via a 1gb fiber to the SFTI LCN for market data and FIX 
> traffic. We fully expected to be able to use hardware assisted NAT and NDE to 
> monitor the traffic. The netflow output we get is random, sporadic and very 
> incomplete. After dealing with our Sales team and TAC, we have finally got 
> them to admit that it doesn't work when NAT and NDE are configured on the 
> same interface.

I seem to remember that being made apparent when the sup720 was first 
announced, and I also think it was presented in the cat6k architecture
session at networkers when I went in 2005.

Sounds to me that you really need a better sales team that can engage 
the right TME.

Dale

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

Re: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface

[Matthew Huff]

We don't have fragmented packets. I checked all the caveats. You missed my 
point. I'm very aware of the restrictions with conflicting flowmasks, etc. 

The problem is that the hardware assisted NAT uses netflow to insert a custom 
tcam entry that doesn't get aged out. In other words, NDE will never work, no 
matter the configuration, no matter the design if NAT is configured on the same 
interface. This is not documented in any Cisco publication.



-Original Message-
From: Stig Meireles Johansen [mailto:stig.johan...@datametrix.no] 
Sent: Saturday, August 27, 2011 10:21 PM
To: Matthew Huff; 'Dale W. Carder'
Cc: 'cisco-nsp@puck.nether.net'
Subject: RE: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not 
supported on 76xx/65xx on the same interface

Matthew said:
>If it was made apparent, could you point to any public documentation that 
>states that? I've scoured Cisco's site, google, and mail archives, and can't 
>find any mention (other than specific caveats) that state that NDE and 
>hardware assisted nat are not supported on the same interface. In fact, it 
>took TAC almost two weeks of escalation before anyone would state it wasn't 
>supported and they couldn't find any documentation that stated that.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/intro.html#wp1034472
 and
http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/intro.html#wp1031772

Quote:
"Note the following information about hardware-assisted NAT:
[...snip...]
-When you configure NAT and NDE on an interface, the PFC3 sends all traffic in 
fragmented packets to the MSFC3 to be processed in software. (CSCdz51590)"

When looking up this bugID, I get some foo about "contains proprietary 
information that cannot be disclosed at this time".

/Stig

___
cisco-nsp 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] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface

[Matthew Huff]

Netflow *collection* of flows traversing the NAT-ed interface. Sorry, I can see 
why that would be confusing.



-Original Message-
From: Gert Doering [mailto:g...@greenie.muc.de] 
Sent: Sunday, August 28, 2011 5:14 AM
To: Matthew Huff
Cc: 'Dale W. Carder'; 'cisco-nsp@puck.nether.net'
Subject: Re: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not 
supported on 76xx/65xx on the same interface

Hi,

On Sat, Aug 27, 2011 at 05:31:09PM -0400, Matthew Huff wrote:
> If it was made apparent, could you point to any public documentation 
> that states that? I've scoured Cisco's site, google, and mail 
> archives, and can't find any mention (other than specific caveats) 
> that state that NDE and hardware assisted nat are not supported on the 
> same interface. In fact, it took TAC almost two weeks of escalation 
> before anyone would state it wasn't supported and they couldn't find 
> any documentation that stated that.

If you say "NDE and nat ... on the same interface", what exactly do you mean by 
that?  Netflow *export* via the same interface that also does NAT, or netflow 
*collection* of flows traversing the NAT-ed interface?

(NDE = "netflow data export" - and if it's just the export functionality, it 
should be easy to build workarounds for the exported flows to go around in a 
circle, and leave via another interface)

gert
--
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

___
cisco-nsp 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] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface

[Matthew Huff]

> Bottom line: you *should* be able to trust vendor marketing, but you
> *can't*, and I strongly advise you don't, for Cisco or any other vendor
> - they simply don't convey accurate information reliably enough :o(

I agree. Caveat Emptor. 

I would understand the limitation if I was using some unusual feature or using 
them in some unusual way. However, the marketing literature for the RSP720 
mentions supporting hardware-assisted NAT, and netflow collection. These are 
major features, and one of the advantages of using a hardware router/switch 
rather than a software one (which is important in the financial realm, since 
market data by nature is bursty). A simple notice that netflow data collection 
and NAT cannot be used on the same interface should be mentioned in that 
literature since it cannot work under any configuration on the same interface.



___
cisco-nsp 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] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface

[Matthew Huff]

> Then hire someone that knows what they are doing.

Hire someone who knows of undocumented limitations of future hardware 
purchases. Right.

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tony
> Varriale
> Sent: Sunday, August 28, 2011 12:13 PM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] WARNING: Netflow Data Export & Hardware assisted NAT not 
> supported on 76xx/65xx
> on the same interface
> 
> On 8/27/2011 4:31 PM, Matthew Huff wrote:
> > If it was made apparent, could you point to any public documentation that 
> > states that? I've scoured
> Cisco's site, google, and mail archives, and can't find any mention (other 
> than specific caveats) that
> state that NDE and hardware assisted nat are not supported on the same 
> interface. In fact, it took TAC
> almost two weeks of escalation before anyone would state it wasn't supported 
> and they couldn't find
> any documentation that stated that.
> >
> > As far as speaking to a TME, I work in small trading firm. We don't have 
> > the luxury of long,
> involved RFP with detailed descriptions or time to work with a TME to discuss 
> every detail of every
> configuration we use. We expect if a vendor advertise features, that they 
> should work, except when
> they are documented (like caveats). Having two major features (and they are 
> both listed as major
> features in Cisco's marketing literature for the RSP720) that won't coexist 
> should be pointed out very
> obviously in their literature.
> >
> >

> 
> tv
> ___
> cisco-nsp 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] WARNING: Netflow Data Export & Hardware assisted NAT not supported on 76xx/65xx on the same interface

[Matthew Huff]

Simon Leine writes:
> In many cases there are technical reasons that can explain why features
> don't coexist well.  For example regarding NAT and NDE on the PFC3:
> They
> both use the same hardware Netfow table, but it has to be managed
> somewhat differently, as Gerd mentioned.  It would probably be possible
> to make them coexist, but that would require work (coding, testing
> etc).

Right. Except that the documentation explicitly mentions caveats with NDE and 
Hardware Assisted NAT including flowmask restrictions and a known bug with 
fragmented packets. I think it' reasonable to assume if the documentation for 
the specific hardware mentions configuring them but warning about known 
caveats, you would think they work together except for the caveats. The only 
reason I can think of the reason for documenting the caveats is that it used to 
work, but some change broke it. If it never worked, there would be no reasons 
for caveats, rather just a mention that it isn't supported.

It took 3 weeks with TAC including a network sniffer trace file to prove to the 
tech it didn't work. When he escalated it to backline BU engineering, he found 
out it wasn't supported. It isn't even well known within Cisco. I really don't 
think a consultant or TME would have found this limitation either. The whole 
purpose of this thread is just to have it documented in the nsp 
archives/google, not to start an argument. 

As far as configuring in a lab, that would be nice, but we hardly have the time 
for that including setting up a test netflow collector and sending through test 
data, just to confirm a feature that Cisco market literature advertises. It 
would be nice to spend the time setting up RFP and test labs to verify vendor 
claims, but there is no way I can spend the resources to do such at the firm 
where I work. My time is devoted to actual implantation (we are a algorithmic 
trading firm). I am sure there are some good consultants out there, but ones 
that understand market data issues well and the network designs that support 
them are few and far between. The equipment we put in place at the NYSE colo 
has worked perfectly as far as delivering packets (iBGP, multicast, layer2/3 
switching, and hardware assisted nat). The monitoring that netflow would 
provide would be very valuable, but isn't a show stopper.

At some point, you just have to do your best and go with what you have. I've 
got 20+ years of cisco experience including a lot of hands on with Sup1A, Sup2, 
Sup32, Sup720, etc, and this is the first time I've run into a feature 
limitation with not so much as a caveat or hint of possible limitations.

___
cisco-nsp 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] ASA vs ISR ZBFW

[Matthew Huff]

Gert,

I understand where this comes from, but the ASA is a bit more modern then the 
"PIXen".

1) It now does dynamic routing (RIP, OSPF, EIGRP)
2) Nat (as of 8.3+) is now "normal"
3) The inspect feature still has issues but is necessary for many protocols and 
is implemented very similar on the ZBFW  in ios.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Gert Doering
> Sent: Friday, September 09, 2011 11:05 AM
> To: Jay Nakamura
> Cc: cisco-nsp
> Subject: Re: [c-nsp] ASA vs ISR ZBFW
> 
> Hi,
> 
> On Fri, Sep 09, 2011 at 01:31:06AM -0400, Jay Nakamura wrote:
> > I have been wondering lately, what advantages do ASA have over ISR as
> > a firewall on the low end?  As just one stand alone firewall, what
> > features are there for ASA that distinguishes itself?  Often, I
> rather
> > have an ISR over an ASA so I have more flexibility in a budget
> > environment.
> 
> It has "FIREWALL!!" painted on the front cover, and will not do dynamic
> routing.  And the NAT is much more interesting, and the way "fixup"
> helpers damage perfectly reasonable communications...
> 
> Mmmh.  This certainly doesn't read as if I like PIXen.  Wonder why.
> 
> gert
> --
> USENET is *not* the non-clickable part of WWW!
> 
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-
> muenchen.de

___
cisco-nsp 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] ASA vs ISR ZBFW

[Matthew Huff]

> ... but still no BGP, which is undoubtly *the* routing protocol that you want 
> to use if you don't trust your neighbours (due to much better filtering
> support) - and "firewall environment" is usually all about "not trusting".

I prefer to keep my BGP routing and firewall on separate boxes especially since 
full routes take quite a bit of CPU and memory. But I can see why it would be 
nice to keep it on the same box.

> (Can you do firewalling without NAT these days without configuring
> external-to-internal permits as "please do NAT from X to X"?)

Yes, a simple acl works now

> Just last week I had a customer call due to weird issues with "passive
> FTP is not working right"... but indeed that might have been an older
> firmware release.

Hmm, would it happen to have including a NetBSD or OpenBSD box? There have been 
some issues with some of the new FTP verbs (especially EPSV). Some ftp clients 
use the new EPSV verb without failing back correctly to PASV even over ipv4 
connections (RFC2428). I've run into this a few times especially with older 
cisco load balancers.




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: Gert Doering [mailto:g...@greenie.muc.de]
> Sent: Friday, September 09, 2011 11:24 AM
> To: Matthew Huff
> Cc: 'Gert Doering'; 'Jay Nakamura'; 'cisco-nsp'
> Subject: Re: [c-nsp] ASA vs ISR ZBFW
> 
> Hi,
> 
> On Fri, Sep 09, 2011 at 11:17:39AM -0400, Matthew Huff wrote:
> > I understand where this comes from, but the ASA is a bit more modern
> then the "PIXen".
> >
> > 1) It now does dynamic routing (RIP, OSPF, EIGRP)
> 
> ... but still no BGP, which is undoubtly *the* routing protocol that
> you want to use if you don't trust your neighbours (due to much better
> filtering
> support) - and "firewall environment" is usually all about "not
> trusting".
> 
> > 2) Nat (as of 8.3+) is now "normal"
> 
> Hooray :-)
> 
> (Can you do firewalling without NAT these days without configuring
> external-to-internal permits as "please do NAT from X to X"?)
> 
> > 3) The inspect feature still has issues but is necessary for many
> protocols and is implemented very similar on the ZBFW  in ios.
> 
> Just last week I had a customer call due to weird issues with "passive
> FTP is not working right"... but indeed that might have been an older
> firmware release.
> 
> OTOH, I never said the PIX/ASAs are *bad*...  there's much worse evil
> on the market :-)
> 
> gert
> --
> USENET is *not* the non-clickable part of WWW!
> 
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-
> muenchen.de

___
cisco-nsp 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] Troubleshoot UDP out-of-sequence

[Matthew Huff]

I have also run into some hosts with optimized udp offloading and/or streams 
offloading that will send a small percentage of packets outbound out of order, 
especially on hosts that have IRQ balancing algos. So if the host is out of 
order



> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dobbins, Roland
> Sent: Monday, September 12, 2011 4:20 PM
> To: Cisco NSP
> Subject: Re: [c-nsp] Troubleshoot UDP out-of-sequence
> 
> On Sep 13, 2011, at 3:08 AM, Lamar Owen wrote:
> 
> > If the application relies on 100% in-order delivery, it shouldn't be using 
> > straight UDP.
> 
> Or, it should have reasonable error-correction/tolerance for out-of-order 
> packets.
> 
> ;>
> 
> ---
> Roland Dobbins  // 
> 
>   The basis of optimism is sheer terror.
> 
> -- Oscar Wilde
> 
> 
> ___
> cisco-nsp 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] ASA vs. ASR for large Wireless NAT deployment ?

[Matthew Huff]

One thing to be aware of is that currently the ASA doesn't support setting the 
managed or other flag for the RA for ipv6 for DHCPv6 support. This is supposed 
to be fixed in the next release for the ASA real soon now (tm).



> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On
> Behalf Of Johnson, Neil M
> Sent: Friday, November 11, 2011 5:49 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ASA vs. ASR for large Wireless NAT deployment ?
> 
> 
> We have a large campus wireless (~8-10K clients simultaneously) network
> that we are considering moving to private address space and NAT'ing to the
> outside world.
> 
> I'm looking at the ASA 5585 with SSP20 or an ASA 1004 with an ESP20 and
> RP2.
> 
> One requirement is that the NAT device not mangle IPv6 and only NAT IPv4
> traffic destined to the Internet (we route some private address space
> internally).
> 
> Any recommendations ?
> 
> Thanks.
> -Neil
> 
> --
> Neil Johnson
> Network Engineer
> The University of Iowa
> Phone: 319 384-0938
> Fax: 319 335-2951
> Mobile: 319 540-2081
> E-Mail: neil-john...@uiowa.edu
> 
> 
> 
> 
> 
> ___
> cisco-nsp 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] Weird Multicast microburst amplification issue

[Matthew Huff]

We have a multicast data stream (real-time ticker data) that by its nature is 
very bursty.

When we connect a source server via gigabit Ethernet to our 6500/sup720 switch 
via a 6748 module and a destination server via gigabit to  the same or 
different module in the same switch, everything works fine. If the destination 
server is on a different switch connected by a layer3 10GB connection then we 
have significant output drops on the Ethernet connected to the destination 
server.

All switches are 6509/sup720 with 6748 line cards. QoS is disabled globally. 
The servers are identical. The output drops only occur on the Ethernet drop 
connected to the server.

The only thing I can think is happening is that by routing the traffic via the 
10gb L3 interface, something is causing the traffic burst to amplify, 
overrunning the output port. Has anyone seen this, and does anyone know how to 
mitigate this?


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff| Fax:   914-460-4139

___
cisco-nsp 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] Weird Multicast microburst amplification issue

[Matthew Huff]

Unfortunately, it isn't something simple like that. The output drops are 
continuously happening. The network is very stable. There are not other issues 
during this time. It's something amplifying the burst of the stream, either the 
multicast replication or passing through the layer 3 interface.

IF we run a test with a server on switch a, a client on switch a, and a client 
on switch b, only the client on switch b is seeing the problem. The problem 
isn't passing the data from switch-a to b, but rather something during the 
transmission that changes the shape of the data to be a heavier burst.



----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: Chuck Church [mailto:chuckchu...@gmail.com]
> Sent: Friday, December 09, 2011 2:11 PM
> To: Matthew Huff; 'cisco-nsp'
> Subject: RE: [c-nsp] Weird Multicast microburst amplification issue
> 
> Are there multiple streams passing through the switch?  A spanning tree
> recalculation will cause IGMP to flush associations, and flood all
> streams out all ports until they're relearned.  Portfast will fix it,
> as will a multicast-specific interface command, would need to look it
> up.
> 
> Chuck
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Matthew Huff
> Sent: Friday, December 09, 2011 1:49 PM
> To: 'cisco-nsp (cisco-nsp@puck.nether.net)'
> Subject: [c-nsp] Weird Multicast microburst amplification issue
> 
> We have a multicast data stream (real-time ticker data) that by its
> nature is very bursty.
> 
> When we connect a source server via gigabit Ethernet to our 6500/sup720
> switch via a 6748 module and a destination server via gigabit to  the
> same or different module in the same switch, everything works fine. If
> the destination server is on a different switch connected by a layer3
> 10GB connection then we have significant output drops on the Ethernet
> connected to the destination server.
> 
> All switches are 6509/sup720 with 6748 line cards. QoS is disabled
> globally.
> The servers are identical. The output drops only occur on the Ethernet
> drop connected to the server.
> 
> The only thing I can think is happening is that by routing the traffic
> via the 10gb L3 interface, something is causing the traffic burst to
> amplify, overrunning the output port. Has anyone seen this, and does
> anyone know how to mitigate this?
> 
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff| Fax:   914-460-4139
> 
> ___
> cisco-nsp 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] Weird Multicast microburst amplification issue

[Matthew Huff]

Yes. The problem only occurs when connected to any other switch than the source 
switch. We have over 300 servers, it isn't anything with a specific server, but 
rather the nature of not being on the same switch as the source. The data is a 
high packet count, bursty traffic. However, the drops only occur on the 6748 
module  via the layer 2 output on a server subscribing to that multicast 
traffic. This occurs if we turn layer 2 flowcontrol on or off. No pause packets 
are generated from the server, rather this is 100% related to the output ASIC 
queues on the 6748 module.




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: Chuck Church [mailto:chuckchu...@gmail.com]
> Sent: Friday, December 09, 2011 2:43 PM
> To: Matthew Huff; 'cisco-nsp'
> Subject: RE: [c-nsp] Weird Multicast microburst amplification issue
> 
> Can you move the source server over to switch B to see if the problem
> still exists on switch B then, or moves to switch A?  Anything showing
> up in the logs?
> 
> Chuck
> 
> 
> -Original Message-
> From: Matthew Huff [mailto:mh...@ox.com]
> Sent: Friday, December 09, 2011 2:25 PM
> To: 'Chuck Church'; 'cisco-nsp'
> Subject: RE: [c-nsp] Weird Multicast microburst amplification issue
> 
> Unfortunately, it isn't something simple like that. The output drops
> are continuously happening. The network is very stable. There are not
> other issues during this time. It's something amplifying the burst of
> the stream, either the multicast replication or passing through the
> layer 3 interface.
> 
> IF we run a test with a server on switch a, a client on switch a, and a
> client on switch b, only the client on switch b is seeing the problem.
> The problem isn't passing the data from switch-a to b, but rather
> something during the transmission that changes the shape of the data to
> be a heavier burst.
> 
> 
> 
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff    | Fax:   914-460-4139
> 
> 
> > -Original Message-
> > From: Chuck Church [mailto:chuckchu...@gmail.com]
> > Sent: Friday, December 09, 2011 2:11 PM
> > To: Matthew Huff; 'cisco-nsp'
> > Subject: RE: [c-nsp] Weird Multicast microburst amplification issue
> >
> > Are there multiple streams passing through the switch?  A spanning
> > tree recalculation will cause IGMP to flush associations, and flood
> > all streams out all ports until they're relearned.  Portfast will fix
> > it, as will a multicast-specific interface command, would need to
> look
> > it up.
> >
> > Chuck
> >
> > -Original Message-
> > From: cisco-nsp-boun...@puck.nether.net
> > [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Matthew Huff
> > Sent: Friday, December 09, 2011 1:49 PM
> > To: 'cisco-nsp (cisco-nsp@puck.nether.net)'
> > Subject: [c-nsp] Weird Multicast microburst amplification issue
> >
> > We have a multicast data stream (real-time ticker data) that by its
> > nature is very bursty.
> >
> > When we connect a source server via gigabit Ethernet to our
> > 6500/sup720 switch via a 6748 module and a destination server via
> > gigabit to  the same or different module in the same switch,
> > everything works fine. If the destination server is on a different
> > switch connected by a layer3 10GB connection then we have significant
> > output drops on the Ethernet connected to the destination server.
> >
> > All switches are 6509/sup720 with 6748 line cards. QoS is disabled
> > globally.
> > The servers are identical. The output drops only occur on the
> Ethernet
> > drop connected to the server.
> >
> > The only thing I can think is happening is that by routing the
> traffic
> > via the 10gb L3 interface, something is causing the traffic burst to
> > amplify, overrunning the output port. Has anyone seen this, and does
> > anyone know how to mitigate this?
> >
> > 
> > Matthew Huff | 1 Manhattanville Rd
> > Director of Operations   | Purchase, NY 10577
> > OTA Management LLC   | Phone: 914-460-4039
> > aim: matthewbhuff| Fax:   914-460-4139
> >
> > ___
> > cisco-nsp 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] Weird Multicast microburst amplification issue

[Matthew Huff]

Yes, only the correct stream. I've opened a case with Cisco. I'm suspecting 
that the multicast replication engine is doing something that causes it to 
amplify the bursty nature of the traffic causing the microburst overruns.


----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: Chuck Church [mailto:chuckchu...@gmail.com]
> Sent: Friday, December 09, 2011 3:01 PM
> To: Matthew Huff; 'cisco-nsp'
> Subject: RE: [c-nsp] Weird Multicast microburst amplification issue
> 
> Hmmm.  If it's not spanning tree, I'd have to say it's something not
> working right with IGMP, and the server's port is getting more streams
> than it should.  Have you checked the IGMP port association to see what
> it's subscribed to?
> 
> Chuck
> 
> 
> -Original Message-
> From: Matthew Huff [mailto:mh...@ox.com]
> Sent: Friday, December 09, 2011 2:48 PM
> To: 'Chuck Church'; 'cisco-nsp'
> Subject: RE: [c-nsp] Weird Multicast microburst amplification issue
> 
> Yes. The problem only occurs when connected to any other switch than
> the source switch. We have over 300 servers, it isn't anything with a
> specific server, but rather the nature of not being on the same switch
> as the source.
> The data is a high packet count, bursty traffic. However, the drops
> only occur on the 6748 module  via the layer 2 output on a server
> subscribing to that multicast traffic. This occurs if we turn layer 2
> flowcontrol on or off. No pause packets are generated from the server,
> rather this is 100% related to the output ASIC queues on the 6748
> module.
> 
> 
> 
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff    | Fax:   914-460-4139
> 
> 
> > -Original Message-
> > From: Chuck Church [mailto:chuckchu...@gmail.com]
> > Sent: Friday, December 09, 2011 2:43 PM
> > To: Matthew Huff; 'cisco-nsp'
> > Subject: RE: [c-nsp] Weird Multicast microburst amplification issue
> >
> > Can you move the source server over to switch B to see if the problem
> > still exists on switch B then, or moves to switch A?  Anything
> showing
> > up in the logs?
> >
> > Chuck
> >
> >
> > -Original Message-
> > From: Matthew Huff [mailto:mh...@ox.com]
> > Sent: Friday, December 09, 2011 2:25 PM
> > To: 'Chuck Church'; 'cisco-nsp'
> > Subject: RE: [c-nsp] Weird Multicast microburst amplification issue
> >
> > Unfortunately, it isn't something simple like that. The output drops
> > are continuously happening. The network is very stable. There are not
> > other issues during this time. It's something amplifying the burst of
> > the stream, either the multicast replication or passing through the
> > layer 3 interface.
> >
> > IF we run a test with a server on switch a, a client on switch a, and
> > a client on switch b, only the client on switch b is seeing the
> problem.
> > The problem isn't passing the data from switch-a to b, but rather
> > something during the transmission that changes the shape of the data
> > to be a heavier burst.
> >
> >
> >
> > 
> > Matthew Huff | 1 Manhattanville Rd
> > Director of Operations   | Purchase, NY 10577
> > OTA Management LLC   | Phone: 914-460-4039
> > aim: matthewbhuff    | Fax:   914-460-4139
> >
> >
> > > -Original Message-
> > > From: Chuck Church [mailto:chuckchu...@gmail.com]
> > > Sent: Friday, December 09, 2011 2:11 PM
> > > To: Matthew Huff; 'cisco-nsp'
> > > Subject: RE: [c-nsp] Weird Multicast microburst amplification issue
> > >
> > > Are there multiple streams passing through the switch?  A spanning
> > > tree recalculation will cause IGMP to flush associations, and flood
> > > all streams out all ports until they're relearned.  Portfast will
> > > fix it, as will a multicast-specific interface command, would need
> > > to
> > look
> > > it up.
> > >
> > > Chuck
> > >
> > > -Original Message-
> > > From: cisco-nsp-boun...@puck.nether.net
> > > [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Matthew
> Huff
> > > Sent: Friday, December 09, 2011 1:49 PM
> > > To: 'cisco-nsp (cisco-

Re: [c-nsp] Weird Multicast microburst amplification issue

[Matthew Huff]

No span sessions enabled.

It definitely looks like a classic microburst output buffer overflow problem, 
but with a Sup720 and a 6748 module, I haven't seen this at this volume. Ticker 
volume has peeked recently, and that might contribute to it. It appears to 
start happening with more than 120Mbps and/or 12,000 pps output on the port. 
Other than moving to 10GB, I don't see any solutions. Given the 6748 buffer 
size, I'm surprised it's overrunning it at this volume.




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: Dale W. Carder [mailto:dwcar...@wisc.edu]
> Sent: Monday, December 12, 2011 10:10 AM
> To: Matthew Huff
> Cc: 'cisco-nsp (cisco-nsp@puck.nether.net)'
> Subject: Re: [c-nsp] Weird Multicast microburst amplification issue
> 
> Do you have any span sessions enabled?
> 
> Dale
> 
> Thus spake Matthew Huff (mh...@ox.com) on Fri, Dec 09, 2011 at
> 01:48:35PM -0500:
> > We have a multicast data stream (real-time ticker data) that by its
> nature is very bursty.
> >
> > When we connect a source server via gigabit Ethernet to our
> 6500/sup720 switch via a 6748 module and a destination server via
> gigabit to  the same or different module in the same switch, everything
> works fine. If the destination server is on a different switch
> connected by a layer3 10GB connection then we have significant output
> drops on the Ethernet connected to the destination server.
> >
> > All switches are 6509/sup720 with 6748 line cards. QoS is disabled
> globally. The servers are identical. The output drops only occur on the
> Ethernet drop connected to the server.
> >
> > The only thing I can think is happening is that by routing the
> traffic via the 10gb L3 interface, something is causing the traffic
> burst to amplify, overrunning the output port. Has anyone seen this,
> and does anyone know how to mitigate this?
> >
> > 
> > Matthew Huff | 1 Manhattanville Rd
> > Director of Operations   | Purchase, NY 10577
> > OTA Management LLC   | Phone: 914-460-4039
> > aim: matthewbhuff| Fax:   914-460-4139
> >
> > ___
> > cisco-nsp 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] Weird Multicast microburst amplification issue

[Matthew Huff]

I agree that the 10g->1G is probably the culprit amplifying the burst nature of 
the packets. At our colo at the NYSE in Mahwah we have implemented HP's flex 
fabric in blade chassis instead of doing what you are doing with the Arista's 
and it's working fine. We probably are going to have to do the same at our core 
datacenter.

http://h18004.www1.hp.com/products/quickspecs/13127_div/13127_div.html

Basically you connect N number of 10GB uplinks into the flex fabric and you can 
control how the bandwidth is allocated to each blade.

I was hoping to avoid having to do anything, but it looks like the data rates 
are killing the port buffers. I was hoping that the 6500/sup720 with 6748 would 
handle > 120Mbps, 12k pps multicast, but it doesn't look like it.




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Jeff Bacon
> Sent: Tuesday, December 13, 2011 9:30 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Weird Multicast microburst amplification issue
> 
> > It definitely looks like a classic microburst output buffer overflow
> > problem, but with a Sup720 and a 6748 module, I haven't seen this at
> > this volume. Ticker volume has peeked recently, and that might
> > contribute to it. It appears to start happening with more than
> 120Mbps
> > and/or 12,000 pps output on the port. Other than moving to 10GB, I
> > don't see any solutions.
> > Given the 6748 buffer size, I'm surprised it's overrunning it at this
> > volume.
> 
> It could very well be. The port buffers on a 6748 are only about so
> big, after all.
> 
> The amplification factor may come from the simple fact that you have a
> 10G pipe between the switches. "But the input is only coming in at 1G!"
> you say. Yes, but it's then being intermingled on the 10G pipe.
> Probably on a 6708/6716 with 200mb port buffers. After going through
> replication engine.
> (Ingress mode? Egress? Shouldn't matter though.) So while in theory the
> traffic should be coming through the 10G at 1G rates, it isn't
> necessarily, and you have to consider the possibility that you are,
> yes, facing the ol' 10G->1G neck-down problem. 100 packets @ 1500 bytes
> == 1.5mbyte == buffer go boom.
> 
> If the packets are large, you also have serialization delay to
> consider. What takes 3 micros to get out the 1G pipe only takes
> 1 micro to come in the 10G pipe. Multiply.
> 
> I'm not going to point at any of these and say "that's it" - but I can
> see where it can happen, as annoying as crap as it might be. Someone
> suggested running a 1G pipe between the switches to see whether the
> problem went away - I suspect that is what they were pointing at.
> 
> I've been moving hosts off the 6500s and onto 10G off aristas fed off
> the 6500s. Let the 6500 drive the WAN, the aristas handle fan-out.  I
> am actually sitting here debating swapping out a pair of VS720s with
> sup-2T kit - not even because the hardware is working particularly hard
> as-is (by the stats, they've got life downright good) but because
> sledgehammer overkill seems to be about the only safe option in dealing
> with these kinds of flows, I know it will take me 3 months to swap the
> sups and cards out, and it might be better to start now, however little
> thrilled I am at forking $20k more per switch than I had originally
> intended (the VS720 parts swapped would be used to populate some new
> chassis in a DR/test facility, the original idea was just to buy VS720
> parts, but my vendor came up with better prices on sup2t kit than I'd
> seen even a couple months ago so now it's just in the range of
> "argh...maybe..."
> instead of "no, way too much").
> 
> Or to quote one of my employees, "who knows what MOAR will be asked for
> next..." - or, when will OPRA blow the cap again?
> 
> I suspect you just helped me decide.
> 
> G.
> -bacon
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

[c-nsp] NTP no longer slewing clock under 12.2(33)SXJ2 ???

[Matthew Huff]

Upgraded this weekend from 12.2(33)SXI5 to SXJ2. Everything appears fine accept 
NTP. I understand that SJ2 upgrades NTP from v3 to v4, but although it appears 
to be working, the local clock never slews (corrects to NTP time). The offsets 
in ntp stay stable, rather than converging on the correct time.

Anyone else seen this?

switch-core1#show ntp associations 

  address ref clock   st   when   poll reach  delay  offset   disp
+~128.4.1.1   .PPS.1431512   377  6.220 186.249  9.071
 ~127.127.1.1 .LOCL.   7  4 16   377  0.000   0.000  0.238
+~209.81.9.7  .GPS.1420512   377 76.374 189.382 13.435
+~69.36.224.15.GPS.1179512   377 80.046 188.355 17.814
-~64.183.55.54109.99.226.215   3421512   377 84.159 175.329  9.469
-~204.152.184.72  .GPS.1427512   377 74.559 185.210 12.907
+~216.218.254.202 .CDMA.   1400512   377 75.982 189.300 11.174
-~18.26.4.105 .CDMA.   1406512   377 36.859 173.421 14.156
*~209.51.161.238  .CDMA.   1436512   377  4.063 188.962 11.768
-~130.207.244.240 .GPS.1412512   377 28.666 184.413 10.079
+~198.60.22.240   .GPS.1349512   377 64.370 187.676 14.138
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

switch-core1#show ntp status
Clock is synchronized, stratum 2, reference is 209.51.161.238
nominal freq is 250. Hz, actual freq is 249. Hz, precision is 2**24
reference time is D2B44C27.24A08416 (12:08:55.143 EST Sun Jan 8 2012)
clock offset is 188.9620 msec, root delay is 4.06 msec
root dispersion is 215.24 msec, peer dispersion is 11.76 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.00180 s/s
system poll interval is 512, last update was 1219 sec ago.

switch-core1#show clock detail
12:29:18.402 EST Sun Jan 8 2012
Time source is NTP
Summer time starts 02:00:00 EST Sun Mar 11 2012
Summer time ends 02:00:00 EDT Sun Nov 4 2012

----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


___
cisco-nsp 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] NTP no longer slewing clock under 12.2(33)SXJ2 ???

[Matthew Huff]

Ugh.

Even though Cisco's documentation clearly states that ntp access groups are not 
configured by default and the default is all access, for security reasons they 
now default to no updates.

You would think this would through off an error in the syslog especially if 
"ntp logging" is configured.

So, setting up an acl and defining "ntp acess-group peer xxx" solves the issue.

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On
> Behalf Of Matthew Huff
> Sent: Sunday, January 08, 2012 12:30 PM
> To: 'cisco-nsp@puck.nether.net'
> Subject: [c-nsp] NTP no longer slewing clock under 12.2(33)SXJ2 ???
> 
> Upgraded this weekend from 12.2(33)SXI5 to SXJ2. Everything appears fine 
> accept NTP. I
> understand that SJ2 upgrades NTP from v3 to v4, but although it appears to be 
> working, the
> local clock never slews (corrects to NTP time). The offsets in ntp stay 
> stable, rather
> than converging on the correct time.
> 
> Anyone else seen this?
> 
> switch-core1#show ntp associations
> 
>   address ref clock   st   when   poll reach  delay  offset   disp
> +~128.4.1.1   .PPS.1431512   377  6.220 186.249  9.071
>  ~127.127.1.1 .LOCL.   7  4 16   377  0.000   0.000  0.238
> +~209.81.9.7  .GPS.1420512   377 76.374 189.382 13.435
> +~69.36.224.15.GPS.1179512   377 80.046 188.355 17.814
> -~64.183.55.54109.99.226.215   3421512   377 84.159 175.329  9.469
> -~204.152.184.72  .GPS.1427512   377 74.559 185.210 12.907
> +~216.218.254.202 .CDMA.   1400512   377 75.982 189.300 11.174
> -~18.26.4.105 .CDMA.   1406512   377 36.859 173.421 14.156
> *~209.51.161.238  .CDMA.   1436512   377  4.063 188.962 11.768
> -~130.207.244.240 .GPS.1412512   377 28.666 184.413 10.079
> +~198.60.22.240   .GPS.1349512   377 64.370 187.676 14.138
>  * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
> 
> switch-core1#show ntp status
> Clock is synchronized, stratum 2, reference is 209.51.161.238
> nominal freq is 250. Hz, actual freq is 249. Hz, precision is 2**24
> reference time is D2B44C27.24A08416 (12:08:55.143 EST Sun Jan 8 2012)
> clock offset is 188.9620 msec, root delay is 4.06 msec
> root dispersion is 215.24 msec, peer dispersion is 11.76 msec
> loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.00180 s/s
> system poll interval is 512, last update was 1219 sec ago.
> 
> switch-core1#show clock detail
> 12:29:18.402 EST Sun Jan 8 2012
> Time source is NTP
> Summer time starts 02:00:00 EST Sun Mar 11 2012
> Summer time ends 02:00:00 EDT Sun Nov 4 2012
> 
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff    | Fax:   914-460-4139
> 
> 
> ___
> cisco-nsp 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] Outbound drops on 6748

[Matthew Huff]

What is the type of data? Is it bursty? Is the data coming from an bigger pipe 
upstream?

You are likely hitting microbursts. The traffic levels you state are measured 
over an interval (30 seconds minimum probably). During peak activity you can 
easy overrun the buffers on the 6748 if your upstream data is coming from > 1gb 
and/or multicast. Since the 6748 has the deepest buffer of any linecards of the 
6500, you might have to look at an Arista or Cisco 30xx aggregation switch that 
can handle the microbursts.

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On
> Behalf Of Dean Smith
> Sent: Saturday, January 28, 2012 6:40 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Outbound drops on 6748
> 
> We have some web security appliances connected via 1Gb/s copper  to 6748
> Line cards in a Cat 6513 with Sup720. The appliance manufacturer assures us
> the appliances can cope with traffic well above 800Mb/s (The traffic is
> always equal in both directions)
> 
> 
> 
> We have previously seen traffic levels > 500Mb/s for a period without any
> issue. However more recently we have seen elevated response times to the
> appliances as the bandwidth approaches 400Mb/s. Investigations show we're
> seeing outbound drops now as we approach those speeds. We have qos enabled
> on the chassis but these particular ports have up till now been left at
> default queue setting. All the traffic is in queue 0 which currently only
> has 50% of the queues. We have now amended that to 90% but will have to wait
> until the next peak in traffic to judge the impact.
> 
> 
> 
> However I'm a little unsure why we previously saw no issue @ 500Mb/s but do
> now @ 400Mb/s. Nothing has changed on the appliances - however we did remove
> some other redundant 6148A cards to allow the switch to operate in full DFC
> mode. I don't have outbound errors/drops from before the cards were removed
> but response times certainly didn't show the increase.
> 
> 
> 
> Is it likely/possible that when operating in CFC mode the chassis/CFC was
> effectively buffering the packets better before hitting the switchport.but
> now they're arriving directly via DFC the individual port buffers are
> struggling ?. If that theory doesn't hold water..any other suggestions ?
> 
> 
> 
> What bi-directional throughput is reasonable to expect from a 6748 port ?
> 
> 
> 
> (If it makes any difference the chassis build has 1x original ACE, 3xFWSM,
> 2x6704 ,1x6708 and 2x6748+ 1 xSup720. All the line cards now have DFC 3B (or
> 3C for 6708) where appropriate)
> 
> 
> 
> Thanks
> 
> Dean
> 
> ___
> cisco-nsp 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] Outbound drops on 6748

[Matthew Huff]

Cisco Nexus 3000 Series switches. They came out to compete with Arista in the 
HFT world, but are useful anywhere latency and/or bursting is an issue:

http://www.cisco.com/en/US/products/ps11541/index.html


> -Original Message-
> From: Robert Hass [mailto:robh...@gmail.com]
> Sent: Saturday, January 28, 2012 12:39 PM
> To: cisco-nsp@puck.nether.net
> Cc: Matthew Huff
> Subject: Re: [c-nsp] Outbound drops on 6748
> 
> On Sat, Jan 28, 2012 at 4:45 PM, Matthew Huff  wrote:
> > You are likely hitting microbursts. The traffic levels you state are 
> > measured over an
> interval (30 seconds minimum probably). During peak activity you can easy 
> overrun the
> buffers on the 6748 if your upstream data is coming from > 1gb and/or 
> multicast. Since the
> 6748 has the deepest buffer of any linecards of the 6500, you might have to 
> look at an
> Arista or Cisco 30xx aggregation switch that can handle the microbursts.
> 
> Can you write which model of switch you mean writing 'Cisco 30xx
> aggregation switch' ?
> 
> Rob

___
cisco-nsp 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] Outbound drops on 6748

[Matthew Huff]

Different architecture. It's designed to handle bursty traffic. The output 
buffer overflow on any hardware can be caused by the output buffer filling up 
when a microburst overflows the queue faster than it can serialize the output 
on the wire. The end host speed is irrelevant. It can't get it out on the 
copper/fiber fast enough. The solutions are 1) Increase the speed of the output 
(1 -> 10GB, 10GB->40GB) 2) Use QOS to shape the traffic 3) Use bigger port 
buffers (in some cases a smaller shared buffer > bigger individual buffers)



 But I would definitely talk to your VAR/rep. Also look at Arista.


> -Original Message-
> From: Robert Hass [mailto:robh...@gmail.com]
> Sent: Saturday, January 28, 2012 12:52 PM
> To: Matthew Huff
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Outbound drops on 6748
> 
> On Sat, Jan 28, 2012 at 6:42 PM, Matthew Huff  wrote:
> > Cisco Nexus 3000 Series switches. They came out to compete with Arista in 
> > the HFT world,
> but are useful anywhere latency and/or bursting is an issue:
> >
> > http://www.cisco.com/en/US/products/ps11541/index.html
> 
> Nexus 3000 have 9MB buffers comparing to 1.3MB per port at
> WS-X6748-GE-TX. Will ultra-low-latency switching decreases need amount
> of buffers ? What about for using Nexus 3000 for long-distance
> connection (eg. 120KM). Do I need more buffers for 120KM Ethernet that
> for 10KM Ethernet ? (normal traffic , no storage)

___
cisco-nsp 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] Outbound drops on 6748

[Matthew Huff]

Is the ACE blade setup as a SLB on a stick, or is it doing bridging? Looks like 
the ACE is sending bursts faster than the 6748 blade can serialize the output 
on 1GB Ethernet. What type of traffic is the ACE load balancing? UDP voip/video 
or just http?



> -Original Message-
> From: Dean Smith [mailto:d...@eatworms.org.uk]
> Sent: Saturday, January 28, 2012 2:27 PM
> To: Matthew Huff; cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] Outbound drops on 6748
> 
> Its user web browsing (no multicast) and  the flow is :-
> 
> Clients -> ACE (load Balance)-> 6748 -> Appliance -> 6748 -> 6708 ->
> Upstream Router (10Gb/s ASR) -> Internet
> 
> So yes the traffic arriving on the appliance port is requests from the ACE
> and return traffic from a 10Gb/s ASR port
> 
> Dean
> 
> Original Message-
> From: Matthew Huff [mailto:mh...@ox.com]
> Sent: 28 January 2012 15:45
> To: 'Dean Smith'; 'cisco-nsp@puck.nether.net'
> Subject: RE: [c-nsp] Outbound drops on 6748
> 
> What is the type of data? Is it bursty? Is the data coming from an bigger
> pipe upstream?
> 
> You are likely hitting microbursts. The traffic levels you state are
> measured over an interval (30 seconds minimum probably). During peak
> activity you can easy overrun the buffers on the 6748 if your upstream data
> is coming from > 1gb and/or multicast. Since the 6748 has the deepest buffer
> of any linecards of the 6500, you might have to look at an Arista or Cisco
> 30xx aggregation switch that can handle the microbursts.
> 
> > -Original Message-
> > From: cisco-nsp-boun...@puck.nether.net
> > [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dean Smith
> > Sent: Saturday, January 28, 2012 6:40 AM
> > To: cisco-nsp@puck.nether.net
> > Subject: [c-nsp] Outbound drops on 6748
> >
> > We have some web security appliances connected via 1Gb/s copper  to
> > 6748 Line cards in a Cat 6513 with Sup720. The appliance manufacturer
> > assures us the appliances can cope with traffic well above 800Mb/s
> > (The traffic is always equal in both directions)
> >
> >
> >
> > We have previously seen traffic levels > 500Mb/s for a period without
> > any issue. However more recently we have seen elevated response times
> > to the appliances as the bandwidth approaches 400Mb/s. Investigations
> > show we're seeing outbound drops now as we approach those speeds. We
> > have qos enabled on the chassis but these particular ports have up
> > till now been left at default queue setting. All the traffic is in
> > queue 0 which currently only has 50% of the queues. We have now
> > amended that to 90% but will have to wait until the next peak in traffic
> to judge the impact.
> >
> >
> >
> > However I'm a little unsure why we previously saw no issue @ 500Mb/s
> > but do now @ 400Mb/s. Nothing has changed on the appliances - however
> > we did remove some other redundant 6148A cards to allow the switch to
> > operate in full DFC mode. I don't have outbound errors/drops from
> > before the cards were removed but response times certainly didn't show the
> increase.
> >
> >
> >
> > Is it likely/possible that when operating in CFC mode the chassis/CFC
> > was effectively buffering the packets better before hitting the
> > switchport.but now they're arriving directly via DFC the individual
> > port buffers are struggling ?. If that theory doesn't hold water..any
> other suggestions ?
> >
> >
> >
> > What bi-directional throughput is reasonable to expect from a 6748 port ?
> >
> >
> >
> > (If it makes any difference the chassis build has 1x original ACE,
> > 3xFWSM,
> > 2x6704 ,1x6708 and 2x6748+ 1 xSup720. All the line cards now have DFC
> > 3B (or 3C for 6708) where appropriate)
> >
> >
> >
> > Thanks
> >
> > Dean
> >
> > ___
> > cisco-nsp 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] Filtering traffic to destinations based off of DNSaddresses on an ASA?

[Matthew Huff]

Go into your recursive DNS server. Add a blank authoritative forward zone for 
google.com. Boom, it's dead to you.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Matthew Park
> Sent: Thursday, February 09, 2012 12:49 PM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Filtering traffic to destinations based off of
> DNSaddresses on an ASA?
> 
> Steve,
> Will this just block URLs or can it block all traffic to a domain?  The
> latter is what I'm looking for.
> Say block ALL traffic (make a domain "Dead to me") to google.com (no
> ping, nothing to mail.google.com, maps.google.com.. etc.)
> 
> Thanks for the quick reply!
> 
> --Matthew Park
> 
> -Original Message-
> From: Steve McCrory [mailto:smccr...@gcicom.net]
> Sent: Thursday, February 09, 2012 10:37 AM
> To: Matthew Park; cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] Filtering traffic to destinations based off of
> DNSaddresses on an ASA?
> 
> Matthew,
> 
> There is a URL filtering feature on the ASA which should be suffice for
> your requirements and does not require additional licenses. It is,
> however, limited to 100 URLs max.
> 
> A good guide can be found here:
> 
> https://supportforums.cisco.com/docs/DOC-1268
> 
> Below is a copy of the configuration we had to block access to facebook
> and youtube. I've listed the commands backwards from applying the
> service-policy to the interface. Hopefully you will be able to follow
> it but feel free to ask any questions you may have:
> 
> service-policy inside-policy interface inside !
> policy-map inside-policy
>  class httptraffic
>   inspect http http_inspection_policy
> !
> class-map httptraffic
>  match access-list inside_URL-block
> !
> access-list inside_URL-block extended permit tcp any any eq www access-
> list inside_URL-block extended permit tcp any any eq 8080 !
> policy-map type inspect http http_inspection_policy  parameters  class
> BlockDomainsClass
>   reset log
>  match request method connect
>   drop-connection log
> !
> class-map type inspect http match-all BlockDomainsClass  match request
> header host regex class DomainBlockList !
> class-map type regex match-any DomainBlockList  match regex domainlist1
> match regex domainlist2 !
> regex domainlist1 "\.facebook\.com"
> regex domainlist2 "\.youtube\.com"
> 
> 
> Couple of extra things you may be interested to know:
> 
> - You can add additional URLs to the filter by defining them with a
> regex and then referencing that regex in the class-map DomainBlockList
> - If you wanted to bypass this filter for a particular user, you can
> add a deny statement for their IP addresses to the beginning of the
> inside_URL-block ACL. This obviously requires that they have a static
> IP address.
> 
> Regards
> 
> Steven
> 
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Matthew Park
> Sent: 09 February 2012 16:29
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Filtering traffic to destinations based off of
> DNSaddresses on an ASA?
> 
> Hello all,
> Does anyone know of a good way to make a filter (access-list or
> whatever) on a Cisco ASA 5510 using a DNS address as the destination
> rather than a set of IP addresses?
> 
> For example, block any internal hosts from browsing to
> www.microsoft.com even though they have several webservers mapped to
> that DNS address, essentially "blacklisting" www.microsoft.com from the
> company.
> 
> I found Cisco's "Botnet Filter" that looks like it might work, but
> before I buy a license for it, I was curious as to anyone else's
> experiences with this filter or another method for accomplishing this?
> 
> Matthew Park
> Senior Systems Administrator
> Exelis Visual Information Solutions
> matthew.p...@exelisvis.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/
> 
> 
> This email has been swept by Webroot for viruses. Any files transmitted
> with it are confidential and intended solely for the email recipient.
> If you are not the intended recipient please delete this email
> immediately.
> Be aware that any disclosure, copying, distribut

Re: [c-nsp] Recommended IPv6 Resources

[Matthew Huff]

+1 on test lab. Lots of issues won't show up until actual use. 

For example, on a Cisco router by if you disable SLAAC by doing:

# ipv6 nd prefix default 300 180 no-autoconfig

Windows and Linux work fine. However, Solaris no longer gets a default route
from RA.

These are the gotcha's that you have to find out yourself.

----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Alan Buxey
> Sent: Tuesday, March 13, 2012 2:35 PM
> To: Steve McCrory
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Recommended IPv6 Resources
> 
> Hi,
> 
> > I'm dipping my toe into the world of IPv6 and I'm looking for
> > recommendations on resources - books, design guides, white papers,
> > tutorials etc.
> 
> there are a few IPv6 books out there - from the cisco offerings to
> third party and usual stalwart publishers. they should get you well
> versed on the subject.
> 
> yes, address space is bigger - but its the other things that will get
> you ..
> uses multicast to do everything, ICMPv6 is very very important for
> operation of hosts, SLAAC is the 'easy way' to get addresses from the
> router - your DHCP server may well not do DHCPv6 (and if it does, the
> clients probably dont! ;-) ) so how do you record/manage hosts? what
> about reverse records - you going to have 65k of entries for each /64
> that you deal with?
> 
> ACLs and switch behaviour - and what about end point protection -
> theres a good layer of ipv4 protection on particualr cisco access layer
> switches now - but the ipv6 is lacking.  likewise management - its a
> big big shame that cisco havent gone full-on with mgmt in IPv6 - theres
> no reason why the mgmt of your switches/APs etc cant all be in IPv6 and
> you have no IPv4 on those netsbut no..  latest IOS has some mgmt
> functions that work over IPv6.. not bad considering how long v6 has
> been around before.
> 
> my take home message? you can leanr a WHOLE LOT more about it by having
> a dev/test router, a couple of VLANs and home hosts (oh, be sure to
> tick the IPv6 box in VMware if you are virtualised with it ;-) )
> 
> alan
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Will the Cisco 2911 push GigE with NAT enabled ?

[Matthew Huff]

If you need the full 1GB for VPN, yes, the 5585-X with SSP10 will be the
best bet. It will probably be on the close order of 20k though.




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Chuck Church
> Sent: Monday, April 30, 2012 12:02 PM
> To: dcostell-cisco...@torzo.com; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Will the Cisco 2911 push GigE with NAT enabled ?
> 
> Since everything looks like Ethernet, why not consider an ASA 5585-X?
> This is probably the cheapest thing you'll find that can do a gigabit
> of VPN.
> 
> Chuck
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dave
> Sent: Monday, April 30, 2012 11:53 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Will the Cisco 2911 push GigE with NAT enabled ?
> 
> Thats what I was afraid someone was going to say :) I guess its time to
> start looking into the ASRs and see what my options are.
> 
> Thanks all! Really appreciate the help and information.
> 
> Dave
> 
> On 04/30/2012 08:50 AM, Aled Morris wrote:
> > On 30 April 2012 16:40, Dave  > <mailto:dcostell-cisco...@torzo.com>> wrote:
> >
> > Thank you all for the responses. I actually found the PDF shortly
> > after sending the e-mail. Sorry for wasting everyone's time.
> (Also a
> > part of me was hoping the PDF was wrong). So for an office router
> > that will do GigE + VPN + NAT anyone have any recommendations ?
> Is
> > it the ASR1k or bust now days ?
> >
> >
> > You're only going to get near gigabit performance with hardware
> > forwarding, so ASR is your best bet.  Switch platforms with Layer 3
> > (like the Catalyst 3560-X) aren't going to support the features you
> > need in their forwarding ASICs so you'll get performance worse than
> > the ISR2 you've already tried.
> >
> > Aled
> >
> 
> 
> ___
> cisco-nsp 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/


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Will the Cisco 2911 push GigE with NAT enabled ?

[Matthew Huff]

If you have metro-ethernet handoff and are running default routes, a Cisco
ASA-5525-X firewall will handle gig-e with NAT + VPN and is a lot cheaper
than a ASR.




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Dave
> Sent: Monday, April 30, 2012 11:53 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Will the Cisco 2911 push GigE with NAT enabled ?
> 
> Thats what I was afraid someone was going to say :) I guess its time to
> start looking into the ASRs and see what my options are.
> 
> Thanks all! Really appreciate the help and information.
> 
> Dave
> 
> On 04/30/2012 08:50 AM, Aled Morris wrote:
> > On 30 April 2012 16:40, Dave  > <mailto:dcostell-cisco...@torzo.com>> wrote:
> >
> > Thank you all for the responses. I actually found the PDF shortly
> > after sending the e-mail. Sorry for wasting everyone's time.
> (Also a
> > part of me was hoping the PDF was wrong). So for an office router
> > that will do GigE + VPN + NAT anyone have any recommendations ?
> Is
> > it the ASR1k or bust now days ?
> >
> >
> > You're only going to get near gigabit performance with hardware
> > forwarding, so ASR is your best bet.  Switch platforms with Layer 3
> > (like the Catalyst 3560-X) aren't going to support the features you
> > need in their forwarding ASICs so you'll get performance worse than
> > the ISR2 you've already tried.
> >
> > Aled
> >
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Tuning HSRP timers for BGP routers

[Matthew Huff]

We have a pair of Cisco 7204VXR with NPE-G2 running 15.1(4)M3. We are using
default timers for the HSRP interfaces, and we are seeing nightly HSRP state
changes. Not a lot, but 1-2 a night. This appears to only have started
recently.  We are looking at logs, but I assume it's due to BGP cpu
exhaustion. We don't see any L2 errors on the VLAN where the HSRP is
running, so I don't think it's a physical problem. 

 

What timers do people use for HSRP on BGP routers as a practice?  Obviously
we want the smallest timers that would be possible.

 



Matthew Huff | 1 Manhattanville Rd

Director of Operations   | Purchase, NY 10577

OTA Management LLC   | Phone: 914-460-4039

aim: matthewbhuff| Fax:   914-460-4139

 



smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Tuning HSRP timers for BGP routers

[Matthew Huff]

That's the thing, we aren't getting any BGP events, just HSRP ones. The
netflow analysis don't show a high bandwidth utilization, that's why I was
looking at the BGP re-calc causing the HSRP hellos to drop.



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: Mack McBride [mailto:mack.mcbr...@viawest.com]
> Sent: Wednesday, May 09, 2012 1:39 PM
> To: Matthew Huff; 'cisco-nsp@puck.nether.net'
> Subject: RE: Tuning HSRP timers for BGP routers
> 
> We use timers 2 and 6 on multiple sets of 6500s with a relatively large
> number of VLANs.
> The 6500 has a much less powerful CPU and seems to handle it ok.
> However, the 7200 is a software device so through traffic can have a
> major effect on CPU.
> It may be you have large high BW bursts during backups or something
> similar.
> You should probably do some correlation analysis before blaming the
> BGP.
> If you are getting that kind of BGP event on a nightly  basis you
> should probably talk to your provider.
> 
> LR Mack McBride
> Network Architect
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Matthew Huff
> Sent: Wednesday, May 09, 2012 7:46 AM
> To: 'cisco-nsp@puck.nether.net'
> Subject: [c-nsp] Tuning HSRP timers for BGP routers
> 
> We have a pair of Cisco 7204VXR with NPE-G2 running 15.1(4)M3. We are
> using default timers for the HSRP interfaces, and we are seeing nightly
> HSRP state changes. Not a lot, but 1-2 a night. This appears to only
> have started recently.  We are looking at logs, but I assume it's due
> to BGP cpu exhaustion. We don't see any L2 errors on the VLAN where the
> HSRP is running, so I don't think it's a physical problem.
> 
> 
> 
> What timers do people use for HSRP on BGP routers as a practice?
> Obviously we want the smallest timers that would be possible.
> 
> 
> 
> 
> 
> Matthew Huff | 1 Manhattanville Rd
> 
> Director of Operations   | Purchase, NY 10577
> 
> OTA Management LLC   | Phone: 914-460-4039
> 
> aim: matthewbhuff| Fax:   914-460-4139
> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Tuning HSRP timers for BGP routers

[Matthew Huff]

Average less than 10%, peek at 40%


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: Mack McBride [mailto:mack.mcbr...@viawest.com]
> Sent: Wednesday, May 09, 2012 2:24 PM
> To: Matthew Huff; 'cisco-nsp@puck.nether.net'
> Subject: RE: Tuning HSRP timers for BGP routers
> 
> What is your base CPU utilization?
> 
> Mack
> 
> -Original Message-
> From: Matthew Huff [mailto:mh...@ox.com]
> Sent: Wednesday, May 09, 2012 12:22 PM
> To: Mack McBride; 'cisco-nsp@puck.nether.net'
> Subject: RE: Tuning HSRP timers for BGP routers
> 
> That's the thing, we aren't getting any BGP events, just HSRP ones. The
> netflow analysis don't show a high bandwidth utilization, that's why I
> was looking at the BGP re-calc causing the HSRP hellos to drop.
> 
> 
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff    | Fax:   914-460-4139
> 
> 
> > -Original Message-
> > From: Mack McBride [mailto:mack.mcbr...@viawest.com]
> > Sent: Wednesday, May 09, 2012 1:39 PM
> > To: Matthew Huff; 'cisco-nsp@puck.nether.net'
> > Subject: RE: Tuning HSRP timers for BGP routers
> >
> > We use timers 2 and 6 on multiple sets of 6500s with a relatively
> > large number of VLANs.
> > The 6500 has a much less powerful CPU and seems to handle it ok.
> > However, the 7200 is a software device so through traffic can have a
> > major effect on CPU.
> > It may be you have large high BW bursts during backups or something
> > similar.
> > You should probably do some correlation analysis before blaming the
> > BGP.
> > If you are getting that kind of BGP event on a nightly  basis you
> > should probably talk to your provider.
> >
> > LR Mack McBride
> > Network Architect
> >
> > -Original Message-
> > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> > boun...@puck.nether.net] On Behalf Of Matthew Huff
> > Sent: Wednesday, May 09, 2012 7:46 AM
> > To: 'cisco-nsp@puck.nether.net'
> > Subject: [c-nsp] Tuning HSRP timers for BGP routers
> >
> > We have a pair of Cisco 7204VXR with NPE-G2 running 15.1(4)M3. We are
> > using default timers for the HSRP interfaces, and we are seeing
> > nightly HSRP state changes. Not a lot, but 1-2 a night. This appears
> > to only have started recently.  We are looking at logs, but I assume
> > it's due to BGP cpu exhaustion. We don't see any L2 errors on the
> VLAN
> > where the HSRP is running, so I don't think it's a physical problem.
> >
> >
> >
> > What timers do people use for HSRP on BGP routers as a practice?
> > Obviously we want the smallest timers that would be possible.
> >
> >
> >
> > 
> >
> > Matthew Huff | 1 Manhattanville Rd
> >
> > Director of Operations   | Purchase, NY 10577
> >
> > OTA Management LLC   | Phone: 914-460-4039
> >
> > aim: matthewbhuff| Fax:   914-460-4139
> >
> >



smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Lot of input errors on a NPE-G1 interface

[Matthew Huff]

Can you explain why it is a best practice to disable portfast connected to a
L3 device such as a router? Switch, obviously, but a router?



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Chris Gotstein
> Sent: Wednesday, May 23, 2012 2:15 PM
> To: Gert Doering
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface
> 
> It's probably not going to address the overrun issue, but from a best
> practices stand point, it should not be enabled on interfaces that
> connected to other connected devices, ie a router or switch.
> 
> On 5/23/2012 12:57 PM, Gert Doering wrote:
> > Hi,
> >
> > On Wed, May 23, 2012 at 10:18:45AM -0500, Chris Gotstein wrote:
> >> First suggestion i would make is removing spanning-tree portfast
> from
> >> the switch config.
> >
> > How exactly is that going to *help* with overruns?
> >
> > All it will do is annoy you after a link flap, and if you run rstp,
> it
> > will annoy half your network after a flap on that link.
> >
> > gert
> 
> --
>    
> Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
> http://uplogon.com | +1 906 774 4847 | ch...@uplogon.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/


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] IOS 15.0 ipv6-related weirdness (fails to fallback to ipv4)

[Matthew Huff]

> Is "ipv6 enable" configured on any interface at all?  What does a "show
> ipv6 interfaces" say?
> 
> With ipv6-unicast routing disabled, the router will still function as
> an
> ipv6 host if there are any IPv6 configured interfaces.  And google
> returns both an A and  record for google.com.

This was my first thought also, however, the post of:

c2800#sh ipv6 interface brief
 FastEthernet0/0[up/up]
 unassigned
 FastEthernet0/1[up/up]
 Unassigned

Appears to disprove that. I would think this is just a bug.



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Bruce Pinsky
> Sent: Monday, July 09, 2012 9:39 PM
> To: Michael Ulitskiy
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] IOS 15.0 ipv6-related weirdness (fails to fallback
> to ipv4)
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Michael Ulitskiy wrote:
> > Hello,
> >
> > I have a 2800 router with IOS 15.0(1)M7 with no ipv6 connectivity.
> > There are no ipv6 addresses configured on any interfaces and i've
> added:
> >
> > no ipv6 cef
> > no ipv6 unicast-routing
> >
> > commands to config.
> >
> > Nonetheless when I try to ping google the following happens:
> >
> > c2800#ping google.com
> > Translating "google.com"...domain server (167.206.112.138) [OK]
> >
> > Type escape sequence to abort.
> > Sending 5, 100-byte ICMP Echos to 2607:F8B0:4006:801::1004, timeout
> is 2 seconds:
> >
> > % No valid source address for destination Success rate is 0 percent
> > (0/1)
> >
> > c2800#sh hosts
> > Default domain is aceinnovative.com
> > Name/address lookup uses domain service Name servers are
> > 167.206.112.138, 167.206.7.4
> >
> > Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
> >temp - temporary, perm - permanent
> >NA - Not Applicable None - Not defined
> >
> > Host  Port  Flags  Age Type   Address(es)
> > google.comNone  (temp, OK)  0  IPv6
> 2607:F8B0:4006:801::1004
> >
> > So when it sees  record it tries to use it (regardless ipv6
> > routing has been disabled), sees there're no valid ipv6 addresses to
> > use as source and fails, instead of trying to use alternative
> > ipv4 addresses. It's also very strange that only IPv6 address has
> been cached by resolver.
> > It looks like resolver discards any A record in the presence of .
> >
> > FYI:
> > c2800#sh ipv6 interface brief
> > FastEthernet0/0[up/up]
> > unassigned
> > FastEthernet0/1[up/up]
> > unassigned
> >
> > c2800#sh ipv6 route
> > IPv6 Routing Table - default - 1 entries
> > Codes: C - Connected, L - Local, S - Static, U - Per-user Static
> route
> >B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
> >I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS
> summary
> >D - EIGRP, EX - EIGRP external, ND - Neighbor Discovery
> >O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF
> ext 2
> >ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
> > L   FF00::/8 [0/0]
> >  via Null0, receive
> >
> > I wonder if this is a known issue, if there are any workarounds or if
> I'm missing something?
> 
> 
> - --
> =
> bep
> 
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk/7h8oACgkQE1XcgMgrtybrxgCgkjn1okrSrVdjNdxya7upf1Sj
> lfoAoN8ql0aXuchVf1ThxsHcJzL2cxRo
> =5EFq
> -END 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/


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Third-Party support providers for 650x switches ???

[Matthew Huff]

We have 4 x 6509 switches, each with 2 x Sup720 cards. In November, they non-E 
chassis go EOSL. At this time we can't justify
upgrading them to the E chassis. Are there any providers that provide past EOSL 
support that anyone would recommend?


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139



smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Third-Party support providers for 650x switches ???

[Matthew Huff]

Unfortunately, the entire support is tied to the chassis, so support for the 
line cards, sup engine, etc will become EOS without the
chassis under support.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: Nick Hilliard [mailto:n...@foobar.org]
> Sent: Wednesday, July 11, 2012 9:21 AM
> To: Matthew Huff
> Cc: 'cisco-nsp@puck.nether.net'
> Subject: Re: [c-nsp] Third-Party support providers for 650x switches ???
> 
> On 11/07/2012 13:43, Matthew Huff wrote:
> > We have 4 x 6509 switches, each with 2 x Sup720 cards. In November,
> > they non-E chassis go EOSL. At this time we can't justify upgrading them
> > to the E chassis. Are there any providers that provide past EOSL support
> > that anyone would recommend?
> 
> Just get a cold spare from ebay?  It's just the chassis that's going EoS,
> and they're pretty cheap.
> 
> Nick


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Third-Party support providers for 650x switches ???

[Matthew Huff]

I agree. Replacing the chassis and getting official Cisco support would be my 
1st, 2nd and 3rd choice. Unfortunately, as cheap as
the E-Chassis might appear, four of them are too expensive given the current 
business challenges. Failing that, getting 3rd party
support is about my only other choice. The other consideration is that in the 
next 18-24 months there is a strong chance we would be
downsizing our datacenter footprint, and investing new capital in the large 
chassis is not something I think would be accepted right
now. 


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Justin
> M. Streiner
> Sent: Wednesday, July 11, 2012 11:08 AM
> To: 'cisco-nsp@puck.nether.net'
> Subject: Re: [c-nsp] Third-Party support providers for 650x switches ???
> 
> Matthew Huff wrote:
> 
> > Unfortunately, the entire support is tied to the chassis, so support for
> > the line cards, sup engine, etc will become EOS without the chassis
> > under support.
> 
> The question still remains as to what you are looking for a third party to
> do for you in this situation.  If vendor support is important to you, it
> might be worth getting an E chassis (not that expensive) and taking the
> outage to replace the chassis.  It just sounds like you're at risk of
> painting yourself into a corner by not doing that.
> 
> jms


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Third-Party support providers for 650x switches ???

[Matthew Huff]

Yeah. I'm very aware of that, and not happy about it. However, at least our 
needs are stable, the hardware is mature, and we are
currently running a recent release for the 6509.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-460-4139


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick
> Hilliard
> Sent: Wednesday, July 11, 2012 11:30 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Third-Party support providers for 650x switches ???
> 
> On 11/07/2012 16:16, Matthew Huff wrote:
> > 3rd party support is about my only other choice
> 
> Bear in mind that if the chassis falls out of support, and consequently the
> sup card, then so does your entitlement to software upgrades on the sup.
> You may want to confirm whether your third party support provider can get
> you legitimate software upgrades on the sup.
> 
> 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/


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Multicast packets dropping at 6509

[Matthew Huff]

Couple of things:

1) What is the TTL set on the packets? If it is set to 1, it won't cross a L3 
boundry.
2) On the Layer 3 switches, what are the multicast settings on the L3 
interfaces (pim sparse, pim dense, etc...)


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: Monday, October 29, 2012 6:46 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Multicast packets dropping at 6509

On 10/29/2012 10:18 AM, Ambedkar wrote:
> Hi,
> I am facing a problem in multicast..
> The scenario is like this, 2 layer-2 switches(2950) and 1 Layer-1
> switch(cisco 6509).
> These three switches are connected in series, L2-L3-L2. The problem is the
> packets are dropping at L3(Cisco 6509) switch using catOS. The multicast
> data is flowing in SAME vlan, means eventhough L3 is there in between, the
> data is flowing at layer-2 only.

How many bits/packets per second?

What linecards are you using?
___
cisco-nsp 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] Multicast packets dropping at 6509

[Matthew Huff]

Do you have pim or igmp snooping turned on?

Without a layer 3 "multicast router" configured, the 6509 will probably shunt 
the traffic. Setup a SVI interface on that vlan and enable pim dense mode. If 
you don't want multicast to pass the layer 3 boundry, you can setup a multicast 
boundry command on the vlan.


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ambedkar
Sent: Tuesday, October 30, 2012 2:23 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Multicast packets dropping at 6509

Hi,
Phil Mayers:
1. Data rate:4 kbps
2. Line cards: 1000BaseX supervisor WS-X6K-S2U-MSFC2
   1000BaseX Ethernet, WS-X6408A-GBIC
CatOS 8.3

Matthew:
1). As we are in the same VLAN, the data is not going to Lyaer-3
2). we are using, pim-dense

Null:
we are not observing such kind of behaviour. what we are observing is that
one of the switch is not creating any multicast table, when we  see in the
mac-address table multicast, there is no multicast table. when we replace
Cisco 6509 with cisco 2950 switch it is working fine.

   thank you

On Mon, Oct 29, 2012 at 11:08 PM, null zeroroute
wrote:

> I'm familiar with a bug CSCsk07136 that was found about 4 years ago that
> causes the multicast table to dump on a hybrid 6500 (catos) every time a
> port in the same VLAN went down/up.  Basically, all members of a group
> would lose access to the group every time a port in the same VLAN, on the
> same 6500, dropped.  I believe the problem was fixed in a later release,
> however we upgraded to native and no longer experienced the issue.  The
> only workaround was to statically assign hosts to the required groups.
>
>
> On Mon, Oct 29, 2012 at 6:18 AM, Ambedkar  wrote:
>
>> Hi,
>> I am facing a problem in multicast..
>> The scenario is like this, 2 layer-2 switches(2950) and 1 Layer-1
>> switch(cisco 6509).
>> These three switches are connected in series, L2-L3-L2. The problem is the
>> packets are dropping at L3(Cisco 6509) switch using catOS. The multicast
>> data is flowing in SAME vlan, means eventhough L3 is there in between, the
>> data is flowing at layer-2 only.
>>
>> Please help me...
>>
>> Thanks,
>> Ambi
>> ___
>> cisco-nsp 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] ace loadbalance prolem

[Matthew Huff]

Care to post a sanitized configuration? Is it a bridged vlan, or LB on a stick 
(Client NAT)?



-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Arne Larsen / Region 
Nordjylland
Sent: Friday, November 02, 2012 3:07 PM
To: 'cisco-nsp@puck.nether.net'
Subject: [c-nsp] ace loadbalance prolem

Hi all
Is there someone that has seen something similar.
I've got four ace load-balancer, two ace blade and two 4710.
Both setup's are connected to a 6500-vss environment, the two 4710 with an 
etherchannel, and the others located in the chassi.
We have an application that is used for medical journal purpose.
Some client tasks makes a lot off GET functions when browsing a patients 
journal.
The load balancing inject a delay of 2-3 sec, and that is on both setup's. 
Direct calls to the servers are much faster
I thought the is was a bandwidth problem, but no packet are being drop, or at 
least I can see.
If I check the resources of the sbl's they are not overloaded at all.
I've trying to figure out the past couple of days, what this is.
I'm pretty sure that it has to do with the amount of concurrent connections, 
but I just can't see any counters, counting any errors.
I've had a Cisco consultant to look at it, also with out any luck.
Is there someone that could guide me in the right direction.

/Arne


___
cisco-nsp 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] Split tunneling on government networks

[Matthew Huff]

I can't speak to the general aspect, but a close friend is a senior IT admin at 
the IRS. 

At a minimum to vpn:

1) Has to use a work provided laptop
2) Uses two factor authentication
3) Is completely locked down
4) No split tunneling

He doesn't have access to IRS files, so I expect this is general practice for 
all IRS employees and is mandated.

----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
> Herro91
> Sent: Tuesday, December 03, 2013 8:45 PM
> To: Cisco-nsp; Juniper-Nsp
> Subject: [c-nsp] Split tunneling on government networks
> 
> Hello,
> 
> I am doing some research regarding whether government agencies generally
> are for or against enabling split tunnels for their teleworkers?
> 
> There are many pros and cons to both approaches, but trying to get a feel
> from the community.
> 
> 
> Thanks!
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

[c-nsp] Weird Transceiver failure after upgraded to 6509-E chassis

[Matthew Huff]

Yesterday we upgraded two of our 6509 chassis to 6509-E. Other than the tedious 
nature of removing/replacing the line cards, everything went well. The 
configuration was set for complete diagnostics, and everything came up with no 
errors reported. However, one transceiver on one switch, and two on another are 
down/down. The diagnostics show no errors nor do the interfaces report any 
problems. They are all configured as layer 3 devices, with no strange features 
enabled. Other transceivers on the same module work fine, and other modules of 
the same type do as well.

Switch1 (6509-E, sup720-3B, module X6704-10GE)
--
Xenpack-10Gbase-LX4 down/down
Xenpack-10Gbase-LX4 down/down

Switch2 (6509-E, sup720-3B, module X6708-10GE)
--
X2-10GBase-ER down/down


Config:

interface TenGigabitEthernet7/3
 ip address x.x.x.x 255.255.255.252
 ip pim sparse-dense-mode
 ipv6 address x:x:x:x::x/127
 ipv6 enable
 ipv6 eigrp x

Things I have tried:

1) Reseating the transceivers
2) Reseating the modules
3) Power cycling the modules
4) Tried OS versions  12.2(33).SXJ2, 12.2(33).SXJ6, 15.1(2)SY1
5) Replaced patch cables
6) The X2-10GBase-ER transceiver connects to an extension from a meet-me room. 
I swapped pairs to try to see if that resolved anything

Nothing worked.

The two switches haven't been reset in over a year, and probably haven't been 
power-cycled in 3-4 years. It's possible that they just failed due to that, 
being moved, etc... But, once is happenstance, twice is circumstance, three 
times is enemy action. I don't like the coincidence of three failing.

I've got an ER optic on order (I don't have any spares), but I'm going to swap 
out the LX4 optics today. 

Has anyone run into this ever before with no error message or any indication of 
the problem? They interfaces show the optics, the ER DOM shows low receive 
levels (varies between -28 and -37), but just won't come up. 




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039


___
cisco-nsp 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] Weird Transceiver failure after upgraded to 6509-E chassis

[Matthew Huff]

Well, at least it means that it's a distinct possibility that the 3 
transceivers just died and it's not some other sort of issue. I'm having the 
wiring tested in the morning to rule that out as well.

From: Mike Hale [mailto:eyeronic.des...@gmail.com]
Sent: Sunday, December 15, 2013 12:03 PM
To: Matthew Huff
Cc: cisco-nsp NSP
Subject: Re: [c-nsp] Weird Transceiver failure after upgraded to 6509-E chassis


I've had plenty sfps fail on me after years of use during a swap.  Our last 
move involved just around 100 sfps of various types, and we ended up with about 
4 dead or wonky ones.  Granted, they were all third party copper gig sfps so 
the quality probably wasnt that great...

On Dec 15, 2013 8:54 AM, "Matthew Huff" mailto:mh...@ox.com>> 
wrote:
Yesterday we upgraded two of our 6509 chassis to 6509-E. Other than the tedious 
nature of removing/replacing the line cards, everything went well. The 
configuration was set for complete diagnostics, and everything came up with no 
errors reported. However, one transceiver on one switch, and two on another are 
down/down. The diagnostics show no errors nor do the interfaces report any 
problems. They are all configured as layer 3 devices, with no strange features 
enabled. Other transceivers on the same module work fine, and other modules of 
the same type do as well.

Switch1 (6509-E, sup720-3B, module X6704-10GE)
--
Xenpack-10Gbase-LX4 down/down
Xenpack-10Gbase-LX4 down/down

Switch2 (6509-E, sup720-3B, module X6708-10GE)
--
X2-10GBase-ER down/down


Config:

interface TenGigabitEthernet7/3
 ip address x.x.x.x 255.255.255.252
 ip pim sparse-dense-mode
 ipv6 address x:x:x:x::x/127
 ipv6 enable
 ipv6 eigrp x

Things I have tried:

1) Reseating the transceivers
2) Reseating the modules
3) Power cycling the modules
4) Tried OS versions  12.2(33).SXJ2, 12.2(33).SXJ6, 15.1(2)SY1
5) Replaced patch cables
6) The X2-10GBase-ER transceiver connects to an extension from a meet-me room. 
I swapped pairs to try to see if that resolved anything

Nothing worked.

The two switches haven't been reset in over a year, and probably haven't been 
power-cycled in 3-4 years. It's possible that they just failed due to that, 
being moved, etc... But, once is happenstance, twice is circumstance, three 
times is enemy action. I don't like the coincidence of three failing.

I've got an ER optic on order (I don't have any spares), but I'm going to swap 
out the LX4 optics today.

Has anyone run into this ever before with no error message or any indication of 
the problem? They interfaces show the optics, the ER DOM shows low receive 
levels (varies between -28 and -37), but just won't come up.




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039


___
cisco-nsp mailing list  
cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7206VXR with NPE-G2 / 12.4(4)XD4

[Matthew Huff]

I have two 7204VXR with NPE-G2 running 15.2(4) S3 for some time. It's doing 
BGP, but no OSPF, but it's been very stable.


On Jan 27, 2014, at 7:57 PM, Mark Tees  wrote:

> Can anyone recommend a 15.x release for these devices? The device is only
> doing BGP + OSPF with a small amount of connected routes.
> 
> 
> On Tue, Jan 28, 2014 at 11:51 AM, Mark Tees  wrote:
> 
>> Point taken. Will arrange to do so.
>> 
>> Thank you.
>> 
>> 
>> On Tue, Jan 28, 2014 at 9:57 AM, Mark Tinka  wrote:
>> 
>>> On Monday, January 27, 2014 04:40:59 PM Mark Tees wrote:
>>> 
 Any pointers for investigating this would be appreciated.
 Can we still get support for those devices? I haven't
 asked our reseller yet.
>>> 
>>> This is very old code, and IIRC, 12.4XD is what launched the
>>> NPE-G2 module.
>>> 
>>> Move to SRE or 15S.
>>> 
>>> Mark.
>>> 
>> 
>> 
>> 
>> --
>> Regards,
>> 
>> Mark L. Tees
>> 
> 
> 
> 
> -- 
> Regards,
> 
> Mark L. Tees
> ___
> cisco-nsp 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] Any one ever worked on Cisco 6500 QOS specifically 6503 or 6524(help) needed

[Matthew Huff]

The 6500 series switch has unique, complex and restrictive hardware QOS 
compared to a software based router/switch.

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/qos.html



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
Swapnendu Mazumdar
Sent: Sunday, October 12, 2014 1:49 PM
To: Ahsan Rasheed
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Any one ever worked on Cisco 6500 QOS specifically 6503 or 
6524(help) needed

6748 is a switch based line card. It has limited qos features supported as
compared to a routed platform such as ISR router.
On 12 Oct 2014 10:45, "Ahsan Rasheed"  wrote:

> Hi All,
>
> I am having issue specifically doing QOS configuration on 6503 or 6524 or
> 6509 switches. I am unable to match any EF(voice) traffic for eompls(vlan
> based) on 6503 cisco switch. If i use any other router as 2811 or 2821 my
> QOS configuration works perfect but if i put 6503 as PE2 it does not work.i
> am using vlan based eompls.
>
> Below is the scenario & configuration which i am having issue.
>
>
> CE1(2821 router)(dot1Q)->PE1(2821 router)--->P(6524
> switch)>PE2(6503 switch)--->(dot1Q)(2821 switch)CE2.
>
> On CE1 i can match ip-precedence 5 traffic and mark that traffic to cos5 on
> outbound port.On PE1 i can match cos5 packet and mark with mpls exp top5 on
> inbound port, on outbound port i can match mpls exp 5.
>
> On PE2(6503) i am unable to match that mpls exp5 packet on inbound port.
> none of the configuration worked on 6500 series switches with mls qos, ,mls
> qos trust dscp,mls qos trust cos etc. Although i can match cos5 traffic on
> CE2 on inbound interface.i can not match mpls exp 5 traffic on 6503 and all
> i can see traffic as default-class on 6503 switch. I tried many things and
> many configurations on 6503 but nothing worked.If i put 2821 router as PE2
> instead of 6503 my qos configuration works. but why if i put 6503 my same
> qos configuration does not work?
>
> ---match means=classification or classify
>
> Can anyone tell me how qos works on 6500 series switches or where i am
> having issue in my scenario.
> i am using this ios on 6503: s72033-advipservicesk9_wan-mz.122-33.SXI3.bin.
>
> below r my questions for 6503 qos:
>
> 1.do i need to use some other map tables,am i  using correct map tables on
> 6503 as cos-dscp,dscp-cos,exp-dscp etc.
> 2.any other configuration of qos needed on 6503?
> 3.i am unable to match anything on outbound port of 6503.
> 4.on 6503 i am using sup720 and PFC3BXL.any specific configuration needed
> for PFC3bxl.
> 5. 6503 not allowing me to match qos-group on inbound interface, not
> allowing me to set cos5 on outbound interface. not allowing me to set cos5
> as an inbound interface.
>
>
> CE1(2821) config:
> 
> !
> class-map match-any EF
>  match ip precedence 5
> class-map match-any data
>  match ip precedence 3
> !
> !
> policy-map ip2mpls
>  class EF
>   set cos 5
>  class data
>   set cos 3
> !
> interface FastEthernet0/0
>  no ip address
>  duplex auto
>  speed auto
> !
> interface FastEthernet0/0.455
>  encapsulation dot1Q 455
>  ip address 172.16.15.1 255.255.255.252
>  service-policy output EF
> !
>
> PE1(2821) config:
> -
> -
> mls qos map cos-dscp 0 8 16 24 32 40 48 56
> !
> class-map match-all exp_3
>  match mpls experimental topmost 3
> class-map match-all mpls_exp
>  match mpls experimental topmost 5
> class-map match-any cos3
>  match cos  3
> class-map match-any LOO1
>  match cos  5
> !
> !
> policy-map EF
>  class LOO1
>   set mpls experimental imposition 5
>  class cos3
>   set mpls experimental imposition 3
> policy-map QOS_G_5
>  class mpls_exp
>   priority
>  class exp_3
>   bandwidth 500
> !
> interface Loopback0
>  ip address 3.3.3.3 255.255.255.255
> !
> interface FastEthernet0/0
>  ip address 192.168.23.2 255.255.255.0
>  ip ospf network point-to-point
>  duplex auto
>  speed auto
>  mpls ip
>  service-policy output QOS_G_5
> !
> interface FastEthernet0/1.455
>  encapsulation dot1Q 455
>  xconnect 5.5.5.5 455 encapsulation mpls
>  service-policy input EF
> !
> ---
> ---
> PE2(6503 qos):
> R1#show module
> Mod Ports Card Type  Model  Serial
> No.
> --- - -- --
> ---
>   14  CEF720 4 port 10-Gigabit Ethernet  WS-X6704-10GE
>  SAL09401U2L
>   2   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX
> SAL114247YN
>   3   16  16 port 1000mb GBIC ethernet   WS-X6416-GBIC
>  SAL0712AM69
>   4   24  CEF720 24 port 1000mb SFP  WS-X6724-SFP
> SAL10019J4N
>   52  Supervisor Engine 720 (Hot)WS-SUP720-3BXL
> SAD102805VM
>   62  Supervisor Engine 720 (Active) WS-SUP720-BASE
> SAD0846060F
>
> Mod  Sub-Module  Mo

Re: [c-nsp] Any one ever worked on Cisco 6500 QOS specifically 6503 or 6524(help) needed

[Matthew Huff]

You have “mls qos trust cos”, which would maintain the L2 COS parameter, but 
set the DSCP values to 0. 

You’ll either need to map COS to DSCP values or trust dscp values.




___
cisco-nsp 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] strange issue on mcast flow

[Matthew Huff]

What size is the link between the 6500 and the c3925? What line card do you 
have on the 6500 that is connected to the c3925? 



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of R LAS
Sent: Wednesday, November 12, 2014 8:16 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] strange issue on mcast flow

Hi,
I've tricky problem:

Net scenario
Multicast Provider --- link 1Gbs --- c6500 --- c3925 (NAT/ACL)  --- 1Gbs link 
--  customer

When my multicast provider have some spike I see a lot of input errors/overrun 
on C3925 and customer experience loss of mcast flow.

Then I tried to move the link directly in an interface of C3925 (doing NAT and 
ACL) bypassing C6500 and do not see anymore input errors/overrun

New Scenario
Multicast Provider --- link 1Gbs --- c3925 (NAT/ACL) --- --- 1Gbs link --  
customer

Any idea why this could happens ?

Greetings 
___
cisco-nsp 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] Enabling multicast routing on 3750G platform

[Matthew Huff]

Use igmp-join if you want the router itself to be a member of the multicast 
group. You don't need it if you are routing multicast through the router. It's 
rarely used and only for very specific circumstances, for example if a servers 
fails if there isn't at least one client joining, etc...

 

----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo
Sent: Thursday, January 29, 2015 9:00 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform

Problem solved!

You guys were right about VLC and its TTL.  Turns out there's a bug in the
program where changing the TTL in the GUI doesn't affect streaming for some
reason.  I added a ttl=30 to the string and the stream started flowing to
the secondary port.  I even changed things back to vlans and it routed
perfectly fine.

I have a question about one comment that was made regarding the igmp-join
command.  In all the documentation I've read, it says to put that command
on the interfaces that plan on receiving the stream(s).  Some comments
suggested removing it or not needing it and with my own testing it clearly
works fine even without this command.  Why is that?

This is the final show ip mroute:

Switch#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
   L - Local, P - Pruned, R - RP-bit set, F - Register flag,
   T - SPT-bit set, J - Join SPT, M - MSDP created entry,
   X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
   U - URD, I - Received Source Specific Host Report,
   Z - Multicast Tunnel, z - MDT-data group sender,
   Y - Joined MDT-data group, y - Sending to MDT-data group
   V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 02:45:34/00:02:34, RP 3.3.3.3, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
Vlan100, Forward/Sparse, 00:00:38/00:02:34
Vlan200, Forward/Sparse, 02:42:59/00:02:32

(*, 239.0.0.1), 02:45:35/stopped, RP 3.3.3.3, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
Vlan200, Forward/Sparse, 02:42:15/00:02:33

(1.1.1.1, 239.0.0.1), 00:00:40/00:02:58, flags: JT
  Incoming interface: Vlan100, RPF nbr 0.0.0.0
  Outgoing interface list:
Vlan200, Forward/Sparse, 00:00:40/00:02:33

(*, 224.0.1.40), 02:45:35/00:02:28, RP 3.3.3.3, flags: SJCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
Loopback0, Forward/Sparse, 02:45:36/00:02:27

Switch#


Thanks again for the tips everyone!

Jose

On Thu, Jan 29, 2015 at 7:23 AM, Adam Vitkovsky  wrote:

> Hi Lobo,
>
> Ok so the SW is indeed a DR on port GigabitEthernet1/0/1 and it's
> obviously receiving some stream in which case it should create an (s,g)
> state and send a register msg to the RP and RP should update its group
> cache (all should be done internally since the DR=RP).
> However none of this is happening most likely because the switch doesn't
> like something about the stream (destination mac address, ttl, som security
> feature,..).
> Can you do: debug ip pim
> -to see if it shows why the switch ignores the incoming stream.
> -or some other techniques to see why the incoming multicast frames are
> being dropped silently.
>
>
> adam
> > -Original Message-
> > From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> > Lobo
> > Sent: 29 January 2015 00:57
> > To: cisco-nsp@puck.nether.net
> > Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform
> >
> > I've moved the configuration on the switch so that the ports are routed
> now
> > instead of using vlans but still no go.
> >
> > Here is the output from a show ip mroute:
> >
> > Switch#sh ip mroute
> > IP Multicast Routing Table
> > Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
> Connected,
> > L - Local, P - Pruned, R - RP-bit set, F - Register flag,
> > T - SPT-bit set, J - Join SPT, M - MSDP created entry,
> > X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
> > U - URD, I - Received Source Specific Host Report,
> > Z - Multicast Tunnel, z - MDT-data group sender,
> > Y - Joined MDT-data group, y - Sending to MDT-data group
> > V - RD & Vector, v - Vector
> > Outgoing interface flags: H - Hardware switched, A - Assert winner
> > Timers: Uptime/Expires
> > Inter

[c-nsp] Cisco console port to USB

[Matthew Huff]

Since Newer PC laptops and all Mac Laptops no longer have a serial port, what 
are people using to connect to Cisco console ports from laptops? Does someone 
make a direct USB to Cisco console port (RJ45) or do people buy a serial to usb 
cable and use the stock cisco cable?


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669


___
cisco-nsp 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] OT: NTP windows servers

[Matthew Huff]

Actually, until recently, most Cisco ntp implementations resolved at 
configuration time and only stored the ip addresses. Even some recent code has 
issues like ntp coming up before DNS client so it fails with names rather than 
ip addresses.



> On Mar 26, 2015, at 5:46 PM, Gert Doering  wrote:
> 
> Hi,
> 
>> On Thu, Mar 26, 2015 at 11:20:19AM -0400, Chuck Church wrote:
>> What was the TTL of the DNS entry?  I'm assuming windows DNS respects TTLs
>> and re-polls when it expires?
> 
> NTP implementations all tend to "resolve at start, and never again".
> 
> Cisco does it that way, standard unix ntpd does, ...
> 
> gert
> 
> -- 
> USENET is *not* the non-clickable part of WWW!
>   //www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
> ___
> cisco-nsp 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] One Cat6k/Sup2T is software switching, its identical partner is not

[Matthew Huff]

Haven't followed this thread too carefully, so I apologize if I duplicated 
anyone's suggestion:

Have you checked for: 

1) Are these systems setup for NHRP (hsrp, glbp, vrrp)? If so, is the box that 
is having the issue the active node?
2) Are you running PIM? Is this box the DR?
3) Have you checked to see if there is traffic headed to the box, rather than 
through it that is causing the issue?

----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Sander 
Steffann
Sent: Monday, April 20, 2015 9:44 AM
To: Jeroen van Ingen
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] One Cat6k/Sup2T is software switching, its identical 
partner is not

Hi,

> On 04/19/2015 06:08 AM, Mack McBride wrote:
>> Are all of the acls the same on both boxes?
>> It almost sounds like one box had a tcam explosion due to differing ACLs.
> 
> Yes, ACLs are 100% identical, I've paid extra attention to that when I 
> vimdiff'd the configs.

Are you using the LI (Lawful Intercept) features on those boxes? LI makes the 
TCAM for ACLs explode, possibly multiple times if it thinks ACLs are not 
identical between ports. This is likely to happen when the ACL changes.

Cheers,
Sander

___
cisco-nsp 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] One Cat6k/Sup2T is software switching, its identical partner is not

[Matthew Huff]

Traffic destined to the switch rather than through the switch is generally 
software switched. Too much software switched traffic causing CPU issues could 
cause other traffic not to be installed in the ASIC causing a cascade failure.

Also, since you are running HSRP, what do you have your "mac-address-table 
aging-time" set to on both boxes? You might be running into asymmetrical 
traffic flows causing unicast flooding. Depending on your traffic levels, this 
could cause major issue. The recommended setting is around 14400, which is not 
the default. Google for either the command or 6500 unicast flooding for details.

During a maintenance window, I probably would suggest doing a complete power 
off, reseat the cards, and see if that makes any difference. I know of a few 
ASIC bugs that have been resolved over the years that are only fixed with 
either a linecard reset or a complete powerdown. The multicast ASIC bug we ran 
into on route topology changes was finally fixed in 12.2(33)SXI14 or later. 
Make sure you are running the latest linecard firmware release as well (at 
least 12.2(18r)S1)

----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669

-Original Message-
From: Jeroen van Ingen [mailto:jer...@zijndomein.nl] 
Sent: Monday, April 20, 2015 11:16 AM
To: Matthew Huff
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] One Cat6k/Sup2T is software switching, its identical 
partner is not

Hi,

> Haven't followed this thread too carefully, so I apologize if I
> duplicated anyone's suggestion:
>
> Have you checked for:
>
> 1) Are these systems setup for NHRP (hsrp, glbp, vrrp)? If so, is
> the box that is having the issue the active node?

Running HSRP, but doesn't make a difference which of the two routers is 
active. The second router is currently active for all interfaces and groups.

> 2) Are you running PIM? Is this box the DR?

Yes, running PIM-SM. This box is DR on some subinterfaces and not on a 
few others, but changing DR priority doesn't seem to make a difference.

> 3) Have you checked to see if there is traffic headed to the box,
> rather than through it that is causing the issue?

I don't see how it could be related to any traffic coming into the 
interfaces, because the interfaces are programmed to handle certain 
features in software even when they are not receiving any traffic.


Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands

___
cisco-nsp 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 for TAC

[Matthew Huff]

Yep. Same thing happened to me this week. Having an issue with IEEE 1588 PTP 
over LACP.  Tech is going on vacation



> On Apr 30, 2015, at 7:29 AM, Alexandr Gurbo  wrote:
> 
> 
> You are in black list :))
> I noticed the same behaviour when you're opened complicated case.
> 
> On Thu, 30 Apr 2015 06:08:18 -0400
> Eric Van Tol  wrote:
> 
>> 
>> I would love to work for Cisco because it seems that their TAC engineers 
>> only work about 6 days a year.  I swear that every time I open a case with 
>> them, I am told that same day that the engineer will be going on vacation 
>> the following day and won't be back for a week or two.  Is there some 
>> special queue that my phone number is tied to that assigns me engineers with 
>> one foot out the door?
>> 
>> 
>> Does anyone else have this problem?  It's frustrating because I either have 
>> to wait until the engineer comes back from vacation for my problem to get 
>> worked on more, or I have to reassign it to someone else and explain the 
>> problem all over again, only to be told that they, too, will be going on 
>> vacation for two weeks.
>> 
>> -evt
>> ___
>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> -- 
> Alexandr Gurbo
> ___
> cisco-nsp 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] Cisco 7206VXR with NPE-G1

[Matthew Huff]

I would strongly recommend picking up a refurb NPE-G2. They should be cheap and 
available. We are running 15.2(4)S7 on ours with BGP/EIGRP. Very stable. You 
might also want to bump up your buffers on the 72xx. 

http://www.cisco.com/c/en/us/support/docs/routers/1-series-routers/15091-buffertuning.html







Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rich 
Davies
Sent: Tuesday, July 7, 2015 3:07 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Cisco 7206VXR with NPE-G1

Hello,

I wanted to reach out to the list to see what is the "current" and
"trusted" version of IOS for Cisco 7206VXR with NPE-G1?   I know this
hardware is EOL but we have a few still in use and wanted to get them up to
a newer version of IOS.   We are currently running 12.4(12b) which I think
we are hitting a bug with this IOS (bug ID CSCsz97091) in relation to input
errors and overruns when a "show run" is done.   I am seeing on our error
trend graphs every hour we take a burst of input errors, and they are timed
exactly to 1 hour interval.  It just so happens our RANCID implementation
is fetching configs every hour, so I have strong suspicion we are hitting
that bug on 12.4(12b).Was wondering what is the best IOS to run on this
NPE-G1?We do OSPF/BGP and minor static routing.   IPSEC would be nice
but not necessary in our situation.


Thanks for any IOS recommendations.


Rich
___
cisco-nsp 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] Cisco 7206VXR with NPE-G1

[Matthew Huff]

Basically, as I understand it, you can get input/output drops with a busy CPU 
on the 7200 not just with interface buffer overruns but generic queue buffers. 
The default values were set when T1s were the standard. The  article shows how 
to see which buffers are being overrun and how to adjust them.




> On Jul 7, 2015, at 4:27 PM, Gert Doering  wrote:
> 
> Hi,
> 
> On Tue, Jul 07, 2015 at 07:16:10PM +0000, Matthew Huff wrote:
>> I would strongly recommend picking up a refurb NPE-G2. They should be cheap 
>> and available. We are running 15.2(4)S7 on ours with BGP/EIGRP. Very stable. 
>> You might also want to bump up your buffers on the 72xx. 
>> 
>> http://www.cisco.com/c/en/us/support/docs/routers/1-series-routers/15091-buffertuning.html
> 
> Never understood buffer tuning on 7200s, tbh.  This feels like a relict
> from 7500 days, which had a totally different architecture...
> 
> gert
> -- 
> USENET is *not* the non-clickable part of WWW!
>   //www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

___
cisco-nsp 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 7206VXR with NPE-G1

[Matthew Huff]

Even with “ip options drop”, we are still seeing a fraction of packets being 
cpu switched (about 0.2% input and 1% output)  even though we are using CEF. 
Looks like they are mostly door-knob packets destined for the router itself 
(which is ACL’d) or some other annoyance. We tuned the buffers to solve the 
cosmetic counter issue with input/output errors. Since we increased the 
buffers, the counters have been clean, and the “show buffers” did show a 
shortage of buffers, so even on the 7200 with particles, perhaps the CLI uses 
the buffers construct regardless. Maybe it was just a placebo effect.

rtr-inet2#sh int gi0/1 stats
GigabitEthernet0/1
  Switching pathPkts In   Chars In   Pkts Out  Chars Out
   Processor2824573  6774030572958521  196941357
 Route cache  944226953  181329390  274701286 1591461341
   Total  947051526  858732447  277659807 1788402698

rtr-inet2#sh ip cef switching statistics

Path   Reason  Drop   Punt  Punt2Host
RP LES Packet destined for us 04377823  0
RP LES Total  04377823  0

RP PAS No route3923  0  0
RP PAS Packet destined for us 04933417  8
RP PAS No adjacency3476  0  0
RP PAS Incomplete adjacency 1204250  0  0
RP PAS TTL expired0  02709278
RP PAS Routed to Null0392389023  0  0
RP PAS Features   151528682  0  22614
RP PAS IP redirects   0  0  12358
RP PAS Neighbor resolution req   399660  0  0
RP PAS Total  54552901449334172744258

AllTotal  54552901493112402744258

On Jul 8, 2015, at 4:13 AM, Lukas Tribus 
mailto:luky...@hotmail.com>> wrote:

"on a 1". The 7200 uses particles, not buffers...

Also, its not relevant for CEF-switched traffic. So unless your configuration
requires fast-switching or process-switching, you don't need to worry about
buffer/particle tuning at all.


Lukas



___
cisco-nsp 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] Remote management console servers?

[Matthew Huff]

We use MRV serial consoles (MRV bought Xyplex).

http://www.mrv.com/products/console-servers

Been very happy with them.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott 
Granados
Sent: Tuesday, July 14, 2015 1:04 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Remote management console servers?

Hi,

Wondering what people are doing / best practices for remote management 
generally in datacenter environments.  We have several datacenter with a mix of 
Cisco, F5, Juniper and Palo Alto equipment in each.  All have a similar RJ45 
type console port and all are pretty much your garden variety devices.  Looking 
for a good solution to gain access when primary connectivity is disrupted.  I 
know back in the day we used 2610XM routers with the octopus cables but I’m 
wondering if there is better available now or is this still a good solution?  
Do you all use out of band loops for remote management like DS1 / DS3 circuits 
from diverse providers, dial in, what’s the standard for remote management?  Do 
you also have your management networks isolated on their own (could be the 
same) management network or do you do some sort of VPN / VRF deal for normal 
non emergency management connectivity?  Any thoughts on the subject would be 
most appreciated.  The last time I built one of these was with 2610XM routers 
in the pops and 7206 routers as aggregation points in each geographic region 
linked together with different T1s and multiplexed to the 7206 regional routers 
with backhaul loops to the NOC.  Seems like a bit of overkill for my 
application now but if this is still the best practice then it might be worth 
while.  Any pointers or other suggestions would be most appreciated.

Thank you
Scott

___
cisco-nsp 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] Remote management console servers?

[Matthew Huff]

If you are using a linux distribution, if you add the rpmforge repo, you can 
just use your package tools to install it. It's also on conserver.com for 
download.

I've been using conserver for close to 15 years with both Cisco and now 
MRV/Xyplex gears. Newer versions add the ability to connect to HP virtual 
serial port for console access to remote HP servers as well.



----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Howard 
Jones
Sent: Wednesday, July 15, 2015 4:10 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Remote management console servers?



On 15/07/15 09:00, Saku Ytti wrote:
> Now this is my favourite way to build OOB. Because with the Cisco CPE 
> I have comprehensive WAN options, which organization already knows how 
> to provision and support. All existing tooling/automation works. Our 
> WAN of choice was either own E1 or 4G, if we run 4G, we get dynamic IP 
> like you do, but that's not a problem for us, as we use DMVPN with 
> IPSEC, so we don't know or care about the WAN IP, we only experience 
> the tunneled static RFC1918 IP. And it's convenient single package and 
> PSU for assync, ethernet and WAN. Instead of assync server, WAN 
> router, modem and switch like worst case might be. 

Do you have a URL? The only things I can find run on a PC, not the 
router (conserver.com), which *would* be another vendor in the comms 
cabinet...

Thanks,

Howard
___
cisco-nsp 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] RSPAN over WAN/MAN

[Matthew Huff]

Unless I missed something, no one mentioned ERSPAN. If you platform supports 
it, then ERSPAN is much simpler. It encapsulates the packets so you can forward 
them over any L3.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669


> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Aaron
> Sent: Wednesday, February 3, 2016 10:13 AM
> To: 'Nick Hilliard' ; 'Steven Pfister'
> 
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] RSPAN over WAN/MAN
> 
> I do rspan over mpls pseudowire nicely... perhaps that's why it works is
> because p2p pw's don't learn mac's.
> 
> Aaron
> 
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Nick Hilliard
> Sent: Tuesday, February 2, 2016 2:38 PM
> To: Steven Pfister 
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] RSPAN over WAN/MAN
> 
> Steven Pfister wrote:
> > At first, I thought RSPAN. I've never done an RSPAN session, but I got
> > it working in a test setup at the central site. I tried the same thing
> > with the remote site, but can't get anything but broadcasts.
> 
> rspan works by transmitting traffic across vlans which have mac learning
> disabled, so therefore they unicast-flood all traffic across all ports
> in the vlan.  If you're transmitting this traffic across multiple
> switches, you need to make sure that the intermediate switches have mac
> learning disabled on the rspan vlan, or else that they're configured as
> rspan-specific vlans.
> 
> 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/
> 
> ___
> cisco-nsp 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] Cisco pptp server

[Matthew Huff]

First,

Why are you using PPTP and not either SSL VPN or IPSEC VPN? PPTP using ancient 
crypto and has been severely deprecated. Policy routing also has a lot of 
issues, including punting from CEF into CPU routing. Avoid it if you can. If 
you have higher metrics, why do you need it?




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669


> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Pavel Dimow
> Sent: Friday, February 26, 2016 11:02 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Cisco pptp server
> 
> Anyone? :)
> 
> On Thu, Feb 25, 2016 at 11:32 PM, Pavel Dimow 
> wrote:
> 
> > Hi,
> >
> > I have a very strange problem (well at least to me).
> >
> > I have a cisco 1921 which serves as PPTP server. On server I have two
> > different ISP's connections, ISP1 and ISP2. I have a default route to
> > ISP1 and default route to ISP2 with tracking and higher metric. I have
> > configured local policy routing so I always send PPTP packets to the
> > correct ISP.
> >
> > Now when I connect from client to PPTP server and in server address I
> > enter the ip address of interface where ISP1 is terminated everything
> > works. But when I connect from client to PPTP server and in server
> > address I enter the ip address of interface where ISP2 is terminated
> > the session is established but I can't do anything as I see only my
> > outgoing traffic and no incoming traffic via PPTP tunnel. The funny
> > part is that, when I enter the static route on PPTP server (the public
> > ip address of  PPTP client) everything works. Is this normal
> behaviour?
> >
> > If anyone can shed a light on this I would be very grateful ;)
> >
> >
> >
> >
> ___
> cisco-nsp 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] IPv6 HSRP Config

[Matthew Huff]

Uh...

Is it as simple as:

Interface vlan777
  ipv6 enable


Otherwise, the config looks spot on

Our config looks like:

interface Vlan110
 standby version 2
 standby 110 ipv6 FE80::1
 standby 110 timers 1 3
 standby 110 priority 110
 standby 110 preempt delay minimum 180
 standby 110 authentication 
 ipv6 address 2620:0:2810:16E::FFFE/64
 ipv6 enable
 ipv6 nd other-config-flag
 ipv6 nd router-preference High  
 ipv6 eigrp 14607
 ipv6 pim dr-priority 4294967295
 ipv6 dhcp relay destination 2620:0:2810:167::1
 ipv6 dhcp relay destination 2620:0:2810:167::2


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669


> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Dario Amaya
> Sent: Thursday, March 3, 2016 4:17 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] IPv6 HSRP Config
> 
> Hi list,
> 
> I have a couple of Cisco boxes:
> 
> 7604 / SUP720-3BXL - IOS 12.2(33)SRE
> 7204 / NPE-G1 - IOS 12.2(33)SRE
> 
> Firstly, can you advise if the config below is correct? Anything I am
> missing? Secondly, I cannot get the ipv6 group 2777 to be
> Active/Standby, both are in an Active state as you can see below, even
> though group 777 is working fine between the two (the vlan is trunked
> between them fine).. Any tips?
> 
> 7604:
> interface Vlan777
>  description Test
>  ip address 192.168.0.2 255.255.255.0
>  ipv6 address 2a00:200:777::2/48
>  standby version 2
>  standby 777 ip 192.168.0.1
>  standby 777 timers 1 3
>  standby 777 priority 150
>  standby 777 preempt
>  standby 777 authentication hsrp777
>  standby 2777 ipv6 FE80::1
>  standby 2777 timers 1 3
>  standby 2777 priority 150
>  standby 2777 preempt
>  standby 2777 authentication hsrp777
> end
> 
> #show standby Vlan777
> Vlan777 - Group 777 (version 2)
>   State is Active
> 2 state changes, last state change 19:35:15
>   Virtual IP address is 192.168.0.1
>   Active virtual MAC address is .0c9f.f309
> Local virtual MAC address is .0c9f.f309 (v2 default)
>   Hello time 1 sec, hold time 3 sec
> Next hello sent in 0.256 secs
>   Authentication text, string "hsrp777"
>   Preemption enabled
>   Active router is local
>   Standby router is 192.168.0.3, priority 50 (expires in 2.528 sec)
>   Priority 150 (configured 150)
>   Group name is "hsrp-Vl777-777" (default)
> Vlan777 - Group 2777 (version 2)
>   State is Active
> 2 state changes, last state change 19:08:22
>   Virtual IP address is FE80::1
>   Active virtual MAC address is 0005.73a0.0ad9
> Local virtual MAC address is 0005.73a0.0ad9 (v2 IPv6 default)
>   Hello time 1 sec, hold time 3 sec
> Next hello sent in 0.688 secs
>   Preemption enabled
>   Active router is local
>   Standby router is unknown
>   Priority 150 (configured 150)
>   Group name is "hsrp-Vl777-2777" (default)
> 
> 7204:
> GigabitEthernet0/1.777
>  description Test
>  encapsulation dot1Q 777
>  ip address 192.168.0.3 255.255.255.0
>  ipv6 address 2a00:200:777::3/48
>  standby version 2
>  standby 777 ip 192.168.0.1
>  standby 777 timers 1 3
>  standby 777 priority 150
>  standby 777 preempt
>  standby 777 authentication hsrp777
>  standby 2777 ipv6 FE80::1
>  standby 2777 timers 1 3
>  standby 2777 priority 150
>  standby 2777 preempt
>  standby 2777 authentication hsrp777
> end
> 
> show standby GigabitEthernet0/1.777
> GigabitEthernet0/1.777 - Group 777 (version 2)
>   State is Standby
> 3 state changes, last state change 18:57:35
>   Virtual IP address is 192.168.0.1
>   Active virtual MAC address is .0c9f.f309
> Local virtual MAC address is .0c9f.f309 (v2 default)
>   Hello time 1 sec, hold time 3 sec
> Next hello sent in 0.864 secs
>   Authentication text, string "hsrp777"
>   Preemption enabled
>   Active router is 192.168.0.2, priority 150 (expires in 2.944 sec)
> MAC address is 0026.cb3a.32c0
>   Standby router is local
>   Priority 50 (configured 50)
>   Group name is "hsrp-Gi0/1.777-777" (default)
> GigabitEthernet0/1.777 - Group 2777 (version 2)
>   State is Active
> 5 state changes, last state change 18:57:36
>   Virtual IP address is FE80::1
>   Active virtual MAC address is 0005.73a0.0ad9
> Local virtual MAC address is 0005.73a0.0ad9 (v2 IPv6 default)
>   Hello time 1 sec, hold time 3 sec
> Next hello sent in 0.480 secs
>   Authentication text, string "hsrp777"
>   Preemption enabled
>   Active router is local
>   Standby router is unknown
>   Priority 50 (c

Re: [c-nsp] ASA for IPv6

[Matthew Huff]

A couple of gotchas:

1) it doesn’t speak IPv6 EIGRP
2) It doesn’t support RDNSS  (RFC6106)
3) It’s DHCPv6 support doesn’t support providing DNS in DHCPv6 (although DHCPv6 
relaying works fine).



> On Aug 20, 2016, at 8:14 PM, chris  wrote:
> 
> 
> 
> 
> Pretty much as youve said.
>  Asa works fantasticly well with v6 ... including ospfv3 and v6 tunnelling 
> for.anyconnect.
>  
> 
> Sent from my Samsung device
> 
>  Original message 
> From: Michael Lee  
> Date: 20/08/2016  10:56 p.m.  (GMT+00:00) 
> To: cisco-nsp@puck.nether.net 
> Subject: [c-nsp] ASA for IPv6 
> 
> Hi,
> 
> Currently I have ASA 5580 with IPv4 NAT setup (public IP outside and RFC
> 1918 inside), I am considering to run IPv6 with Public IPv6 outside and
> Public IPv6 inside (routing mode)
> 
> Just wondering there is anything I would need to consider except CPU,
> memory and sessions)
> 
> Thanks,
> 
> ~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/

___
cisco-nsp 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] stange vlan 1 output

[Matthew Huff]

It should not cause any issues with the interface. “switchport nonegotiate” 
simply turns off “DTP” which is only used between cisco devices (mostly only 
switches) to neogogitate ISL/802.1Q trunking. Since you already have “mode 
trunk”, it shouldn’t be an issue.

On 10/7/16, 3:08 PM, "cisco-nsp on behalf of james list" 
 wrote:

Does it cause interface flapping?

Il 07/Ott/2016 21:02, "Nick Cutting"  ha scritto:

> You could add switchport nonnegotiate to force it to trunk. Kill the dtp
> But usually it is not needed
>
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> james list
> Sent: Friday, October 7, 2016 1:44 PM
> To: Pete Templin 
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] stange vlan 1 output
>
> There is firewall on the other side...
>
> Thanks all for the hints!
>
> Il 07/Ott/2016 19:41, "Pete Templin"  ha scritto:
>
> > DTP faulted on the port in question, causing it to not trunk even
> > though the mode is trunk.
> >
> > Any chance the adjacent device is a 4948? I've seen that platform do
> > this a lot where the 4948 participates in DTP enough for the other
> > side to drop to access but the 4948 forgets to match it.
> >
> >
> > On 10/7/2016 9:17 AM, james list wrote:
> >
> >> Hi experts,
> >>
> >> an issue on my c6500 sup720 12.2(33)SXI5.
> >>
> >>
> >>
> >> I have two equal trunk configuration ports:
> >>
> >>
> >>
> >> xxx#sh run int g8/45
> >>
> >> interface GigabitEthernet8/45
> >>
> >> switchport
> >>
> >>   switchport trunk encapsulation dot1q
> >>
> >>   switchport trunk allowed vlan 269
> >>
> >>   switchport mode trunk
> >>
> >>   logging event link-status
> >>
> >>   logging event trunk-status
> >>
> >>   load-interval 30
> >>
> >>   spanning-tree portfast edge trunk
> >>
> >>
> >>
> >> xxx#sh run int g9/27
> >>
> >> interface GigabitEthernet9/27
> >>
> >> switchport
> >>
> >>   switchport trunk encapsulation dot1q
> >>
> >>   switchport trunk allowed vlan 48
> >>
> >>   switchport mode trunk
> >>
> >>   logging event link-status
> >>
> >>   logging event trunk-status
> >>
> >>   load-interval 30
> >>
> >>   udld port
> >>
> >>   spanning-tree portfast edge trunk
> >>
> >>
> >>
> >> Do you see any reason why using "show interface status" I see vlan 1
> >> associated to g9/27 instead of trunk as for example of interface g8/45 
?
> >>
> >>
> >>
> >> xxx#sh interface status
> >>
> >> PortName  Status   Vlan
> >>   Duplex  Speed Type
> >>
> >> Gi8/45   connectedtrunk
> >> full   1000 1000BaseT
> >>
> >> Gi9/27    connected1
> >>full   1000 1000BaseT
> >>
> >>
> >>
> >> I see as well native vlan is not associated to gi9/27
> >>
> >>
> >>
> >> xxx#sh interfaces trunk
> >>
> >>
> >>
> >> PortMode Encapsulation  StatusNative
> vlan
> >>
> >> Te1/1   on   802.1q trunking  1
> >>
> >> Te1/2   on   802.1q trunking  1
> >>
> >> Te1/3   on   802.1q trunking  1
> >>
> >> Te1/4   on   802.1q trunking  1
> >>
> >> Te2/1   on   802.1q trunking  1
> >>
> >> Te2/2   on   802.1q trunking  1
> >>
> >> Te2/3   on   802.1q trunking  1
> >>
> >> Te3/4   on   802.1q trunking  1
> >>
> >> Te3/6   on   802.1q trunking  1
> >>
> >> Te3/7   on   802.1q trunking  1
> >>
> >> Te3/8   on   802.1q trunking  1
> >>
> >> Te7/1   on   802.1q trunking  1
> >>
> >> Te7/3   on   802.1q trunking  1
> >>
> >> Te7/9   on   802.1q trunking  1
> >>
> >> Te7/13  on   802.1q trunking  1
> >>
> >> Te7/14  on   802.1q trunking  1
> >>
> >> Gi8/3   on   802.1q trunking  1
> >>
> >> Gi8/9   on   802.1q trunking  1
> >>
> >> Gi8/13  on   802.1q trunking  1
> >>
> >> Gi8/29  on   8

Re: [c-nsp] huge amount of mcast traffic

[Matthew Huff]

Even with fabric enable blades in the c6500, you are going to get massive 
output buffer overflows. Market data has very uneven traffic patterns causing 
microburst effects. What sup-engines/blades are on the boxes? What type of 
multicast replication is being used (ingress/egress). QoS policies typically 
make matters worse. What type of interfaces are on the 6500?



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> james list
> Sent: Thursday, October 13, 2016 10:45 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] huge amount of mcast traffic
> 
> Dear experts,
> 
> I’ve a multicast financial market connected to my infrastructure, I’ve
> been
> informed that a new data multicast flow could reach up to 6 Gbs, so an
> huge
> amount of traffic needs to be replicated.
> 
> Market is connected to an ASR 1001, than to a C6807-XL and customers
> are
> connected to C6500.
> 
> ASR1001 is running 15.3(3)S1 and currently has a license for 2.5Gbs (to
> be
> upgrade)
> 
> C6807 has  Supervisor Engine 2T 10GE and IOS 15.1(2)SY4
> 
> C6500 has Supervisor Engine 720 10GE and IOS 12.2(33)SXI5
> 
> I’d like to understand in your experience if the mentioned
> infrastructure
> could suffer in performance or throughput or other, having to replicate
> the
> mentioned amount of traffic.
> 
> Thanks in advance for any feedback
> 
> Cheers
> 
> James
> ___
> cisco-nsp 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] huge amount of mcast traffic

[Matthew Huff]

The 6748 blades are going to be an issue with buffer overruns. Whether this 
will be a minor or major issue depends on the application that uses the 
multicast data.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff| Fax:   914-694-5669

From: james list [mailto:jameslis...@gmail.com]
Sent: Thursday, October 13, 2016 12:25 PM
To: Matthew Huff 
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] huge amount of mcast traffic


Hi



I’m not able to find the multicast replication mode on ASR..



On core routers:



C6807 has  Supervisor Engine 2T 10GE and IOS 15.1(2)SY4



xxx>sh module
Mod Ports Card Type  Model  Serial No.
 --- - -- -- ---
   1   20  DCEF2T 4 port 40GE / 16 port 10GE  WS-X6904-40G   xx
   2   20  DCEF2T 4 port 40GE / 16 port 10GE  WS-X6904-40G   xx
   35  Supervisor Engine 2T 10GE w/ CTS (Acti VS-SUP2T-10G   xx
   5   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6848-GE-TX xx



Mod  Sub-Module  Model  Serial   Hw Status



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



  1  Distributed Forwarding Card WS-F6K-DFC4-E  xxx  1.2Ok



  2  Distributed Forwarding Card WS-F6K-DFC4-E  xxx  1.2Ok



  3  Policy Feature Card 4   VS-F6K-PFC4xxx  3.0Ok



  3  CPU Daughterboard   VS-F6K-MSFC5   xxx  3.0Ok



  5  Distributed Forwarding Card WS-F6K-DFC4-A  xxx  1.4Ok



xxx#sh platform multicast routing replication



Current mode of replication is Egress



Configured mode of replication is Egress





Switch  SlotMulticast replication capability



 1   1  Egress



 1   2  Egress



 1   3  Egress



 1   5  Egress



 2   1  Egress



 2   2  Egress



 2   3  Egress



 2   5  Egress



 4   1  Ingress



 3   1  Ingress



 5   1  Ingress





C6500 has Supervisor Engine 720 10GE and IOS 12.2(33)SXI5





xxx>sh module



Mod Ports Card Type  Model  Serial No.



--- - -- -- ---



  1   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX xxx



  28  CEF720 8 port 10GE with DFCWS-X6708-10GE  xxx



  3   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX xxx



  4   48  CEF720 48 port 1000mb SFP  WS-X6748-SFP   xxx



  55  Supervisor Engine 720 10GE (Active)VS-S720-10Gxxx





Mod  Sub-Module  Model  Serial   Hw Status



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



  1  Distributed Forwarding Card WS-F6700-DFC3C xxx  1.6Ok



  2  Distributed Forwarding Card WS-F6700-DFC3C xxx 1.8Ok



  3  Distributed Forwarding Card WS-F6700-DFC3C xxx  1.6Ok



  4  Centralized Forwarding Card WS-F6700-CFC   xxx  4.2Ok



  5  Policy Feature Card 3   VS-F6K-PFC3C   xxx  1.1Ok



  5  MSFC3 Daughterboard VS-F6K-MSFC3   xxx  1.0Ok





xxx>show mls ip multicast capability



Current mode of replication is Egress



Configured replication mode is Auto





 Slot   Multicast replication capability



1Egress



2Egress



3Egress



4Egress



5Egress



Cheers

2016-10-13 17:59 GMT+02:00 Matthew Huff mailto:mh...@ox.com>>:
Even with fabric enable blades in the c6500, you are going to get massive 
output buffer overflows. Market data has very uneven traffic patterns causing 
microburst effects. What sup-engines/blades are on the boxes? What type of 
multicast replication is being used (ingress/egress). QoS policies typically 
make matters worse. What type of interfaces are on the 6500?


----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff| Fax:   914-694-5669

> -Original Message-
> From: cisco-nsp 
> [mailto:cisco-nsp-boun...@puck.nether.net<mailto:cisco-nsp-boun...@puck.nether.net>]
>  On Behalf Of
> james list
> Sent: Thursday, October 13, 2016 10:45 AM
> To: cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> Subject: [c-nsp] huge amount of mcast traffic
>
> Dear experts,
>
> I’ve a multicast financial marke

Re: [c-nsp] huge amount of mcast traffic

[Matthew Huff]

A sustained 6Gps on a 10GB pipe is hard to do already, but with multicast…. 
Typically that large of multicast is broken up into different multicast 
addresses can be split on multiple lines. The burst nature of the feed is going 
to be an issue. Will it work, yes. Will it work well, I doubt it.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff| Fax:   914-694-5669

From: james list [mailto:jameslis...@gmail.com]
Sent: Thursday, October 13, 2016 12:34 PM
To: Matthew Huff 
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] huge amount of mcast traffic

well we'll connect to 10 Gbs interface a traffic up to 6 Gbs, not on 6748 1 Gbs 
blades... no other issue you see ?

2016-10-13 18:31 GMT+02:00 Matthew Huff mailto:mh...@ox.com>>:
The 6748 blades are going to be an issue with buffer overruns. Whether this 
will be a minor or major issue depends on the application that uses the 
multicast data.

----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff| Fax:   914-694-5669

From: james list [mailto:jameslis...@gmail.com<mailto:jameslis...@gmail.com>]
Sent: Thursday, October 13, 2016 12:25 PM
To: Matthew Huff mailto:mh...@ox.com>>
Cc: cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
Subject: Re: [c-nsp] huge amount of mcast traffic


Hi



I’m not able to find the multicast replication mode on ASR..



On core routers:



C6807 has  Supervisor Engine 2T 10GE and IOS 15.1(2)SY4



xxx>sh module
Mod Ports Card Type  Model  Serial No.
 --- - -- -- ---
   1   20  DCEF2T 4 port 40GE / 16 port 10GE  WS-X6904-40G   xx
   2   20  DCEF2T 4 port 40GE / 16 port 10GE  WS-X6904-40G   xx
   35  Supervisor Engine 2T 10GE w/ CTS (Acti VS-SUP2T-10G   xx
   5   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6848-GE-TX xx



Mod  Sub-Module  Model  Serial   Hw Status



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



  1  Distributed Forwarding Card WS-F6K-DFC4-E  xxx  1.2Ok



  2  Distributed Forwarding Card WS-F6K-DFC4-E  xxx  1.2Ok



  3  Policy Feature Card 4   VS-F6K-PFC4xxx  3.0Ok



  3  CPU Daughterboard   VS-F6K-MSFC5   xxx  3.0Ok



  5  Distributed Forwarding Card WS-F6K-DFC4-A  xxx  1.4Ok



xxx#sh platform multicast routing replication



Current mode of replication is Egress



Configured mode of replication is Egress





Switch  SlotMulticast replication capability



 1   1  Egress



 1   2  Egress



 1   3  Egress



 1   5  Egress



 2   1  Egress



 2   2  Egress



 2   3  Egress



 2   5  Egress



 4   1  Ingress



 3   1  Ingress



 5   1  Ingress





C6500 has Supervisor Engine 720 10GE and IOS 12.2(33)SXI5





xxx>sh module



Mod Ports Card Type  Model  Serial No.



--- - -- -- ---



  1   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX xxx



  28  CEF720 8 port 10GE with DFCWS-X6708-10GE  xxx



  3   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX xxx



  4   48  CEF720 48 port 1000mb SFP  WS-X6748-SFP   xxx



  55  Supervisor Engine 720 10GE (Active)VS-S720-10Gxxx





Mod  Sub-Module  Model  Serial   Hw Status



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



  1  Distributed Forwarding Card WS-F6700-DFC3C xxx  1.6Ok



  2  Distributed Forwarding Card WS-F6700-DFC3C xxx 1.8Ok



  3  Distributed Forwarding Card WS-F6700-DFC3C xxx  1.6Ok



  4  Centralized Forwarding Card WS-F6700-CFC   xxx  4.2Ok



  5  Policy Feature Card 3   VS-F6K-PFC3C   xxx  1.1Ok



  5  MSFC3 Daughterboard VS-F6K-MSFC3   xxx  1.0Ok





xxx>show mls ip multicast capability



Current mode of replication is Egress



Configured replication mode is Auto





 Slot   Multicast replication capability



1Egress



2Egress



3Egress



4Egress



5Egress



Cheers

2016-10-13 17:59 GMT+02:00 Matthew Huff mailto:mh...@ox.com>>:
Even with fabr

Re: [c-nsp] looking to find the best cisco device

[Matthew Huff]

What about Nexus 3524 (Doesn't support ipv6 or sflow/netflow though), but does 
low-latency multicast and line rate with BGP and nat. If you need ipv6 look at 
some of the other nexus 30xx switches.




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> james list
> Sent: Monday, October 24, 2016 11:56 AM
> To: cisco-nsp NSP 
> Subject: [c-nsp] looking to find the best cisco device
> 
> Dear expert
> 
> I’m having a look to a scenario in order to find the best matching (and
> cheapest) device.
> 
> I need at least 3 x 10 Gbs interface (one in ingress and 2 in egress
> port-channel) and to support functionalities such as:
> 
> 
> - BGP
> 
> - Mcast PIM
> 
> - Mcast proxy register
> 
> - NAT
> 
> - 10 Gbs throughput line rate
> 
> 
> I’m looking an 1001-X but it seems support only 2 x 10 Gbs interface
> and
> 1001-HX is too much expensive.
> 
> 
> I was looking for different solutions (ie 3850) but not all the
> functionalities are supported (ie NAT).
> 
> 
> Any other idea can you suggest to me  ?
> 
> 
> Cheers
> 
> James
> ___
> cisco-nsp 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] looking to find the best cisco device

[Matthew Huff]

BTW, neither Nick's nor my suggestion will take full internet Ipv4 routes by 
default although the N9K will take a max of 896k routes fully configured. That 
doesn't leave much head room with Ipv4 + ipv6 routes taking ~650k now.



----
Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669


> -Original Message-
> From: Nick Cutting [mailto:ncutt...@edgetg.com]
> Sent: Monday, October 24, 2016 12:08 PM
> To: Matthew Huff ; james list ;
> cisco-nsp NSP 
> Subject: RE: [c-nsp] looking to find the best cisco device
> 
> ASR920 with licensing (apparently Netflow now supported) - 1/4 price of
> 1001-X
> Nexus 2nd gen 9k - 93180YC-EX Switch (s-flow support) - 1/3 price of
> 1001-X
> 
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Matthew Huff
> Sent: Monday, October 24, 2016 12:00 PM
> To: james list ; cisco-nsp NSP  n...@puck.nether.net>
> Subject: Re: [c-nsp] looking to find the best cisco device
> 
> What about Nexus 3524 (Doesn't support ipv6 or sflow/netflow though),
> but does low-latency multicast and line rate with BGP and nat. If you
> need ipv6 look at some of the other nexus 30xx switches.
> 
> 
> 
> 
> Matthew Huff | 1 Manhattanville Rd Director of
> Operations   | Purchase, NY 10577 OTA Management LLC   | Phone:
> 914-460-4039
> aim: matthewbhuff    | Fax:   914-694-5669
> 
> > -Original Message-
> > From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf
> > Of james list
> > Sent: Monday, October 24, 2016 11:56 AM
> > To: cisco-nsp NSP 
> > Subject: [c-nsp] looking to find the best cisco device
> >
> > Dear expert
> >
> > I’m having a look to a scenario in order to find the best matching
> > (and
> > cheapest) device.
> >
> > I need at least 3 x 10 Gbs interface (one in ingress and 2 in egress
> > port-channel) and to support functionalities such as:
> >
> >
> > - BGP
> >
> > - Mcast PIM
> >
> > - Mcast proxy register
> >
> > - NAT
> >
> > - 10 Gbs throughput line rate
> >
> >
> > I’m looking an 1001-X but it seems support only 2 x 10 Gbs interface
> > and 1001-HX is too much expensive.
> >
> >
> > I was looking for different solutions (ie 3850) but not all the
> > functionalities are supported (ie NAT).
> >
> >
> > Any other idea can you suggest to me  ?
> >
> >
> > Cheers
> >
> > James
> > ___
> > cisco-nsp 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] XOS-XE bgp default neighbor shutdown ???

[Matthew Huff]

Is there any way in IOS to set that all neighbors are by default shutdown until 
unshut?


Matthew Huff | 1 Manhattanville Rd 
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039


___
cisco-nsp 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] XOS-XE bgp default neighbor shutdown ???

[Matthew Huff]

Yes, the usual trick works...But not if you are in a hurry and forget or fat 
finger it :)

Just checking to see if something had been added that I missedI guess not :(


Matthew Huff | 1 Manhattanville Rd 
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039


-Original Message-
From: Gert Doering [mailto:g...@greenie.muc.de] 
Sent: Wednesday, September 26, 2018 1:45 PM
To: Matthew Huff 
Cc: Cisco NSP 
Subject: Re: [c-nsp] XOS-XE bgp default neighbor shutdown ???

Hi,

On Wed, Sep 26, 2018 at 04:44:55PM +, Matthew Huff wrote:
> Is there any way in IOS to set that all neighbors are by default shutdown 
> until unshut?

No, but the usual trick

  neigh 1.2.3.4 remote-as 5678 shutdown
  
  no neigh 1.2.3.4 shutdown

still works...

gert
--
"If was one thing all people took for granted, was conviction that if you  feed 
honest figures into a computer, honest figures come out. Never doubted  it 
myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.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] need help about switch cisco 4 9 4 8

[Matthew Huff]

config register 2142 means boot without config

in the rommon set config-register to "0x2102" and type "restart"

I'm not up on the 4948 management interface. 


Matthew Huff   | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
http://www.ox.com  | Phone: 914-460-4039
aim: matthewbhuff  | Fax:   914-460-4139



> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of chloe K
> Sent: Friday, February 20, 2009 2:08 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] need help about switch cisco 4 9 4 8
> 
> Hi
> 
>   I have problems in this switch 49 48
> 
>   1/ I can't setup the management interface.
>   I have another same modeul. I can see there is Fasthernet to set it
> up as management port.
> 
>   2/ After reload, I lost configuration. I did copy run start
>   It said that it can't find the Valid boot environment
> 
>config-register = 0x2142
>  Autobooting using BOOT variable specified file.
>Could not find a valid file in BOOT environment variable.
> rommon 1 >
> 
>   Please help
> 
> 
> 
> 
> -
> 
> 
> Yahoo! Canada Toolbar : Search from anywhere on the web
> and bookmark your favourite sites. Download it now!
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] need help about switch cisco 4 9 4 8

[Matthew Huff]

it may be that your flash is corrupt, is missing a ios image, etc...

My rommon memory is a bit fuzy atm, but you should be able to do a "dir
flash:" or "dir /all" and see what images are there. Then do a "boot
"


Matthew Huff   | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
http://www.ox.com  | Phone: 914-460-4039
aim: matthewbhuff  | Fax:   914-460-4139


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of chloe K
> Sent: Friday, February 20, 2009 4:00 PM
> To: Antonio Soares; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] need help about switch cisco 4 9 4 8
> 
> Thank you
> 
>   Now I change it to 0x2102
>   but it can't boot properly
> 
>   Can you help?
> 
>   Thank you
> 
>    The system will autoboot now 
> 
>  config-register = 0x2102
>  Autobooting using BOOT variable specified file.
>Could not find a valid file in BOOT environment variable.
>  BOOT variable can be set from IOS. To find currently set
>  Rom Monitor variables, please type 'set' command.
>For help on choosing a boot method,  type 'confreg' command.
> 
> Antonio Soares  wrote:
>   There are IOS releases that do not support the Management Interface.
> I know that 12.2.46SG supports it. So compare your 4948's and
> check the IOS releases.
> 
> You need a config-register=0x2101. With 0x2142, the switch won't load
> the startup config and needs a "boot system flash" statement
> to load the IOS image.
> 
> 
> Regards,
> 
> Antonio Soares, CCIE #18473 (R&S)
> amsoa...@netcabo.pt
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of chloe K
> Sent: sexta-feira, 20 de Fevereiro de 2009 19:08
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] need help about switch cisco 4 9 4 8
> 
> Hi
> 
> I have problems in this switch 49 48
> 
> 1/ I can't setup the management interface.
> I have another same modeul. I can see there is Fasthernet to set it up
> as management port.
> 
> 2/ After reload, I lost configuration. I did copy run start
> It said that it can't find the Valid boot environment
> 
> config-register = 0x2142
> Autobooting using BOOT variable specified file.
> Could not find a valid file in BOOT environment variable.
> rommon 1 >
> 
> Please help
> 
> 
> 
> 
> -
> 
> 
> Yahoo! Canada Toolbar : Search from anywhere on the web and bookmark
> your favourite sites. Download it now!
> 
> ___
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> 
> 
> 
> 
> -
> 
> 
> Yahoo! Canada Toolbar : Search from anywhere on the web
> and bookmark your favourite sites. Download it now!
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] PIX causing problems with TLS esmtp session

[Matthew Huff]

setup an access list with the hosts in it and port 25. use the capture
command to setup a capture on both interfaces. See which side is sending the
reset (the real host, or the firewall)


Matthew Huff   | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
http://www.ox.com  | Phone: 914-460-4039
aim: matthewbhuff  | Fax:   914-460-4139



> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Steven Pfister
> Sent: Friday, February 27, 2009 4:00 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] PIX causing problems with TLS esmtp session
> 
> There is one particular outside mail server we're having trouble
> sending to. Basically, our server (Groupwise) does an EHLO, and the
> other server offers STARTTLS. Our server sends a STARTTLS, sends a few
> bytes of encrypted data, and then the other server sends a RST.
> 
> If we try a test server outside the PIX, everything is fine.
> 
> I've looked at "no fixup protocol smtp 25" and "no inspect esmtp" and
> those already seem to be in place.
> 
> Could the pix be doing something with the certificate? Could esmtp
> inspection still be on?
> 
> Thanks!
> 
> Steve Pfister
> Technical Coordinator,
> The Office of Information Technology
> Dayton Public Schools
> 115 S. Ludlow St.
> Dayton, OH 45402
> 
> Office (937) 542-3149
> Cell (937) 673-6779
> Direct Connect: 137*131747*8
> Email spfis...@dps.k12.oh.us
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


smime.p7s
Description: S/MIME cryptographic signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/