Re: [c-nsp] Copying new IOS to 7600 resulting in IPC logs

[Frank Bulk]

Just because I like to choose secure TCP rather than insecure UDP.  I'm not
dogmatic about it, and it looks like it has its impacts.

Thanks for all the feedback.

Frank

-Original Message-
From: Chuck Church <chuckchu...@gmail.com> 
Sent: Wednesday, May 02, 2018 5:26 PM
To: 'James Bensley' <jwbens...@gmail.com>; 'Frank Bulk' <frnk...@iname.com>;
'Cisco-nsp List' <cisco-nsp@puck.nether.net>
Subject: RE: [c-nsp] Copying new IOS to 7600 resulting in IPC logs

Is there a reason you need to use SCP?  The crypto overhead is pretty
massive.  Granted it's more secure, but the CPU hit is bad on many older
devices.

Chuck

-Original Message-
From: cisco-nsp <cisco-nsp-boun...@puck.nether.net> On Behalf Of James
Bensley
Sent: Wednesday, May 02, 2018 10:41 AM
To: Frank Bulk <frnk...@iname.com>; Cisco-nsp List
<cisco-nsp@puck.nether.net>
Subject: Re: [c-nsp] Copying new IOS to 7600 resulting in IPC logs

On 2 May 2018 at 14:00, Frank Bulk <frnk...@iname.com> wrote:
> No, I do not have anything set.  What do you recommend for a value?
>
> Frank

Hi Frank,

The default value is 200 (ms). You need to have a play to find out whats
right for you. Some 7600s we have with many hundreds of BGP sessions that
have developed a bit of a flop sweat, I think they are set to 100ms which
seems to work OK.

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] Copying new IOS to 7600 resulting in IPC logs

[Frank Bulk]

No, I do not have anything set.  What do you recommend for a value?

Frank

-Original Message-
From: James Bensley  
Sent: Wednesday, May 02, 2018 4:46 AM
To: frnk...@iname.com; Cisco-nsp List 
Subject: Re: [c-nsp] Copying new IOS to 7600 resulting in IPC logs

Hi Frank,

What do you have set (if anything) for process-max-time?

I've not experienced your exact issue before but setting that (if not
set) might help - limiting the max CPU time without a context switch
to other pending processes.

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/

Re: [c-nsp] Equipment for a large-ish LAN event

[Frank Bulk]

This thread and the video might be interesting and relevant:
http://markmail.org/thread/crgxdtqsbegf72ah

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Laurent Dumont
Sent: Tuesday, December 08, 2015 2:08 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Equipment for a large-ish LAN event

Hi gents,

This email might seem a bit strange but bear with me. I am a member of a 
student club in Montreal named "Lan ETS". Every year, we organize on the 
biggest LAN event in North-America. We have an amazing partnership with 
Cisco where they allow us to request a fair amount of equipment so that 
we can create the best experience for our players.

This year, we are looking into some equipment that slightly out of our 
usual expertise. Usually, we target high-density stackable switches like 
a 3650/3750/3850 with 48 GigE and 4 SFP for our 10G core. We design our 
network around small "islands" of players all linked with each other 
through a 2x10G fiber network. Everyone is assigned a public address and 
we route everyone out through our core switch.

We were looking at either the Nexus 7004 chassis or the ASR 9004/9006 
chassis as the core "switch". We would then use 48xGigE and 1x24 SFP+ 
line cards. Our actual port requirements and somewhat flexible but we do 
need at least 4x10G Fiber ports. And at least 48 GigE ports for players 
or access switches.

I'm also open to any suggestion within Cisco portfolio. Our needs are 
pretty standard and nothing extraordinary but we would like to use this 
opportunity in order to try new equipment and technologies that are 
usually only seem within ISP and large networks.

I appreciate any input on the matter!

Thank you

-- 
Laurent Dumont
https://coldnorthadmin.com

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


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

[c-nsp] Monitoring queue drops/interface errors on 7600

[Frank Bulk]

Over the years there have been lots of posting about using "show" command
outputs to identify various interface and resource issues.
show interfaces gigabitEthernet 1/1 stat
show interfaces gigabitEthernet 1/1 | inc drop
show interfaces gigabitEthernet 1/1 counters errors
show buffers
show ibc
show platform buffers
show platform ibc
show platform eobc
show platform hardware capacity cpu
show platform hardware capacity eobc
show platform hardware capacity fabric
show platform hardware capacity forwarding
show platform hardware capacity interface
show platform hardware capacity netflow
show platform hardware capacity pfc
show platform hardware capacity qos

How many of these are available via SNMP?  Are there certain key numbers to
regularly (per 5 minutes, hourly, daily, weekly, etc) track?  Has someone
developed a script that runs on a regular basis that captures the CLI output
and analyzes it?

Frank

___
cisco-nsp 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] Monitoring PoE usage

[Frank Bulk]

I have a Cisco 2960-48PST-L (running (15.0(2)SE6)) where we recently hit
some power limits while upgrading some Aruba access points.

I'd like to monitor this switch (and also a 3500 PoE switch) for power usage
by building a NAGIOS plugin.

What I don't understand is why the CLI reports 362.6 watts in use while the
standard SNMP OID reports just 113 watts in use.

switch-sc5#show power inline | inc Av
Available:370.0(w)  Used:362.6(w)  Remaining:7.4(w)
switch-sc5#

root@nagios:~# snmpwalk -v 2c -c public 192.168.0.19 1.3.6.1.2.1.105.1.3.1.1
SNMPv2-SMI::mib-2.105.1.3.1.1.2.1 = Gauge32: 370
SNMPv2-SMI::mib-2.105.1.3.1.1.3.1 = INTEGER: 1
SNMPv2-SMI::mib-2.105.1.3.1.1.4.1 = Gauge32: 113
SNMPv2-SMI::mib-2.105.1.3.1.1.5.1 = INTEGER: 10
root@nagios:~#

[actually in use, on a per-port basis, adds up to ~113 watts]
root@nagios:~# snmpwalk -v 2c -c public 192.168.0.19
1.3.6.1.4.1.9.9.402.1.2.1.9
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.1 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.2 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.3 = Gauge32: 1787
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.4 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.5 = Gauge32: 1986
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.6 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.7 = Gauge32: 9337
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.8 = Gauge32: 1738
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.9 = Gauge32: 1735
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.10 = Gauge32: 1685
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.11 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.12 = Gauge32: 1685
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.13 = Gauge32: 1735
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.14 = Gauge32: 9320
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.15 = Gauge32: 9469
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.16 = Gauge32: 1437
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.17 = Gauge32: 9164
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.18 = Gauge32: 1733
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.19 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.20 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.21 = Gauge32: 1832
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.22 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.23 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.24 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.25 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.26 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.27 = Gauge32: 1734
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.28 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.29 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.30 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.31 = Gauge32: 9216
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.32 = Gauge32: 9216
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.33 = Gauge32: 1539
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.34 = Gauge32: 1638
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.35 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.36 = Gauge32: 1688
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.37 = Gauge32: 1886
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.38 = Gauge32: 1936
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.39 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.40 = Gauge32: 2929
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.41 = Gauge32: 1688
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.42 = Gauge32: 9433
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.43 = Gauge32: 9135
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.44 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.45 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.46 = Gauge32: 1688
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.47 = Gauge32: 1390
SNMPv2-SMI::enterprises.9.9.402.1.2.1.9.1.48 = Gauge32: 3673
root@nagios:~#

Is it that the CLI reports what's been allocated (either 7000 or 15400 mw)
and standard SNMP MIB reports what's actually in use?

Frank

___
cisco-nsp 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] cs.co on IPv6

[Frank Bulk]

FYI, this came back up at 12:54 pm U.S. Central.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Joshua Riesenweber
Sent: Tuesday, April 07, 2015 6:06 PM
To: Cisco Mailing list
Subject: [c-nsp] cs.co on IPv6

Hi,

Is anyone else having issues with http://cs.co on IPv6? I've been having
issues with it over the last little while. It seems to be working on v4, but
the  record still exists so it's causing some grief.

Cheers,Josh   
___
cisco-nsp 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] cheat sheet for new netflow?

[Frank Bulk]

RANCID has saved me through several Cisco firmware upgrades.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Charles Sprickman
Sent: Friday, April 10, 2015 11:09 AM
To: cisco-nsp@puck.nether.net NSP
Subject: [c-nsp] cheat sheet for new netflow?

I upgraded from 15.3 and 15.4 and saw my nfsen graphs flatline.

The upgrade helpfully removed all my netflow config, I suppose this is a
subtle hint that I'm behind in my knowledge of the new way of doing netflow.

Any good, quick cheat sheets for the transition?  I have something cobbled
together from CCO now, but my traffic levels look to be much lower in nfsen,
so I've obviously botched something.

Thanks
-- 
Charles Sprickman
NetEng/SysAdmin
Bway.net - New York's Best Internet www.bway.net
sp...@bway.net - 212.982.9800

___
cisco-nsp 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] Strange static MAC address entry is cisco 6500, anyone seen this?

[Frank Bulk]

Please open up a ticket with Cisco TAC so that this can be resolved.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Maarten Carels
Sent: Friday, January 16, 2015 3:34 AM
To: Jay Ford
Cc: Cisco Network Service Providers
Subject: Re: [c-nsp] Strange static MAC address entry is cisco 6500, anyone
seen this?

 On 15 Jan 2015, at 23:16 , Jay Ford jay-f...@uiowa.edu wrote:
 
 On Thu, 15 Jan 2015, Maarten Carels wrote:
 Investigation learned however that both the 6500 had static entries in
their MAC address tables for
 .0001.0002
 
 That's most likely the result of MLD snooping.  In this case static
means not dynamic (normal traffic-based MAC learning);  the switch put the
MAC entry there as part of the MLD snooping mechanism.
 
 In my experience, MLD snooping is broken in various older hardware  in
some software.  You could try disabling it instead of overriding it with
your own static MAC entry.
Static entries were my 'workaround'. You directed me to the real cause!
Disabling mld by setting:
no ipv6 mld snooping
removed that idiotic entry

Many thanks, you saved my day!

--maarten


___
cisco-nsp 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] Single core fibre question

[Frank Bulk]

Well, if you have two strands then you can use the standard SFPs, but if it
ends up being a single strand (for cost or other reason), then you'll need a
pair of SFPs, where one side will TX at 1310 and RX at 1490 (or 1550), and
the other side will TX at 1490 (or 1550) and RX at 1310, and then a spare
for each of those.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
CiscoNSP List
Sent: Saturday, November 29, 2014 10:01 PM
To: Jared Mauch
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Single core fibre question

Thanks Jared,
 
 Do you mean single strand of fiber? 

Yes - Single strand of fibre.

If so many people make and sell these bx/bi-di optics for both 1 and 10G.
Keep in mind there are two types up vs down and note the frequencies and
transmit power for these as there are 10/20/40 and 80km varieties out there.

 
 Of course make sure you have spares etc. 


Thanks - Thought so.so If we want to use the single strand/core, we will
need to get different SFP's at both ends.or(which Id prefer), get the
single converted to a double/dual-core x-connect, and use our standard
GLC-LH-SM SFP's?

Cheers.


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


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

Re: [c-nsp] Full Duplex

[Frank Bulk]

Another example: vendors who sell new equipment and highlight the unit's
phenomenal backplane...but none of their linecards can be configured in any
kind of way even use it.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mark
Tinka
Sent: Saturday, November 22, 2014 1:43 PM
To: cisco-nsp@puck.nether.net
Cc: M K
Subject: Re: [c-nsp] Full Duplex

On Saturday, November 22, 2014 02:16:23 AM Octavio Alvarez 
wrote:

 If I found a vendor that did that, I would run away from
 it for lying.

But they all do that.

What is more confusing is when vendors use half-duplex 
bandwidth to make a line card seem faster, e.g., a 30Gbps 
line card is sold as a 60Gbps if traffic flows in only one 
direction.

Mark.

___
cisco-nsp 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] LACP Trunk between Cisco VSS and Brocade MLX.

[Frank Bulk (iname.com)]

Harry,

Thanks for sharing, but I don't see Cisco 1/3/45 nor Cisco 1/3/46.

The Brocade side is showing disabled.  Have you tried disabling the Brocade 
3/19 and 3/20 and then re-enabling them one at a time?

Frank

-Original Message-
From: Harry Hambi - Atos [mailto:harry.ha...@bbc.co.uk] 
Sent: Friday, October 24, 2014 3:12 AM
To: 'Frank Bulk'
Cc: cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] LACP Trunk between Cisco VSS and Brocade MLX.

Hi Frank,
Please find attached information requested.
I've tried disabling lacp rate fast no joy. The working half of the trunk has 
this command enabled.

Cisco --1/3/45 --MLX 3/19non-working trunk
Cisco --1/3/46 --MLX 3/20


Cisco --2/3/45MLX 8/19 working trunk.
Cisco --2/3/46MLX 8/20



 

 
Rgds
Harry
 
Harry Hambi BEng(Hons)  MIET  Rsgb

-Original Message-
From: Frank Bulk [mailto:frnk...@iname.com] 
Sent: 24 October 2014 03:10
To: Harry Hambi - Atos
Cc: cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] LACP Trunk between Cisco VSS and Brocade MLX.

Thanks for sharing.  Could you please share the Cisco interface configs (Po345 
and each of the LAG members)?

Note that the Cisco is set to use fast while Brocade is set to use slow.  I 
would start with setting them the same.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Harry 
Hambi - Atos
Sent: Thursday, October 23, 2014 4:11 AM
To: james jones
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] LACP Trunk between Cisco VSS and Brocade MLX.

Hi James,
Yes good idea, please find attached configuration of Cisco  Brocade switches. 
Not much on the Brocade end see attached.
The ports with the error message LACP-BLOCKED are 3/19  3/20  on the Brocade 
end.


Rgds
Harry

Harry Hambi BEng(Hons)  MIET  Rsgb

From: james.v...@gmail.com [mailto:james.v...@gmail.com] On Behalf Of james 
jones
Sent: 22 October 2014 16:07
To: Harry Hambi - Atos
Cc: Nick Hilliard; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] LACP Trunk between Cisco VSS and Brocade MLX.

Config snippets would be useful.

On Wed, Oct 22, 2014 at 10:42 AM, Harry Hambi - Atos 
harry.ha...@bbc.co.ukmailto:harry.ha...@bbc.co.uk wrote:
Yes, I have checked config of working Trunk and no difference.


Rgds
Harry

Harry Hambi BEng(Hons)  MIET  Rsgb
-Original Message-
From: Nick Hilliard [mailto:n...@foobar.orgmailto:n...@foobar.org]
Sent: 22 October 2014 15:39
To: Harry Hambi - Atos; 
'cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net'
Subject: Re: [c-nsp] LACP Trunk between Cisco VSS and Brocade MLX.

On 22/10/2014 15:31, Harry Hambi - Atos wrote:
 Has anyone seen this error ?.

yes, it's normally caused by misconfiguration.  Both brocade netiron and
cisco IOS have mature 802.3ad/LACP implementations which interoperate nicely.

Nick


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




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

Re: [c-nsp] IPv6 BGP peers over SNMP

[Frank Bulk]

Do you happen to have the OIDs or MIB name for that info?

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick
Hilliard
Sent: Monday, September 22, 2014 4:22 PM
To: chiel; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IPv6 BGP peers over SNMP

On 22/09/2014 22:05, chiel wrote:
 2 years later. Wanted to deploy IPv6 on small parts of our network.
 Configured IPv6 neighbors and thought to start monitoring does sessions
 right away before moving on. After an hour Googling I find that in 2014
you
 still can't monitor your IPv6 peers with Cisco..Really?? Running 6500/7600

this is now supported on some varieties of IOS - 15.2(3)T and 15.2(4)S.
Also, XR has supported it for some years.

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] Tapping a PPPoVPDN and/or PPPoE subscriber session the ASR1000

[Frank Bulk]

You haven't mentioned what kind of budget you have, but the first and third
options are worth pursuing.  If you don't like what the LI feature set can
do on the ASR then it's really just the SPAN option, but you can use a
product from a vendor like Gigamon to slim the traffic volume down to your
data capture device.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Christian Schmit
Sent: Tuesday, September 09, 2014 8:46 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Tapping a PPPoVPDN and/or PPPoE subscriber session the
ASR1000

Hi,
  
 Legal authorities require that upon request we provide them with pcap 
files of a PPPoVPDN or PPPoE subscriber session we terminate on ASR1000 
devices.
  
 I need to limit the captured data to a specific subscriber/IP address.
  
 So far I looked into:
  
 - SPAN: on the ASR1000 SPAN does not seem to offer the possibility to 
apply an IP access list to the SPAN session
 - EPC: EPC can only collect data until the buffer is full which is by far 
to small if a session needs to be captured/monitored over weeks
 - LI feature: For using the lawful intercept (LI) feature of the ASR a 
mediation device is required which we do not have
  
 Any hints will be appreciated.
  
 thanks,
 Christian
  

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


___
cisco-nsp 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 corrupt DNS Cache in IOS

[Frank Bulk]

Don't use a router as a DNS resolver for customers.  Just don't.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Sascha E. Pollok
Sent: Friday, August 15, 2014 5:56 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Strange corrupt DNS Cache in IOS

Hello networking fellows!

We are trying to find the cause of a corrupt local DNS cache of a Cisco 
1803 running 15.1(4)M8 (also appeared on 12.4something - 15.1 ist just a 
desperate attempt of solving).

The router acts as a local DNS resolver for locally connected clients 
using ip dns server.

Every now and then it seems to break locally cached IPv4 A-RRs like this:

Router#show hosts
test.fqdn.fqdn   None  (temp, OK)  0   IP0.0.0.5  ---

This seems to happen for hosts that also have an  RR. To us it looks 
like it mixes  and A records as the IPv6 address for this host is 
[...]::5. This happens with other hosts too.

The host is sometimes first seen correctly with an IP and IPv6 entry 
in the cache but then changes to the broken IP RR while sometimes even 
keeping the correct IPv6 entry. It never happens to the IPv6 address.

Debugging debugging domain and debugging domain replies didnt give a 
clue.

Thanks for any hints!
Sascha
___
cisco-nsp 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] Strange corrupt DNS Cache in IOS

[Frank Bulk]

Right, but that's all non-Cisco.  My comments were intended to be
constrained to Cisco.  

Frank

-Original Message-
From: Jared Mauch [mailto:ja...@puck.nether.net] 
Sent: Friday, August 15, 2014 9:42 AM
To: Frank Bulk
Cc: Sascha E. Pollok; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Strange corrupt DNS Cache in IOS


 On Aug 15, 2014, at 10:34 AM, Frank Bulk frnk...@iname.com wrote:
 
 Don't use a router as a DNS resolver for customers.  Just don't.
 

Or if you are, use something that is properly designed for that function.
Check out the UBNT EdgeRouter stuff, cheap, vyatta (JunOS-like), and gives
you shell access to do other more advanced stuff.  Basically, you can't lose
at the unit cost, etc.

- Jared

___
cisco-nsp 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] Simple ACL not working 7600

[Frank Bulk]

We're getting data feeds that lately have been indicating that our
residential subscribers (about 12%) have open SSDP services on their routers
that allow for UDP reflection/amplification attacks.

I applied an ACL on our CMTS last week and that was very effective in
resolving that gap, but I've not had the same success for those subscribers
hanging off our 7609-S.

Using a very simple perl command provided by one of those data feeds I can
reproduce the attack:
perl -e 'print M-SEARCH *
HTTP/1.1\r\nHost:239.255.255.250:1900\r\nST:upnp:rootdevice\r\nMan:\ssdp:di
scover\\r\nMX:3\r\n'  /dev/udp/%IP_address%/1900
I use tcpdump on my host to see the packet exchange. 

I updated our existing ACL on one of the VLAN interfaces, but that didn't
work.  I then stripped it down to its barest components:
no access-list 128
access-list 128 deny   udp any any eq 1900 
access-list 128 permit ip any any
but that also didn't work. 

show access-list 128 doesn't show any matches.  

==
Mutual_7609#show access-lists 128
Extended IP access list 128
10 deny udp any any eq 1900
20 permit ip any any (349 matches)
Mutual_7609#
Mutual_7609#show tcam interface vlan 40 acl in ip

* Global Defaults not shared


Entries from Bank 0

deny udp any any eq 1900
permit   ip any any

Entries from Bank 1

Mutual_7609#
==

We have lots of TCAM resources.  Any idea why this isn't working? 

We're running IOS 15.2(4)S5.

Regards,

Frank Bulk





