Re: [c-nsp] LNS Alternatives

[Mark Tinka]

On 23/May/16 10:32, James Bensley wrote:

> At this level you only need two boxes with the correct broadband
> licenses (not the 5 originally mentioned, unless you have some other
> requirements relating to geo-diversity or backhaul connectivity).
>
> I recommend you advoice the ASR1002-X if possible. There seems to be
> various features in the ASR1000 range that aren't support on the
> 1002-X only.
>
> We have some live ones, they work OK, but we also have some 7200s too!
> These are some rough notes I made during the initial testing, many
> problems:
>
> https://null.53bits.co.uk/index.php?page=asr-ios-xr-lns-config
>
> https://null.53bits.co.uk/index.php?page=adsl-and-lns-shaping-llq

These are great notes. Thanks for these!

Just to note that QoS application on a LAG is now supported on the ASR1000:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/xe-3s/asr1000/qos-mqc-xe-3s-asr1000-book/qos-mqc-xe-3s-asr1000-book_chapter_01011.html

It's not without some limitations, but it works.

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] Level 2 switch 1U, 4 x 10GE

[Lucas Lazaro]

Good to know... thanks!

El lun., may. 23, 2016 22:25, Sachin Gupta (sagupta) 
escribió:

>
> That's an older model. 4948E and 4948E-F with reverse airflow are
> orderable.
>
>
> On May 23, 2016, at 6:15 PM, Lucas Lazaro  wrote:
>
> WS-C4948-E are end of sale since August 2013...
>
> El lun., may. 23, 2016 19:22, Sachin Gupta (sagupta) 
> escribió:
>
>> Can you use Catalyst 4948E?
>>
>>
>> http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-4948e-ethernet-switch/data_sheet_c78-598933.html
>>
>> Sachin
>>
>> On 5/23/16, 12:49 PM, "cisco-nsp on behalf of Sean Caron" <
>> cisco-nsp-boun...@puck.nether.net on behalf of sca...@diablonet.net>
>> wrote:
>>
>> >On Mon, 23 May 2016, lis...@cutre.net wrote:
>> >
>> >> I know JunOS (besides I have the JNCIP, I’ve worked a lot with them),
>> and I would love to buy Juniper, but this is a large company and we have
>> agreements that can’t be forgeted….
>> >
>> >Thanks anyway
>> >
>> >Fernando Garcia
>> >
>> >> El 23/5/2016, a las 17:44, Gert Doering 
>> escribió:
>> >>
>> >> Hi,
>> >>
>> >> On Mon, May 23, 2016 at 05:36:18PM +0200, lis...@cutre.net wrote:
>> >>> Sorry, we?re a Cisco house (not my preference, but?) that?s why I
>> posted the question in c-nsp and not in j-nsp.
>> >>
>> >> I understand that - we used to be a Cisco house as well, but Cisco so
>> >> missed the boat in L2 switches (expensive, too few 10G ports, but to
>> >> compensate, too small buffers) that we started looking elsewhere...
>> >>
>> >> If you have enough of them, investing the few days to learn the
>> >> ickiness of JunOS-for-switches might be well worth it.
>> >>
>> >> 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 just does not have an offering in this product space anymore. We
>> >used to buy a ton of Catalyst 2360 switches here but now that they are
>> >discontinued, we've also moved to the J EX3300 and have been quite happy
>> >with it. No interop problems with our Nexus switches one layer up. Wish
>> >Cisco would re-introduce a competitive product in this segment.
>> >
>> >Best,
>> >
>> >Sean
>> >___
>> >cisco-nsp 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] Level 2 switch 1U, 4 x 10GE

[Sachin Gupta (sagupta)]

That's an older model. 4948E and 4948E-F with reverse airflow are orderable.


On May 23, 2016, at 6:15 PM, Lucas Lazaro 
> wrote:


WS-C4948-E are end of sale since August 2013...

El lun., may. 23, 2016 19:22, Sachin Gupta (sagupta) 
> escribi?:
Can you use Catalyst 4948E?

http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-4948e-ethernet-switch/data_sheet_c78-598933.html

Sachin

On 5/23/16, 12:49 PM, "cisco-nsp on behalf of Sean Caron" 
 on 
behalf of sca...@diablonet.net> wrote:

>On Mon, 23 May 2016, lis...@cutre.net wrote:
>
>> I know JunOS (besides I have the JNCIP, I've worked a lot with them), and I 
>> would love to buy Juniper, but this is a large company and we have 
>> agreements that can't be forgeted
>
>Thanks anyway
>
>Fernando Garcia
>
>> El 23/5/2016, a las 17:44, Gert Doering 
>> > escribi?:
>>
>> Hi,
>>
>> On Mon, May 23, 2016 at 05:36:18PM +0200, 
>> lis...@cutre.net wrote:
>>> Sorry, we?re a Cisco house (not my preference, but?) that?s why I posted 
>>> the question in c-nsp and not in j-nsp.
>>
>> I understand that - we used to be a Cisco house as well, but Cisco so
>> missed the boat in L2 switches (expensive, too few 10G ports, but to
>> compensate, too small buffers) that we started looking elsewhere...
>>
>> If you have enough of them, investing the few days to learn the
>> ickiness of JunOS-for-switches might be well worth it.
>>
>> 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 just does not have an offering in this product space anymore. We
>used to buy a ton of Catalyst 2360 switches here but now that they are
>discontinued, we've also moved to the J EX3300 and have been quite happy
>with it. No interop problems with our Nexus switches one layer up. Wish
>Cisco would re-introduce a competitive product in this segment.
>
>Best,
>
>Sean
>___
>cisco-nsp 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] Level 2 switch 1U, 4 x 10GE

[Lucas Lazaro]

WS-C4948-E are end of sale since August 2013...

El lun., may. 23, 2016 19:22, Sachin Gupta (sagupta) 
escribió:

> Can you use Catalyst 4948E?
>
>
> http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-4948e-ethernet-switch/data_sheet_c78-598933.html
>
> Sachin
>
> On 5/23/16, 12:49 PM, "cisco-nsp on behalf of Sean Caron" <
> cisco-nsp-boun...@puck.nether.net on behalf of sca...@diablonet.net>
> wrote:
>
> >On Mon, 23 May 2016, lis...@cutre.net wrote:
> >
> >> I know JunOS (besides I have the JNCIP, I’ve worked a lot with them),
> and I would love to buy Juniper, but this is a large company and we have
> agreements that can’t be forgeted….
> >
> >Thanks anyway
> >
> >Fernando Garcia
> >
> >> El 23/5/2016, a las 17:44, Gert Doering  escribió:
> >>
> >> Hi,
> >>
> >> On Mon, May 23, 2016 at 05:36:18PM +0200, lis...@cutre.net wrote:
> >>> Sorry, we?re a Cisco house (not my preference, but?) that?s why I
> posted the question in c-nsp and not in j-nsp.
> >>
> >> I understand that - we used to be a Cisco house as well, but Cisco so
> >> missed the boat in L2 switches (expensive, too few 10G ports, but to
> >> compensate, too small buffers) that we started looking elsewhere...
> >>
> >> If you have enough of them, investing the few days to learn the
> >> ickiness of JunOS-for-switches might be well worth it.
> >>
> >> 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 just does not have an offering in this product space anymore. We
> >used to buy a ton of Catalyst 2360 switches here but now that they are
> >discontinued, we've also moved to the J EX3300 and have been quite happy
> >with it. No interop problems with our Nexus switches one layer up. Wish
> >Cisco would re-introduce a competitive product in this segment.
> >
> >Best,
> >
> >Sean
> >___
> >cisco-nsp 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] Level 2 switch 1U, 4 x 10GE

[Sachin Gupta (sagupta)]

Can you use Catalyst 4948E?