___
cisco-nsp 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] Simple ACL not working 7600

[Frank Bulk]

Unfortunately I'm not in the position to dictate which routers my
residential subscribers use on their broadband connection, and the quantity
of subs (over 1000) makes forcing them to remediate nigh impossible.  In
fact, there may not be vendor code to resolve it.

So while in general I agree with your position (which I've seen you argue
before), in practice, in this case, it's not cost effective to implement it.
For open NTP and SNMP we are contacting customers and having them resolve
it.  Almost 100% of the time that's a configuration issue, not a firmware
issue.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Roland Dobbins
Sent: Monday, August 04, 2014 8:09 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Simple ACL not working 7600


On Aug 5, 2014, at 7:17 AM, Frank Bulk frnk...@iname.com wrote:

 I applied an ACL on our CMTS last week and that was very effective in
resolving that gap

You do understand that this is going to randomly break stuff for your
subscribers, yes?

The best way to resolve this issue is to remediate the abusable CPE and/or
work with customers to get it remediated, if it isn't CPE you own/operate.

If you have to do this temporarily whilst remediation is taking place,
herding the abusable CPE together in terms of CIDR blocks and then doing
this only for the CIDR blocks in question will minimize the scope of any
collateral issues.

But blocking high ports towards your subscribers as a permanent blanket
policy causes problems and isn't the way to permanently resolve issues of
this nature.

--
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

   Equo ne credite, Teucri.

  -- Laocoön


___
cisco-nsp 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] Simple ACL not working 7600

[Frank Bulk (iname.com)]

We do have a good AUP that allows us to interact with customers on things
like this.  We don't have a captive portal, and even if we did, I wouldn't
block over 10% of our customers!  That would be a career changing move.  And
even more so if there's no reasonable mitigation other than buying a new
SOHO router.

Blocking port 1900 is clearly the cleaner mitigation approach.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Roland Dobbins
Sent: Monday, August 04, 2014 9:09 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Simple ACL not working 7600


On Aug 5, 2014, at 9:01 AM, Frank Bulk frnk...@iname.com wrote:

 Unfortunately I'm not in the position to dictate which routers my
residential subscribers use on their broadband connection, 

Is there anything in your AUP about customers running abusable services?  If
not, it might be time to consider revising it.

The AUP is the single most effective security tool a network operator has,
if it's both complete and enforced (the second most effective security tool
a network operator has is the RFP).

 and the quantity of subs (over 1000) makes forcing them to remediate nigh
impossible.

Do you have some sort of capture/quarantine system to force a subscriber
browsing the Web into a portal which can be used to display a page telling
them that they've an issue they must remediate?  If not, it might be a good
idea to look at implementing one.

--
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

   Equo ne credite, Teucri.

  -- Laocoön


___
cisco-nsp 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] 2 to 3% packet loss on single VLAN on LAG interface

[Frank Bulk]

Thanks for the feedback offline. 

I spent some time on this in the last 36 hours.  Unfortunately turning off
port mirroring didn't help.  What I did notice, when adding more test
points, was that I was seeing 9 to 12 Mbps of traffic egressing a port on
the Brocade that had nothing but a SOHO router.  When I sniffed it it was
clear that it was unicast flooding.  I checked and re-checked, but at ~5000
MAC addresses we weren't exhausting the Brocade's tables nor the 7609's.  I
adjust MAC and ARP aging times down to shorter values (so that the 7609
wouldn't even forward the traffic if the ARP table for that IP was empty),
but also no change.

What did reduce the packet loss of almost zero and the reduced the unicast
flooding to ~50 kbps was shutting down the LAG member on the 6704 that was
the busier of the two 6704's (it's busier because the card also handles most
of our incoming Internet traffic).  If I unshut the LAG member the unicast
flooding and packet loss resumed.

So is this a symptom of some resources on the 7600 or the on the 6704?
Should I put the 10G port that handles the Internet traffic LAG member on
the same ASIC?

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Frank Bulk
Sent: Wednesday, July 23, 2014 2:19 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 2 to 3% packet loss on single VLAN on LAG interface

Looking for some tribal knowledge from this group -- we have a Cisco 7609-S
running IOS 15.2(4)S5 with RSP720C's and DFC3C's on all our line cards.  We
have two WS-X6704-10GE cards that move around 7 Gbps (that's a total of in
and out) at peak times between their 7 active interfaces.  Some of those
Gbps are mirrored traffic.

What our customers are seeing and what we have confirmed is 2 to 3% ICMP
packet loss for traffic in a certain VLAN that flow in/out of the 10G
cross-card port channel facing a Brocade ICX6610 stack.  This is packet loss
pinging *through* the router, not ICMP traffic terminating hitting the
router.  

e.g. 
server--1G---Cisco7609==10G==VLAN A==Brocade---CPE  (packet loss)
server--1G---Cisco7609==10G==VLAN B==Brocade---CMTS (no packet loss)
server--1G---Cisco7609==1G===VLAN A==access-gear---CPE (no packet loss)
laptop==access gear==10G==VLAN A==Brocade---CPE (no packet loss)
laptop==access gear---CPE (no packet loss)

That VLAN has about 4500 to 5500 active MAC addresses.  We can ping an IP
address in that certain VLANs that flow in/out some other 1G port-channel on
a WS-X6748-GE-TX and there is no packet loss.  Some of other VLANs I've
tested that flow in/out of the 10G cross-card port channel also don't have
packet loss.

So what would cause (what appears to be) a certain VLAN to drop some traffic
when flowing across a 10G port-channel and not a 1G port-channel?  I know
the 6704 has some performance limitations -- how do I measure that on the
box?

Regards,

Frank Bulk

___
cisco-nsp 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] UDLD enabling port prematurely?

[Frank Bulk]

There also may be errdisable recovery times to say how long to wait before
trying to come out of the errdisable state.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Peter Rathlev
Sent: Thursday, July 17, 2014 4:38 AM
To: Victor Sudakov
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] UDLD enabling port prematurely?

On Thu, 2014-07-17 at 15:14 +0700, Victor Sudakov wrote:
 [...] I need some sort of point-to-point L2 link fault management
 between the switches.
  
 Is UDLD suitable for this purpose? I have experimented a bit with
 udld port aggressive and have found out the following strange
 thing.
 
 When the physical link goes down, UDLD detects this condition and
 shuts the switch interface down. However, after several minutes, the
 interface goes up again with %PM-4-ERR_RECOVER: Attempting to recover
 from udld err-disable state on Gi0/17. The interface is up even
 though Current bidirectional state: Unknown, and seems to be in the
 STP forwarding state.

This is because UDLD errdisable recovery has been enabled. You can
disable it with:

   no errdisable recovery cause udld

Problem is that you have to intervene manually to enable the interface
after service has been restored. But at least you will not have loops.

I'm not aware of a more elegant solution to your problem, but I'm
interested in hearing about one.

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

[c-nsp] 2 to 3% packet loss on single VLAN on LAG interface

[Frank Bulk]

Looking for some tribal knowledge from this group -- we have a Cisco 7609-S
running IOS 15.2(4)S5 with RSP720C's and DFC3C's on all our line cards.  We
have two WS-X6704-10GE cards that move around 7 Gbps (that's a total of in
and out) at peak times between their 7 active interfaces.  Some of those
Gbps are mirrored traffic.

What our customers are seeing and what we have confirmed is 2 to 3% ICMP
packet loss for traffic in a certain VLAN that flow in/out of the 10G
cross-card port channel facing a Brocade ICX6610 stack.  This is packet loss
pinging *through* the router, not ICMP traffic terminating hitting the
router.  

e.g. 
server--1G---Cisco7609==10G==VLAN A==Brocade---CPE  (packet loss)
server--1G---Cisco7609==10G==VLAN B==Brocade---CMTS (no packet loss)
server--1G---Cisco7609==1G===VLAN A==access-gear---CPE (no packet loss)
laptop==access gear==10G==VLAN A==Brocade---CPE (no packet loss)
laptop==access gear---CPE (no packet loss)

That VLAN has about 4500 to 5500 active MAC addresses.  We can ping an IP
address in that certain VLANs that flow in/out some other 1G port-channel on
a WS-X6748-GE-TX and there is no packet loss.  Some of other VLANs I've
tested that flow in/out of the 10G cross-card port channel also don't have
packet loss.

So what would cause (what appears to be) a certain VLAN to drop some traffic
when flowing across a 10G port-channel and not a 1G port-channel?  I know
the 6704 has some performance limitations -- how do I measure that on the
box?

Regards,

Frank Bulk

___
cisco-nsp 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] Netflow analysis tools?

[Frank Bulk (iname.com)]

Scott,

It looks like the Netflow monitoring of PRTG is only for 30 days -- if you want 
to try something that doesn't expire, but only has the last hour of 
information, look at SolarWinds' product: 
http://www.solarwinds.com/products/freetools/appflow-jflow-sflow-analyzer.aspx

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of David 
beckett
Sent: Monday, May 19, 2014 12:45 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Netflow analysis tools?

Hello Scott,

PRTG Network Monitor can present Netflow monitoring in pretty graphs, 
including usage over time, and top talkers. 

It is commercial / paid for, but I think you can test up to 10 sensors 
(monitored objects) without a license.  That means 10 Netflow instances if 
you pause or stop monitoring everything else.

HTH

Yours sincerely, Sincères salutations, Mit freundlichen Grüssen, Distinti 
saluti,

David BECKETT

Network Service Delivery 
Switzerland DACH IMT

IBM Suisse
IBM Banking Solutions Center 
Avenue de la Vallombreuse 100
CH - 1008 PRILLY Switzerland

Hotline / Piquet Téléphone : +41 (0) 58 333 68 23
Téléphone Direct : +41 (0) 58 333 24 07
Téléphone Mobile : +41 (0) 765 54 07 23
Fax: +41 (0) 21 683 0094
mailto: david.beck...@ch.ibm.com
http://www.ibm.ch




From:   Scott Granados sc...@granados-llc.net
To: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net
Date:   16.05.2014 16:17
Subject:[c-nsp] Netflow analysis tools?
Sent by:cisco-nsp cisco-nsp-boun...@puck.nether.net



Good morning,
 I’m starting to work with Net Flow data and am looking 
for both good background documentation to get more familiar and 
suggestions for an analyzer.  I already have data collection working so 
I’m looking for suggestions for something to turn that data in to 
something meaningful, preferably open source or paid with a trial period 
to evaluate.  Are there any tools that run on the Mac that anyone would 
suggest for processing the nfcapd files or something with a web front end 
I can install in a *nix environment.  Any general documentation or 
specific tool recommendations would be most welcome.

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/


___
cisco-nsp 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] C7200 and AAA Accounting

[Frank Bulk]

Trying adding something along these lines:
aaa accounting network radius-group-aaa start-stop group
radius-group

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Chris Knipe
Sent: Saturday, April 05, 2014 7:22 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] C7200 and AAA Accounting

Hi Guys,

I'm hoping that someone can assist in debugging something rather strange.  I
have a 7206 (NPE-G1) terminating PPPoEoE sessions.  AAA is working fine and
Authentication as well as Authorization happens as expected.  However, for
some reason, the 7200 refuses to send any Accounting information.  I'm sure
this must be something stupid and small that I am overlooking - hopefully a
fresh pair of eyes will spot what I'm failing to see! :-)

Version:
Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version
15.2(4)M4, RELEASE SOFTWARE (fc2)

Relevant configurations:
aaa new-model
aaa session-mib disconnect
aaa group server radius MYRADIUS
 server x.x.x.43 auth-port 1812 acct-port 1813
 ip radius source-interface Loopback0
 attribute nas-port format a
 load-balance method least-outstanding
 mac-delimiter colon
aaa authentication login MYRADIUS group radius local
aaa authentication ppp default group MYRADIUS
aaa authorization exec MYRADIUS group radius local 
aaa authorization network default group MYRADIUS 
aaa accounting send stop-record always
aaa accounting delay-start
aaa accounting session-duration ntp-adjusted
aaa accounting update newinfo periodic 30
aaa accounting network default start-stop group MYRADIUS
aaa nas port extended
aaa session-id common

radius-server attribute 44 extend-with-addr
radius-server attribute 6 mandatory
radius-server attribute 32 include-in-access-req 
radius-server attribute 32 include-in-accounting-req 
radius-server attribute nas-port format b
radius-server attribute 61 extended
radius-server attribute 31 mac format ietf upper-case
radius-server host x.x.x.43 auth-port 1812 acct-port 1813 key 7 a
radius-server retransmit 2
radius-server timeout 10
radius-server unique-ident 5
radius-server load-balance method least-outstanding

debug aaa accounting:
000279: Apr  5 12:12:09.718: AAA/ACCT/CLIENT(001A): recv 10bps
xmit 10bps
000280: Apr  5 12:12:09.718: AAA/ACCT/HC(001A): Register PPPoE/5B1C
64 bit counter support not configured
000281: Apr  5 12:12:09.718: AAA/ACCT/HC(001A): Update PPPoE/5B1C 
000282: Apr  5 12:12:09.718: AAA/ACCT/HC(001A): no HC PPPoE/5B1C 
000283: Apr  5 12:12:09.718: AAA/ACCT/EVENT/(001A): CALL START
000284: Apr  5 12:12:09.718: Getting session id for NET(001A) :
db=6AB5C8B8
000285: Apr  5 12:12:09.718: AAA/ACCT(): add node, session 215
000286: Apr  5 12:12:09.718: AAA/ACCT/NET(001A): add, count 1
000287: Apr  5 12:12:09.718: AAA/ACCT/NET(001A): Pick method list
'default'
000288: Apr  5 12:12:09.718: AAA/ACCT/SETMLIST(001A): Handle 0, mlist
6A148168, Name default
000289: Apr  5 12:12:09.718: AAA/ACCT/EVENT/(001A): ATTR REPLACE
000290: Apr  5 12:12:09.718: AAA/ACCT(001A): Accounting response status
= FAILURE
000291: Apr  5 12:12:09.718: AAA/ACCT(001A): Send NEWINFO accounting
notification to EM successfully
000292: Apr  5 12:12:09.718: AAA/ACCT/EVENT/(001A): ATTR REPLACE
000293: Apr  5 12:12:09.718: AAA/ACCT/EVENT/(001A): ATTR REPLACE
000294: Apr  5 12:12:09.838: Getting session id for NET(001A) :
db=6AB5C8B8
000295: Apr  5 12:12:10.842: Getting session id for NET(001A) :
db=6AB5C8B8
000296: Apr  5 12:12:10.850: AAA/ACCT/NET(001A): Pick method list
'default'
000297: Apr  5 12:12:10.850: AAA/ACCT/SETMLIST(001A): Handle 0, mlist
6A148168, Name default
000298: Apr  5 12:12:10.850: AAA/ACCT/EVENT/(001A): NET UP
000299: Apr  5 12:12:10.850: AAA/ACCT/CLIENT(001A): recv 10bps
xmit 10bps
000300: Apr  5 12:12:10.850: AAA/ACCT/HC(001A): Update PPPoE/5B1C 
000301: Apr  5 12:12:10.850: AAA/ACCT/HC(001A): no HC PPPoE/5B1C 
000302: Apr  5 12:12:10.862: AAA/ACCT/EVENT/(001A): IPCP_PASS
000303: Apr  5 12:12:10.862: AAA/ACCT/NET(001A): Queueing record is
START
000304: Apr  5 12:12:10.862: AAA/ACCT(001A): Accounting method=MYRADIUS
(RADIUS)
000305: Apr  5 12:12:10.862: AAA/ACCT/NET(001A): Suppressed record  
Accounting supressed and not sent.
000306: Apr  5 12:12:10.862: AAA/ACCT(001A): mlist_periodic is not set,
interval 0
000307: Apr  5 12:12:10.862: AAA/ACCT(001A): Resetting Periodic timer
600

Many thanks,
Chris.



___
cisco-nsp 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] Use NTP server for syncing but do not respond to NTP requests

[Frank Bulk]

It's not as good as an access-group, but I've applied ntp disable on each
Vlan interface that I don't want to participate in NTP.  It seems effective.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick
Hilliard
Sent: Saturday, March 22, 2014 11:11 AM
To: Andrew Clark; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Use NTP server for syncing but do not respond to NTP
requests

On 22/03/2014 15:31, Andrew Clark wrote:
 Take a look at NTP access-groups.  You can control access for each
 aspect (server, peer, etc).  Details here:

CSCuj66318: 15.2 ntp allows query with access-group configured

Affects all 15.2 through 15.4 before: 15.4(1.13)S, 15.3(3)S2.4 and
15.2(1)IC273.28, including if you've configured your box to handle ntp
service only in a different VRF.

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] NTP DDoS

[Frank Bulk]

Two weeks ago one of our neighbors had a (non-Cisco) CMTS with an NTP config
on the CMTS's management interface that resulted in a 120+ Mbps
reflection...

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Alan
Buxey
Sent: Tuesday, February 11, 2014 4:07 PM
To: sledge...@gmail.com; Richard Clayton; Cisco NSPs
Subject: Re: [c-nsp] NTP DDoS

Yep.  Had a system on one of our ranges that was involved in yesterday's
cloudfare ddos. It's not anymore and won't be anymore.  Open to all NTP
queries types from the world :/

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/


___
cisco-nsp 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] Looking for recommended IOS for 7600 RSP720CXL

[Frank Bulk]

We need to upgrade to an IOS release that supports DHCPv6 relay chaining
(i.e. there's already a relay in DHCPv6 request).  We're currently running
12.2(33)SRE2 and it's been very stable.

We have redundant RSP720-3C's, three WS-X6748 and two WS-X6704-10GE
linecards, all with DFCs.

I'm leaning towards 15.2(4)S4a -- anyone have reason to discourage us?  Any
upgrade surprises?

Regards,

Frank Bulk

___
cisco-nsp 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] Transparent WAN Encryption

[Frank Bulk]

I've been working with MACsec over the last two weeks as a cheaper way to
get some encryption in place over some lit paths.  In our case I also manage
the transport gear.

I had to change a frame disposition setting on our transport gear because,
by default, the Ethertype for the initial EAPOL exchange, 0x888E, was
filtered out.  MACsec content has a 0x88E5 Ethertype.  It still didn't work,
but our transport vendor identified the issue as a bug already fixed that in
a future newer release, and they were able to patch the problem.  

So if you run the traffic through transport gear that handles those two
Ethertypes, MACsec should run fine.

Regards,

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Benny Amorsen
Sent: Monday, February 03, 2014 5:31 PM
To: Ian Henderson
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Transparent WAN Encryption

Ian Henderson i...@ianh.net.au writes:

 What about MacSec? Works between 3560X/4500/4500X/Sup2T/etc for wire rate
L2 encryption.


http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/15.1/XE_330SG/conf
iguration/guide/swmacsec.html#wp1334072 says:

Does that actually work over WAN links that are not just plain optical
paths? I have been wondering if you can get MacSec to work over EoMPLS.

VPLS seems unlikely, as MacSec seems to be point-to-point.


/Benny


___
cisco-nsp 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] 7204VXR reboots

[Frank Bulk]

I don't believe there is a version of 12.2SR for the 7200's that supports
both DHCPv6-PD static route insertion AND IPv6 PBR.

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mark
Tinka
Sent: Saturday, June 08, 2013 5:27 AM
To: Gert Doering
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 7204VXR reboots

On Friday, June 07, 2013 10:30:38 PM Gert Doering wrote:

 Yeah, true.  But my experience with 12.2SR on 7200s has
 not been very good overall,...

What kinds of problems did you have?

I've been running it since 2010 (which was the only/best way 
to harmonize code between the NPE-G2/7201 and other NPE's 
for the 7200 platform), and apart from various bugs that 
were very prevalent in SRC, it's been rock solid for me.

I never did run SRD - when it made sense to upgrade, I went 
from SRC to SRE, as SRE introduced 32-bit ASN support on the 
platform.

 and given that there is
 15.0M, I have always questioned what use it is to have
 support for *one* software platform in a special-case
 IOS train, maintained by the BU inside Cisco that caused
 the most annoyance of all of them (having a polite day
 today).

12.2SR is also coded for the 7600. So it's the 7200 and 7600 
that this code is maintained for.

Mark.

___
cisco-nsp 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] RIPE 554, availability of required IPv6 features

[Frank Bulk]

You speak with your dollars...

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering
Sent: Saturday, November 24, 2012 12:23 PM
To: Peter Rathlev
Cc: cisco-nsp
Subject: Re: [c-nsp] RIPE 554, availability of required IPv6 features

Hi,

On Sat, Nov 24, 2012 at 02:32:59PM +0100, Peter Rathlev wrote:
 Are my assumptions wrong? We're (in part politically) not allowed to
 require anything that only one or two vendors would be able to fulfill,
 though something that lives up to one of the three points above
 shouldn't be a problem.

This is an interesting problem.  If one vendor (out of a fairly small
group anyway) is listening and providing solutions, while everybody else
keeps stalling, what can you do...?

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-35655025
g...@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] IPv6 BGP peers over SNMP

[Frank Bulk]

This topic has been much discussed, but there's been little action.  Some
shops are scraping the CLI output.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Sander Steffann
Sent: Wednesday, October 24, 2012 5:58 AM
To: Robert Williams
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IPv6 BGP peers over SNMP

Hi,

 Can anyone confirm if it is possible to retrieve IPv6 BGP Neighbor
statistics from a Sup-720-3BXL running 12.2(33)SXJ ?
 
 My research suggests it should be at 1.3.6.1.4.1.9.9.187.1.2.5
(cbgpPeer2Table)
 
 However, a walk of the whole ...187.1.2 tree reveals no sign of a 1.2.5
and no IPv6 peers at all.

As far as I know Cisco never implemented SNMP for IPv6 BGP sessions. Yes,
this is bad. Yes, put some pressure on your account manager :-)

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

[c-nsp] DHCPv6-PD relay with static route insertion not working on 7609 when CE's DHCPv6 request goes through access platform's LDRA

[Frank Bulk]

Our 7609 running 12.2(33)SRE2 has been using DHCPv6-PD relay with static
router insertion (with an external DHCPv6 server) for over a year now and
it's worked quite well for customers on our access platform.  The 7609
snoops the DHCPv6 responses and builds the static route like it's supposed
to.

Sep 27 14:02:46.714 CDT: IPv6 DHCP: Received SOLICIT from
FE80::5ED9:98FF:FE64:6823 on Vlan10
Sep 27 14:02:46.714 CDT: IPv6 DHCP_RELAY: Relaying SOLICIT from
FE80::5ED9:98FF:FE64:6823 on Vlan10
Sep 27 14:02:46.714 CDT: IPv6 DHCP_RELAY: Packet forwarded to stripped
Sep 27 14:02:46.714 CDT: IPv6 DHCP: Sending RELAY-FORWARD to stripped on
Vlan3
Sep 27 14:02:46.714 CDT: IPv6 DHCP: Received RELAY-REPLY from stripped on
Vlan3
Sep 27 14:02:46.714 CDT: IPv6 DHCP_RELAY: Relaying RELAY-REPLY from
stripped on Vlan3
Sep 27 14:02:46.714 CDT: IPv6 DHCP_RELAY: Packet forwarded to
FE80::5ED9:98FF:FE64:6823 via Vlan10
Sep 27 14:02:46.714 CDT: IPv6 DHCP: Sending ADVERTISE to
FE80::5ED9:98FF:FE64:6823 on Vlan10
Sep 27 14:02:47.726 CDT: IPv6 DHCP: Received REQUEST from
FE80::5ED9:98FF:FE64:6823 on Vlan10
Sep 27 14:02:47.726 CDT: IPv6 DHCP_RELAY: Relaying REQUEST from
FE80::5ED9:98FF:FE64:6823 on Vlan10
Sep 27 14:02:47.726 CDT: IPv6 DHCP_RELAY: Packet forwarded to stripped
Sep 27 14:02:47.726 CDT: IPv6 DHCP: Sending RELAY-FORWARD to stripped on
Vlan3
Sep 27 14:02:47.726 CDT: IPv6 DHCP: Received RELAY-REPLY from stripped on
Vlan3
Sep 27 14:02:47.726 CDT: IPv6 DHCP_RELAY: Relaying RELAY-REPLY from
stripped on Vlan3
Sep 27 14:02:47.726 CDT: [DHCPv6 Relay]IPv6RT[default]: static, Route add
stripped:1000:F800::/56 [new 1/0]
Sep 27 14:02:47.726 CDT: [DHCPv6 Relay]IPv6RT[default]: static, Added path
FE80::5ED9:98FF:FE64:6823/Vlan10
Sep 27 14:02:47.726 CDT: IPv6 DHCP_RELAY: Route added:
stripped:1000:F800::/56 via FE80::5ED9:98FF:FE64:6823 dist 1 ia id
08646823 lifetime 43200
Sep 27 14:02:47.726 CDT: IPv6 DHCP_RELAY: Packet forwarded to
FE80::5ED9:98FF:FE64:6823 via Vlan10
Sep 27 14:02:47.726 CDT: IPv6 DHCP: Sending REPLY to
FE80::5ED9:98FF:FE64:6823 on Vlan10

Our access platform vendor has a new major release that we're testing on a
lab shelf that now adds LDRA support.  We noticed that we could receive a
IPv6 address and delegated prefix on our CE, but had no routability.  Using
the same Cisco debug commands that gave me the output above, I could see
that no static routes were being added.

I did some packet sniffing between the access platform and the 7609 and I
could see that the access platform's LDRA added an Interface-ID (option 18),
Remote Identifier (option 37), and of course the original DHCP request
(option 9).  Now the access platform's LDRA must not mangle it so badly
because our 7609 does relay it to the external DHCPv6 server and relays back
its response, but the 7609 is not inserting a static route.  Hence no
routability between CE and the 7609.

Has anyone run into this before, and if so, what needs to be done?  I tried
chasing down the dhcp snoop trusted route, but it seems to be IPv4 only.
Perhaps I ran into a limitation of this rendition code and it's addressed in
a future release, but my google-fu has not uncovered anything.  There's some
talk about DHCPv6 relay chaining support in 15.x, but it doesn't explicitly
say it's needed to get static route insertion working again.

Any assistance would be helpful.

Regards,

Frank

___
cisco-nsp 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] Broadcast storm Cisco Solution

[Frank Bulk]

Rich:

Our access gear allows us to specify the DHCP directionality, which
addresses this issue.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Hilliard
Sent: Thursday, July 26, 2012 11:21 AM
To: Rich Trinkle
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Broadcast storm Cisco Solution

On 26/07/2012 17:07, Rich Trinkle wrote:
 Thanks Nick.  I did some research on storm control.  If I set this up
 for broadcast and this happens again, all broadcast traffic stops on
 this port thus affecting all my subs.  Here is a quick breakdown:
 
 Cisco 7206 - I have a vlan set up on a sub interface with a dhcp pool in
 it.  This Vlan is then trunked out to a 3750.
 Cisco 3750 - From here it gets trunked out 3 different gig ports to
 Ethernet uplink cards (Tellabs AFC equipment) in different geographical
 locals and then gets dumped to shelves, adsl cards and then to sub.
 
 The AFC equipment does not have the capability of controlling or
 monitoring for this type of excessive traffic.  In the event of a storm,
 or ddos attack, I'd like to be able to just isolate that mac or ip
 that's causing it and not affect any of the other subs on that dhcp
 network.

Hi Rich,

you need to be able to handle storms as close as possible to the source of
the storm.  In your case, as you can't handle it on the tellabs boxes,
you're going to need to configure it on the 3750 interfaces facing them.
However, this is going to cause you problems because if you have a storm
event on a single customer and storm control stop it from being a problem
for other ports, it has the potential to interfere with your other
customers on that port - who are also going to be issuing you with periodic
dhcp requests,

I'd view it as a pretty serious failing on the part of the Tellabs AFC kit
if they couldn't handle broadcast storm control.  If you're running L2 to
the customer, you need adequate L2 protection in order to keep your network
running properly.  The absolute minimum features you need here would inlude
mac address counting, broadcast / multicast storm control and dhcp
snooping.  If your kit doesn't handle this, you have problems. :-(

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] WLC Active users / SNMP

[Frank Bulk]

Try this:
https://supportforums.cisco.com/thread/330308

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Andrew Miehs
Sent: Sunday, July 01, 2012 7:52 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] WLC Active users / SNMP

Hi Guys,

Anyone using SNMP with the Cisco Wireless Controllers?

I would like to find out every five minutes how many users I have
associated per access point, and was hoping to find this information on the
WLCs... It seems as if the WLCs don't have everything exported via SNMP...

Thoughts?

Andrew
___
cisco-nsp 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] Packet capturing

[Frank Bulk]

I assume you're using an Calix E5 or E7?  If so, why not trying to port
mirror off the Calix.  You can then use display or capture filters to zero
in on the VLAN you want to look at, though a capture filter on DHCP should
be sufficient to make it a manageable stream to look at.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Michael Sprouffske
Sent: Thursday, June 14, 2012 9:24 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Packet capturing

I currently have a calix switch attached to a Cisco 7606. I'm doing Q-n-Q to
the router and having an issue with customers obtaining an ip address. If I
delete and re-create the sub interface for the customer they can get an ip
and I see an arp entry. I also looked at my dhcp server logs to verify that
it hands out an address immediately after the interface is created. 
I have a Linux box setup on a mirror port for packet captures. I'm having a
hard time capturing the right packets to see where this problem exists.  I
wanna see if the packets are leaving the calix gear and going toward the
router. Has anyone had an issue with sub interfaces responding this way?
This problem started 1 week ago. Thank you for any help.

Sent from my iPhone
___
cisco-nsp 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] Long range 10G ethernet?

[Frank Bulk]

You generally will save some light if you skip the intermediate patch cords
and splice it through.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Peter Rathlev
Sent: Thursday, May 17, 2012 5:14 AM
To: Phil Mayers
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Long range 10G ethernet?

On Wed, 2012-05-16 at 11:46 +0100, Phil Mayers wrote:
 Out of curiosity, is this an immensely long leg, or is it just really 
 crappy?

A bit of both. :-) I think it's just short of 100 Km in total, but with
several patch cords/ODFs along the way. Some of these can be removed but
removing all would probably make too expensive compared to what we win
by running 10G.

 One possibility might be to use a transponder with G.709 capability, and 
 appropriate optics.
...
 You didn't say what specific complexity puts you off amps, but if it's 
 just more kit then this solution isn't really any better, and I doubt 
 much cheaper, than a pair of 9dB amps.

Hadn't thought of the G.709 angle. But since it still requires external
equipment (for a 6500) the amplification path is probably easier.

-- 
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] ASR 1006 Code

[Frank Bulk]

A neighboring ISP has had an ASR1002 for about two years for BRAS + ISG
functionality and it's still not stable.  I can't count how many (beta) code
releases Cisco has had him try.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of N. Max Pierson
Sent: Thursday, March 22, 2012 9:14 AM
To: Cisco Mailing list
Subject: [c-nsp] ASR 1006 Code

Hi List,

Turning up a few new 1006's and would like to hear from those of you on a
stable revision of XE. W're currently running on 15.1(2)S1 and have hit
quite a few bugs. Our Cisco team says we should move to 15.2.(1)S1. Being
this release is relativity new, i'm a little hesitant to jump to it. The
last go around had us on an image ridden with bugs after some exposure.

Features used ... nothing really exotic 

BGPv4
EIGRPv4
Netflow
QoS
IP Sla

Any recommendations would be great.

Regards,
Max
___
cisco-nsp 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] www.ipv6.cisco.com down for 5+ days

[Frank Bulk]

Just came back up -- thanks to anyone/everyone that moved this issue
forward.

Frank

-Original Message-
From: Frank Bulk [mailto:frnk...@iname.com] 
Sent: Saturday, January 07, 2012 3:00 PM
To: cisco-nsp@puck.nether.net
Subject: www.ipv6.cisco.com down for 5+ days

I sent an email to the only NOC email address I could find for Cisco, but it
hasn't made a difference.

www.ipv6.cisco.com has been down since Sunday:
nagios:/usr/lib/nagios/plugins# wget www.ipv6.cisco.com
--2012-01-07 14:58:55--  http://www.ipv6.cisco.com/
Resolving www.ipv6.cisco.com... 2001:420:80:1::5
Connecting to www.ipv6.cisco.com|2001:420:80:1::5|:80... connected.
HTTP request sent, awaiting response... 503 Service Unavailable
2012-01-07 14:58:55 ERROR 503: Service Unavailable.

nagios:/usr/lib/nagios/plugins#

It pings just fine.

If anyone from Cisco is lurking could they reach out to the NOC or IT staff?

Regards,

Frank Bulk

___
cisco-nsp 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] www.ipv6.cisco.com down for 5+ days

[Frank Bulk]

I sent an email to the only NOC email address I could find for Cisco, but it
hasn't made a difference.

www.ipv6.cisco.com has been down since Sunday:
nagios:/usr/lib/nagios/plugins# wget www.ipv6.cisco.com
--2012-01-07 14:58:55--  http://www.ipv6.cisco.com/
Resolving www.ipv6.cisco.com... 2001:420:80:1::5
Connecting to www.ipv6.cisco.com|2001:420:80:1::5|:80... connected.
HTTP request sent, awaiting response... 503 Service Unavailable
2012-01-07 14:58:55 ERROR 503: Service Unavailable.

nagios:/usr/lib/nagios/plugins#

It pings just fine.

If anyone from Cisco is lurking could they reach out to the NOC or IT staff?

Regards,

Frank Bulk

___
cisco-nsp 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] Recommendation for small GBit router

[Frank Bulk]

It's too bad that they don't have a release that supports both IPv6 PBR and 
DHCPv6-PD with static route insertion.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka
Sent: Sunday, December 18, 2011 7:28 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Recommendation for small GBit router

On Sunday, December 18, 2011 03:06:18 AM Andrew Miehs wrote:

 Apart from running something like running lots of E1s,
 x21 interfaces I would no longer purchase a new 7200. As
 for second hand boxes - if you can get a service
 contract for them, ok.

Same.

If we're buying for small-to-medium Ethernet requirements, 
the ASR1000's are the platform to pick on the Cisco side of 
things.

If we need low-speed non-Ethernet, the 7200 is hard to beat, 
even today.

 I still remember a friend of mine buying 4x 7500s filled
 with VIPs and ?Supervisors?… Every card, and even the
 chassis all had problems! But it was not that the cards
 didn't work - they booted, came on line, and then
 crashed after 2 days, etc. He spent 6 months debugging
 the issues with these boxes due to that and EVERY single
 piece needed replacing. Needless to say, it ended up
 costing the company more than it would have to buy new.

I don't think it would be fair to compare the 7500 to the 
7200. They may share port adapters, but that's about it.

The NPE-G1 and NPE-G2 on SRE are pretty modern if you're not 
looking at pushing lots of bandwidth. It's a shame the 
platform has been discontinued in the long-term, but it's 
still has miles to run in the short-to-medium term.

Mark.


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

[Frank Bulk]

What if you interconnect the two switches with 1G rather than 10?

Frank

-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 2:18 PM
To: 'Chuck Church'; 'cisco-nsp'
Subject: Re: [c-nsp] Weird Multicast microburst amplification issue

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

Re: [c-nsp] Low-cost rate-shaping/policing switch

[Frank Bulk]

There's a low-end hardware from vendors such as D-Link that do egress
policing, but not ingress.  Ingress is much harder to come by.

Frank

-Original Message-
From: Mark Tinka [mailto:mti...@globaltransit.net] 
Sent: Sunday, September 11, 2011 8:59 AM
To: cisco-nsp@puck.nether.net; frnk...@iname.com
Subject: Re: [c-nsp] Low-cost rate-shaping/policing switch

On Sunday, September 11, 2011 11:45:46 AM Frank Bulk wrote:

 What is the lowest-cost Cisco *switch* that does
 rate-limiting on the egress and policing on the ingress,
 on a per-port basis?

My guess is that would be the ME3600X/3800X, since it 
supports egress policing.

However, do note that egress policing, which has appeared 
for the first time on this platform in IOS 15.1(2)EY, is 
currently limited to policing on egress for Priority 
traffic/queues. I've already contacted our SE to ensure 
egress policing is supported for all traffic/queue types, 
and will wait to see when that happens.

I know most classic switches don't support egress policing 
(some do egress shaping), but I can't be really sure. The 
same goes for Juniper's EX switches, although they really 
aren't in the same league as the ME3600X/3800X I'm 
mentioning here.

Would suggest you check with your SE.

Cheers,

Mark.

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

Re: [c-nsp] BGP IPv6 OIDs

[Frank Bulk]

Cisco's support for IPv6 aspects of CISCO-BGP4-MIB has been very poor.  My
TAC cases have gone nowhere -- they just confirm there's no support (i.e.
CSCse32865).

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jon Lewis
Sent: Saturday, September 10, 2011 2:33 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] BGP IPv6 OIDs

Is there an OID for SNMP polling the number of ipv6 unicast routes 
received from an ipv6 BGP peer?  i.e. I've been graphing the # of IPv4 
routes received from our transit providers with

.1.3.6.1.4.1.9.9.187.1.2.4.1.1.${peerIP}.1.1

mostly as an indicator of transit provider health.  i.e. if the number 
suddenly goes up or down much, there's probably something wrong.

I'd like to do the same with IPv6 routes, but I haven't found the OID.

--
  Jon Lewis, MCP :)   |  I route
  Senior Network Engineer |  therefore you are
  Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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

[c-nsp] Low-cost rate-shaping/policing switch

[Frank Bulk]

We serve an MDU where would like to provide one of four tiers of speeds
(128K/128K, 3M/512K, 8M/768K, and 15M/1M) to subscribers living in different
apartments.  

What is the lowest-cost Cisco *switch* that does rate-limiting on the egress
and policing on the ingress, on a per-port basis?

Frank

___
cisco-nsp 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] NAT over Two different providers

[Frank Bulk]

Here's some good articles to read:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_examp
le09186a0080950834.shtml
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_examp
le09186a00808d2b72.shtml
http://www.nil.com/ipcorner/SmallSiteMultiHoming/
http://www.nil.si/ipcorner/RedundantMultiHoming/

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of jacob miller
Sent: Monday, July 11, 2011 8:59 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] NAT over Two different providers

Hi,

Am having the following scenario which I need assistance in solving.

I have two Internet service providers each of which has provided a /29 set
of public IP addresses.

I would like to use Link A (ISP A) as the main link and Link B (ISP B) as my
back up.

I would like to do this automatically such that users on the LAN do not
detect that one link is down.

My LAN is on Private IP address range is beign NATed on the ISP's.

Regards,
Jacob Miller 
___
cisco-nsp 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] Limit Access right on Cisco 6500 IOS ?

[Frank Bulk]

TACACS+ will facilitate the ability to limit which commands are usable.
http://my.safaribooksonline.com/book/networking/cisco-ios/0596527225/tacacsp
lus/i13896__heada__4_2

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Olivier CALVANO
Sent: Sunday, August 28, 2011 12:32 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Limit Access right on Cisco 6500 IOS ?

Hi

anyone know if it's possible to limit the access right on one user in telnet
access on
a cisco 6500 ?

I want know if i can limit a user to :
 - See port states on of module card (not all)
 - See vlan database and can create/modofy/delete a vlan
 - Can configure a lot of Port on a specifique card

thanks for your help
Olivier
___
cisco-nsp 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

[Frank Bulk]

I agree with you: what ought to be, isn't.  

I don't make buying decisions based on what I would like vendors to do or
what they should do, but what is.  Until documentation matches reality, I
will use consultants to help us with our due-diligence.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Randy
Sent: Sunday, August 28, 2011 9:15 PM
To: Gert Doering; Brett Frankenberger
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

I have been following this thread and it is upto the *vendor* to
*Clearly-Document* what-combinations work and what doesn't!
It has nothing to do with what you or other OP have said wrt regard to
due-diligence or for that matter - ...hiring-someone-who-knowssnip
What *^% diligence are you talking about? When, what works/doesn't is not
documented!!

As applicable to me(as an example)

I am still waiting for a clear-answer from TAC(as applicable to sxi4a  a
DFC environment) *IF* routed-mac-entries still-get-aged-out regardless of
whether-or-not-there is traffic!

..all boiles-down-to vendor-doc!

Given the times; it may be of interest to you and op:

Unlike the 90's there is very-little-to-none by the way of
resources(man-hours/lab) that $Employers can spare.
./Randy





--- On Sun, 8/28/11, Brett Frankenberger rbf+cisco-...@panix.com wrote:

 From: Brett Frankenberger rbf+cisco-...@panix.com
 Subject: Re: [c-nsp] WARNING: Netflow Data Export  Hardware assisted NAT