http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-4948e-ethernet-switch/data_sheet_c78-598933.html

Sachin

On 5/23/16, 12:49 PM, "cisco-nsp on behalf of Sean Caron" 
 wrote:

>On Mon, 23 May 2016, lis...@cutre.net wrote:
>
>> I know JunOS (besides I have the JNCIP, I’ve worked a lot with them), and I 
>> would love to buy Juniper, but this is a large company and we have 
>> agreements that can’t be forgeted….
>
>Thanks anyway
>
>Fernando Garcia
>
>> El 23/5/2016, a las 17:44, Gert Doering  escribió:
>> 
>> Hi,
>> 
>> On Mon, May 23, 2016 at 05:36:18PM +0200, lis...@cutre.net wrote:
>>> Sorry, we?re a Cisco house (not my preference, but?) that?s why I posted 
>>> the question in c-nsp and not in j-nsp.
>> 
>> I understand that - we used to be a Cisco house as well, but Cisco so
>> missed the boat in L2 switches (expensive, too few 10G ports, but to
>> compensate, too small buffers) that we started looking elsewhere...
>> 
>> If you have enough of them, investing the few days to learn the 
>> ickiness of JunOS-for-switches might be well worth it.
>> 
>> 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 just does not have an offering in this product space anymore. We 
>used to buy a ton of Catalyst 2360 switches here but now that they are 
>discontinued, we've also moved to the J EX3300 and have been quite happy 
>with it. No interop problems with our Nexus switches one layer up. Wish 
>Cisco would re-introduce a competitive product in this segment.
>
>Best,
>
>Sean
>___
>cisco-nsp 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] LNS Alternatives

[Pshem Kowalczyk]

Hi,

On Mon, 23 May 2016 at 21:04 CiscoNSP List 
wrote:

> Cheers James - We need them all(5), as our POPs are geographically VERY
> far apart lol..majority of our customers are eth based, and use DSL as
> either redundant link, or where eth/fibre not
> available...unfortunately, they make a HUGE noise re latency(They are
> VERY latency conscious!)  when we tried a single LNS setup...i.e. All DSL
> tails terminating on the one LNS.as an example, 2 sites, 1 kilometre
> apart, latency was over 120m/sec..if we had an LNS at that POP, latency
> would have been 30ishhard pill to swallow, but when the noisy customers
> are spending lots of $ with you, it's best to keep them happy.
>
> Regarding features and the "X" range...Ive played a bit now with our Lab
> 1006, and yes, definitely some "challenging"(insane!) differences between
> them and the 7200geez the stupid no compression thing,  some reply
> attributes cause the ASR to use full VAI, which causes it to fail also, qos
> pre-classify under virt template also causes ASR to use full VAI(Again,
> causes it to fail).damn, Cisco loved making the transition from
> 7200->ASR an easy one lol..Are there even more things I need to be
> aware of with the old 1001 vs the 1001-X series?(From your e-mail, sounds
> like there is?)
>
> Thanks very much for your notes+linksIll be reading them tonight :)
>

If they are so far apart then why not use a simple PWE3  device (whatever
suits your needs) and bring the traffic back to a central site(s) where the
ASR1k is? Do you do a lot of local traffic switching between the DSL tails?

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

Re: [c-nsp] Level 2 switch 1U, 4 x 10GE

[Sean Caron]

On Mon, 23 May 2016, lis...@cutre.net wrote:


I know JunOS (besides I have the JNCIP, I’ve worked a lot with them), and I 
would love to buy Juniper, but this is a large company and we have agreements 
that can’t be forgeted….


Thanks anyway

Fernando Garcia


El 23/5/2016, a las 17:44, Gert Doering  escribió:

Hi,

On Mon, May 23, 2016 at 05:36:18PM +0200, lis...@cutre.net wrote:

Sorry, we?re a Cisco house (not my preference, but?) that?s why I posted the 
question in c-nsp and not in j-nsp.


I understand that - we used to be a Cisco house as well, but Cisco so
missed the boat in L2 switches (expensive, too few 10G ports, but to
compensate, too small buffers) that we started looking elsewhere...

If you have enough of them, investing the few days to learn the 
ickiness of JunOS-for-switches might be well worth it.


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


Cisco just does not have an offering in this product space anymore. We 
used to buy a ton of Catalyst 2360 switches here but now that they are 
discontinued, we've also moved to the J EX3300 and have been quite happy 
with it. No interop problems with our Nexus switches one layer up. Wish 
Cisco would re-introduce a competitive product in this segment.


Best,

Sean
___
cisco-nsp 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] A9K Netflow export drops

[Jimmy]

Hi,
Just wondering,
Did you find something like this on your syslog ?
 %MGBL-NETFLOW-6-INFO_CACHE_SIZE_EXCEEDED : Cache size of 100 for
monitor xxx has been exceeded

Regards,
Jimmy Hng.


On Tue, May 24, 2016 at 12:02 AM, Robert Williams 
wrote:

> Hi,
>
> Doing some more digging, found this from 2014:
>
> Netflow specific scale and Limitations are described below:
>   1. Supports configurable Sampling Rate 1:1 ~ 1: 65535
>   2. Supports only up to 4 Sampling Rates (or Intervals) per Ethernet LC
> LC; no such limit for Enhanced Ethernet LC.
>   3. Up to 4k interfaces/sub-interfaces (4K system limitation) can be
> configured with flow monitor per system.
>   4. Supports up to 8 flow exporters per flow monitor
>   5. Supports up to 1 million flow entries per LC
>   6. Supports up to 50k flows per second with LC CPU usage up to 50% per
> Ethernet LC LC
>   7. Supports upto 100K flows per second with LC CPU usage up to 50% per
> Enhanced Ethernet LC LC
>   8. Netflow scale is increased to 200Kpps on Enhanced Ethernet LC based
> LCs
>   9. Supports exporting packet rates up to 50k flows per second (100K
> flows per sec on Enhanced Ethernet LC based LCs) with LC CPU usage up to 50%
>
> "Irrespective of the rate at which the NP punts the records to CPU,
> exporter picks up a maximum of 2000 records at a time from the cache that
> are eligible for export (timers, network/TCP session events, etc). This is
> basically to avoid NetIO dropping the packets due to lack of b/w. When the
> exporter wakes up again, it repeats the same."
>
> So, it can collect 100k flows per second, but can only export 2k each time
> it runs the exporter. The interval for the exporter is unclear however.
>
> I've also found out why this is such an issue on our 9001 but not on any
> of our 900x larger chassis. Looks like on those the hardware punt is being
> limited to 25kpps per NP because we have some BVIs with Netflow on them.
> This causes it to distribute the rate limit for punting to ALL the NPs on
> the LC, even when only two ports are involved in Netflow. Thus, it's
> "sampled sampling" and so the rate of flow data is significantly lower than
> the 9001 which is allowing all 100kpps on one NP which has 4 x 10G
> interfaces punting into it.
>
> mmm...
>
>
>
> Robert Williams
> Custodian Data Centre
> Email: rob...@custodiandc.com
> http://www.CustodianDC.com
>
> -Original Message-
> From: Dale W. Carder [mailto:dwcar...@wisc.edu]
> Sent: 23 May 2016 16:02
> To: Robert Williams 
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] A9K Netflow export drops
>
> Thus spake Robert Williams (rob...@custodiandc.com) on Sat, May 21, 2016
> at 10:59:50AM +:
> >
> > I've got an issue on one of our smaller 9001 boxes which is puzzling me.
> > It suffers from a high rate of netflow export drops (not cache drops)
> shown here:
> >
> > So from what I understand, it is capturing the flows OK but is unable to
> get the flow data out, for some reason.
>
> I can confirm that our 9k's suffer from this also.
>
> The last I checked you can export at the rate of 2000 flows/sec.  I have
> not
> looked in 2 years or so to see if this limit was configurable yet.
>
> > So - what am I missing here? Surely with a cache capability of 1M it
> should be ok to export flows when were are only around 30,000 of them
> nicely ticking over?
>
> join the club.  :-(
>
> 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/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] IOS-XR 5.3.3 add Yang Models