not supported on 76xx/65xx on the same interface
 To: Gert Doering g...@greenie.muc.de
 Cc: cisco-nsp@puck.nether.net
 Date: Sunday, August 28, 2011, 5:33 PM
 On Sun, Aug 28, 2011 at 08:04:00PM
 +0200, Gert Doering wrote:
  
  On Sun, Aug 28, 2011 at 11:12:44AM -0500, Tony
 Varriale wrote:
   Then hire someone that knows what they are
 doing.
  
  Am I the only one to find that sort of remark a bit
 nasty?
  
  While not sporting any nice certificates, I consider
 myself to be 
  somewhat experienced with Cisco platforms, and Cisco
 architecture - and
  if a prospective customer would have asked me will
 NAT and netflow
  work together? I would have checked the
 documentation, would not have
  found anything about that conflict either, and would
 have said no 
  problem there.
 
 But now much money would you commit to that position? 
 You've been
 doing this a while ... presumably you're well aware that
 not everything
 always works togethor on platforms that do most of their
 switching in
 ASICs.  (I do a lot of GRE tunnelling and have for a
 long time.  The
 first thing I thought when I learned that Sup720s would
 support GRE
 tunnels in hardware was I wonder what the limitations
 are.  There are
 many, and only some of them are documented.)
 
 The comment you reference above was in respose to this:
    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).
 
 While you might not personally know off hand if NAT and
 netflow work
 togethor, if you had a requirement for that functionality
 and were
 considering the 65xx/76xx for it, would you read the
 documentation, not
 find anything saying they won't work togethor, and then buy
 it?  Or
 would you do a detailed RFP or talk to a TME about that
 functionality
 before buying it?  Or if you didn't have the time or
 talent to do one
 of those things yourself, would you hire someone who did?
 
 The comment was rather blunt, but in terms of content, it
 was dead on. 
 Buyers need to do their due diligence.  Some are large
 and/or
 sophisticated enough to do it with in house employees,
 others need to
 hire outside talent.  But if you do neither, you run
 the risk of being
 disappointed. 
 
 (In response to the comment about I can't hire anyone who
 knows about
 limitations on future unreleased products.  Of course
 you can't.  But
 you can hire someone who knows how to do the necessary due
 diligence
 before purchasing a product.)
 
      -- Brett
 ___
 cisco-nsp 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] Service Provider Anti-Spam

[Frank Bulk]

Mailchannels (http://mailchannels.com/) comes to mind.  I don't have any
experience with it, but it would seem to meet your product requirments.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Felix Nkansah
Sent: Wednesday, July 06, 2011 7:42 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Service Provider Anti-Spam

Hello,

I am interested in deploying an anti-spam solution in an ISP network that
would scan all incoming/outgoing email traffic and block spam to/from
downstream users.

The system should be integrated to work in the ISP network without requiring
any subscriber (business or individual) to make changes on his
network/servers.

I would appreciate your suggestions on a good product/solution and/or
approach.

Thanks. Felix
___
cisco-nsp 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] Platform feature development for 7200

[Frank Bulk]

Yes, but IPv6 PBR is not, in that release. =(

 

Frank

 

From: Manu Chao [mailto:linux.ya...@gmail.com] 
Sent: Tuesday, June 21, 2011 1:49 AM
To: frnk...@iname.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Platform feature development for 7200

 

Right, but DHCPv6 Relay Agent notification for Prefix Delegation is
available in 12.2(33)SRE3 on 7200 platform

On Tue, Jun 21, 2011 at 6:19 AM, Frank Bulk frnk...@iname.com wrote:

Just saw this today:
   This feature [DHCPv6-PD with automatic route insertion] is
   not yet supported on the T-Train. The feature in question
   is DHCPv6  Relay Agent notification for Prefix Delegation
   which is supported on all the Cisco switch trains and on
   the ASR1K  7600 platforms. We intend to bring this
   feature to the T-train by mid to late 2012.
https://supportforums.cisco.com/message/3373998#3373998

Mid to late 2012?  You have got to be kidding me...

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Frank Bulk -
iName.com
Sent: Monday, June 20, 2011 3:45 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Platform feature development for 7200


I learned from our SE today that platform feature development for the 7200
has ended, and that SB code train is going to be EOL very soon.  The
recommendation is to move to the ASR1K.

This affects us because we needed both IPv6 PBR and DHCPv6-PD with automatic
route insertion on the same code release.

Regards,

Frank Bulk


___
cisco-nsp 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] Platform feature development for 7200

[Frank Bulk - iName.com]

I learned from our SE today that platform feature development for the 7200
has ended, and that SB code train is going to be EOL very soon.  The
recommendation is to move to the ASR1K.

This affects us because we needed both IPv6 PBR and DHCPv6-PD with automatic
route insertion on the same code release.

Regards,

Frank Bulk


___
cisco-nsp 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] Platform feature development for 7200

[Frank Bulk]

I think I could use 15.1, but it's missing DHCPv6-PD automatic route
insertion.  And according to our SE, even 15.1 will not be developed on the
7200VXR.  I know, it's doesn't make sense.

 

Frank

 

From: Manu Chao [mailto:linux.ya...@gmail.com] 
Sent: Monday, June 20, 2011 3:59 PM
To: frnk...@iname.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Platform feature development for 7200

 

There is a gap between IOS 12.2SB and current IOS 15.1 ;)

IOS 15 will do the v6 job

ASR1K if you need performance


Sure 7200 IOS 15.1 will do the v6 job

On Mon, Jun 20, 2011 at 10:45 PM, Frank Bulk - iName.com frnk...@iname.com
wrote:

I learned from our SE today that platform feature development for the 7200
has ended, and that SB code train is going to be EOL very soon.  The
recommendation is to move to the ASR1K.

This affects us because we needed both IPv6 PBR and DHCPv6-PD with automatic
route insertion on the same code release.

Regards,

Frank Bulk


___
cisco-nsp 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] Platform feature development for 7200

[Frank Bulk]

Just saw this today:
This feature [DHCPv6-PD with automatic route insertion] is 
not yet supported on the T-Train. The feature in question 
is DHCPv6  Relay Agent notification for Prefix Delegation 
which is supported on all the Cisco switch trains and on 
the ASR1K  7600 platforms. We intend to bring this 
feature to the T-train by mid to late 2012.
https://supportforums.cisco.com/message/3373998#3373998

Mid to late 2012?  You have got to be kidding me...

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Frank Bulk -
iName.com
Sent: Monday, June 20, 2011 3:45 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Platform feature development for 7200

I learned from our SE today that platform feature development for the 7200
has ended, and that SB code train is going to be EOL very soon.  The
recommendation is to move to the ASR1K.

This affects us because we needed both IPv6 PBR and DHCPv6-PD with automatic
route insertion on the same code release.

Regards,

Frank Bulk


___
cisco-nsp 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 Support in Cisco IOS AnyConnect?

[Frank Bulk]

The missing IPv6 nameservers issue is described in BugID CSCtg92043.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Kaj Niemi
Sent: Thursday, June 16, 2011 2:43 PM
To: Chris Mason
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IPv6 Support in Cisco IOS AnyConnect?

Hi,


IOS SSL VPN doesn¹t currently support IPv6 for SVC. See Features Not
Supported on the Cisco IOS SSL VPN
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/
guide/sec_ssl_vpn_ps10591_TSD_Products_Configuration_Guide_Chapter.html#wp1
502587

It works quite well on ASA with the exception of not being able to supply
IPv6 name servers so you can't pretend to have IPv6 only connectivity.
Also, at least with OS X, if you have IPv6 on the LAN and then enter SVC
and enable your tunnel, when you disconnect your IPv6 connectivity on the
LAN wont work anymore.



Kaj




On 16/6/2011 18:34, Chris Mason ch...@noodles.org.uk wrote:

Is anyone from Cisco able to confirm if IPv6 is supported when using
the IOS based SSL VPN feature (inside the VPN)?
The AnyConnect VPN client has a field for Client Address (IPv6) but
I can't see how to enable it on the router.

Using 15.0(1)M6 on the router and AnyConnect 2.5 on the client.

I can see it is supported if I was using an ASA as the headend, but
looking for some pointers when using an IOS based head-end?


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

Re: [c-nsp] IPv6 nd table on the 6500

[Frank Bulk]

What about in the 12.2SR code line?

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tóth András
Sent: Thursday, May 05, 2011 8:26 AM
To: Phil Mayers
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IPv6 nd table on the 6500

There are improvements made already in the following:
CSCtn78957 - High CPU seen with large IPv6 neighbor table

Integrated in SXI6 already.

Andras


On Thu, May 5, 2011 at 9:08 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
 On 05/05/2011 07:46 AM, Saku Ytti wrote:

 Speaking of ND entries, they appear to carry significant new DoS vector
 which
 is rather hard to fix and it appears that not even new gear have given it
 much
 thought at all.



 I saw some IOS roadmap stuff for IPv6 ND DoS protection recently - 2-phase
 (1: global prevent ND DoS, 2: per-interface Prevent) so Cisco are at
 least aware of it.
 ___
 cisco-nsp 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] ADSL errors

[Frank Bulk]

I vaguely recall having since this issue on our system, too.  What IOS
release are you running?  Here's another posting on the issue (from 2007):
http://www.ccie.pl/printview.php?t=4999start=0sid=04b8525fcdec2f2ad56e7dc3
be6c5513

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mohammad Khalil
Sent: Saturday, April 02, 2011 7:53 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ADSL errors


Dears i am facing disconnections on ADSL sessions
i made debug ppp error
043350: 1y42w: Vi779 PPP: Attempt to free context twice
043351: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
0x62587FD8
2.access.router#
043352: 1y42w: Vi728 PPP: Attempt to free context twice
043353: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
0x62587FD8
043354: 1y42w: ppp230 AUTH: Timeout 1
2.access.router#
043355: 1y42w: Vi99 PPP: Attempt to free context twice
043356: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
0x62587FD8
2.access.router#
043357: 1y42w: Vi127 PPP: Attempt to free context twice
043358: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
0x62587FD8
043359: 1y42w: Vi465 PPP: Attempt to free context twice
043360: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
0x62587FD8
043361: 1y42w: ppp230 AUTH: Timeout 2
2.access.router#
043362: 1y42w: Vi435 PPP: Attempt to free context twice
043363: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
0x62587FD8
2.access.router#
043364: 1y42w: ppp230 PPP: Dynamic send error, close LCP
2.access.router#
043365: 1y42w: Vi460 PPP: Attempt to free context twice
043366: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
0x62587FD8
  
___
cisco-nsp 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] ADSL errors

[Frank Bulk]

I believe this software is 5+ years old - I'd recommend that you upgrade.

 

Frank

 

From: Mohammad Khalil [mailto:eng_m...@hotmail.com] 
Sent: Saturday, April 02, 2011 4:36 PM
To: frnk...@iname.com; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] ADSL errors

 

Thanks Frank , below are the information

c7200-adventerprisek9-mz.124-4.T1.bin
no changes have been made recently
Cisco 7206VXR (NPE400) processor
128098304 bytes total (78315520 bytes free)
 uptime is 1 year, 42 weeks, 6 days, 14 hours, 56 minutes
the CPU ranges from 50 to 70 %
the PPPoE sessions are terminated on G5/0
  MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, 
 reliability 255/255, txload 21/255, rxload 3/255
  Encapsulation ARPA, loopback not set
  Keepalive set (5 sec)
  Full-duplex, 1000Mb/s, link type is autonegotiation, media type is SX

 From: frnk...@iname.com
 To: eng_m...@hotmail.com; cisco-nsp@puck.nether.net
 Subject: RE: [c-nsp] ADSL errors
 Date: Sat, 2 Apr 2011 16:31:51 -0500
 
 I vaguely recall having since this issue on our system, too. What IOS
 release are you running? Here's another posting on the issue (from 2007):
 http://www.ccie.pl/printview.php?t=4999
http://www.ccie.pl/printview.php?t=4999start=0sid=04b8525fcdec2f2ad56e7dc
3 start=0sid=04b8525fcdec2f2ad56e7dc3
 be6c5513
 
 Frank
 
 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net
 [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mohammad Khalil
 Sent: Saturday, April 02, 2011 7:53 AM
 To: cisco-nsp@puck.nether.net
 Subject: [c-nsp] ADSL errors
 
 
 Dears i am facing disconnections on ADSL sessions
 i made debug ppp error
 043350: 1y42w: Vi779 PPP: Attempt to free context twice
 043351: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
 0x62587FD8
 2.access.router#
 043352: 1y42w: Vi728 PPP: Attempt to free context twice
 043353: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
 0x62587FD8
 043354: 1y42w: ppp230 AUTH: Timeout 1
 2.access.router#
 043355: 1y42w: Vi99 PPP: Attempt to free context twice
 043356: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
 0x62587FD8
 2.access.router#
 043357: 1y42w: Vi127 PPP: Attempt to free context twice
 043358: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
 0x62587FD8
 043359: 1y42w: Vi465 PPP: Attempt to free context twice
 043360: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
 0x62587FD8
 043361: 1y42w: ppp230 AUTH: Timeout 2
 2.access.router#
 043362: 1y42w: Vi435 PPP: Attempt to free context twice
 043363: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
 0x62587FD8
 2.access.router#
 043364: 1y42w: ppp230 PPP: Dynamic send error, close LCP
 2.access.router#
 043365: 1y42w: Vi460 PPP: Attempt to free context twice
 043366: 1y42w: -Traceback= 0x61F2F314 0x61F531E8 0x625B85D8 0x625B8738
 0x62587FD8
 
 ___
 cisco-nsp 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] 3845 maxing out at 400 Mbps

[Frank Bulk]

Just an update -- I shuffled interfaces last night, so that the bulk of the
traffic goes through the 3845's native GigE interfaces.  This has reduced
CPU by about 10 to 15% and my new max is 423 Mbps, already 5% my previous
max.

Thanks for the help.

Frank

-Original Message-
From: Pierre Emeriaud [mailto:petrus...@gmail.com] 
Sent: Tuesday, March 29, 2011 12:18 PM
To: frnk...@iname.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 3845 maxing out at 400 Mbps

2011/3/29 Frank Bulk frnk...@iname.com:
 Yes, I am running that HWIC!

 NAME: High Speed WAN Interface Card - 1 Port Gigabit Ethernet on Slot 0
 SubSlot 2, DESCR: High Speed WAN Interface Card - 1 Port Gigabit
Ethernet
 PID: HWIC-1GE-SFP      , VID: V01 , SN: 

 If I shuffle around interfaces so that the inter-3845 links use the HWIC
 instead, would that totally resolve the issue?

I guess so. This issue was discussed some time ago on frnog mailing
list (french nanog)

After asking earlier today, I told myself that you would already use
the hwic for the inter-3845, but it appears not.

Things should improve if less traffic flows through the hwic.

regards,
-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/

Re: [c-nsp] 3845 maxing out at 400 Mbps

[Frank Bulk]

The 'sh ip cef switching stats' is unfortunately not supported on my IOS
release.  AFAIK, this is not BU-special software.  I d/l this several years
ago from using CCO account when initially turning these up.

I'd prefer not upgrade unless someone can point me to a specific issue/bug
fix.  

Thanks for your thoughts.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lukasz Bromirski
Sent: Tuesday, March 29, 2011 2:33 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 3845 maxing out at 400 Mbps

On 2011-03-29 04:14, Frank Bulk wrote:
 We have two 3845's as border routers, each with three GigE interfaces (one
 facing upstream, the other downstream, the third facing the other 3845).
 The first 3845 has a typical packet-size mix (residential/business
Internet)
 is consistently maxing out at 400 Mbps (predominately ingress because of
 asymmetric routing) running at about 43 kpps and 40% CPU.  It's flat-lines
 very evenly, uncannily so.  We checked and double-checked transport and
it's
 set much higher, the same as the second 3845.
 The second 3845, which has a mix of both ingress and egress traffic at a
 combined 82 kpps (35 kpps ingress/50 kpps egress) but lower combined 360
 Mbps operates at a higher CPU (presumably because there's also egress
 traffic) with no flatlining.

Are there any CEF drops? Have you checked 'sh ip cef switching stats'?

 The ACLs are BCP 38-oriented with eBGP; no rate-limiting.
  We're running 124-11.XW2.

Why you're running BU-special software? Some specific feature not
included in normal IOS? Given the relese date of the software,
all the features should be already in the mainline IOS. You
should propably move to 12.4(15)T or 15.0(1)Mx (latest rebuild).

-- 
There's no sense in being precise when |   Łukasz Bromirski
  you don't know what you're talking |  jid:lbromir...@jabber.org
  about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


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

Re: [c-nsp] 3845 maxing out at 400 Mbps

[Frank Bulk]

I agree.  It's just that I have an identical router that's set up
identically with slightly lower ingress but higher total ingress + egress
numbers, and can go over 40%.

Frank

-Original Message-
From: Asbjorn Hojmark - Lists [mailto:li...@hojmark.org] 
Sent: Tuesday, March 29, 2011 3:01 AM
To: frnk...@iname.com
Cc: Cisco NSP
Subject: Re: [c-nsp] 3845 maxing out at 400 Mbps

On Mon, 28 Mar 2011 21:14:21 -0500, you wrote:

 The ACLs are BCP 38-oriented with eBGP; no rate-limiting.  We're running
 124-11.XW2.

You really should look at upgrading that to some more recent and less
End-of-X. 12.4 XW also has know vulnerabilities only fixed in later
releases.

 Any ideas?  The numbers are well below Cisco's router spec sheet.

Actually, the 3800 is positioned for T3/E3 speeds... I consider it
quite impressive that you're pushing up to 400 Mbps though them with
some features.

The spec sheet is best case numbers with no features. *Any* feature
that you turn on will negatively affect performance, and the actual
performance hit for each feature will also vary with traffic patterns.

-A

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

Re: [c-nsp] 3845 maxing out at 400 Mbps

[Frank Bulk]

Let me clear the air and say that I'm very happy with the performance of our
3845s -- they've done much better than even our consulting company thought
they would.  

They need to last just a few more weeks until the new border routers we
ordered come in and we turn them up.  I just need to buy a few more weeks'
time.  

What prompted the initial question was that I was seeing different behavior
between the two (identical) routers.  That gave me a unique opportunity to
compare and contrast.  I think the HWIC is likely the culprit here.

Frank

-Original Message-
From: Christopher Pilkington [mailto:c...@0x1.net] 
Sent: Tuesday, March 29, 2011 11:55 AM
To: Asbjorn Hojmark - Lists
Cc: frnk...@iname.com; Cisco NSP
Subject: Re: [c-nsp] 3845 maxing out at 400 Mbps

On Tue, Mar 29, 2011 at 4:00 AM, Asbjorn Hojmark - Lists
li...@hojmark.org wrote:
 Actually, the 3800 is positioned for T3/E3 speeds... I consider it
 quite impressive that you're pushing up to 400 Mbps though them with
 some features.

I believe the marketing blurb for the 3845 was full T3 with
concurrent services.  Even this is a stretch of reality.  A
voice-heavy traffic mix (avg 300 bytes/packet) while using GRE/IPSec
brings the 3845, and it's younger sibling the 3945, to it's knees
around 35-40Mb/s.

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

[c-nsp] 3845 maxing out at 400 Mbps

[Frank Bulk]

We have two 3845's as border routers, each with three GigE interfaces (one
facing upstream, the other downstream, the third facing the other 3845).
The first 3845 has a typical packet-size mix (residential/business Internet)
is consistently maxing out at 400 Mbps (predominately ingress because of
asymmetric routing) running at about 43 kpps and 40% CPU.  It's flat-lines
very evenly, uncannily so.  We checked and double-checked transport and it's
set much higher, the same as the second 3845.

The second 3845, which has a mix of both ingress and egress traffic at a
combined 82 kpps (35 kpps ingress/50 kpps egress) but lower combined 360
Mbps operates at a higher CPU (presumably because there's also egress
traffic) with no flatlining.

The ACLs are BCP 38-oriented with eBGP; no rate-limiting.  We're running
124-11.XW2.

Any ideas?  The numbers are well below Cisco's router spec sheet.

Frank

___
cisco-nsp 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] 3845 maxing out at 400 Mbps

[Frank Bulk]

Packet sizes are believed to be roughly equivalent between both 3845's
because our upstream is just preffing some subnets toward one path than
another.  I checked everything CEF/interface related on both routers and it
all appears to be correct and healthy.

Thanks,

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tony Varriale
Sent: Monday, March 28, 2011 10:24 PM
To: cisco-nsp
Subject: Re: [c-nsp] 3845 maxing out at 400 Mbps

On 3/28/2011 9:14 PM, Frank Bulk wrote:
 We have two 3845's as border routers, each with three GigE interfaces (one
 facing upstream, the other downstream, the third facing the other 3845).
 The first 3845 has a typical packet-size mix (residential/business
Internet)
 is consistently maxing out at 400 Mbps (predominately ingress because of
 asymmetric routing) running at about 43 kpps and 40% CPU.  It's flat-lines
 very evenly, uncannily so.  We checked and double-checked transport and
it's
 set much higher, the same as the second 3845.

 The second 3845, which has a mix of both ingress and egress traffic at a
 combined 82 kpps (35 kpps ingress/50 kpps egress) but lower combined 360
 Mbps operates at a higher CPU (presumably because there's also egress
 traffic) with no flatlining.

 The ACLs are BCP 38-oriented with eBGP; no rate-limiting.  We're running
 124-11.XW2.

 Any ideas?  The numbers are well below Cisco's router spec sheet.

 Frank
The first idea is pretty obvious: different packet sizes.  Why so?  The 
second idea would be to make sure you are staying in the CEF path as 
much as possible.  Verify that yet?

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] DHCP_PD usage for PPPoE Access

[Frank Bulk]

Why would the IPv6 address on the WAN interface ever be seen?  Clients
attached to the CE router would be using the delegated prefix...

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Miquel van
Smoorenburg
Sent: Friday, March 25, 2011 7:51 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] DHCP_PD usage for PPPoE Access

snip

The advantage is that you *know* what address or range the CPE has. If 
it also uses an address gotten via SLAAC on the WAN interface, how are 
you going to find the customer when the government asks who is (or was) 
behind this IPv6 address and it's from your shared pool ?

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] DHCP_PD usage for PPPoE Access

[Frank Bulk]

This approach was discouraged ipv6-ops listserv and one person pointed out
that this violates an RFC:
http://lists.cluenet.de/pipermail/ipv6-ops/2011-January/004677.html 

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Victor Lyapunov
Sent: Thursday, March 24, 2011 10:30 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] DHCP_PD usage for PPPoE Access

Hello

I have been testing some scenarios for IPv6 over broadband
connections. The setup is a the most common one, the CPE gets

-One ::/128 WAN ipv6 address using autonegotiaton.
-A signle ::/56 LAN subnet for the user networks, through DHCP-PD
(further subneted into /64 subnets for the various VLANs in the CPE)

For this setup the NAS server is configured with a local ipv6 pool for
WAN address assignment (autonegotiation)

  ipv6 local pool PPPOE 2001:100::/64 128 shared

And a second pool used by the DHCP_PD

 ipv6 local pool LAN 2001:200::/48 56

In this way I have to maintain two different pools (one for CPEs WAN
and one LAN addressing).
A possible alternative that is discussed, is having the NAS allocate
just the DHCP_PD ::/56 prefix to the CPE (as far as global addresses
are concerned). And then configure the CPE to use the first of the
resulting 256 ::/64 subnets for the WAN and the rest for the LANs.

What is your experience, is the second alternative worth pursuing? Is
there a common practice?

Thanx for the input
___
cisco-nsp 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] DHCP_PD usage for PPPoE Access

[Frank Bulk]

Based on what I've seen of residential IPv6 CE routers, that would be a very
unusual configuration, in fact, perhaps impossible.

Frank

-Original Message-
From: Miquel van Smoorenburg [mailto:miqu...@cistron.nl] 
Sent: Friday, March 25, 2011 4:43 PM
To: frnk...@iname.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] DHCP_PD usage for PPPoE Access

There's always a customer that bridges the PPP connection to a PC on 
which the connection is terminated.

And though we don't want it, modems will turn up that do IPv6 NAT.

And what address do you think will be used as source address for 
connections originating from the CPE ? Like SIP ?

In all those cases, the WAN address is used for outgoing connections.

Mike.

On 25-03-11 9:16 PM, Frank Bulk wrote:
 Why would the IPv6 address on the WAN interface ever be seen?  Clients
 attached to the CE router would be using the delegated prefix...

 Frank

 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net
 [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Miquel van
 Smoorenburg
 Sent: Friday, March 25, 2011 7:51 AM
 To: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] DHCP_PD usage for PPPoE Access

 snip

 The advantage is that you *know* what address or range the CPE has. If
 it also uses an address gotten via SLAAC on the WAN interface, how are
 you going to find the customer when the government asks who is (or was)
 behind this IPv6 address and it's from your shared pool ?

 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] DHCP_PD usage for PPPoE Access

[Frank Bulk]

I'm sorry, I don't follow how these excerpts from ipv6-cpe-router are
recommending using a /64 out of the delegated prefix on the WAN interface.

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Miquel van
Smoorenburg
Sent: Friday, March 25, 2011 4:52 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] DHCP_PD usage for PPPoE Access

http://potaroo.net/ietf/all-ids/draft-ietf-v6ops-ipv6-cpe-router-08.txt

WAA-8:  If the IPv6 CE router does not acquire global IPv6
address(es) from either SLAAC or DHCPv6, then it MUST create
global IPv6 address(es) from its delegated prefix(es) and
configure those on one of its internal virtual network
interfaces.

WAA-9:  As a router the IPv6 CE router MUST follow the weak host
model [RFC1122].  When originating packets out an interface
it will use a source address from another of its interfaces
if the outgoing interface does not have an address of
suitable scope.

In short, put prefix::Y/64 on a loopback interface, then make the WAN 
interface ipv6 unnumbered loopback X (or something that has the same 
effect - in fact it should behave like that by default)

Mike.

On 25-03-11 10:03 PM, Frank Bulk wrote:
 This approach was discouraged ipv6-ops listserv and one person pointed out
 that this violates an RFC:
 http://lists.cluenet.de/pipermail/ipv6-ops/2011-January/004677.html

 Frank

 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net
 [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Victor Lyapunov
 Sent: Thursday, March 24, 2011 10:30 AM
 To: cisco-nsp@puck.nether.net
 Subject: [c-nsp] DHCP_PD usage for PPPoE Access

 Hello

 I have been testing some scenarios for IPv6 over broadband
 connections. The setup is a the most common one, the CPE gets

 -One ::/128 WAN ipv6 address using autonegotiaton.
 -A signle ::/56 LAN subnet for the user networks, through DHCP-PD
 (further subneted into /64 subnets for the various VLANs in the CPE)

 For this setup the NAS server is configured with a local ipv6 pool for
 WAN address assignment (autonegotiation)

ipv6 local pool PPPOE 2001:100::/64 128 shared

 And a second pool used by the DHCP_PD

   ipv6 local pool LAN 2001:200::/48 56

 In this way I have to maintain two different pools (one for CPEs WAN
 and one LAN addressing).
 A possible alternative that is discussed, is having the NAS allocate
 just the DHCP_PD ::/56 prefix to the CPE (as far as global addresses
 are concerned). And then configure the CPE to use the first of the
 resulting 256 ::/64 subnets for the WAN and the rest for the LANs.

 What is your experience, is the second alternative worth pursuing? Is
 there a common practice?

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

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

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

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

Re: [c-nsp] ARP strangeness

[Frank Bulk - iName.com]

No, the FTTH doesn't allow broadcasts, at all. =(

Right now the ARP timeout is 480 seconds, CAM is 540 seconds, and the FTTH's
FDB is 900 seconds.

If the CPE had a reasonable ARP timeout, it would refresh the ARP entry for
it's default gateway (7609) upon the first CPE-initiated packet after a
period of deafness, but it doesn't.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: Wednesday, January 12, 2011 4:09 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

On 01/11/2011 08:06 PM, Keegan Holley wrote:

 That doesn't make sense though.  The cpe will need to broadcast for the
 initial request and after reboots regardless of what the provider router
 does.  The device that was blocking broadcast was a third party FTTH
device.
   I get the feeling I'm missing something here though.  Maybe it only
allows
 broadcast for a specific interval after it detects a link down/link up.

As I understood it, the FTTH device permits broadcasts but they're only
flooded on ports with FDB entries (!). So, once the FDB entry expires
(as a result of a quiet CPE) it's impossible to refresh the ARP (and
FDB) entry from the outside - only the CPE could do it, and it isn't
doing it.

Therefore there is a need to tune ARP timers well below FDB timers on
the FTTH device, to ensure that even for quiet hosts, ARP refresh
traffic from the 7600 keeps the state.

This does seem like a broken smart layer2 to me, but I'm sure someone
thought it was a good idea ;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/


___
cisco-nsp 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] ARP strangeness

[Frank Bulk - iName.com]

Yes, broadcast traffic blocked from the headend toward the CPE.

The challenge is as you described, getting the CPE in the home environment
to ARP for its default gateway more regularly.

Frank

-Original Message-
From: Rodney Dunn [mailto:rod...@cisco.com]
Sent: Wednesday, January 12, 2011 8:58 AM
To: Keegan Holley
Cc: frnk...@iname.com; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

I thought it was stated it only blocked them from the headend out
towards the CPE. As long as you had them originated from the CPE (which
in a home environment makes some sense as it's usually traffic
originated from the CPE not servers hosted there..typically that is) one
wouldn't need broadcast from the headend router if the refresh was unicast.

I'm not advocating for that as the optimal solution by any means. ;)

Rodney


On 1/11/11 3:06 PM, Keegan Holley wrote:



 On Tue, Jan 11, 2011 at 2:50 PM, Rodney Dunn rod...@cisco.com
 mailto:rod...@cisco.com wrote:



 On 1/11/11 11:49 AM, Keegan Holley wrote:

 Possibly a stupid question, but I thought ARP had to be broadcast
 because the mac address of the destination was unknown.


 That is true for the first request. For subsequent arp refreshes the
 most efficient way is to unicast it.


 That's what I said.  However, having an ethernet that doesn't support
 broadcast would make that first entry impossible.  The problem would
 repeat after reboots or power outages.




   If the CPE has

 the correct mac address to unicast an ARP request, why would it
 need to
 arp in the first place?


 To make sure the CPE is still alive and responding.


 RIght but it can only do that if it has already successfully arp'd so I
 think we are saying the same thing.




   I suppose I can understand renewing the entry

 via unicast, but there will always be a need for broadcast ARP.
   It just
 seems strange to implement an ethernet based device and block all
 broadcast traffic. Am I missing something?


 I didn't go back and read the entire thread to remember what was
 blocking the broadcast and understand the thought logic of whey they
 do it. It may would be, and possibly has some logic to it, that in a
 CPE environment you always rely on traffic originated at the CPE to
 trigger the arp so you block broadcast out to the CPE not coming
 from the CPE.


 That doesn't make sense though.  The cpe will need to broadcast for the
 initial request and after reboots regardless of what the provider router
 does.  The device that was blocking broadcast was a third party FTTH
 device.  I get the feeling I'm missing something here though.  Maybe it
 only allows broadcast for a specific interval after it detects a link
 down/link up.





 On Mon, Jan 10, 2011 at 5:27 PM, Frank Bulk frnk...@iname.com
 mailto:frnk...@iname.com
 mailto:frnk...@iname.com mailto:frnk...@iname.com wrote:

 Thanks for explaining.

 Since the Linksys BEFRS41 does not ARP regularly, even after
 a DHCP
 RENEW
 and DHCP DISCOVER, and because the access gear blocks all
 broadcast
 traffic,
 the 7609-S will never (re-)populate its ARP entry.

 I'm going to see if the Linksys BEFRS41 has a configurable ARP
 expiration
 timer.  If so, dropping it to 10 minutes would cause it to
 unicast
 ARP for
 the default gateway, which would resolve the issue.

 Another possible option, I guess, is to extend the 7609-S ARP
 expiration to
 a longer time interval, but if the BEFRS41 is silent for
 even a second
 longer than the ARP timer, then I'm still stuck.

 I should really look at the behavior of other CPE to see how
 often they
 unicast ARP.

 Frank

 -Original Message-
 From: Rodney Dunn [mailto:rod...@cisco.com
 mailto:rod...@cisco.com mailto:rod...@cisco.com
 mailto:rod...@cisco.com]
 Sent: Monday, January 10, 2011 1:30 PM
 To: frnk...@iname.com mailto:frnk...@iname.com
 mailto:frnk...@iname.com mailto:frnk...@iname.com
 Cc: cisco-nsp@puck.nether.net
 mailto:cisco-nsp@puck.nether.net
 mailto:cisco-nsp@puck.nether.net
 mailto:cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] ARP strangeness

 It only gets updated on getting and ARP packet from the host.

 It is not updated based on L3 data level traffic flowing
 to/from the
 host.

 Rodney



 On 1/10/11 11:43 AM, Frank Bulk wrote:
   Does the ARP cache get populated, or updated, if the traffic
 comes into an
   L3 interface, or is it only populated

Re: [c-nsp] ARP strangeness

[Frank Bulk - iName.com]

Keegan:

 

You're correct - without broadcast support, re-population initiated from the
7609 is impossible.  Once it's expired, the FTTH access gear's design, which
blocks broadcast traffic, makes it impossible for the CPE to respond to the
broadcast ARP.  The FTTH access gear never allows broadcast traffic to
ingress from the 7609.  So the only thing that can re-populate the 7609's
ARP cache is an ARP request by the CPE, *but* the CPE only does that after a
DHCP exchange after power on, never again, even after a full DHCP exchange.

 

Frank

 

From: Keegan Holley [mailto:keegan.hol...@sungard.com] 
Sent: Tuesday, January 11, 2011 2:07 PM
To: rod...@cisco.com
Cc: frnk...@iname.com; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

 





On Tue, Jan 11, 2011 at 2:50 PM, Rodney Dunn rod...@cisco.com wrote:



On 1/11/11 11:49 AM, Keegan Holley wrote:

Possibly a stupid question, but I thought ARP had to be broadcast
because the mac address of the destination was unknown.

 

That is true for the first request. For subsequent arp refreshes the most
efficient way is to unicast it.

 

That's what I said.  However, having an ethernet that doesn't support
broadcast would make that first entry impossible.  The problem would repeat
after reboots or power outages.




 If the CPE has

the correct mac address to unicast an ARP request, why would it need to
arp in the first place?

 

To make sure the CPE is still alive and responding.

 

 

RIght but it can only do that if it has already successfully arp'd so I
think we are saying the same thing.




 I suppose I can understand renewing the entry

via unicast, but there will always be a need for broadcast ARP.  It just
seems strange to implement an ethernet based device and block all
broadcast traffic. Am I missing something?

 

I didn't go back and read the entire thread to remember what was blocking
the broadcast and understand the thought logic of whey they do it. It may
would be, and possibly has some logic to it, that in a CPE environment you
always rely on traffic originated at the CPE to trigger the arp so you block
broadcast out to the CPE not coming from the CPE.

 

 

That doesn't make sense though.  The cpe will need to broadcast for the
initial request and after reboots regardless of what the provider router
does.  The device that was blocking broadcast was a third party FTTH device.
I get the feeling I'm missing something here though.  Maybe it only allows
broadcast for a specific interval after it detects a link down/link up. 

 

 

 



On Mon, Jan 10, 2011 at 5:27 PM, Frank Bulk frnk...@iname.com

mailto:frnk...@iname.com wrote:

   Thanks for explaining.

   Since the Linksys BEFRS41 does not ARP regularly, even after a DHCP
   RENEW
   and DHCP DISCOVER, and because the access gear blocks all broadcast
   traffic,
   the 7609-S will never (re-)populate its ARP entry.

   I'm going to see if the Linksys BEFRS41 has a configurable ARP
   expiration
   timer.  If so, dropping it to 10 minutes would cause it to unicast
   ARP for
   the default gateway, which would resolve the issue.

   Another possible option, I guess, is to extend the 7609-S ARP
   expiration to
   a longer time interval, but if the BEFRS41 is silent for even a second
   longer than the ARP timer, then I'm still stuck.

   I should really look at the behavior of other CPE to see how often they
   unicast ARP.

   Frank

   -Original Message-

   From: Rodney Dunn [mailto:rod...@cisco.com mailto:rod...@cisco.com]
   Sent: Monday, January 10, 2011 1:30 PM

   To: frnk...@iname.com mailto:frnk...@iname.com
   Cc: cisco-nsp@puck.nether.net mailto:cisco-nsp@puck.nether.net
   Subject: Re: [c-nsp] ARP strangeness

   It only gets updated on getting and ARP packet from the host.

   It is not updated based on L3 data level traffic flowing to/from the
   host.

   Rodney



   On 1/10/11 11:43 AM, Frank Bulk wrote:
 Does the ARP cache get populated, or updated, if the traffic
   comes into an
 L3 interface, or is it only populated upon a successful ARP response?

 Frank

 -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 Rodney Dunn
 Sent: Wednesday, January 05, 2011 7:38 AM
 To: Jeff Kell

 Cc: cisco-nsp@puck.nether.net mailto:cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] ARP strangeness

 On 1/4/11 11:43 PM, Jeff Kell wrote:
 On 1/4/2011 9:01 PM, Rodney Dunn wrote:
 There were some changes to ARP at one point to provide some more
 triggered capability. I don't recall exactly what that was but the
 default behavior for many years was that we send a unicast arp
   to the
 destination 60 seconds prior to the arp timer set to expire. If we
 don't get a response we send it again when the timer pops and if no
 response

Re: [c-nsp] ARP strangeness

[Frank Bulk - iName.com]

There's no way for a smart L2 could compensate for the broadcast issue.
With a broadcast ARP the MAC address is not known, unlike a unicast ARP
where it is.  So the only way for that broadcast ARP to make it to the CPE,
which is unknown, is to blast it out to all the FTTH ports.

The FTTH vendor is going to support MACFF
(http://en.wikipedia.org/wiki/MAC-Forced_Forwarding), but that doesn't
really address the issue I've been having.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Keegan Holley
Sent: Wednesday, January 12, 2011 7:26 AM
To: Phil Mayers
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

On Wed, Jan 12, 2011 at 5:08 AM, Phil Mayers p.may...@imperial.ac.ukwrote:

 On 01/11/2011 08:06 PM, Keegan Holley wrote:


 That doesn't make sense though.  The cpe will need to broadcast for the
 initial request and after reboots regardless of what the provider router
 does.  The device that was blocking broadcast was a third party FTTH
 device.
  I get the feeling I'm missing something here though.  Maybe it only
 allows
 broadcast for a specific interval after it detects a link down/link up.


 As I understood it, the FTTH device permits broadcasts but they're only
 flooded on ports with FDB entries (!). So, once the FDB entry expires (as
a
 result of a quiet CPE) it's impossible to refresh the ARP (and FDB)
entry
 from the outside - only the CPE could do it, and it isn't doing it.

 Therefore there is a need to tune ARP timers well below FDB timers on the
 FTTH device, to ensure that even for quiet hosts, ARP refresh traffic
from
 the 7600 keeps the state.

 This does seem like a broken smart layer2 to me, but I'm sure someone
 thought it was a good idea ;o)



Thanks, I knew I had missed a detail somewhere.  It may be a longer route
but I'd also send a feature request to the FTTH vendor.  Opening up all
broadcast has potential security implications.  However, making the smart
layer-2 a little smarter and may be in order.  They could change the device
so that it could recognize when the CPE was trying to wake up.  They could
also implement some sort of directed broadcast where arp and other protocols
sent as broadcasts are only replicated to a single device.  Implementing
something similar to cisco private vlans would also work here.
___
cisco-nsp 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] ARP strangeness

[Frank Bulk - iName.com]

The order in which it fails (7609's ARP cache, 7609's MAC address table, and
FTTH gear's forwarding bridge table) has not yet been made clear, because
every since I started capturing state every 2 minutes, a week ago, it hasn't
happened again.

What you're describing should be all true.  My only assumption at this point
in time is that the pre-expiry and expiry ARPs don't make their way to the
FTTH gear, and its forwarding bridge table expires its entries.

Frank

-Original Message-
From: Rodney Dunn [mailto:rod...@cisco.com]
Sent: Tuesday, January 11, 2011 6:51 AM
To: frnk...@iname.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

Frank,

Maybe you could put it in a timeline for me as i think I'm still missing
what exactly is failing. Sorry, a bit slow the last few days.

The 7600 should send a *unicast* arp to every entry in it's arp cache 60
seconds prior to what you have the arp timer set to.
It will then send another just at the arp timer expiring *if* it didn't
get a response to the first one.

So if your arp timer on the 7600 is low enough it should keep L2 mac
forwarding state alive on all transit devices out to the CPE no?

Broadcast is only sent when the L2 mapping isn't known.

Rodney




On 1/10/11 5:27 PM, Frank Bulk wrote:
 Thanks for explaining.

 Since the Linksys BEFRS41 does not ARP regularly, even after a DHCP RENEW
 and DHCP DISCOVER, and because the access gear blocks all broadcast
traffic,
 the 7609-S will never (re-)populate its ARP entry.

 I'm going to see if the Linksys BEFRS41 has a configurable ARP expiration
 timer.  If so, dropping it to 10 minutes would cause it to unicast ARP for
 the default gateway, which would resolve the issue.

 Another possible option, I guess, is to extend the 7609-S ARP expiration
to
 a longer time interval, but if the BEFRS41 is silent for even a second
 longer than the ARP timer, then I'm still stuck.

 I should really look at the behavior of other CPE to see how often they
 unicast ARP.

 Frank

 -Original Message-
 From: Rodney Dunn [mailto:rod...@cisco.com]
 Sent: Monday, January 10, 2011 1:30 PM
 To: frnk...@iname.com
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] ARP strangeness

 It only gets updated on getting and ARP packet from the host.

 It is not updated based on L3 data level traffic flowing to/from the host.

 Rodney



 On 1/10/11 11:43 AM, Frank Bulk wrote:
 Does the ARP cache get populated, or updated, if the traffic comes into