[Christian Kildau]

Hi all,

sorry for not replying earlier.

We will continue evaluating YANG in the lab as we have now upgraded one box
to 6.0.1 and there is Cisco-IOS-XR-ipvX-acl-cfg.yang.
Currently we still have other issues with 6.0.1 like totally broken
netflow...

Best regards,
Chris

On Thu, May 12, 2016 at 4:02 PM, Phil Mayers 
wrote:

> On 12/05/16 12:49, chip wrote:
>
>> I don't really get the benefit of using XML wrapped cli commands and
>> output
>> via XML.  One must still ssh to the device and the output is the same as
>> the CLI with just an  tag wrapped around the results of
>>
>
> Depends on the vendor. It's obviously not ideal, but at least in theory it
> can be a marginal improvement over using expect-over-CLI, if for no other
> reason than you don't have to much around with parsing the reply e.g.
> detecting prompt-as-end-of-data, pager, setting term len 0, etc.
>
> If you're *really* lucky, the CLI-over-XML API will actually distinguish
> between a successful command and a failed command.
>
> You do still have to screen-scrape the actual command output, which
> obviously sucks.
>
> On the downside I've seen platforms that don't XML-escape the CLI output,
> so a CLI command like:
>
> # sh int desc
> ...
> Vlan10up  up NOC & others
>
> ...ends up as on-the-wire XML:
>
> 
> ...
> Vlan10 up up NOC & others
> 
>
> i.e. the & doesn't get turned to  and similarly with <>.
>
> This level of fail is, obviously, worse than useless.
>
> ___
> cisco-nsp 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] A9K Netflow export drops

[Christian Kildau]

Hi all,

we're seeing the exact same symptoms on our all our 9001s.
I have opened a TAC case regarding this issue last week.

Will keep you posted!

Best regards,
Chris

On Mon, May 23, 2016 at 6:09 PM, Christian Kildau  wrote:

> Hi all,
>
> we're seeing the exact same symptoms on our all our 9001s.
> I have opened a TAC case regarding this issue last week.
>
> Will keep you posted!
>
> Best regards,
> Chris
>
> On Mon, May 23, 2016 at 6:02 PM, Robert Williams 
> wrote:
>
>> Hi,
>>
>> Doing some more digging, found this from 2014:
>>
>> Netflow specific scale and Limitations are described below:
>>   1. Supports configurable Sampling Rate 1:1 ~ 1: 65535
>>   2. Supports only up to 4 Sampling Rates (or Intervals) per Ethernet LC
>> LC; no such limit for Enhanced Ethernet LC.
>>   3. Up to 4k interfaces/sub-interfaces (4K system limitation) can be
>> configured with flow monitor per system.
>>   4. Supports up to 8 flow exporters per flow monitor
>>   5. Supports up to 1 million flow entries per LC
>>   6. Supports up to 50k flows per second with LC CPU usage up to 50% per
>> Ethernet LC LC
>>   7. Supports upto 100K flows per second with LC CPU usage up to 50% per
>> Enhanced Ethernet LC LC
>>   8. Netflow scale is increased to 200Kpps on Enhanced Ethernet LC based
>> LCs
>>   9. Supports exporting packet rates up to 50k flows per second (100K
>> flows per sec on Enhanced Ethernet LC based LCs) with LC CPU usage up to 50%
>>
>> "Irrespective of the rate at which the NP punts the records to CPU,
>> exporter picks up a maximum of 2000 records at a time from the cache that
>> are eligible for export (timers, network/TCP session events, etc). This is
>> basically to avoid NetIO dropping the packets due to lack of b/w. When the
>> exporter wakes up again, it repeats the same."
>>
>> So, it can collect 100k flows per second, but can only export 2k each
>> time it runs the exporter. The interval for the exporter is unclear however.
>>
>> I've also found out why this is such an issue on our 9001 but not on any
>> of our 900x larger chassis. Looks like on those the hardware punt is being
>> limited to 25kpps per NP because we have some BVIs with Netflow on them.
>> This causes it to distribute the rate limit for punting to ALL the NPs on
>> the LC, even when only two ports are involved in Netflow. Thus, it's
>> "sampled sampling" and so the rate of flow data is significantly lower than
>> the 9001 which is allowing all 100kpps on one NP which has 4 x 10G
>> interfaces punting into it.
>>
>> mmm...
>>
>>
>>
>> Robert Williams
>> Custodian Data Centre
>> Email: rob...@custodiandc.com
>> http://www.CustodianDC.com
>>
>> -Original Message-
>> From: Dale W. Carder [mailto:dwcar...@wisc.edu]
>> Sent: 23 May 2016 16:02
>> To: Robert Williams 
>> Cc: cisco-nsp@puck.nether.net
>> Subject: Re: [c-nsp] A9K Netflow export drops
>>
>> Thus spake Robert Williams (rob...@custodiandc.com) on Sat, May 21, 2016
>> at 10:59:50AM +:
>> >
>> > I've got an issue on one of our smaller 9001 boxes which is puzzling me.
>> > It suffers from a high rate of netflow export drops (not cache drops)
>> shown here:
>> >
>> > So from what I understand, it is capturing the flows OK but is unable
>> to get the flow data out, for some reason.
>>
>> I can confirm that our 9k's suffer from this also.
>>
>> The last I checked you can export at the rate of 2000 flows/sec.  I have
>> not
>> looked in 2 years or so to see if this limit was configurable yet.
>>
>> > So - what am I missing here? Surely with a cache capability of 1M it
>> should be ok to export flows when were are only around 30,000 of them
>> nicely ticking over?
>>
>> join the club.  :-(
>>
>> 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/
>>
>
>
>
> --
> http://www.chrisk.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] A9K Netflow export drops

[Robert Williams]

Hi,

Doing some more digging, found this from 2014:

Netflow specific scale and Limitations are described below:
  1. Supports configurable Sampling Rate 1:1 ~ 1: 65535
  2. Supports only up to 4 Sampling Rates (or Intervals) per Ethernet LC LC; no 
such limit for Enhanced Ethernet LC.
  3. Up to 4k interfaces/sub-interfaces (4K system limitation) can be 
configured with flow monitor per system.
  4. Supports up to 8 flow exporters per flow monitor
  5. Supports up to 1 million flow entries per LC
  6. Supports up to 50k flows per second with LC CPU usage up to 50% per 
Ethernet LC LC
  7. Supports upto 100K flows per second with LC CPU usage up to 50% per 
Enhanced Ethernet LC LC
  8. Netflow scale is increased to 200Kpps on Enhanced Ethernet LC based LCs
  9. Supports exporting packet rates up to 50k flows per second (100K flows per 
sec on Enhanced Ethernet LC based LCs) with LC CPU usage up to 50%

"Irrespective of the rate at which the NP punts the records to CPU, exporter 
picks up a maximum of 2000 records at a time from the cache that are eligible 
for export (timers, network/TCP session events, etc). This is basically to 
avoid NetIO dropping the packets due to lack of b/w. When the exporter wakes up 
again, it repeats the same."

So, it can collect 100k flows per second, but can only export 2k each time it 
runs the exporter. The interval for the exporter is unclear however.

I've also found out why this is such an issue on our 9001 but not on any of our 
900x larger chassis. Looks like on those the hardware punt is being limited to 
25kpps per NP because we have some BVIs with Netflow on them. This causes it to 
distribute the rate limit for punting to ALL the NPs on the LC, even when only 
two ports are involved in Netflow. Thus, it's "sampled sampling" and so the 
rate of flow data is significantly lower than the 9001 which is allowing all 
100kpps on one NP which has 4 x 10G interfaces punting into it.

mmm...



Robert Williams
Custodian Data Centre
Email: rob...@custodiandc.com
http://www.CustodianDC.com

-Original Message-
From: Dale W. Carder [mailto:dwcar...@wisc.edu]
Sent: 23 May 2016 16:02
To: Robert Williams 
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] A9K Netflow export drops

Thus spake Robert Williams (rob...@custodiandc.com) on Sat, May 21, 2016 at 
10:59:50AM +:
>
> I've got an issue on one of our smaller 9001 boxes which is puzzling me.
> It suffers from a high rate of netflow export drops (not cache drops) shown 
> here:
>
> So from what I understand, it is capturing the flows OK but is unable to get 
> the flow data out, for some reason.

I can confirm that our 9k's suffer from this also.

The last I checked you can export at the rate of 2000 flows/sec.  I have not
looked in 2 years or so to see if this limit was configurable yet.

> So - what am I missing here? Surely with a cache capability of 1M it should 
> be ok to export flows when were are only around 30,000 of them nicely ticking 
> over?

join the club.  :-(

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] Level 2 switch 1U, 4 x 10GE

[listas]

I know JunOS (besides I have the JNCIP, I’ve worked a lot with them), and I 
would love to buy Juniper, but this is a large company and we have agreements 
that can’t be forgeted….

Thanks anyway

Fernando Garcia

> El 23/5/2016, a las 17:44, Gert Doering  escribió:
> 
> Hi,
> 
> On Mon, May 23, 2016 at 05:36:18PM +0200, lis...@cutre.net wrote:
>> Sorry, we?re a Cisco house (not my preference, but?) that?s why I posted the 
>> question in c-nsp and not in j-nsp.
> 
> I understand that - we used to be a Cisco house as well, but Cisco so
> missed the boat in L2 switches (expensive, too few 10G ports, but to
> compensate, too small buffers) that we started looking elsewhere...
> 
> If you have enough of them, investing the few days to learn the 
> ickiness of JunOS-for-switches might be well worth it.
> 
> gert
> -- 
> USENET is *not* the non-clickable part of WWW!
>   //www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

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

Re: [c-nsp] Level 2 switch 1U, 4 x 10GE

[Gert Doering]

Hi,

On Mon, May 23, 2016 at 05:36:18PM +0200, lis...@cutre.net wrote:
> Sorry, we?re a Cisco house (not my preference, but?) that?s why I posted the 
> question in c-nsp and not in j-nsp.

I understand that - we used to be a Cisco house as well, but Cisco so
missed the boat in L2 switches (expensive, too few 10G ports, but to
compensate, too small buffers) that we started looking elsewhere...

If you have enough of them, investing the few days to learn the 
ickiness of JunOS-for-switches might be well worth it.

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


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

Re: [c-nsp] Level 2 switch 1U, 4 x 10GE

[Alan Buxey]

Nexus 3k series? 

What l2 performance are you after? Required buffer size etc? A stack of 2 2960x 
would give you 4x10GSFP+ for example

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/

Re: [c-nsp] Level 2 switch 1U, 4 x 10GE

[Gert Doering]

Hi,

On Mon, May 23, 2016 at 05:22:21PM +0200, lis...@cutre.net wrote:
> Do you have any recomendation?

$J EX3300?

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


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

Re: [c-nsp] Level 2 switch 1U, 4 x 10GE

[listas]

Sorry, we’re a Cisco house (not my preference, but…) that’s why I posted the 
question in c-nsp and not in j-nsp.

But thanks anyway

Fernando Garcia

> El 23/5/2016, a las 17:34, Gert Doering  escribió:
> 
> Hi,
> 
> On Mon, May 23, 2016 at 05:22:21PM +0200, lis...@cutre.net wrote:
>> Do you have any recomendation?
> 
> $J EX3300?
> 
> gert
> -- 
> USENET is *not* the non-clickable part of WWW!
>   //www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

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

[c-nsp] Level 2 switch 1U, 4 x 10GE

[listas]

Hello community

For our lab we are looking for some switches to do mainly level 2 swtiching. So 
nothing fancy like MPLS, etc. (that is welcome if included, but not needed) but 
all the bells and whistles of the L2 (R-STP, PVST,etc. no TOR limitations like 
the ME3400 has). the main problem is the number of SFP+ ports. We need four of 
them in each switch.

One model with 48 RJ45 GE ports + 4 10GE
Other model with 24 SFP GE ports + 4 10GE

For the first one I’ve looked at the WS3850-48T + C3850-NM-4-10G (4 10g ports) 
and for the second one the SW3850-24S + C3850-NM-2-10G (2 10g ports). But is 
“slightly” expensive.

Do you have any recomendation?

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/

Re: [c-nsp] A9K Netflow export drops

[Robert Williams]

Hi,

Thanks for the input, there doesn't seem to be any applicable rate-limit that I 
can spot to be honest. You can limit the rate that flows are 'expired' but this 
only limits the cache element, not the exporting element I believe.

Also, none of the loads look 'challenging' for the hardware compared to the 
throughput/capacity it could potentially be dealing with (this box only has 
like 8G of throughput on it.

Unless anyone else has any ideas then I'll probably go to TAC with this, as it 
seems ludicrous that an edge device like this can capture flows at a rate way 
beyond that which it can export them...

Cheers!



Robert Williams
Custodian Data Centre
Email: rob...@custodiandc.com
http://www.CustodianDC.com

-Original Message-
From: Dale W. Carder [mailto:dwcar...@wisc.edu]
Sent: 23 May 2016 16:02
To: Robert Williams 
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] A9K Netflow export drops

Thus spake Robert Williams (rob...@custodiandc.com) on Sat, May 21, 2016 at 
10:59:50AM +:
>
> I've got an issue on one of our smaller 9001 boxes which is puzzling me.
> It suffers from a high rate of netflow export drops (not cache drops) shown 
> here:
>
> So from what I understand, it is capturing the flows OK but is unable to get 
> the flow data out, for some reason.

I can confirm that our 9k's suffer from this also.

The last I checked you can export at the rate of 2000 flows/sec.  I have not 
looked in 2 years or so to see if this limit was configurable yet.

> So - what am I missing here? Surely with a cache capability of 1M it should 
> be ok to export flows when were are only around 30,000 of them nicely ticking 
> over?

join the club.  :-(

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] asr9k dhcp relay + ipv4 verify unicast

[Phil Mayers]

On 23/05/16 16:02, Tarko Tikan wrote:

hey,


interface BVI60004
 ipv4 address 10.4.5.1 255.255.255.0
 ipv4 verify unicast source reachable-via rx allow-self-ping


Is this actual config or simplified? If simplified, is there VRRP/HSRP
involved?

If there is, it can be explained by DHCP return packet hitting other
router (because it's sent to GIADDR but you only announce your connected
prefix). Other router then fails to send packet to original router via
connected interface because from other routers POV it fails RPF (saddr:
dhcp-server, daddr: giaddr).


Yep. A PITA...

Often this is safe because both HSRP/VRRP members will forward the 
packet, both will be replied (usually identically - the DHCP server will 
tend to have allocated the lease already, so the 2nd gets the same 
offer/ack) and one will be dropped, but the other will arrive.


route for router#1 giaddr -> router #1 (uRPF ok)
route for router#2 giaddr -> router #1 (uRPF fail)

But if you're in ECMP-enabled networks, you can have a nasty where, from 
the DHCP server PoV:


ECMP hash for router#1 giaddr -> router #2 (uRPF fail)
ECMP hash for router#2 giaddr -> router #1 (uRPF fail)