an
 L3 interface, or is it only populated upon a successful ARP response?

 Frank

 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net
 [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rodney Dunn
 Sent: Wednesday, January 05, 2011 7:38 AM
 To: Jeff Kell
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] ARP strangeness

 On 1/4/11 11:43 PM, Jeff Kell wrote:
 On 1/4/2011 9:01 PM, Rodney Dunn wrote:
 There were some changes to ARP at one point to provide some more
 triggered capability. I don't recall exactly what that was but the
 default behavior for many years was that we send a unicast arp to the
 destination 60 seconds prior to the arp timer set to expire. If we
 don't get a response we send it again when the timer pops and if no
 response we invalidate the ARP entry.

 Umm, that sort of rocks my boat with regard to network monitoring
 assumptions...

 We have one of those NMS systems that periodically reads L2 devices for
 mac-address/port mapping and reads L3 devices ARP for mac-to-IP
 mapping.  Ideally, there should be no missing links (if the MAC is
 found, hopefully the ARP/IP is found, and vice-versa).


 That still holds true as long as a timer (sam cam ager) didn't pop
 sooner than your arp refresh timer.

 For the default mac-address aging time of 300 seconds, I had this notion
 that setting the ARP timeouts to 270 seconds would necessitate the
 router ARPing the device (assuming active traffic) prior to the
 mac-address aging out, keeping the mac-address table populated.

 Keep the other timers 60+ seconds out to be safe.


 But if the Cisco L3 behavior is to gratuitously do this for me before
 the ARP timeout... that changes things a bit.

 Is this default behavior across all the Cats, or just the 6500/7600?  Is
 it supervisor-specific?


 Traditionally generic to all of IOS. There may have been some platform
 specific thing that changed here that I have missed in the last couple
 of years though.

 Rodney

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


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

Re: [c-nsp] ARP strangeness

[Frank Bulk - iName.com]

VLAN per customer provides L2 separation/protection and would avoid the
problems we've had.  Just I don't like the (lack of) scalability of (extra)
management of that approach.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jared Mauch
Sent: Wednesday, January 19, 2011 9:41 AM
To: Tim Franklin
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness


On Jan 19, 2011, at 5:16 AM, Tim Franklin wrote:


 - Gert Doering g...@greenie.muc.de wrote:

 This sounds like a very very stupid design in the FTTH gear.

 But either not unique, or on some popular gear.

 I've recently reviewed the spec for a wholesale FTTH offering from a
certain incumbent which contains exactly the same caveats.

 In my particular case, I'd be sticking a managed Cisco on the end of the
service generating (and receiving) IPSLA probes if nothing else, so there
should never be silence long enough for the MAC learning to time out.  It
was a bit of a WTF? moment, though...

I've been continuing research on doing a small FTTH deployment, and my
general consensus/balancing point starts to look somewhere between:

1) Put everyone on a large(r) broadcast domain with bidi sfps (something
that would be nice if cisco would support more natively)
2) use a variety of kludges such as occam or other ftth gear to actually
terminate and possibly vlan/qos for voip, iptv, etc to make it happen.

Having not asked Frank what hardware he is using, it seems like It's a bug
that should be addressed.  The security model is intending to block some
activity but is actually creating greater problems.  Either the gear should
act more like a true bridge, or support the features necessary to terminate
the customers without trouble (and do things like IPv6 and other modern
tech).

Divorcing price from the equation entirely, I'd love to take something like
Nexus and use it for massive FTTH termination with vlans, pvlans, and other
capabilities supported in the Earl8.

- Jared
___
cisco-nsp 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] ARP strangeness

[Frank Bulk - iName.com]

Phil, we're doing exactly this (pinging) for the Linksys BEFRS41 customers
that have complained, until we find a way to mitigate or work around the
problem.

Known options at this time:
a) replace the CPE with something else (thought a customer should be able to
choose their own CPE and not have this issue)
b) put that ONT Ethernet port in bi-directional mode, so it can receive
broadcasts (hard to manage through future changes)
c) allow the FTTH gear to router (it will do the ARP to the CPE, but this
breaks our path toward IPv6 because the FTTH vendor's is at least a year or
two away from sufficient IPv6 support to do that).

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: Wednesday, January 19, 2011 5:24 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

On 19/01/11 07:47, Frank Bulk - iName.com wrote:
 Keegan:



 You're correct - without broadcast support, re-population initiated from
the
 7609 is impossible.  Once it's expired, the FTTH access gear's design,
which
 blocks broadcast traffic, makes it impossible for the CPE to respond to
the

I'm confused; Rodney mentioned up-thread that, in newer IOS, the
behaviour is different than many (myself included) had assumed. If I
understood him correctly:

  1. At expiry - 60 seconds, attempt to renew the ARP entry via unicast
  2. At expiry, attempt to renew the ARP entry via broadcast

Shouldn't the first step flow through the FTTH gear fine, and renew the
FDB entry?


Anyway - this is vile, but have you considered pinging the CPE from a
separate device as a way to keep the FDB entry alive?

We do this to keep quiet hosts in the FDB on our switches because the
mac-based-vlan implementation we're using is tied to FDB entry (not link
up/down state) and if a host goes quiet (like a printer not used in 5
minutes) the FDB entry (and vlan assignment) will expiry, and
unless/until the *host* sends a packet (which may be never) it's
unreachable.

We use fping every 4 minutes on 2 servers (offset by 2 minutes, so a
ping arrives every 120 nseconds) for this. We extract the IP addresses
from our registration database, but you could perhaps script it from a
walk of the 7600 ARP table (maybe even filter by OUI or MAC of the
devices you know need it?).

Just a thought...
___
cisco-nsp 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] ARP strangeness

[Frank Bulk - iName.com]

Gert, you couldn't be more insightful: I did a software upgrade of the 7609
a few weeks ago, which led our helpdesk to raise this issue to me.

Frank

-Original Message-
From: Gert Doering [mailto:g...@greenie.muc.de]
Sent: Wednesday, January 19, 2011 3:54 AM
To: Frank Bulk - iName.com
Cc: 'Keegan Holley'; rod...@cisco.com; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

Hi,

On Wed, Jan 19, 2011 at 01:47:20AM -0600, Frank Bulk - iName.com wrote:
 You're correct - without broadcast support, re-population initiated from
the
 7609 is impossible.  Once it's expired, the FTTH access gear's design,
which
 blocks broadcast traffic, makes it impossible for the CPE to respond to
the
 broadcast ARP.  The FTTH access gear never allows broadcast traffic to
 ingress from the 7609.  So the only thing that can re-populate the 7609's
 ARP cache is an ARP request by the CPE, *but* the CPE only does that after
a
 DHCP exchange after power on, never again, even after a full DHCP
exchange.

This sounds like a very very stupid design in the FTTH gear.

Imagine what happens if the 7609 needs to be rebooted - *all* customers
having to powercycle their CPEs?

(Also, the whole idea of blocking broadcasts from the ISP side is
bogus to start with - broadcasts from the CPE side are what needs to
be well-controlled and only distributed to the ISP PE...)

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-35655025
g...@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] ARP strangeness

[Frank Bulk]

Does the ARP cache get populated, or updated, if the traffic comes into an
L3 interface, or is it only populated upon a successful ARP response?

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rodney Dunn
Sent: Wednesday, January 05, 2011 7:38 AM
To: Jeff Kell
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

On 1/4/11 11:43 PM, Jeff Kell wrote:
 On 1/4/2011 9:01 PM, Rodney Dunn wrote:
 There were some changes to ARP at one point to provide some more
 triggered capability. I don't recall exactly what that was but the
 default behavior for many years was that we send a unicast arp to the
 destination 60 seconds prior to the arp timer set to expire. If we
 don't get a response we send it again when the timer pops and if no
 response we invalidate the ARP entry.

 Umm, that sort of rocks my boat with regard to network monitoring
 assumptions...

 We have one of those NMS systems that periodically reads L2 devices for
 mac-address/port mapping and reads L3 devices ARP for mac-to-IP
 mapping.  Ideally, there should be no missing links (if the MAC is
 found, hopefully the ARP/IP is found, and vice-versa).


That still holds true as long as a timer (sam cam ager) didn't pop 
sooner than your arp refresh timer.

 For the default mac-address aging time of 300 seconds, I had this notion
 that setting the ARP timeouts to 270 seconds would necessitate the
 router ARPing the device (assuming active traffic) prior to the
 mac-address aging out, keeping the mac-address table populated.

Keep the other timers 60+ seconds out to be safe.


 But if the Cisco L3 behavior is to gratuitously do this for me before
 the ARP timeout... that changes things a bit.

 Is this default behavior across all the Cats, or just the 6500/7600?  Is
 it supervisor-specific?


Traditionally generic to all of IOS. There may have been some platform 
specific thing that changed here that I have missed in the last couple 
of years though.

Rodney

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

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

Re: [c-nsp] ARP strangeness

[Frank Bulk]

Thanks for explaining.  

Since the Linksys BEFRS41 does not ARP regularly, even after a DHCP RENEW
and DHCP DISCOVER, and because the access gear blocks all broadcast traffic,
the 7609-S will never (re-)populate its ARP entry.  

I'm going to see if the Linksys BEFRS41 has a configurable ARP expiration
timer.  If so, dropping it to 10 minutes would cause it to unicast ARP for
the default gateway, which would resolve the issue.

Another possible option, I guess, is to extend the 7609-S ARP expiration to
a longer time interval, but if the BEFRS41 is silent for even a second
longer than the ARP timer, then I'm still stuck.  

I should really look at the behavior of other CPE to see how often they
unicast ARP.

Frank

-Original Message-
From: Rodney Dunn [mailto:rod...@cisco.com] 
Sent: Monday, January 10, 2011 1:30 PM
To: frnk...@iname.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

It only gets updated on getting and ARP packet from the host.

It is not updated based on L3 data level traffic flowing to/from the host.

Rodney



On 1/10/11 11:43 AM, Frank Bulk wrote:
 Does the ARP cache get populated, or updated, if the traffic comes into an
 L3 interface, or is it only populated upon a successful ARP response?

 Frank

 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net
 [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rodney Dunn
 Sent: Wednesday, January 05, 2011 7:38 AM
 To: Jeff Kell
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] ARP strangeness

 On 1/4/11 11:43 PM, Jeff Kell wrote:
 On 1/4/2011 9:01 PM, Rodney Dunn wrote:
 There were some changes to ARP at one point to provide some more
 triggered capability. I don't recall exactly what that was but the
 default behavior for many years was that we send a unicast arp to the
 destination 60 seconds prior to the arp timer set to expire. If we
 don't get a response we send it again when the timer pops and if no
 response we invalidate the ARP entry.

 Umm, that sort of rocks my boat with regard to network monitoring
 assumptions...

 We have one of those NMS systems that periodically reads L2 devices for
 mac-address/port mapping and reads L3 devices ARP for mac-to-IP
 mapping.  Ideally, there should be no missing links (if the MAC is
 found, hopefully the ARP/IP is found, and vice-versa).


 That still holds true as long as a timer (sam cam ager) didn't pop
 sooner than your arp refresh timer.

 For the default mac-address aging time of 300 seconds, I had this notion
 that setting the ARP timeouts to 270 seconds would necessitate the
 router ARPing the device (assuming active traffic) prior to the
 mac-address aging out, keeping the mac-address table populated.

 Keep the other timers 60+ seconds out to be safe.


 But if the Cisco L3 behavior is to gratuitously do this for me before
 the ARP timeout... that changes things a bit.

 Is this default behavior across all the Cats, or just the 6500/7600?  Is
 it supervisor-specific?


 Traditionally generic to all of IOS. There may have been some platform
 specific thing that changed here that I have missed in the last couple
 of years though.

 Rodney

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

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

Re: [c-nsp] ARP strangeness

[Frank Bulk]

Yes, broken spoke would be one thing to call it.  Another cisco-nsp reader
guessed what FTTH platform I have, because they've seen the same issue.
I've also posted on the vendor's closed web forum and I'll see if I get any
responses there.

With the current settings our test CPE remains a live spoke.  If it would
fail, what you're suggesting regarding a span egress would be our next step.

Frank

-Original Message-
From: Rodney Dunn [mailto:rod...@cisco.com] 
Sent: Wednesday, January 05, 2011 7:35 AM
To: frnk...@iname.com
Cc: 'Keegan Holley'; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

snip

 Broadcast ARPs, due to the FTTH's L2 security protection mechanisms, are
not
 passed on.  Once the MAC entry ages out of the FTTH, it has to relearn it
 from the CPE (I think via ARP) before it will pass thru certain types of
 traffic.

Whoaaok. That means you could have a broken spoke if the main 
traffic is out towards the CPE and no CPE originated traffic. Unlikely 
I'm sure but not impossible.

 The rest of what you're describing about ARP expiration makes sense.

Ok. There were some arp code optimizations that I'd have to dig back up 
and see if it changed any of the legacy behavior but I don't think it did.

What is really needed here would be the span egress the 7600 port 
watching for those unicast refreshes. If that doesn't happen it's a bug 
on the 7600. If they do then it's likely an issue downstream.

Rodney


 Thanks,

 Frank

 -Original Message-
 From: Rodney Dunn [mailto:rod...@cisco.com]
 Sent: Tuesday, January 04, 2011 8:01 PM
 To: frnk...@iname.com
 Cc: 'Keegan Holley'; cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] ARP strangeness

 On 1/3/11 11:13 PM, Frank Bulk - iName.com wrote:
 The 7609 does stop ARPing after receiving a reply from the CPE, but the
 7609
 ARPs again 7 minutes later.  One person told me off-list that Cisco
 doesn't
 expire an ARP entry before checking its ARP entries by doing an ARP
 request.
 Since ARP timeout is set for 8 minutes, perhaps Cisco's approach is to
ARP
 the host one minute before expiration.

 There were some changes to ARP at one point to provide some more
 triggered capability. I don't recall exactly what that was but the
 default behavior for many years was that we send a unicast arp to the
 destination 60 seconds prior to the arp timer set to expire. If we don't
 get a response we send it again when the timer pops and if no response
 we invalidate the ARP entry.


 Because the FTTH product has its own smart-L2 implementation with a MAC
 address expiration time of 7 minutes, it won't forward directed or
 broadcast
 ARP requests from the 7609 once the CPE's MAC address has expired from
the
 FTTH's MAC table.

 I wonder if you are missing one and then getting in to a race condition
 of the FTTH product not forwarding. If so it would seem you need to set
 the arp refresh down to a value less than the timeout of the transport
gear.


 Once the CPE goes deaf, even a full DHCP exchange doesn't
 wake up the connection.  Only power-cycling the BEFRS41 resolves the
 issue.  The difference between a power cycle and a full DHCP exchange is
 that the BEFSR41 does an ARP request for the default router (7609) after
 the
 DHCP exchange.

 If you lose the arp from the 7609 and you ping from it directly we
 should send a broadcast arp.

 Not sure where you are getting the packet capture but a span directly
 off the port is what you need to see if we don't send those two
 refreshes (one 60 seconds prior to the timer expiring and the second on
 the timer expiring). If we do send those and no response then data
 driven from the 7609 (packets headed towards that remote IP) should
 trigger the arp broadcast out again.

 Rodney



 I've extended the MAC address expiration time of the FTTH link to 15
 minutes
 (two times the 7 minutes plus 1 minute) and we'll see how that goes.

 Frank

 -Original Message-
 From: Keegan Holley [mailto:keegan.hol...@sungard.com]
 Sent: Monday, January 03, 2011 7:14 PM
 To:frnk...@iname.com
 Cc:cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] ARP strangeness

 The 7600 should stop arping if it has gotten a reply.  What happens when
 you
 ping your test CPE both from the router and from another node behind it?
 You can also run he command sh ip cef exact-match to see what the router
 is
 doing with a specific source-destination ip pair. If nothing strange pops
 up
 then it's probably a bug.

 Sent from my iPhone

 On Jan 3, 2011, at 12:58 PM, Frank Bulkfrnk...@iname.com   wrote:

 We have over a thousand FTTH customers hanging off a VLAN on our 7609-S
 running 12.2SRE3.  Those who have Linksys BEFRS41 (wired-only routers)
 are
 complaining about lack of Internet access after many hours or days of
 idle
 time (not using their PC or other devices).  Those who have Linksys
 WRT54G
 (wireless) have no complaints (my guess is that they're sending packets
 out
 regularly).

 We replicated this in our CO

Re: [c-nsp] ARP strangeness

[Frank Bulk]

This information is golden.  

 

To make sure I'm understanding you correctly, are you implying that because
the CPE uses BOOTP with a broadcast flag, that when the FTTH access
equipment has expired its bridge forwarding table it doesn't re-populate,
and therefore incoming traffic towards the CPE never comes through because
there is no unicast traffic from the CPE?

 

Frank

 

From: Chad Whitten [mailto:chadwick.whit...@gmail.com] 
Sent: Wednesday, January 05, 2011 11:46 AM
To: frnk...@iname.com; Cisco List
Subject: Re: [c-nsp] ARP strangeness

 

This is a problem with how the linksys sends out the DHCP request for
renewal.  The BEFSR41 and BEFSR81 use a broadcast bootp flag, whereas all
other CPE devices use a unicast bootp flag.  When using the broadcast bootp
flag the Cisco will send an arp broadcast which is dropped by the access
equipment.

 

 

On Wed, Jan 5, 2011 at 11:32 AM, Frank Bulk frnk...@iname.com wrote:

Yes, broken spoke would be one thing to call it.  Another cisco-nsp reader
guessed what FTTH platform I have, because they've seen the same issue.
I've also posted on the vendor's closed web forum and I'll see if I get any
responses there.

With the current settings our test CPE remains a live spoke.  If it would
fail, what you're suggesting regarding a span egress would be our next step.


Frank

-Original Message-
From: Rodney Dunn [mailto:rod...@cisco.com]

Sent: Wednesday, January 05, 2011 7:35 AM
To: frnk...@iname.com
Cc: 'Keegan Holley'; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

snip

 Broadcast ARPs, due to the FTTH's L2 security protection mechanisms, are
not
 passed on.  Once the MAC entry ages out of the FTTH, it has to relearn it
 from the CPE (I think via ARP) before it will pass thru certain types of
 traffic.

Whoaaok. That means you could have a broken spoke if the main
traffic is out towards the CPE and no CPE originated traffic. Unlikely
I'm sure but not impossible.

 The rest of what you're describing about ARP expiration makes sense.

Ok. There were some arp code optimizations that I'd have to dig back up
and see if it changed any of the legacy behavior but I don't think it did.

What is really needed here would be the span egress the 7600 port
watching for those unicast refreshes. If that doesn't happen it's a bug
on the 7600. If they do then it's likely an issue downstream.

Rodney


 Thanks,

 Frank

 -Original Message-
 From: Rodney Dunn [mailto:rod...@cisco.com]
 Sent: Tuesday, January 04, 2011 8:01 PM
 To: frnk...@iname.com
 Cc: 'Keegan Holley'; cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] ARP strangeness

 On 1/3/11 11:13 PM, Frank Bulk - iName.com wrote:
 The 7609 does stop ARPing after receiving a reply from the CPE, but the
 7609
 ARPs again 7 minutes later.  One person told me off-list that Cisco
 doesn't
 expire an ARP entry before checking its ARP entries by doing an ARP
 request.
 Since ARP timeout is set for 8 minutes, perhaps Cisco's approach is to