...and both replies get dropped. This is statistically likely for approx 
1/4 of networks (all other things being equal).


Yet another reason that "layer 3 up on standby" protocols suck.
___
cisco-nsp 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] asr9k dhcp relay + ipv4 verify unicast

[Tarko Tikan]

hey,


interface BVI60004
 ipv4 address 10.4.5.1 255.255.255.0
 ipv4 verify unicast source reachable-via rx allow-self-ping


Is this actual config or simplified? If simplified, is there VRRP/HSRP 
involved?


If there is, it can be explained by DHCP return packet hitting other 
router (because it's sent to GIADDR but you only announce your connected 
prefix). Other router then fails to send packet to original router via 
connected interface because from other routers POV it fails RPF (saddr: 
dhcp-server, daddr: giaddr).


--
tarko
___
cisco-nsp 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] LNS Alternatives

[raf]

Basically linux have no support for VRF (until very recently very 
limited support on new kernel).


So if you want to park your subscriber into VRFs I think the best is to 
have one or two instance of linux by vrf.


With virtualization it can be easily achieved but result in a much more 
complex (or biggest) infrastructure.


Regards,


Le 23/05/2016 à 11:51, CiscoNSP List a écrit :

Cheers Raphael - Wasnt aware of the vrf complexities.this would hurt us 
significantly, as 70-80% of our DSL tails are in vrf's


From: cisco-nsp  on behalf of raf 

Sent: Monday, 23 May 2016 7:39 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] LNS Alternatives

I would also recommend to have a look at openl2tp.

Software LNS are a good solution if you only need basic features. If you
want to separate user in vrf/context it was a bit more complicated, as
you have to dedicate instance by vrf. but nothing impossible.
So the choice is as always, a relative expensive, but good hardware
platform, or a home solution which need much more engineering.

Or you can mix the two approach, I got a friend who handle 10K of
subscribers using a cluster of X c890 if I remember correctly.

Regards,

--
Raphael Mazelier


Le 22/05/2016 à 03:52, Patrick Cole a écrit :

I have used l2tpns in a cluster successfully in the past for this.
It's capable of doing 65k sessions per cluster if you throw enough
nodes at it.

The codebase is fairly stable and has been around for a long time
but isn't really maintained anymore.

We recently moved to the ASR1k platform for BRAS and had similar
gripes over the licensing prices, but just so you know the licenses
are honesty based on the ASR1k, the box will run at any license
level once you accept the EULA, but don't expect TAC to be jumping
to support you when your unlicensed features don't work.

We ended up talking direct to a local Cisco rep and they were able
to get us fully licensed boxes for the right price point.

Regards,

Patrick



___
cisco-nsp 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] asr9k dhcp relay + ipv4 verify unicast

[Phil Mayers]

On 23/05/16 15:45, Saku Ytti wrote:

Hey Florian,

Technically it is uRPF violation, you're getting packet from SADDR
0.0.0.0, which is clearly not routed to the interface. JunOS has this
same behaviour and you need to create exception ACL for uRPF to fix
it, I think it's fine, leveraging existing configuration infra,
without introducing new hacks in the code, which invariably will cause
bugs.

However I don't think IOS-XR has this exception ACL support for uRPF.
What you're seeing may be a bug, quick search for DDTS gave me this
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuu01825

I'm curious how '633892863' was solved. Perhaps 'not supported, use
ACL instead of uRPF'.


I know nothing about -XR but surely if uRPF was eating packets with 
source of 0.0.0.0, the DISCOVER wouldn't make it to the server?


Seeing a DISCOVER at the server but no request sounds like the OFFER 
getting dropped, which can happen if the route back to the giaddr from 
the server hits an RPF failure (beyond tedious in ECMP-enabled HSRP 
setups as we recently discovered...)

___
cisco-nsp 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] asr9k dhcp relay + ipv4 verify unicast

[Saku Ytti]

On 23 May 2016 at 17:56, Phil Mayers  wrote:
> I know nothing about -XR but surely if uRPF was eating packets with source
> of 0.0.0.0, the DISCOVER wouldn't make it to the server?

You're right, I most confess I didn't read email fully before
responding, apologies to OP for it.

> Seeing a DISCOVER at the server but no request sounds like the OFFER getting
> dropped, which can happen if the route back to the giaddr from the server
> hits an RPF failure (beyond tedious in ECMP-enabled HSRP setups as we
> recently discovered...)

Right, so speculation is, we offered something else than 10.4.5/24

Anyhow if it's low volume box, we can capture the NPU counter which
does uRPF drop, to see the exact packet being dropped.

Small script to find NPU captures in a session log and turn them into
PCAP - https://gist.github.com/ytti/436fe3b602a963acf21e

-- 
  ++ytti
___
cisco-nsp 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] A9K Netflow export drops

[Dale W. Carder]

Thus spake Robert Williams (rob...@custodiandc.com) on Sat, May 21, 2016 at 
10:59:50AM +:
> 
> I've got an issue on one of our smaller 9001 boxes which is puzzling me.
> It suffers from a high rate of netflow export drops (not cache drops) shown 
> here:
> 
> So from what I understand, it is capturing the flows OK but is unable to get 
> the flow data out, for some reason.

I can confirm that our 9k's suffer from this also.

The last I checked you can export at the rate of 2000 flows/sec.  I have not
looked in 2 years or so to see if this limit was configurable yet.

> So - what am I missing here? Surely with a cache capability of 1M it should 
> be ok to export flows when were are only around 30,000 of them nicely ticking 
> over?

join the club.  :-(

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] ASR920 stops routing unexpectedly

[Mark Tinka]

On 23/May/16 13:44, Lukas Tribus wrote:

> Does this affect other services than ipv4, like vpnv4 or l2vpns?

Well, it affects anything that requires IPv4 as transport, e.g., LDP,
RSVP, e.t.c.

The issue only affects IPv4, but only IPv4 is supported by MPLS today,
on this platform. So IPv6 continues to work just fine, which is how we
are able to maintain access to the unit remotely.

Suffice it to say, the fix in the test image works perfectly. Now to
wait for the general release, which will come 1st week of June.

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] asr9k dhcp relay + ipv4 verify unicast

[Saku Ytti]

Hey Florian,

Technically it is uRPF violation, you're getting packet from SADDR
0.0.0.0, which is clearly not routed to the interface. JunOS has this
same behaviour and you need to create exception ACL for uRPF to fix
it, I think it's fine, leveraging existing configuration infra,
without introducing new hacks in the code, which invariably will cause
bugs.

However I don't think IOS-XR has this exception ACL support for uRPF.
What you're seeing may be a bug, quick search for DDTS gave me this
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuu01825

I'm curious how '633892863' was solved. Perhaps 'not supported, use
ACL instead of uRPF'.

On 23 May 2016 at 17:36, Florian Lohoff  wrote:
>
> Hi,
> today i had to debug an ASR9001 setup with DHCP Relay and an
> ipv4 verify unicast source reachable-via rx allow-self-ping on
> an BVI interface. The clients failed to get leases - I saw
> DISCOVERS on the server side and the server sent out
> OFFERS. I could not determine whether the OFFER fails
> to reach the client or the REQUEST would not reach the server.
>
> [ ... ]
>
> dhcp ipv4
>  profile relayprofile relay
>   helper-address vrf default 10.7.8.9
>   giaddr policy replace
>  !
>  interface BVI108 relay profile relayprofile
>  interface BVI60004 relay profile relayprofile
>
> [ ... ]
>
> interface BVI60004
>  ipv4 address 10.4.5.1 255.255.255.0
>  ipv4 verify unicast source reachable-via rx allow-self-ping
>
> Removing the ipv4 verify unicast ... solved the issue which
> left me a little puzzled. My google foo turned up nothing
> concerning incompatibilities ...
>
> From my understanding the verify unicast is a pure input packet
> validation. The whole DHCP handshake would not create packets
> stemming from an invalid IP address on the L2 Bridge e.g.
> the BVI interface so i have no clue where and why the packet
> would be dropped.
>
> Flo
> --
> Florian Lohoff f...@zz.de
>  UTF-8 Test: The  ran after a , but the  ran away
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIVAwUBV0MVX5DdQSDLCfIvAQpzQA/7BROfXOU0dUeQ+yK4uykgGrvImlw1FDbx
> sSW6zZJZqVN1bY0yy37onD6bT2ZDOOYWOy7Oann0UQ+UfXP6y6/LpW0FYt4S2eTf
> rCi2psYzjwzYhpyfIfuFGW3Z5G+9z3JNhyICVdLOdLv6jeVpoGxBPMRKUYLrBoJ0
> XB7vpQ63gX8VpNutniBOGnUuYW9QY3+N+d2zcjReIRxEMtonakijY7feINMiK8fB
> s9/Cx1Sdx1B2VbX+fPryUSp+tcjyaqX2jK9dNSHGFIo60P2I/xlFa+Z+mvjTwWa3
> ZyIr4UiJtWLoHi6uM5j9Iuzpk0Rds+YnFBeE1IMlRhMSfl7DmybW60Xj2rEy/Vjb
> aOGawABD88nuTQy1YtgrS02U37hSr0Gt+7M/9A0patAw1mQFLHdb4Sjqu5UFvnZu
> 1ACeu7sudtu/EZJZteIwenoTsSCyDLnWc3WV9i62U4iNfNQqhWdKIheODC45sFrz
> rws09VQunka7wyVVjJ3CcSw0WewWUrGEKRZfJqpaPagKBFWaMGCGipINlgvnV352
> aOTLbG//Dm0biLHdlylErOi00TnCYS0OEIojxKq5d0tEbop6qTRfKnt6DL2smyBb
> 28B34wHf2tYGrsMRGpo1N/VNTT7/vYqQoc0yOzV7NzncOQT2O0D0WoT/AYb8zauK
> uKaILzAU6cU=
> =xpfI
> -END PGP SIGNATURE-
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



-- 
  ++ytti
___
cisco-nsp 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] asr9k dhcp relay + ipv4 verify unicast

[Florian Lohoff]

Hi,
today i had to debug an ASR9001 setup with DHCP Relay and an
ipv4 verify unicast source reachable-via rx allow-self-ping on
an BVI interface. The clients failed to get leases - I saw
DISCOVERS on the server side and the server sent out
OFFERS. I could not determine whether the OFFER fails
to reach the client or the REQUEST would not reach the server.

[ ... ]

dhcp ipv4
 profile relayprofile relay
  helper-address vrf default 10.7.8.9
  giaddr policy replace
 !
 interface BVI108 relay profile relayprofile
 interface BVI60004 relay profile relayprofile

[ ... ]

interface BVI60004
 ipv4 address 10.4.5.1 255.255.255.0
 ipv4 verify unicast source reachable-via rx allow-self-ping

Removing the ipv4 verify unicast ... solved the issue which
left me a little puzzled. My google foo turned up nothing
concerning incompatibilities ...

From my understanding the verify unicast is a pure input packet
validation. The whole DHCP handshake would not create packets
stemming from an invalid IP address on the L2 Bridge e.g.
the BVI interface so i have no clue where and why the packet
would be dropped.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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

Re: [c-nsp] ASR1006 Hardware redundancy question

[Satish Patel]

Thank for input.

Good to know we don't need to do extra configuration to create
redundancy. So in future if i slide in other RP/ESP it will auto
function right?


On Sun, May 22, 2016 at 5:32 PM, CiscoNSP List
 wrote:
> You have no RP/ESP/SIP redundancyif any of those fail, you are in trouble
>
> If you add another RP+ESP, then you have auto redundancy...one will be 
> primary, the other failover (We have them, I have tried this many times in 
> the lab.ie disconnecting primary RP etc to ensure backup RP takes 
> overthey do)
>
> If you only have one SIP, but multiple SPAs, then connect into different SPAs 
> for "redundancy"but you are only getting SPA redundancy, not 
> SIP.dual(Or more SIPs), SPAs in each one, you get SPA redundancy.
>
> Or, the best option, is two completely separate boxesboth connected to 
> upstreamcustomers can connect to both.if one dies, you are still 
> operational...this is far better than a single box, with dual "everything"
>
> 
> From: cisco-nsp  on behalf of Satish Patel 
> 
> Sent: Monday, 23 May 2016 5:13 AM
> To: Cisco Network Service Providers
> Subject: [c-nsp] ASR1006 Hardware redundancy question
>
> I am new to ASR1006 and i never work on router with hardware
> redundancy so i just want some input and understanding how does it
> work. currently we have single component so its not a 100% redundant.
>
> ESP40  - 1
> RP2 - 1
> SIP - 1
> SPA - 4  ( 1x10GB SPA)
>
> Question:
>
> Do i need to configure or run some command to tell router related
> redundancy or  its builtin function and it will auto detect number of
> component and take decision related Action-Hot standby. Let say in
> future i purchase RP2 component and plug into router does my router
> auto detect two RP2 processor and enable Redundancy?
>
> Just want to understand how Hardware redundancy will work.
>
> In my current setup where we have all single component in that case we
> have single SIP with 4 SPA cards, If one of SPA failed how does it
> provide redundancy?
> ___
> cisco-nsp 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] ASR920 stops routing unexpectedly

[Lukas Tribus]

Hi Mark,


> We are running a special image from this release to test a fix for
> CSCuy29638 (very nasty bug). The fix will make into the general code
> 11th June.

Does this affect other services than ipv4, like vpnv4 or l2vpns?


Thanks,

Lukas

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

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

[Stefan]

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

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

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

Re: [c-nsp] LNS Alternatives

[Dale Shaw]

(Resending to list from subscribed address -- got my puck nsp lists mixed
up :-))

On Monday, 23 May 2016, Dale Shaw  wrote:

> Hi anonymous poster, and James,
>
> On Monday, 23 May 2016, James Bensley  wrote:
>
>> Have you considered
>> Juniper too? You can do all the same stuff on MX's as far as I know,
>> we have MX480's running as LNS too. Just a thought.
>
>
> Indeed. I noticed that Juniper have just released Junos 15.1F5-S1 for vMX,
> which supports vBNG.
>
> http://kb.juniper.net/InfoCenter/index?page=content=TSB16942=RSS
>
> Looks brand new (as the release number suggests -- "F" /and/ "S1"!) and
> intended for early field trials only, with full support coming in a
> subsequent release.
>
> Talk to your sales rep about pricing. Relnotes say it needs vMX "premium"
> bundle at 1Gb/s or bigger, plus subscriber scale license.
>
> Cheers,
> 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] LNS Alternatives

[CiscoNSP List]

Cheers Raphael - Wasnt aware of the vrf complexities.this would hurt us 
significantly, as 70-80% of our DSL tails are in vrf's 


From: cisco-nsp  on behalf of raf 

Sent: Monday, 23 May 2016 7:39 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] LNS Alternatives

I would also recommend to have a look at openl2tp.

Software LNS are a good solution if you only need basic features. If you
want to separate user in vrf/context it was a bit more complicated, as
you have to dedicate instance by vrf. but nothing impossible.
So the choice is as always, a relative expensive, but good hardware
platform, or a home solution which need much more engineering.

Or you can mix the two approach, I got a friend who handle 10K of
subscribers using a cluster of X c890 if I remember correctly.

Regards,

--
Raphael Mazelier