ARP
 the host one minute before expiration.

 There were some changes to ARP at one point to provide some more
 triggered capability. I don't recall exactly what that was but the
 default behavior for many years was that we send a unicast arp to the
 destination 60 seconds prior to the arp timer set to expire. If we don't
 get a response we send it again when the timer pops and if no response
 we invalidate the ARP entry.


 Because the FTTH product has its own smart-L2 implementation with a MAC
 address expiration time of 7 minutes, it won't forward directed or
 broadcast
 ARP requests from the 7609 once the CPE's MAC address has expired from
the
 FTTH's MAC table.

 I wonder if you are missing one and then getting in to a race condition
 of the FTTH product not forwarding. If so it would seem you need to set
 the arp refresh down to a value less than the timeout of the transport
gear.


 Once the CPE goes deaf, even a full DHCP exchange doesn't
 wake up the connection.  Only power-cycling the BEFRS41 resolves the
 issue.  The difference between a power cycle and a full DHCP exchange is
 that the BEFSR41 does an ARP request for the default router (7609) after
 the
 DHCP exchange.

 If you lose the arp from the 7609 and you ping from it directly we
 should send a broadcast arp.

 Not sure where you are getting the packet capture but a span directly
 off the port is what you need to see if we don't send those two
 refreshes (one 60 seconds prior to the timer expiring and the second on
 the timer expiring). If we do send those and no response then data
 driven from the 7609 (packets headed towards that remote IP) should
 trigger the arp broadcast out again.

 Rodney



 I've extended the MAC address expiration time of the FTTH link to 15
 minutes
 (two times the 7 minutes plus 1 minute) and we'll see how that goes.

 Frank

 -Original Message-
 From: Keegan Holley [mailto:keegan.hol...@sungard.com]
 Sent: Monday, January 03, 2011 7:14 PM
 To:frnk

Re: [c-nsp] ARP strangeness

[Frank Bulk - iName.com]

Jared:

Thanks.  We're running 12.2(33)SRE2, which is pretty recent.  I could only
hope that those CEF-MFI re-writes made it in the SR code line.

As mentioned in the original post, the CAM timers are 540 seconds, and
that's because Cisco documentation says it should be longer than the ARP
time, which I have set to 480 seconds.

Frank

-Original Message-
From: Jared Mauch [mailto:ja...@puck.nether.net]
Sent: Tuesday, January 04, 2011 9:35 PM
To: frnk...@iname.com
Cc: 'Keegan Holley'; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

One thing to watch out for is the 6500/7600 (aka 76k) has the SUP and the
MFSC that may have independent arp/mac/cam information that can also be out
of sync.

Depending on your layer-2 topology, software version, etc.. it's also
possible that large numbers of MACs out a single interface can cause
troubles as well (we've seen TFIB tracebacks due to arp timer churn in the
SXF code creating duplicate cef events).

A lot of this is better in newer code, eg: SXI5 (post cef-mfi rewrite that
appeared in SXH).

If you are doing layer-2 vlans at all, check your cam timers, eg:

Router#sh mac-address-table aging-time
VlanAging Time
--
Global  300
no vlan age other than global age configured

These may also be causing the troubles you are seeing.  You may want to
increase these timers to keep the SUP and MFSC aging closer to in-sync.

- Jared

On Jan 3, 2011, at 11:13 PM, Frank Bulk - iName.com wrote:

 The 7609 does stop ARPing after receiving a reply from the CPE, but the
7609
 ARPs again 7 minutes later.  One person told me off-list that Cisco
doesn't
 expire an ARP entry before checking its ARP entries by doing an ARP
request.
 Since ARP timeout is set for 8 minutes, perhaps Cisco's approach is to ARP
 the host one minute before expiration.

 Because the FTTH product has its own smart-L2 implementation with a MAC
 address expiration time of 7 minutes, it won't forward directed or
broadcast
 ARP requests from the 7609 once the CPE's MAC address has expired from the
 FTTH's MAC table.  Once the CPE goes deaf, even a full DHCP exchange
doesn't
 wake up the connection.  Only power-cycling the BEFRS41 resolves the
 issue.  The difference between a power cycle and a full DHCP exchange is
 that the BEFSR41 does an ARP request for the default router (7609) after
the
 DHCP exchange.

 I've extended the MAC address expiration time of the FTTH link to 15
minutes
 (two times the 7 minutes plus 1 minute) and we'll see how that goes.

 Frank

 -Original Message-
 From: Keegan Holley [mailto:keegan.hol...@sungard.com]
 Sent: Monday, January 03, 2011 7:14 PM
 To: frnk...@iname.com
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] ARP strangeness

 The 7600 should stop arping if it has gotten a reply.  What happens when
you
 ping your test CPE both from the router and from another node behind it?
 You can also run he command sh ip cef exact-match to see what the router
is
 doing with a specific source-destination ip pair. If nothing strange pops
up
 then it's probably a bug.

 Sent from my iPhone

 On Jan 3, 2011, at 12:58 PM, Frank Bulk frnk...@iname.com wrote:

 We have over a thousand FTTH customers hanging off a VLAN on our 7609-S
 running 12.2SRE3.  Those who have Linksys BEFRS41 (wired-only routers)
are
 complaining about lack of Internet access after many hours or days of
idle
 time (not using their PC or other devices).  Those who have Linksys
WRT54G
 (wireless) have no complaints (my guess is that they're sending packets
 out
 regularly).

 We replicated this in our CO and put a hub between the ONT and the
Linksys
 CPE so that we could capture those packets.  What we're seeing in that
 capture are directed ARP requests every 7 minutes from the 7609 to the
 Linksys with an ARP response from the Linksys.  After many hours, the
 7609-S
 stops sending the ARP requests (well, at least we're not seeing it come
 in,
 perhaps it did try).

 We currently have our ARP timeout set to 480 seconds and MAC address
table
 aging time to 540 seconds.  Why?  We use mac-address-table synchronize
 which is set to 160 seconds by default.  The recommendation from that
 command is to set ARP three times that, so that would be 480.  But it's
 also
 recommended that the MAC address table aging time be greater than the ARP
 timeout, so we added another 60 seconds on top.

 Two questions:
 - why is the 7609 sending any directed ARP requests at all, every 7
 minutes?
 - why does it appear to stop sending them after many hours?

 I'm all ears if we should be using different expiration values, but the
 numbers I'm using are based on reading a lot of cisco-nsp archives and
 Cisco
 tech articles.

 Frank

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

Re: [c-nsp] ARP strangeness

[Frank Bulk - iName.com]

Rodney:

I can't recall seeing that ARP refresh documented anywhere, but it's
obviously happening.

I agree with you about the race condition.  Yesterday I set the FTTH MAC
timeout to be 2 times the ARP refresh interval plus 60 seconds (to give me
some room if the ARP unicast refresh doesn't happen exactly after 7
minutes).

Broadcast ARPs, due to the FTTH's L2 security protection mechanisms, are not
passed on.  Once the MAC entry ages out of the FTTH, it has to relearn it
from the CPE (I think via ARP) before it will pass thru certain types of
traffic.

The rest of what you're describing about ARP expiration makes sense.

Thanks,

Frank

-Original Message-
From: Rodney Dunn [mailto:rod...@cisco.com]
Sent: Tuesday, January 04, 2011 8:01 PM
To: frnk...@iname.com
Cc: 'Keegan Holley'; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

On 1/3/11 11:13 PM, Frank Bulk - iName.com wrote:
 The 7609 does stop ARPing after receiving a reply from the CPE, but the
7609
 ARPs again 7 minutes later.  One person told me off-list that Cisco
doesn't
 expire an ARP entry before checking its ARP entries by doing an ARP
request.
 Since ARP timeout is set for 8 minutes, perhaps Cisco's approach is to ARP
 the host one minute before expiration.

There were some changes to ARP at one point to provide some more
triggered capability. I don't recall exactly what that was but the
default behavior for many years was that we send a unicast arp to the
destination 60 seconds prior to the arp timer set to expire. If we don't
get a response we send it again when the timer pops and if no response
we invalidate the ARP entry.


 Because the FTTH product has its own smart-L2 implementation with a MAC
 address expiration time of 7 minutes, it won't forward directed or
broadcast
 ARP requests from the 7609 once the CPE's MAC address has expired from the
 FTTH's MAC table.

I wonder if you are missing one and then getting in to a race condition
of the FTTH product not forwarding. If so it would seem you need to set
the arp refresh down to a value less than the timeout of the transport gear.


   Once the CPE goes deaf, even a full DHCP exchange doesn't
 wake up the connection.  Only power-cycling the BEFRS41 resolves the
 issue.  The difference between a power cycle and a full DHCP exchange is
 that the BEFSR41 does an ARP request for the default router (7609) after
the
 DHCP exchange.

If you lose the arp from the 7609 and you ping from it directly we
should send a broadcast arp.

Not sure where you are getting the packet capture but a span directly
off the port is what you need to see if we don't send those two
refreshes (one 60 seconds prior to the timer expiring and the second on
the timer expiring). If we do send those and no response then data
driven from the 7609 (packets headed towards that remote IP) should
trigger the arp broadcast out again.

Rodney



 I've extended the MAC address expiration time of the FTTH link to 15
minutes
 (two times the 7 minutes plus 1 minute) and we'll see how that goes.

 Frank

 -Original Message-
 From: Keegan Holley [mailto:keegan.hol...@sungard.com]
 Sent: Monday, January 03, 2011 7:14 PM
 To:frnk...@iname.com
 Cc:cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] ARP strangeness

 The 7600 should stop arping if it has gotten a reply.  What happens when
you
 ping your test CPE both from the router and from another node behind it?
 You can also run he command sh ip cef exact-match to see what the router
is
 doing with a specific source-destination ip pair. If nothing strange pops
up
 then it's probably a bug.

 Sent from my iPhone

 On Jan 3, 2011, at 12:58 PM, Frank Bulkfrnk...@iname.com  wrote:

 We have over a thousand FTTH customers hanging off a VLAN on our 7609-S
 running 12.2SRE3.  Those who have Linksys BEFRS41 (wired-only routers)
are
 complaining about lack of Internet access after many hours or days of
idle
 time (not using their PC or other devices).  Those who have Linksys
WRT54G
 (wireless) have no complaints (my guess is that they're sending packets
 out
 regularly).

 We replicated this in our CO and put a hub between the ONT and the
Linksys
 CPE so that we could capture those packets.  What we're seeing in that
 capture are directed ARP requests every 7 minutes from the 7609 to the
 Linksys with an ARP response from the Linksys.  After many hours, the
 7609-S
 stops sending the ARP requests (well, at least we're not seeing it come
 in,
 perhaps it did try).

 We currently have our ARP timeout set to 480 seconds and MAC address
table
 aging time to 540 seconds.  Why?  We use mac-address-table synchronize
 which is set to 160 seconds by default.  The recommendation from that
 command is to set ARP three times that, so that would be 480.  But it's
 also
 recommended that the MAC address table aging time be greater than the ARP
 timeout, so we added another 60 seconds on top.

 Two questions:
 - why is the 7609 sending any directed ARP requests at all, every 7

[c-nsp] ARP strangeness

[Frank Bulk]

We have over a thousand FTTH customers hanging off a VLAN on our 7609-S
running 12.2SRE3.  Those who have Linksys BEFRS41 (wired-only routers) are
complaining about lack of Internet access after many hours or days of idle
time (not using their PC or other devices).  Those who have Linksys WRT54G
(wireless) have no complaints (my guess is that they're sending packets out
regularly).

We replicated this in our CO and put a hub between the ONT and the Linksys
CPE so that we could capture those packets.  What we're seeing in that
capture are directed ARP requests every 7 minutes from the 7609 to the
Linksys with an ARP response from the Linksys.  After many hours, the 7609-S
stops sending the ARP requests (well, at least we're not seeing it come in,
perhaps it did try).  

We currently have our ARP timeout set to 480 seconds and MAC address table
aging time to 540 seconds.  Why?  We use mac-address-table synchronize
which is set to 160 seconds by default.  The recommendation from that
command is to set ARP three times that, so that would be 480.  But it's also
recommended that the MAC address table aging time be greater than the ARP
timeout, so we added another 60 seconds on top.

Two questions: 
- why is the 7609 sending any directed ARP requests at all, every 7 minutes?
- why does it appear to stop sending them after many hours?

I'm all ears if we should be using different expiration values, but the
numbers I'm using are based on reading a lot of cisco-nsp archives and Cisco
tech articles.

Frank

___
cisco-nsp 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] ARP strangeness

[Frank Bulk - iName.com]

The 7609 does stop ARPing after receiving a reply from the CPE, but the 7609
ARPs again 7 minutes later.  One person told me off-list that Cisco doesn't
expire an ARP entry before checking its ARP entries by doing an ARP request.
Since ARP timeout is set for 8 minutes, perhaps Cisco's approach is to ARP
the host one minute before expiration.

Because the FTTH product has its own smart-L2 implementation with a MAC
address expiration time of 7 minutes, it won't forward directed or broadcast
ARP requests from the 7609 once the CPE's MAC address has expired from the
FTTH's MAC table.  Once the CPE goes deaf, even a full DHCP exchange doesn't
wake up the connection.  Only power-cycling the BEFRS41 resolves the
issue.  The difference between a power cycle and a full DHCP exchange is
that the BEFSR41 does an ARP request for the default router (7609) after the
DHCP exchange.

I've extended the MAC address expiration time of the FTTH link to 15 minutes
(two times the 7 minutes plus 1 minute) and we'll see how that goes.

Frank

-Original Message-
From: Keegan Holley [mailto:keegan.hol...@sungard.com]
Sent: Monday, January 03, 2011 7:14 PM
To: frnk...@iname.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP strangeness

The 7600 should stop arping if it has gotten a reply.  What happens when you
ping your test CPE both from the router and from another node behind it?
You can also run he command sh ip cef exact-match to see what the router is
doing with a specific source-destination ip pair. If nothing strange pops up
then it's probably a bug.

Sent from my iPhone

On Jan 3, 2011, at 12:58 PM, Frank Bulk frnk...@iname.com wrote:

 We have over a thousand FTTH customers hanging off a VLAN on our 7609-S
 running 12.2SRE3.  Those who have Linksys BEFRS41 (wired-only routers) are
 complaining about lack of Internet access after many hours or days of idle
 time (not using their PC or other devices).  Those who have Linksys WRT54G
 (wireless) have no complaints (my guess is that they're sending packets
out
 regularly).

 We replicated this in our CO and put a hub between the ONT and the Linksys
 CPE so that we could capture those packets.  What we're seeing in that
 capture are directed ARP requests every 7 minutes from the 7609 to the
 Linksys with an ARP response from the Linksys.  After many hours, the
7609-S
 stops sending the ARP requests (well, at least we're not seeing it come
in,
 perhaps it did try).

 We currently have our ARP timeout set to 480 seconds and MAC address table
 aging time to 540 seconds.  Why?  We use mac-address-table synchronize
 which is set to 160 seconds by default.  The recommendation from that
 command is to set ARP three times that, so that would be 480.  But it's
also
 recommended that the MAC address table aging time be greater than the ARP
 timeout, so we added another 60 seconds on top.

 Two questions:
 - why is the 7609 sending any directed ARP requests at all, every 7
minutes?
 - why does it appear to stop sending them after many hours?

 I'm all ears if we should be using different expiration values, but the
 numbers I'm using are based on reading a lot of cisco-nsp archives and
Cisco
 tech articles.

 Frank

 ___
 cisco-nsp 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] c3750x upgrade to 12.2(55)SE1 takes forever

[Frank Bulk - iName.com]

Would this apply to the 3750 Metro, too?

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Hilliard
Sent: Monday, December 20, 2010 12:28 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] c3750x upgrade to 12.2(55)SE1 takes forever

Just a heads-up for those planning to upgrade to 12.2(55)SE1 on the 3750X 
platform: this version includes both a bootloader upgrade and a hardware 
microcode upgrade.  I did a upgrade on a C3750X stack several days ago, 
which took fully 38 minutes of nail-scratching downtime before all stack 
members were back in service.

It doesn't mention the microcode upgrade in the release notes, nor give any 
hint that the upgrade will take a very long time indeed.  If there's anyone 
from Cisco listening: it would really help if this sort of thing was 
mentioned in the release notes - please!  Not everyone is in a position to 
lab-test their upgrades.

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] Freeing up an internal use VLAN on a 6509/Sup2/12.1(E) Native mode box

[Frank Bulk - iName.com]

We ended marking those VLAN numbers as unavailable, and if your transport
provider should be to use VLAN translation/re-tagging to accommodate your
environment.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jason Lixfeld
Sent: Thursday, December 02, 2010 4:38 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Freeing up an internal use VLAN on a 6509/Sup2/12.1(E)
Native mode box

I have a 6509/Sup2/12.1(13)E1 box that allocated VLAN1025 for internal use:

router#show vlan internal usage | i 1025
1025 FastEthernet5/13

My transport provider is delivering a TLS service to me on VLAN1025, so
needless to say, I can't create a VLAN1025 SVI to terminate this connection.
Getting the transport provider change the VLAN is going to be very
problematic so I need to know how to free up this VLAN on my side.  Changing
the internal allocation policy from ascending to descending following by a
reboot will, I'm hoping, cause the box to come back up and allocate a VLAN
to F5/13 from the high end of the range instead of the low end of the range
but I have no way to test this.

Anyone know if this will do the trick or is there something else that has to
be done as well or can be done instead to free up this VLAN.

Thanks in advance.
___
cisco-nsp 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] Bridging 802.1q tagged Ethernet traffic to multiple T-1 in a DS-3

[Frank Bulk - iName.com]

M(L)PPP is not an option

Frank

-Original Message-
From: Michael K. Smith - Adhost [mailto:mksm...@adhost.com] 
Sent: Wednesday, November 17, 2010 4:27 PM
To: frnk...@iname.com; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] Bridging 802.1q tagged Ethernet traffic to multiple T-1
in a DS-3

What's the encapsulation protocol of the T-1's?  I would think you could do
MPPP and put both T-1's into the same bridge group as the Ethernet
interface, but I'm not sure how that would work if it was using HDLC.

Mike

--
Michael K. Smith - CISSP, GSEC, GISP
Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
 boun...@puck.nether.net] On Behalf Of Frank Bulk
 Sent: Wednesday, November 17, 2010 1:51 PM
 To: cisco-nsp@puck.nether.net
 Subject: [c-nsp] Bridging 802.1q tagged Ethernet traffic to multiple T-1
in a
 DS-3
 
 Is it possible to use a Cisco 7206VXR to bridge 802.1q tagged Ethernet
 traffic to multiple T-1s within a DS-3?  The remote end, a RNC, can
 apparently take tagged traffic over multiple T-1's.
 
 We might be willing to live with the restriction of assigning certain
T-1's
 within the DS-3 to a certain 802.1q, but would like to take advantage of
 aggregation.
 
 Apparently we can't use PVCs, otherwise I would prefer that approach.
 
 Frank
 
 
 ___
 cisco-nsp 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] Bridging 802.1q tagged Ethernet traffic to multiple T-1 in a DS-3

[Frank Bulk]

Is it possible to use a Cisco 7206VXR to bridge 802.1q tagged Ethernet
traffic to multiple T-1s within a DS-3?  The remote end, a RNC, can
apparently take tagged traffic over multiple T-1's.  

We might be willing to live with the restriction of assigning certain T-1's
within the DS-3 to a certain 802.1q, but would like to take advantage of
aggregation.

Apparently we can't use PVCs, otherwise I would prefer that approach.

Frank


___
cisco-nsp 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] Migrating to a 7200 for DSL aggregation

[Frank Bulk]

You haven't mentioned current and anticipated PPS requirement.  If it's
really just one DS3 then a 7200VXR with NPE-G2 should be fine, otherwise if
your needs were 100+ Mbps and growing, the ASR1K, I'm told, is a good box.

We use 12.2(31)SB18 -- the latest in that series, but only because of a
resource bug that TAC said *may* be resolved in the latest release.  Came
across as just try. ;)

I haven't implemented any MLPPP myself, but as your research in the archives
has shown, it's not all roses.  I'm guessing ADSL2+ pair bonding or VDSL2
aren't options?

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Andy Dills
Sent: Tuesday, August 17, 2010 2:03 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Migrating to a 7200 for DSL aggregation


For the last decade, we've been using a Redback SMS 500 to terminate our 
DSL customers, delivered via ATM DS3.

Recently, however, a few customers (as well as the partners of the 
company) have expressed a desire to bond 2 DSL circuits.