Le 22/05/2016 à 03:52, Patrick Cole a écrit :
> I have used l2tpns in a cluster successfully in the past for this.
> It's capable of doing 65k sessions per cluster if you throw enough
> nodes at it.
>
> The codebase is fairly stable and has been around for a long time
> but isn't really maintained anymore.
>
> We recently moved to the ASR1k platform for BRAS and had similar
> gripes over the licensing prices, but just so you know the licenses
> are honesty based on the ASR1k, the box will run at any license
> level once you accept the EULA, but don't expect TAC to be jumping
> to support you when your unlicensed features don't work.
>
> We ended up talking direct to a local Cisco rep and they were able
> to get us fully licensed boxes for the right price point.
>
> Regards,
>
> Patrick
>
>

___
cisco-nsp 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] LNS Alternatives

[CiscoNSP List]

Thanks James - Apologies for the non-inline replies, Im on phone, via 
Hotmail...lol, makes it difficult :)

Ill have another chat to Cisco, see what they can do for usre Juniper, yes, 
I did look at themmy only issue is that we are only a small company, with 
all Cisco engineers...i.e. zero Juniper in-house knowledge...but Ill 
investigate further...if its a far cheaper option (And feature parity is equal 
or better), then Id be crazy not toowill be a difficult learning experience 
for us all(Mainly due to time constraints), but potentially worth it :)

Yes indeed re radius attributes etcwas scratching my head for a while 
wondering why the hell a basic dsl service wouldnt auth!...some mind boggling 
changes by Cisco lol

Thanks for the tip re QOSwill be doing a lot more testing in this area (As 
well as others!)

Cheers for all your feedback+helpmuch appreciated.


From: cisco-nsp  on behalf of James Bensley 

Sent: Monday, 23 May 2016 7:28 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] LNS Alternatives

On 23 May 2016 at 10:03, CiscoNSP List  wrote:
> Cheers James - We need them all(5), as our POPs are geographically VERY far 
> apart lol..majority of our customers are eth based, and use DSL as either 
> redundant link, or where eth/fibre not available...unfortunately, they 
> make a HUGE noise re latency(They are VERY latency conscious!)  when we tried 
> a single LNS setup...i.e. All DSL tails terminating on the one LNS.as an 
> example, 2 sites, 1 kilometre apart, latency was over 120m/sec..if we had an 
> LNS at that POP, latency would have been 30ishhard pill to swallow, but 
> when the noisy customers are spending lots of $ with you, it's best to keep 
> them happy.

Hmm in that case, I would either shout loudly at Cisco to get a better
price, the ASR1001-X for say <1000 subscribers (assuming an even
distribution between PoPs) is rather pricey. Have you considered
Juniper too? You can do all the same stuff on MX's as far as I know,
we have MX480's running as LNS too. Just a thought.

> Regarding features and the "X" range...Ive played a bit now with our Lab 
> 1006, and yes, definitely some "challenging"(insane!) differences between 
> them and the 7200geez the stupid no compression thing,  some reply 
> attributes cause the ASR to use full VAI, which causes it to fail also, qos 
> pre-classify under virt template also causes ASR to use full VAI(Again, 
> causes it to fail).damn, Cisco loved making the transition from 7200->ASR 
> an easy one lol..Are there even more things I need to be aware of with 
> the old 1001 vs the 1001-X series?(From your e-mail, sounds like there is?)

Yes the change in RADIUS attributes and using sub-interfaces et al. is
very annoying. We have managed to work around pretty much everything
however it was additional head ache caused by Cisco, the reasons for
which are (mostly) unknown to us.

They do work AS LNS/BNG, the ASR1000 series devices, I just cast
stress how much testing you must do first. We were having issues were
the couldn't make QoS changes without rebooting the box, so we needed
to get our configs exactly right and fully testd before any traffic
goes live.

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] LNS Alternatives

[raf]

I would also recommend to have a look at openl2tp.

Software LNS are a good solution if you only need basic features. If you 
want to separate user in vrf/context it was a bit more complicated, as 
you have to dedicate instance by vrf. but nothing impossible.
So the choice is as always, a relative expensive, but good hardware 
platform, or a home solution which need much more engineering.


Or you can mix the two approach, I got a friend who handle 10K of 
subscribers using a cluster of X c890 if I remember correctly.


Regards,

--
Raphael Mazelier


Le 22/05/2016 à 03:52, Patrick Cole a écrit :

I have used l2tpns in a cluster successfully in the past for this.
It's capable of doing 65k sessions per cluster if you throw enough
nodes at it.

The codebase is fairly stable and has been around for a long time
but isn't really maintained anymore.

We recently moved to the ASR1k platform for BRAS and had similar
gripes over the licensing prices, but just so you know the licenses
are honesty based on the ASR1k, the box will run at any license
level once you accept the EULA, but don't expect TAC to be jumping
to support you when your unlicensed features don't work.

We ended up talking direct to a local Cisco rep and they were able
to get us fully licensed boxes for the right price point.

Regards,

Patrick




___
cisco-nsp 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] LNS Alternatives

[James Bensley]

On 23 May 2016 at 10:03, CiscoNSP List  wrote:
> Cheers James - We need them all(5), as our POPs are geographically VERY far 
> apart lol..majority of our customers are eth based, and use DSL as either 
> redundant link, or where eth/fibre not available...unfortunately, they 
> make a HUGE noise re latency(They are VERY latency conscious!)  when we tried 
> a single LNS setup...i.e. All DSL tails terminating on the one LNS.as an 
> example, 2 sites, 1 kilometre apart, latency was over 120m/sec..if we had an 
> LNS at that POP, latency would have been 30ishhard pill to swallow, but 
> when the noisy customers are spending lots of $ with you, it's best to keep 
> them happy.

Hmm in that case, I would either shout loudly at Cisco to get a better
price, the ASR1001-X for say <1000 subscribers (assuming an even
distribution between PoPs) is rather pricey. Have you considered
Juniper too? You can do all the same stuff on MX's as far as I know,
we have MX480's running as LNS too. Just a thought.

> Regarding features and the "X" range...Ive played a bit now with our Lab 
> 1006, and yes, definitely some "challenging"(insane!) differences between 
> them and the 7200geez the stupid no compression thing,  some reply 
> attributes cause the ASR to use full VAI, which causes it to fail also, qos 
> pre-classify under virt template also causes ASR to use full VAI(Again, 
> causes it to fail).damn, Cisco loved making the transition from 7200->ASR 
> an easy one lol..Are there even more things I need to be aware of with 
> the old 1001 vs the 1001-X series?(From your e-mail, sounds like there is?)

Yes the change in RADIUS attributes and using sub-interfaces et al. is
very annoying. We have managed to work around pretty much everything
however it was additional head ache caused by Cisco, the reasons for
which are (mostly) unknown to us.

They do work AS LNS/BNG, the ASR1000 series devices, I just cast
stress how much testing you must do first. We were having issues were
the couldn't make QoS changes without rebooting the box, so we needed
to get our configs exactly right and fully testd before any traffic
goes live.

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] LNS Alternatives

[Nathan Ward]

> On 22/05/2016, at 12:48, Charles Sprickman  wrote:
> 
> 
>> On May 21, 2016, at 8:32 PM, CiscoNSP List  wrote:
>> 
>> Hi Everyone,
>> 
>> 
>> We have around 5 POPs that need to terminate DSL tails, so require LNS - 
>> historically, we have done this on 7200's, now with 7200 basically EOLd, we 
>> are looking at the ASR1K's, but the broadband licensing on them is heinously 
>> expensive...Just wondering what others are using as an alternative?  We make 
>> very little margin on DSL tails, so if we had to go down the path of 
>> ASR1K/Broadband license it would take a very very long time to recoup 
>> license costs.
>> 
>> 
>> Ive had a hunt around for Linux-based options, but all the ones Ive found 
>> are from quite a few years back, and dont appear to be under active 
>> development?
> 
> Vaguely OT, but FreeBSD with mpd5 seems to be a common option for this.  I 
> would imagine if you could fit all your users on a 7200, you could terminate 
> at least that many on a current generation server.
> 
> A quick example config:
> 
> https://sourceforge.net/p/mpd/discussion/44693/thread/8038e404/