Unfortunately, we've discovered that the customers who have Comtrend 
modems cannot negotiate LCP with the Redback when ppp multilink is 
enabled...after working through this with Comtrend, they demonstrated that 
the Redback is violating RFC 1990, and because of this and the fact that 
the Comtrend modem didn't support MP, it was unable to negotiate LCP.

At the same time, we're starting to get a little nervous about relying on 
Redback as a platform, given that all the equipment we currently use is 
EOL and Redback has long since been acquired. We have spares, but clearly 
it's a deadend.

So, we're investigating migrating to a 7200(VXR) platform for DSL 
aggregation.

I was curious about a couple of things:

1) Given that Verizon delivers all of the DSL connections on a 
region-based series of UBR PVCs, what is the best way to bond two DSL 
circuits, given that they would not be on private PVCs? Is MLPPP possible 
in that configuration? Or would I need to do CEF per-packet? Given the 
archives on this list, I'm leaning toward per-packet CEF via radius 
assigned routes. I know we won't get ideal performance, but it should be 
an improvement over a single DSL connection nonetheless.

2) What IOS do people suggest for ATM DSL aggregation...the router won't 
be doing anything else other than OSPF.

Thanks,
Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
___
cisco-nsp 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] Safe debug commands for ATM DSL PPPoE troubleshooting?

[Frank Bulk]

Been there, done that, got the t-shirt.  I strongly endorse using debug
conditions to minimize the chance of locking up.


Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of P C
Sent: Wednesday, July 28, 2010 11:23 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Safe debug commands for ATM DSL PPPoE troubleshooting?

We have a Cisco 7201 which takes in an ATM DS3 from the telco on which ADSL
connections running PPPoE are terminated.

At times when troubleshooting using all other methods fail, we need to debug
connection problems for an individual site or PVC.  However with the
quantity of connections on the BRAS, debugging can be dangerous at best, and
the wrong command can effectively hang the device.

Does anyone know (from experience) what debug commands are safe on a BRAS
like this, and what combination of more unsafe commands and debug
condition statements have you also find acceptable?

Code is 12.2SRE1 on a 7201.

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

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

Re: [c-nsp] QPPB on Cisco 3750-ME

[Frank Bulk - iName.com]

Is this a feature that only works on the ES ports of that switch?

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Chris Mason
Sent: Monday, July 26, 2010 12:01 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] QPPB on Cisco 3750-ME

Hi,

I am not having much luck on Google with regards to if this is
supported or not, but I currently have a 3750-ME running 12.2(44)SE6
and I am having some interesting results when trying to use QPPB. The
same configuration works perfectly well on an ISR, but the 3750 can be
quite feature limiting due to it's hardware nature. I wouldn't be
using a 3750 for this sort of thing unless I needed the throughput
with H-QoS.

I have a table-map applied under BGP which sets a precedence value
based on a community (standard QPPB) and I can see that CEF has this
precendence value saved ready to use:

Switch# show ip route 192.0.2.1
Routing entry for 192.0.2.0/24
  Known via bgp 64512, distance 20, metric 0
  Tag 100, precedence priority (1), type external -- IP Prec 1
  Last update from 192.168.0.1 00:47:11 ago
  Routing Descriptor Blocks:
  * 192.168.0.1, from 192.168.0.1, 00:47:11 ago
  Route metric is 0, traffic share count is 1
  AS Hops 6
  Route tag 100

I then define bgp-policy destination ip-prec-map on the ingress interface:

interface FastEthernet1/0/2
 no switchport
 ip address 10.254.0.1 255.255.255.0
 bgp-policy destination ip-prec-map
!

When I send traffic in on this interface it isn't being marked - I
have applied an outbound ACL which matches precedence values and I can
see it coming through as IP Prec 0. If I originate traffic with IP
Prec 1 then it comes through as IP Prec 1 on my ACL - the bgp-policy
statement doesn't appear to be doing anything at all.

Has anyone tried to use this feature on the 3750-ME before or am I
hitting a platform limitation?

Thanks,
Chris
___
cisco-nsp 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] Logging Server

[Frank Bulk - iName.com]

Did you look at Xangati, too, and if so, what did you think of it?

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wojciechowski
Sent: Tuesday, July 13, 2010 10:01 AM
To: Walter Keen; Mohammad Khalil; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Logging Server

For just Neflow I would like to give Plixer's Scrutinizer a plug. They also
have a syslog tool called LogAlot that I haven't tried out yet.

We just bought Scrutinizer and I can't imagine any other tool giving more
detail without doing packet sniffing.

My understanding is that once we upgrade to IOS 15 on our routers that
Netflow and NBAR will be integrated so instead of just  seeing device X is
talking on port 80 to another device - NBAR can help determine what is
traveling over port 80 (http or other) so we will have even more insight
into our traffic.

Thanks,

-Jeff


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Walter Keen
Sent: Tuesday, July 13, 2010 9:29 AM
To: Mohammad Khalil; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Logging Server

Logging as in Syslog (ksyslogd), netflow (nfsen), or
authentication/authorization for configuration (tacacs+ from shrubbery.net)

If anyone has suggestions other than the above, especially for netflow, I'd
love to hear them.


-Original Message-
From: cisco-nsp-boun...@puck.nether.net on behalf of Mohammad Khalil
Sent: Tue 7/13/2010 6:55 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Logging Server


Dears

what is the best free logging server to implement ?

_
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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

This electronic mail (including any attachments) may contain information
that is privileged, confidential, or otherwise protected from disclosure to
anyone other than its intended recipient(s). Any dissemination or use of
this electronic mail or its contents (including any attachments) by persons
other than the intended recipient(s) is strictly prohibited. If you have
received this message in error, please delete the original message in its
entirety (including any attachments) and notify us immediately by reply
email so that we may correct our internal records.  Midland Paper Company
accepts no responsibility for any loss or damage from use of this electronic
mail, including any damage resulting from a computer virus.

___
cisco-nsp 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] Cheapest Cisco desktop switch that supports Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs

[Frank Bulk - iName.com]

So it sounds like if an end-customer wants an *untagged* port off of an SP
switch that there aren't any/many options to deliver double-tagged traffic
to that SP switch.  Sounds like we can have double-tagged traffic between
the core and distribution, but when we bring it to the edge we need to take
strip off the outer tag.


|core  |

   || (double tagged)

| distribution |

   | (single tagged)

| Edge | SP switch at customer premise

   | (untagged)
customer

-Original Message-
From: sth...@nethelp.no [mailto:sth...@nethelp.no] 
Sent: Friday, July 09, 2010 3:45 AM
To: frnk...@iname.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Cheapest Cisco desktop switch that supports
Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs

 Thanks for explaining the semantical differences.  What I'm looking to do
is
 the termination -- wouldn't the ME3400 do the trick?

No, the ME3400 cannot terminate dual tagged VLANs (encapsulation dot1q
x second-dot1q y).

Steinar Haug, Nethelp consulting, sth...@nethelp.no

___
cisco-nsp 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] Cheapest Cisco desktop switch that supports Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs

[Frank Bulk - iName.com]

Thanks for explaining the semantical differences.  What I'm looking to do is
the termination -- wouldn't the ME3400 do the trick?

Frank

-Original Message-
From: sth...@nethelp.no [mailto:sth...@nethelp.no] 
Sent: Thursday, July 08, 2010 3:56 AM
To: frnk...@iname.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Cheapest Cisco desktop switch that supports
Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs

 What is the cheapest Cisco desktop switch that supports Q-in-Q?  Is it the
 ME-3400G-2CS-A?  We prefer the encapsulation dot1q x second-dot1q y
 approach.

Your last sentence doesn't make sense here. 

Q-in-Q generally refers to *tunneling* one VLAN trunk through an L2
network by adding an extra VLAN tag in front of the existing VLAN tag.

encapsulation dot1q x second-dot1q y is used to *terminate* a dual
tagged VLAN connection (typically an IP termination). This is very
different from *tunneling*.

So - do you want tunneling or termination? I don't believe there are
any Cisco desktop switches which can IP terminate a dual tagged VLAN
connection. There are, of course, plenty of desktop switches which
will do 802.1Q tunneling.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

___
cisco-nsp 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] Cheapest Cisco desktop switch that supports Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs

[Frank Bulk]

What is the cheapest Cisco desktop switch that supports Q-in-Q?  Is it the
ME-3400G-2CS-A?  We prefer the encapsulation dot1q x second-dot1q y
approach.

And why does one page on Cisco's site say: 
Q. What is 802.1Q Tunneling? Is it an IEEE standard?
A. With 802.1Q Tunneling, a service provider's switch can tag on a second
802.1Q tag on top of the customer's 802.1Q tag. This feature is sometimes
referred to as Q-in-Q. The Cisco implementation is proprietary and does
not interoperate with other implementations. There is currently no effort to
make this into a standard.

Frank

___
cisco-nsp 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] Cheapest Cisco desktop switch that supports Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs

[Frank Bulk]

Hopefully Cisco can update that page.

I was working on a Foundry/Brocade this week trying to some Q-in-Q - do you
mean 0x8100 versus 0x9100?  Looks like 802.1ad uses 0x88a8.

Frank

-Original Message-
From: Dale W. Carder [mailto:dwcar...@wisc.edu] 
Sent: Wednesday, July 07, 2010 11:09 PM
To: frnk...@iname.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Cheapest Cisco desktop switch that supports
Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs


On Jul 7, 2010, at 10:54 PM, Frank Bulk wrote:
 
 And why does one page on Cisco's site say: 
 Q. What is 802.1Q Tunneling? Is it an IEEE standard?
 A. With 802.1Q Tunneling, a service provider's switch can tag on a second
 802.1Q tag on top of the customer's 802.1Q tag. This feature is sometimes
 referred to as Q-in-Q. The Cisco implementation is proprietary and does
 not interoperate with other implementations.

false

 There is currently no effort to
 make this into a standard.


false, see 802.1ad-2005

What this text really means is that they use a different ethertype.  So, 
if you connect a cat switch to other vendor kit, you need to make sure you 
have things match.  Usually this is not really an issue as long as you are 
aware of it (and test for it) well in advance.

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] ospf monitor

[Frank Bulk]

Attached is a NAGIOS module that I've put together.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Michael Sprouffske
Sent: Tuesday, May 04, 2010 2:38 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ospf monitor

I'm looking to find something I can implement that will monitor all ospf
changes in a nice clear manner.  Snmp traps are ok but, they don't make
things easy for multiple people to see.  Any suggestions will be great.



  
___
cisco-nsp 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] Radius Accounting Question

[Frank Bulk]

We use accounting to start/stop an internet filtering service for customer
who've signed up, and we've not had an issue with RADIUS accounting.  We
added aaa accounting update periodic 480 jitter maximum 600 to help catch
an hiccups on the internet filtering device if it loses state on a
connection.

In our virtual template we have ppp authentication xxx radius-group-aaa
defined, and which depends on the following:

aaa group server radius radius-group
 server-private a.b.0.36 auth-port 1645 acct-port 1646 key 7 snip
 server-private a.b.0.37 auth-port 1645 acct-port 1646 key 7 snip
 load-balance method least-outstanding
!
aaa authentication ppp default group radius-group
aaa authentication ppp radius-group-aaa group radius-group
aaa authorization network default group radius-group
aaa authorization network radius-group-aaa group radius-group
aaa accounting delay-start all
aaa accounting update periodic 480 jitter maximum 600
aaa accounting network default start-stop group radius-group
aaa accounting network radius-group-aaa start-stop group radius-group

We're running 12.2(31)SB16.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart
Sent: Wednesday, April 21, 2010 5:25 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Radius Accounting Question

Hi there..

On a 7206VXR with the following radius configuration, does the accounting
packets get delivered to all radius servers or is it something else like
round robin?  I'm trying to troubleshoot an issue where accounting packets
are not showing up where expected all the time... in particular I want all
accounting packets to be delivered to .123 below...


aaa group server radius 

 server-private xxx.xxx.xx.28 auth-port 1812 acct-port 1813 key
x

 server-private xxx.xxx.xx.13 auth-port 1645 acct-port 1646 key
x

 server-private xxx.xxx.xx.216 auth-port 1812 acct-port 1813 key
xxx

 server-private xx.xxx.xx.123 auth-port 0 acct-port 1813 key xxx

 ip radius source-interface Loopback0

 

Thanks,

 

Paul

 

 

 

___
cisco-nsp 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] Missing BGP MIB support on Cisco 2621

[Frank Bulk - iName.com]

Thanks for the suggestion, but querying for it specifically via snmpget and
snmpwalk failed, so I don't think downloading the MIB itself would help.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ziv Leyes
Sent: Sunday, February 21, 2010 1:57 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Missing BGP MIB support on Cisco 2621

I think you should download the specific MIB for your release and try to
browse it with some MIB Browser or using the Cisco MIB Locator

Here's a link for the v2 MIB
http://tools.cisco.com/ITDIT/MIBS/MainServlet?ReleaseSel=0PlatformSel=0fsS
el=0IMAGE_NAME=c2600-is4-mz.123-26.binSUBMIT2=Submit

HTH

Ziv

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Frank Bulk -
iName.com
Sent: Friday, February 19, 2010 12:31 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Missing BGP MIB support on Cisco 2621

According to Cisco's MIB Locator, c2600-is4-mz.123-26.bin should have
CISCO-BGP4-MIB support, but when I try to walk that part of the tree
(1.3.6.1.4.1.9.9.187) in v1 or v2c that fails.  I'm using this router to do
IPv6 tunneling, and the only routes exchanged on this router are IPv6.

Anyone else see this?  Or is there a special knob I need to turn that on?

Frank

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

 
 


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





___
cisco-nsp 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] Missing BGP MIB support on Cisco 2621

[Frank Bulk - iName.com]

According to Cisco's MIB Locator, c2600-is4-mz.123-26.bin should have
CISCO-BGP4-MIB support, but when I try to walk that part of the tree
(1.3.6.1.4.1.9.9.187) in v1 or v2c that fails.  I'm using this router to do
IPv6 tunneling, and the only routes exchanged on this router are IPv6.

Anyone else see this?  Or is there a special knob I need to turn that on?

Frank

___
cisco-nsp 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] Dynamic IP VPN clients on a dual-ISP ASA 5505

[Frank Bulk]

We have a customer that recently added a second ISP uplink to their ASA 5505
at the hub (headquarters) and would like to migrate some of their spokes
(IPSec) sites to terminate on the new uplink at the hub.  Secondly, they
would like the new uplink to be their hub's primary internet link (using
PAT).

Their spokes are predominately using SOHO gear on different ISP services
that have dynamic IP addresses, and behind each spoke is a unique private
subnet.

What Cisco is telling us that if we want to use dual-ISP interfaces that the
spokes cannot use a dynamic WAN IP addresses.  If the spokes have static WAN
IP address it will work -- something with how the VPN session gets setup and
the fact that the default router is for the new uplink, we're told.  But the
client wants to avoid the $10/month charge for a static for each spoke, if
at all possible.

With all the knobs and buttons that the ASA has, I find this a little
surprising.  Does anyone have a similar setup for which they would be
willing to share a configuration snippet?

Here's an abbreviated configuration:

  headquarters
 192.168.x.0/24
|
ASA 5505
 /\
  ISP #1  ISP #2
|  |
INTERNET
 || 
 ||
dynamic IPdynamic IP
  Remote ARemote B
192.168.a.0/24192.168.b.0/24

A bonus would be if HQ could automatically fail over to the other ISP link,

Thanks in advance for any assistance.

Regards,

Frank Bulk

___
cisco-nsp 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 - Infoblox vs. Bluecat

[Frank Bulk]

We've been using Bluecat for several years in a SP environment primarily for
DHCP and we've had a tough go of it, with the product, people, and support
(contact me off-list for more detail).  Based on our experience, I think
it's a better fit in an enterprise environment with a single DHCP/DNS
administrator.  A few months ago I had a web-based presentation and demo of
the Infoblox product and would probably buy their product the next time.

In regards to IPv6 support, this is from the BlueCat's Adonis v6.0.1 release
notes:
- DNS Service is not supported on XHA in IPv6 networks.
- Cannot configure an IPv6 address on an NIC.
When I asked about DHCPv6, this was the tech support person's response:
What do you mean by DHCPv6?  And this coming from a DHCP/DNS appliance
vendor.  When I pointed them to the Wikipedia article, they came back and
said they don't support it.  When I asked for an ETA, they wrote back I am
sorry, but I don't have any ETA.  I then asked if the support DNS over
IPv6, and they wrote back I am sorry but, we don't support DNS over IPv6.
So unless things have changed drastically from late October, it would appear
that BlueCat's claims for IPv6 support are false.

Frank

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Church, Charles
Sent: Friday, January 15, 2010 9:10 AM
To: nsp-cisco
Subject: [c-nsp] OT - Infoblox vs. Bluecat

I apologize for this being fairly OT for a Cisco list, but I figured someone
on here has touched some DNS gear before.  Anyone work with Infoblox and
Bluecat, and run across a significant reason to choose one over another?
I've googled, but most articles are 5 years or more old.  Off-line responses
encouraged.  The planned use is for govt, so full access to the kernel is
nice for hardening/verification.  Also need TSIG, DNSSEC, and IPv6 support,
which they both claim to have, as they're both based on recent bind.  Secure
mgmt such as SNMPv3, SSHv2, and SSL would be nice.

Thanks in advance,

Chuck

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

___
cisco-nsp 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] Unicast flooding?

[Frank Bulk - iName.com]

I agree, I have some good evidence.  I'm not against upgrading if that will
resolve the issue.

Frank

 -Original Message-
 From: Pavel Skovajsa [mailto:pavel.skova...@gmail.com]
 Sent: Wednesday, January 13, 2010 3:43 AM
 To: frnk...@iname.com
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] Unicast flooding?
 
 Hello Frank,
 
 Does not sound really healthy - if you have gathered good evidence
 this is a good candidate for TAC. Anyway - you should probably upgrade
 to something other then SRB4 as TAC will tell you probably the same
 thing
 
 -pavel skovajsa
 
 On Wed, Jan 13, 2010 at 7:02 AM, Frank Bulk frnk...@iname.com wrote:
  We've been seeing some strange behavior on our 7609-S running
 12.2(33r)SRB4.
  We have a VLAN (with four /24s) configured on three ports across two
  10/100/1000 blades facing some FTTH transport equipment.
 
  Customers hanging off the FTTH equipment on the third port are
 complaining
  that several times per day they lose internet access.  We've been
 able to
  correlate their complaints with failed ping attempts from our
 workstations
  and the 7609-S to their public IPs.  What's interesting is that it's
 not all
  the traffic, and of the 4 IPs we are tracking, two of which are on
 separate
  /24s, the outages happen within the same /24.  At the same time,
 while using
  Wireshark, I can see one of the Cisco interfaces sending out 1 to 2
 Mbps of
  traffic that should be going to one of the other two Ethernet
 interfaces.
  This is happening about a dozen times per day for 4 to 6 minutes at a
 time.
 
 
  While the event is occurring I have verified the ARP and CAM entry.
  The CAM
  entry is associated with one of the first two Ethernet interfaces,
 not the
  third.  I can clear the ARP and CAM entry from the CLI and they are
  re-learned with the same information, yet the traffic continues to
 egress
  the wrong Ethernet port.
 
  I've set the ARP timeout to 4 minutes so that it's less than the CAM
 table's
  default configuration of 5 minutes, but there was no improvement.
  One more
  observation -- the errant port is the root of the bridge.
 
  Any ideas why the 7609 would be sending traffic out an Ethernet port
 to a
  device that the CAM table says is on a different Ethernet port?
 
  Frank
 
 
  interface Vlan10
   description FTTH network
   ip dhcp relay information trusted
   ip dhcp relay information option-insert none
   ip dhcp relay information policy-action keep
   ip address 67.22.a.1 255.255.255.0 secondary
   ip address 67.22.b.1 255.255.255.0 secondary
   ip address 67.22.c.1 255.255.255.0 secondary
   ip address 67.22.d.1 255.255.255.0
   ip helper-address e.f.g.h
   no ip redirects
   arp timeout 300
  end
 
  interface GigabitEthernet1/29 (and 3/39 and 3/45)
   switchport
   switchport trunk encapsulation dot1q
   switchport trunk allowed vlan 10
   switchport mode trunk
   switchport nonegotiate
   load-interval 30
   spanning-tree portfast trunk
  end
 
  ___
  cisco-nsp mailing list  cisco-...@puck.nether.net
  https://puck.nether.net/mailman/listinfo/cisco-nsp
  archive at http://puck.nether.net/pipermail/cisco-nsp/
 

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