Hi Charles,

I’ll throw in a vote for mpd5 here as well, as a cheap alternative if you’re 
doing basic stuff. Not great if you need to drop people in to multiple VRFs and 
so on, but more than fine for Internet access.

Check out http://mpd.sourceforge.net/doc5/mpd30.html 
 for details on how to do most of 
the things you’d want with it, triggered by RADIUS. Not mentioned there, but 
CoA is supported for many attributes, also.

Compression, mentioned recently, is supported. I’ve not seen anyone doing that 
in broadband networks in quite a while though.

--
Nathan Ward

___
cisco-nsp 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] LNS Alternatives

[CiscoNSP List]

Cheers James - We need them all(5), as our POPs are geographically VERY far 
apart lol..majority of our customers are eth based, and use DSL as either 
redundant link, or where eth/fibre not available...unfortunately, they make 
a HUGE noise re latency(They are VERY latency conscious!)  when we tried a 
single LNS setup...i.e. All DSL tails terminating on the one LNS.as an 
example, 2 sites, 1 kilometre apart, latency was over 120m/sec..if we had an 
LNS at that POP, latency would have been 30ishhard pill to swallow, but 
when the noisy customers are spending lots of $ with you, it's best to keep 
them happy.

Regarding features and the "X" range...Ive played a bit now with our Lab 1006, 
and yes, definitely some "challenging"(insane!) differences between them and 
the 7200geez the stupid no compression thing,  some reply attributes cause 
the ASR to use full VAI, which causes it to fail also, qos pre-classify under 
virt template also causes ASR to use full VAI(Again, causes it to 
fail).damn, Cisco loved making the transition from 7200->ASR an easy one 
lol..Are there even more things I need to be aware of with the old 1001 vs 
the 1001-X series?(From your e-mail, sounds like there is?)

Thanks very much for your notes+linksIll be reading them tonight :)


From: cisco-nsp  on behalf of James Bensley 

Sent: Monday, 23 May 2016 6:32 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] LNS Alternatives

> we are only doing ~2-3000 tailsbut to do the same on an ASR1Kwhoa! 
> price is a killer.

At this level you only need two boxes with the correct broadband
licenses (not the 5 originally mentioned, unless you have some other
requirements relating to geo-diversity or backhaul connectivity).

I recommend you advoice the ASR1002-X if possible. There seems to be
various features in the ASR1000 range that aren't support on the
1002-X only.

We have some live ones, they work OK, but we also have some 7200s too!
These are some rough notes I made during the initial testing, many
problems:

https://null.53bits.co.uk/index.php?page=asr-ios-xr-lns-config

https://null.53bits.co.uk/index.php?page=adsl-and-lns-shaping-llq

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] LNS Alternatives

[James Bensley]

> we are only doing ~2-3000 tailsbut to do the same on an ASR1Kwhoa! 
> price is a killer.

At this level you only need two boxes with the correct broadband
licenses (not the 5 originally mentioned, unless you have some other
requirements relating to geo-diversity or backhaul connectivity).

I recommend you advoice the ASR1002-X if possible. There seems to be
various features in the ASR1000 range that aren't support on the
1002-X only.

We have some live ones, they work OK, but we also have some 7200s too!
These are some rough notes I made during the initial testing, many
problems:

https://null.53bits.co.uk/index.php?page=asr-ios-xr-lns-config

https://null.53bits.co.uk/index.php?page=adsl-and-lns-shaping-llq

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] VSM NAT - throughput

[Pshem Kowalczyk]

Hi,

Thank you for this. I'm just a little concerned that this looks like a
exact copy of the section of the document on the ISM card (with ISM
replaced with VSM):
https://supportforums.cisco.com/document/11939006/cgv6-ism-cgnnat44-deployment-guide#nat44-on-ism-configuration

So they either exactly the same, or it's just a copy-paste error.

Also reading this section:

https://supportforums.cisco.com/document/12019576/cgv6-vsm-cgn-nat44-deployment-guide#handling-of-asymmetric-i2o-and-o2i-traffic-with-better-performance
seems to indicate a different setup from ISM card (our traffic is highly
asymmetric, this would apply).

I have not found any information on the actual throughput either.

kind regards
Pshem


On Mon, 23 May 2016 at 19:18 Fredrik Vöcks 
wrote:

> Hi Pshem,
>
> Yes you need to partition the VSM to get full throughput. I finally found
> the document;
>
> Logical Partitioning inside VSM
>
>
> https://supportforums.cisco.com/document/12019576/cgv6-vsm-cgn-nat44-deployment-guide#nat44-on-vsm-configuration
>
>
> Regards,
>
> Fredrik
>
> On 23 May 2016 at 02:34, Pshem Kowalczyk  wrote:
>
>> Hi,
>>
>> With the ISM cards we used to run 4 set of VRFs (and 4 sets of SA
>> interfaces) to achieve full throughput of the card for NAT. We're
>> upgrading
>> to VSM cards now, but I'm unable to determine if they also need a similar
>> split of traffic or not. I seem to recall that they should be able to do
>> about 60Gb/s of throughput and apparently the traffic needs to be split
>> into two pairs of SA interfaces to achieve that, but really can't find a
>> source of that information.
>>
>> My google fu is failing me today, but perhaps someone can point me to the
>> relevant document or share some experience.
>>
>> Thx,
>>
>> Kind regards
>> Pshem
>>
> ___
>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>
___
cisco-nsp 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] VSM NAT - throughput

[Fredrik Vöcks]

Hi Pshem,

Yes you need to partition the VSM to get full throughput. I finally found
the document;

Logical Partitioning inside VSM

https://supportforums.cisco.com/document/12019576/cgv6-vsm-cgn-nat44-deployment-guide#nat44-on-vsm-configuration


Regards,

Fredrik

On 23 May 2016 at 02:34, Pshem Kowalczyk  wrote:

> Hi,
>
> With the ISM cards we used to run 4 set of VRFs (and 4 sets of SA
> interfaces) to achieve full throughput of the card for NAT. We're upgrading
> to VSM cards now, but I'm unable to determine if they also need a similar
> split of traffic or not. I seem to recall that they should be able to do
> about 60Gb/s of throughput and apparently the traffic needs to be split
> into two pairs of SA interfaces to achieve that, but really can't find a
> source of that information.
>
> My google fu is failing me today, but perhaps someone can point me to the
> relevant document or share some experience.
>
> Thx,
>
> Kind regards
> Pshem
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp 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] Field Notice: FN - 64110 - looking for an OID to monitor the NMI events

[Lukas Tribus]

> Been hit by this:
>
> http://www.cisco.com/c/en/us/support/docs/field-notices/641/fn64110.html
> https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuw75381/?reffering_site=dumpcr
>
> and looking for an SNMP OID to establish monitoring and alerting across all
> models and code version, while planning for upgrades. Cisco TAC provided no
> feedback, so far, and we have no high hopes for throughout the weekend, in
> this regard, on their part (the severity is being addressed, from their
> stand point, by upgrading)

According to the field notice TAC has a workaround:

> If an upgrade cannot be performed immediately, contact the Technical
> Assistance Center (TAC) in order to load a debugging plugin. This grants
> access to the Linux shell where the ports can be temporarily blocked via
> the CLI. Note that this workaround does not survive a reload, and the
> NX-OS upgrade is suggested as a long-term fix.


So you should probably insist on that workaround.



Lukas

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