Re: [c-nsp] VXLAN with EVPN CP

[Gustav Ulander]

Only Nexus 9k we want to keep our DC network and MPLS network separate so we 
run VRF-Lite and subinterfaces between ASR9k and Nexus 9k. 
We do BGP between both to redistribute VPNV4 routes to ASR9k per VRF. VXLAN 
fabric acts as a CE router viewed from PE. 

//Gustav

-Ursprungligt meddelande-
Från: adamv0...@netconsultings.com  
Skickat: den 29 augusti 2018 22:32
Till: Gustav Ulander ; 
cisco-nsp@puck.nether.net
Ämne: RE: [c-nsp] VXLAN with EVPN CP

And this is just between the Nexus9k themselves or with ASR9k in the mix as 
well please?

adam 

netconsultings.com
::carrier-class solutions for the telecommunications industry::

> -Original Message-
> From: Gustav Ulander [mailto:gustav.ulan...@telecomputing.se]
> Sent: Tuesday, August 28, 2018 8:51 AM
> To: adamv0...@netconsultings.com; cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] VXLAN with EVPN CP
> 
> Hello.
> 9K here if its any help?
> 
> //Gustav
> 
> -Original Message-
> From: cisco-nsp  On Behalf Of 
> adamv0...@netconsultings.com
> Sent: den 27 augusti 2018 20:04
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] VXLAN with EVPN CP
> 
> Hi folks,
> 
> 
> 
> Is anyone running VXLAN with EVPN Control-Plane successfully on 
> nexus3k switches please?
> 
> Thanks,
> 
> 
> 
> adam
> 
> 
> 
> netconsultings.com
> 
> ::carrier-class solutions for the telecommunications industry::
> 
> 
> 
> ___
> cisco-nsp 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] VXLAN with EVPN CP

[Gustav Ulander]

Hello.
9K here if its any help? 

//Gustav

-Original Message-
From: cisco-nsp  On Behalf Of 
adamv0...@netconsultings.com
Sent: den 27 augusti 2018 20:04
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] VXLAN with EVPN CP

Hi folks,

 

Is anyone running VXLAN with EVPN Control-Plane successfully on nexus3k 
switches please?

Thanks, 

 

adam

 

netconsultings.com

::carrier-class solutions for the telecommunications industry::

 

___
cisco-nsp 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] router suggestion for backup link

[Gustav Ulander]

Depending on featureset a good old L3 switch might be applicable? 

//Gustav

-Ursprungligt meddelande-
Från: cisco-nsp  För aptgetd
Skickat: den 10 juli 2018 06:44
Till: cisco-nsp 
Ämne: [c-nsp] router suggestion for backup link

Hi,

Can anyone provide suggestion outside cisco ASR/ISR router model that can 
handle 2.5gb throughput and also able to scale to 5gb? Currently this router 
will perform static routes but we may switch to BGP down the path to accept 
default route(s). 

Both ASR/ISR seem to be little pricey/feature rich for what we need for our 
backup 2gb link.

Any feedback will be appreciated.

-- sky
___
cisco-nsp 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] LACP Nexus vpc down after server reboot

[Gustav Ulander]

We have had some issues with VPC over non networking hw.
Works great towards our Juniper switches but is a pain to all things EMC more 
or less.
Its hit and miss towards some IBM AIX machines. It gets broken quite often when 
they patch the AIX machines. 
I would be abit careful running VPC to non networking hw and test a lot not 
just initialization of the channel but also failover, redundancy tests and so 
on.  

//Gustav

-Ursprungligt meddelande-
Från: cisco-nsp  För Satish Patel
Skickat: den 9 juli 2018 18:44
Till: Cisco Network Service Providers 
Ämne: [c-nsp] LACP Nexus vpc down after server reboot

I have Nexus 3064 with vPC configuration and some strange issue going on, I 
have configured LACP 802.3ad bonding with my Linux server everything was good 
and working great but as soon as i reboot server i found on Nexus switch vpc is 
down

N3K(config-if)# sh vpc 137


vPC status
--
id   Port   Status Consistency Reason Active vlans
--      -- --- -- 
137  Po137  down*  success success-


But as soon as i do "shut/no shut" on po137 interface it works and vpc brought 
up.

is this normal behavior on Cisco Nexus switches? I am using many IOS switch in 
same config and it works but with vpc i am having issue.

This is my switch config, i am running nexus 7.0.x NX-OS

interface port-channel137
  switchport mode trunk
  switchport trunk native vlan 40
  switchport trunk allowed vlan 10,20,30,100
  speed 1
  vpc 137


on Linux side i have following config.

BONDING_OPTS="mode=4 miimon=500 downdelay=1000 lacp_rate=1"
___
cisco-nsp 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] Core layer device n7004 vs n9396px

[Gustav Ulander]

How much routing are you going to do? 
Nexus platform is still a switch so it really depends on what features you need 
and not just the number of 10Gbit ports. 
NCS 5k platform could also be a contender perhaps? 

//Gustav

-Ursprungligt meddelande-
Från: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] För Satish Patel
Skickat: den 16 januari 2018 14:44
Till: cisco-nsp@puck.nether.net
Ämne: [c-nsp] Core layer device n7004 vs n9396px


We are planing to get 40gbps (4x10G) bonded link from ISP and I’m looking for 
any good device to terminate. 

Should I use n7004 or n9396px for core? 

We have very basic network no MPLS, no cloud etc. all I need good performance 
and reliable hardware. 

Let’s say after couple year I get new 40gbps link on same hardware in that case 
how I will set default gw for two ISP uplink? Should I use VDC or VRF for that 
senario?


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] BGP-EVPN vs Traditional Nexus 7k/5k Design

[Gustav Ulander]

Hello.
Lots of if and buts in the BGP E-VPN and VXLAN solution including some not so 
nice bugs. 
Documentation isn't really clear on some of the pitfalls either. I would 
suggest a heavy testing period more so than usual perhaps. 
Since you are running L3 on all those 1u boxes make sure that you understand 
where you land in the scalability documents. Some knobs bring scalability way 
down especially if you are running it with the older 9300 generation switches 
since they are Broadcom based. 
Newer generation 9200 and 9300 is better but there is still a couple of 
pitfalls to step into. 

//gustav

-Ursprungligt meddelande-
Från: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] För Yham
Skickat: den 2 december 2017 17:34
Till: cisco-nsp@puck.nether.net NSP 
Ämne: [c-nsp] BGP-EVPN vs Traditional Nexus 7k/5k Design

Hi Gentlemen,

We are planning to upgrade our data centers which were built on cisco'
traditional design at that time i.e nexus7Ks as core and nexus5Ks and 2Ks as 
distribution and access layer (TOR). In this design, 7Ks run layer-3 and extend 
layer2 via VPC down to 5Ks. We have the multi-tenant environment (VDCs and 
VRFs) and host customer's critical services

For the upgrade, we are exploring BGP-EVPN with VXLAN option? can someone 
please give me the pros and cons when compare with traditional 7ks/5ks vpc 
design? I read about cisco's bgp-evpn design but not sure yet what is the real 
value. are there real benefits or its just marketing fluff to sell nexus 9Ks 
and part of SDN buzz.

cisco also offer ACI and we may want to try it in green field deployment but 
don't think it mature enough and ready for us to migrate the critical 
customer's service over it now.

Regards
___
cisco-nsp 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] IPerf alternative

[Gustav Ulander]

Hello
We use some small computers similar to Intel NUC to work as probes in our POPs 
and DCs. 
We get them for like 200 USD or similar and use them for Netrounds. 


//Gustav

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
CiscoNSP List
Sent: den 9 augusti 2017 09.44
To: Josh Galvez 
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IPerf alternative

lll def check this out - Cheers - from a hardware perspective, pizza box 1RU 
servers work great, but we would also like a "smaller" option that we can send 
to various POPs for testinghas anyone got suggestions ?  I doubt the 
raspberry pi range would have the grunt to push 1G (or more?)...I maybe wrong 
though? perhaps one of the forks?


Cheers



From: Josh Galvez 
Sent: Tuesday, 8 August 2017 2:33 AM
To: CiscoNSP List
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IPerf alternative

I'm not sure how stuck on Layer3 protocols you are, but this 
https://github.com/jwbensley/Etherate is a nice Layer2 testing tool.
[https://avatars2.githubusercontent.com/u/1025875?v=4=400]

GitHub - jwbensley/Etherate: Linux CLI Ethernet and MPLS 
...
github.com
Etherate - Linux CLI Ethernet and MPLS Testing Tool



Josh

On Mon, Aug 7, 2017 at 1:25 AM, CiscoNSP List 
> wrote:
Hi everyone,


Looking for an alternative to IPerf for link testing - Having some 
"reliability" concerns with IPerf results (Primarily with simultaneous data 
transfers) - Any recommendations are greatly appreciated (10G capabilities 
would be fantastic, but not 100% necessary) - Has anyone used/tried Ostinato ? 
Primarily after a tool that can provide load testing results (simultaneous 
bidirectional, one direction, and UDP/TCP are primary requirements...Happy to 
look at a commercial product/appliance if it ticks all the boxes, but not 
wanting to spend a fortune :)


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/
___
cisco-nsp 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] NCS4200 - re-badged ASR920 / ASR900 ?

[Gustav Ulander]

Asr920 hw with ios-xr would be interesting depending on price. 

//Gustav 

-Ursprungligt meddelande-
Från: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] För Erik Sundberg
Skickat: den 25 april 2017 20:22
Till: Pete Templin ; Gert Doering ; 
CiscoNSP List 
Kopia: cisco-nsp@puck.nether.net
Ämne: Re: [c-nsp] NCS4200 - re-badged ASR920 / ASR900 ?

I just had a presentation on this.

Sounded like the ASR920 AKA Rebranded as the NCS4200 will be running the NCS 
Code. Sounded like same hardware.

Also thinking it's more of a product switch to fill out the NCS Product set.



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Pete 
Templin
Sent: Tuesday, April 25, 2017 10:09 AM
To: Gert Doering; CiscoNSP List
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] NCS4200 - re-badged ASR920 / ASR900 ?

Or the Nexus 5010 vs. UCS Fabric Interconnect debacle? I think there's one 
extra CPU/ASIC on the board of the FIs, and the paint color is different, but 
the code is different.


On 4/25/17 4:24 AM, Gert Doering wrote:
> Hi,
>
> On Tue, Apr 25, 2017 at 11:06:33AM +, CiscoNSP List wrote:
>> If feature parity between the 2 are identicalIt makes no sense?
> Look at the history of the 6500/7600 split...
>
> Starting out with identical hardware, just differently coloured, sold 
> by different BUs.
>
> Then start differenciating - one BU builds a faster supervisor, and 
> adds a software check "if we detect that the other BU got the money
> for this chassis, refuse to boot".   The other BU starts adding nice
> OS features that you really want (but are not supported on the *other* 
> chassis, then) and down the drain goes the journey.
>
> I ended up having 6500s, because we wanted IOS modularity (which 
> turned out to be no good, and was discontinued), and was lacking all 
> the newer
> control-plane(!) features the 7600 IOS received after the split...
>
>
> (cisco-nsp archives have lots of material on this)
>
> gert
>
>
> ___
> cisco-nsp 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/



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain confidential information 
that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of any of the 
information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error please notify the 
sender immediately by replying to this e-mail. You must destroy the original 
transmission and its attachments without reading or saving in any manner. Thank 
you.
___
cisco-nsp 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] NCS-5501 & 5502 Experiences?

[Gustav Ulander]

Ahhh I see. 
Yepp, were using em as LSRs so no real public access vector into it so we 
didn’t deepdive and trim that much just added some standardized configuration 
on it. 
Good to know to be cautious with that setting though thanks 

//Gustav

-Ursprungligt meddelande-
Från: Saku Ytti [mailto:s...@ytti.fi] 
Skickat: den 4 februari 2017 01:38
Till: Gustav Ulander <gustav.ulan...@telecomputing.se>
Kopia: Adrian Minta <adrian.mi...@gmail.com>; cisco-nsp@puck.nether.net
Ämne: Re: [c-nsp] NCS-5501 & 5502 Experiences?

On 4 February 2017 at 02:01, Gustav Ulander <gustav.ulan...@telecomputing.se> 
wrote:

Hey,

> We are able to enter the configuration and were also able to show lpts and se 
> counters go up. It would be interesting to know how far you got?

As far as unable to keep good BGP up, when unconfigured flood of BGP packets 
came in, Cisco confirmed not supported/implemented (yet). It's not atypical in 
this segment of devices, so not throwing dirt here.
Many applications of the device are in networks where malicious packets are not 
a concern and it would be foolish to delay TTM until this is done.

--
  ++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] NCS-5501 & 5502 Experiences?

[Gustav Ulander]

Hello Saku. 
Interesting, granted we haven’t played around that much with it and its abit 
troubling if it actually dosent work. 
Where you able to enter the configuration when you were evaluating it? We are 
running 6.1.2.
We are able to enter the configuration and were also able to show lpts and se 
counters go up. It would be interesting to know how far you got? 

RP/0/RP0/CPU0:cr03(config)#lpts pifib hardware police ?
  acl   pre-ifib acl name
  flow  lpts flow type
  location  Location Specification
  
RP/0/RP0/CPU0:cr03(config)#lpts pifib hardware police
RP/0/RP0/CPU0:cr03(config-pifib-policer-global)#commit
Fri Feb  3 23:53:42.671 UTC

Also counters are going up when doing show lpts. 

RP/0/RP0/CPU0:cr03#sh lpts pifib hardware police
Fri Feb  3 23:55:03.863 UTC
-
Node 0/RP0/CPU0:
-
 Burst = 100ms for all flow types
-
FlowType   Policer TypeCur. Rate  Def. Rate  Accepted   
  Dropped  TOS Value
-- --- --- -- -- 
  --
unconfigured-default   0   Static  2500   2500   0  
  001234567
L2TPv2-fragment85  Static  1  1  0  
  001234567
Fragment   1   Static  1000   1000   0  
  001234567
OSPF-mc-known  2   Static  2000   2000   0  
  001234567
OSPF-mc-default3   Static  1500   1500   0  
  001234567
OSPF-uc-known  4   Static  2000   2000   0  
  001234567
OSPF-uc-default5   Static  1000   1000   0  
  001234567
ISIS-known 43  Static  2000   2000   2084616
  001234567
ISIS-default   44  Static  1500   1500   2084616
  001234567
BFD-known  50  Static  9600   9600   0  
  001234567
BFD-default60  Static  9600   9600   0  
  001234567

//Gustav

-Ursprungligt meddelande-
Från: Saku Ytti [mailto:s...@ytti.fi] 
Skickat: den 3 februari 2017 20:01
Till: Gustav Ulander <gustav.ulan...@telecomputing.se>
Kopia: Adrian Minta <adrian.mi...@gmail.com>; cisco-nsp@puck.nether.net
Ämne: Re: [c-nsp] NCS-5501 & 5502 Experiences?

On 3 February 2017 at 17:36, Gustav Ulander <gustav.ulan...@telecomputing.se> 
wrote:

> As far as we have been able to verify the copp policy seems to be working in 
> the same manner.

This does not match our testing nor information we've received from Cisco. To 
my best of knowledge platform should not support LPTS yet.

--
  ++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] NCS-5501 & 5502 Experiences?

[Gustav Ulander]

Hello
We are actually using the 5001 not the 5501. This means we are having 40x10Gbit 
and 4x100Gbit which is the same as stated throughput. However we are pretty far 
from those traffic levels so we don't see that as a major issue at the moment 
anyway.
As far as we have been able to verify the copp policy seems to be working in 
the same manner. 

//Gustav
-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Adrian 
Minta
Sent: den 3 februari 2017 14.08
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] NCS-5501 & 5502 Experiences?

Hi Gustav,
How bad NCS5501 not SE variant is oversubscribed ? From the data sheet "up to 
800 Gbps of system throughput" fall short of the total 48x10 + 6x100.
Does NCS5501 has a LPTS/CoPP implementation similar with ASR9k ?

Many thanks in advance !

On 02/02/2017 10:56 AM, Gustav Ulander wrote:
> Hello.
> We are using NCS 5001 in this role with great success haven't had any issues 
> with it.
> They seem to be just working although that's not that surprising given that 
> its not that complex of an environment.
> We don't do OSPF-TE or RSVP-TE though so on that I cannot comment.
>
> //Gustav
>
>
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf 
> Of James Jun
> Sent: den 2 februari 2017 00.35
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] NCS-5501 & 5502 Experiences?
>
>
> Is anybody rolling NCS 5501 or 5502 in production yet with the current IOXR 
> 6.1 build?
>
> We're evaluating deploying NCS 5501 and 5502 (the -TR variants, not SE) for 
> some MPLS LSR role.
> If selected, the NCS55K would be used as pure 'P' router where all it does is 
> label switching in the middle, with ASR9K and MX boxes serving as PE's using 
> 100GE into NCS55k.  We do not need L2VPN, L3VPN or any PE services.
>
> Our requirements are fairly simple, as noted below.  I've already run this 
> through with our SE, and he had confirmed that NCS5501 and 5502 should 
> support them all, but I was wondering if anybody had any experience using 
> these boxes in production.
>
>
> Requirements:
> - MPLS Traffic Engineering (using OSPF-TE) and RSVP-TE
> - Fast Reroute for RSVP-TE LSPs
> - Bundle-Ether/LAG hashing - src/dst + ports, labels, for labeled traffic.
>Majority of labeled traffic expected to traverse through the NCS are 
> typical IP/IMIX internet
>traffic, but labeled 1 time for PE-to-PE LSPs; IPv6 traffic would see two 
> labels due to 6PE;
>There is also some limited pseudowire and vpn traffic so hashing on labels 
> would be needed
>as well.  For the latter case regarding l2vpn, PEs will build l2circuits 
> using FAT-PW.
> - No need for large FIB, just decent LFIB to hold LSPs and FRR bypasses for 
> typical metro size
>regional network.
>
> - The port buffers on NCS5501 are deemed sufficient enough for 100GE->10GE 
> stepdown on bursty
>internet use/IMIX traffic, but real life experiences/feedback would be 
> nice to hear.
>
> - We do not need to run BGP on these; out-of-band route-reflectors are used.
>
>
> Many thanks in advance,
>
> James

--
Best regards,
Adrian Minta


___
cisco-nsp 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] NCS-5501 & 5502 Experiences?

[Gustav Ulander]

Hello Aaron. 
Yea only IGP and LDP for labelswitching. 
We are thinking about testing out segment routing to be able to ditch LDP and 
be able to do TE without going RSVP-TE path. 
However, we have some legacy equipment the needs to be replaced first so we 
aren't in a hurry.

//gustav

-Ursprungligt meddelande-
Från: Aaron [mailto:aar...@gvtc.com] 
Skickat: den 2 februari 2017 23:14
Till: Gustav Ulander <gustav.ulan...@telecomputing.se>; 'James Jun' 
<ja...@towardex.com>; cisco-nsp@puck.nether.net
Ämne: RE: [c-nsp] NCS-5501 & 5502 Experiences?

Gustav, do you just do an igp-core like ospf with ldp for label advertisements ?

Also, would you mind sending the output for "show version" and "show inventory" 
(or xr equivalent , "admin show plat" and "show install committed
summary")

I might have my cisco account team bring one for lab testing.

When I looked at a NCS5000 last year the PE functions weren't working.  But now 
I am in the market for a pure P box and might take another look at it.

-Aaron


___
cisco-nsp 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] NCS-5501 & 5502 Experiences?

[Gustav Ulander]

Hello.
We are using NCS 5001 in this role with great success haven't had any issues 
with it. 
They seem to be just working although that's not that surprising given that its 
not that complex of an environment. 
We don't do OSPF-TE or RSVP-TE though so on that I cannot comment. 

//Gustav


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of James 
Jun
Sent: den 2 februari 2017 00.35
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] NCS-5501 & 5502 Experiences?


Is anybody rolling NCS 5501 or 5502 in production yet with the current IOXR 6.1 
build?

We're evaluating deploying NCS 5501 and 5502 (the -TR variants, not SE) for 
some MPLS LSR role.
If selected, the NCS55K would be used as pure 'P' router where all it does is 
label switching in the middle, with ASR9K and MX boxes serving as PE's using 
100GE into NCS55k.  We do not need L2VPN, L3VPN or any PE services.

Our requirements are fairly simple, as noted below.  I've already run this 
through with our SE, and he had confirmed that NCS5501 and 5502 should support 
them all, but I was wondering if anybody had any experience using these boxes 
in production.


Requirements:
- MPLS Traffic Engineering (using OSPF-TE) and RSVP-TE
- Fast Reroute for RSVP-TE LSPs
- Bundle-Ether/LAG hashing - src/dst + ports, labels, for labeled traffic.
  Majority of labeled traffic expected to traverse through the NCS are typical 
IP/IMIX internet
  traffic, but labeled 1 time for PE-to-PE LSPs; IPv6 traffic would see two 
labels due to 6PE;
  There is also some limited pseudowire and vpn traffic so hashing on labels 
would be needed
  as well.  For the latter case regarding l2vpn, PEs will build l2circuits 
using FAT-PW.
- No need for large FIB, just decent LFIB to hold LSPs and FRR bypasses for 
typical metro size
  regional network.

- The port buffers on NCS5501 are deemed sufficient enough for 100GE->10GE 
stepdown on bursty
  internet use/IMIX traffic, but real life experiences/feedback would be nice 
to hear.

- We do not need to run BGP on these; out-of-band route-reflectors are used.


Many thanks in advance,

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] 3rd party dwdm 80km optics in asr 9001

[Gustav Ulander]

Hello.

Yea but the 9001 should also support 3rd party optics. 
We have worked with our supplier for this batch of optics and they confirm that 
the ones we received might not have been compatible with ASR9k so they are 
sending us new ones to exchange with.
Hopefully this will solve the problem.

On a different note and more on the lines of your email I find it interesting 
that the optics suppliers produce optics with different coding. 


-Ursprungligt meddelande-
Från: Ulrik Ivers [mailto:ulrik.iv...@excanto.se] 
Skickat: den 19 oktober 2016 22:48
Till: Gustav Ulander <gustav.ulan...@telecomputing.se>; Cisco Network Service 
Providers <cisco-nsp@puck.nether.net>
Ämne: RE: [c-nsp] 3rd party dwdm 80km optics in asr 9001

Hi Gustav,

Found this compatability matrix specifically for ASR 9000 the other day 
(researching CWDM XFP:s for our 9001).
https://supportforums.cisco.com/document/12940551/asr9000-optics-support-matrix

According to this the DWDM SFP+ for 9001 should be coded as DWDM-SFP10G-xx.yy

/Ulrik

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gustav 
Ulander
Sent: den 28 september 2016 13:09
To: Shawn L <sh...@rmrf.us>; Cisco Network Service Providers 
<cisco-nsp@puck.nether.net>
Subject: Re: [c-nsp] 3rd party dwdm 80km optics in asr 9001

Yepp
We actually got an error that says unsupported transceiver so that's why we are 
going to try a different supplier. 

LC/0/0/CPU0:Sep 27 08:26:43.698 : pfm_node_lc[294]: 
%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR : Clear|vic[475264]|0x1029000|SFP 
Module for port 00 is not a supported module type LC/0/0/CPU0:Sep 27 
08:26:43.699 : pfm_node_lc[294]: %PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED : 
Clear|vic[475264]|0x1029000|SFP Module for port 00 is not a supported Product 
ID (PID) RP/0/RSP0/CPU0:Sep 27 08:26:44.151 : invmgr[255]: 
%PLATFORM-INV-6-IF_OIROUT : xFP OIR: 0/0/2 port_num: 0 is removed, state: 0 
RP/0/RSP0/CPU0:Sep 27 08:27:28.669 : invmgr[255]: %PLATFORM-INV-6-IF_OIRIN : 
xFP OIR: 0/0/2 port_num: 0 is inserted, state: 1 LC/0/0/CPU0:Sep 27 
08:27:29.775 : pfm_node_lc[294]: %PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR : 
Set|vic[475264]|0x1029000|SFP Module for port 00 is not a supported module type 
LC/0/0/CPU0:Sep 27 08:27:29.775 : pfm_node_lc[294]: 
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED : Set|vic[475264]|0x1029000|SFP 
Module for port 00 is not a supported Product ID (PID) When looking at the 
optics. 

Operational data for interface TenGigE0/0/2/0:

State:
Administrative state: enabled
Operational state: Down (Reason: Link loss or low light, no loopback)
LED state: Red On

Phy:
Media type: Not known
Optics:
Vendor: Pro10Optix
Part number: SFP-10G-DWDM-192
Serial number: D1509180341
Wavelength: 0 nm
Digital Optical Monitoring:
Transceiver Temp: 37.000 C
Transceiver Voltage: 3.217 V

Im starting to wonder if it's the wrong partnumber that it is reacting on. 

//Gustav

-Ursprungligt meddelande-
Från: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] För Shawn L
Skickat: den 28 september 2016 12:54
Till: Cisco Network Service Providers <cisco-nsp@puck.nether.net>
Ämne: Re: [c-nsp] 3rd party dwdm 80km optics in asr 9001

I've found cisco routers to be especially picky about 3rd party optics lately.  
I have guaranteed compatible optics that work flawlessly in Cisco switches the 
will absolutely not work in a cisco router (asr-1001 /
ASR-9001 / 9k).  Generally in the router you can see them, etc.  they just 
don't ever establish a link.

On Wed, Sep 28, 2016 at 6:47 AM, Curtis Piehler <cpiehl...@gmail.com> wrote:

> I am rather shocked this doesn't work.   I'm not sure about the 9001
> however we use varies MPAs for the 9006/9010 with third party dwdm 
> xfp/sfp+ no issues.
>
> On Sep 28, 2016 6:42 AM, "Gustav Ulander" 
> <gustav.ulan...@telecomputing.se
> >
> wrote:
>
> > Hello.
> >
> > Iam woundering if anyone has had issues running 3rd party optics in 
> > the built in optics ports of a ASR9001 .
> > We have some 80km DWDM optics that we get module is not supported for.
> > We tried with transceiver permit pid all. We have similar SR-MM 
> > modules installed in the same machine that is working as advertised.
> > Iam beginning to wounder if the ASR 9001 is more sensitive with the 
> > longrange optics?
> > We have been using the same optics in a couple of 6500 SUP2t with X2 
> > converters without issues but we cant seem to be bale to get a link 
> > on
> the
> > ASR9001.
> > We are running 5.3.3 on these routers which might be an issue also 
> > we haven't tried downgrade them to something earlier.
> > Perhaps others has had the same issue?
> >
> > //Gustav
> >
> > _

Re: [c-nsp] 3rd party dwdm 80km optics in asr 9001

[Gustav Ulander]

Hello Adam.

Yepp both commands are set but still no joy.
As I understand it from a post by Xander on cisco supportforum those commands 
should let the router bypass all checks for product id and so on so in my mind 
it “should work”.
I will get in touch with our present suppliers and ask them to recode the 
optics as Anders said bellow.

//Gustav

Från: Adam Vitkovsky [mailto:adam.vitkov...@gamma.co.uk]
Skickat: den 28 september 2016 13:39
Till: Gustav Ulander <gustav.ulan...@telecomputing.se>; Shawn L 
<sh...@rmrf.us>; Cisco Network Service Providers <cisco-nsp@puck.nether.net>
Ämne: RE: [c-nsp] 3rd party dwdm 80km optics in asr 9001

> Gustav Ulander
> Sent: Wednesday, September 28, 2016 12:09 PM
>
> Yepp
> We actually got an error that says unsupported transceiver so that's why we
> are going to try a different supplier.
>
Can you ask your supplier to code the transceiver to be supported by your box, 
then you shouldn't even need the below?

I presume you have tried these commands already:
Interface:
"transceiver permit pid all"
Or
global (hidden):
"service unsupported-tranceiver"


adam








Adam Vitkovsky
IP Engineer

T: 0333 006 5936
E: adam.vitkov...@gamma.co.uk<mailto:adam.vitkov...@gamma.co.uk>
W: www.gamma.co.uk<http://www.gamma.co.uk>

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email 
postmas...@gamma.co.uk<mailto:postmas...@gamma.co.uk>

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


This email has been scanned for email related threats and delivered safely by 
Mimecast.
For more information please visit http://www.mimecast.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/

Re: [c-nsp] 3rd party dwdm 80km optics in asr 9001

[Gustav Ulander]

Yepp
We actually got an error that says unsupported transceiver so that's why we are 
going to try a different supplier. 

LC/0/0/CPU0:Sep 27 08:26:43.698 : pfm_node_lc[294]: 
%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR : Clear|vic[475264]|0x1029000|SFP 
Module for port 00 is not a supported module type
LC/0/0/CPU0:Sep 27 08:26:43.699 : pfm_node_lc[294]: 
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED : Clear|vic[475264]|0x1029000|SFP 
Module for port 00 is not a supported Product ID (PID)
RP/0/RSP0/CPU0:Sep 27 08:26:44.151 : invmgr[255]: %PLATFORM-INV-6-IF_OIROUT : 
xFP OIR: 0/0/2 port_num: 0 is removed, state: 0
RP/0/RSP0/CPU0:Sep 27 08:27:28.669 : invmgr[255]: %PLATFORM-INV-6-IF_OIRIN : 
xFP OIR: 0/0/2 port_num: 0 is inserted, state: 1
LC/0/0/CPU0:Sep 27 08:27:29.775 : pfm_node_lc[294]: 
%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR : Set|vic[475264]|0x1029000|SFP Module 
for port 00 is not a supported module type
LC/0/0/CPU0:Sep 27 08:27:29.775 : pfm_node_lc[294]: 
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED : Set|vic[475264]|0x1029000|SFP 
Module for port 00 is not a supported Product ID (PID)
When looking at the optics. 

Operational data for interface TenGigE0/0/2/0:

State:
Administrative state: enabled
Operational state: Down (Reason: Link loss or low light, no loopback)
LED state: Red On

Phy:
Media type: Not known
Optics:
Vendor: Pro10Optix
Part number: SFP-10G-DWDM-192
Serial number: D1509180341
Wavelength: 0 nm
Digital Optical Monitoring:
Transceiver Temp: 37.000 C
Transceiver Voltage: 3.217 V

Im starting to wonder if it's the wrong partnumber that it is reacting on. 

//Gustav

-Ursprungligt meddelande-
Från: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] För Shawn L
Skickat: den 28 september 2016 12:54
Till: Cisco Network Service Providers <cisco-nsp@puck.nether.net>
Ämne: Re: [c-nsp] 3rd party dwdm 80km optics in asr 9001

I've found cisco routers to be especially picky about 3rd party optics lately.  
I have guaranteed compatible optics that work flawlessly in Cisco switches the 
will absolutely not work in a cisco router (asr-1001 /
ASR-9001 / 9k).  Generally in the router you can see them, etc.  they just 
don't ever establish a link.

On Wed, Sep 28, 2016 at 6:47 AM, Curtis Piehler <cpiehl...@gmail.com> wrote:

> I am rather shocked this doesn't work.   I'm not sure about the 9001
> however we use varies MPAs for the 9006/9010 with third party dwdm 
> xfp/sfp+ no issues.
>
> On Sep 28, 2016 6:42 AM, "Gustav Ulander" 
> <gustav.ulan...@telecomputing.se
> >
> wrote:
>
> > Hello.
> >
> > Iam woundering if anyone has had issues running 3rd party optics in 
> > the built in optics ports of a ASR9001 .
> > We have some 80km DWDM optics that we get module is not supported for.
> > We tried with transceiver permit pid all. We have similar SR-MM 
> > modules installed in the same machine that is working as advertised.
> > Iam beginning to wounder if the ASR 9001 is more sensitive with the 
> > longrange optics?
> > We have been using the same optics in a couple of 6500 SUP2t with X2 
> > converters without issues but we cant seem to be bale to get a link 
> > on
> the
> > ASR9001.
> > We are running 5.3.3 on these routers which might be an issue also 
> > we haven't tried downgrade them to something earlier.
> > Perhaps others has had the same issue?
> >
> > //Gustav
> >
> > ___
> > cisco-nsp 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] 3rd party dwdm 80km optics in asr 9001

[Gustav Ulander]

Yea same here it has caused some delays for us.
We have ordered optics from another supplier to se if that’s a way forward 
however it seems rather unpleasant.

//Gustav

Från: Curtis Piehler [mailto:cpiehl...@gmail.com]
Skickat: den 28 september 2016 12:47
Till: Gustav Ulander <gustav.ulan...@telecomputing.se>
Kopia: Cisco Network Service Providers <cisco-nsp@puck.nether.net>
Ämne: Re: [c-nsp] 3rd party dwdm 80km optics in asr 9001


I am rather shocked this doesn't work.   I'm not sure about the 9001 however we 
use varies MPAs for the 9006/9010 with third party dwdm xfp/sfp+ no issues.

On Sep 28, 2016 6:42 AM, "Gustav Ulander" 
<gustav.ulan...@telecomputing.se<mailto:gustav.ulan...@telecomputing.se>> wrote:
Hello.

Iam woundering if anyone has had issues running 3rd party optics in the built 
in optics ports of a ASR9001 .
We have some 80km DWDM optics that we get module is not supported for.
We tried with transceiver permit pid all. We have similar SR-MM modules 
installed in the same machine that is working as advertised.
Iam beginning to wounder if the ASR 9001 is more sensitive with the longrange 
optics?
We have been using the same optics in a couple of 6500 SUP2t with X2 converters 
without issues but we cant seem to be bale to get a link on the ASR9001.
We are running 5.3.3 on these routers which might be an issue also we haven't 
tried downgrade them to something earlier.
Perhaps others has had the same issue?

//Gustav

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

Re: [c-nsp] 3rd party dwdm 80km optics in asr 9001

[Gustav Ulander]

Hello.

Iam woundering if anyone has had issues running 3rd party optics in the built 
in optics ports of a ASR9001 .
We have some 80km DWDM optics that we get module is not supported for.
We tried with transceiver permit pid all. We have similar SR-MM modules 
installed in the same machine that is working as advertised.
Iam beginning to wounder if the ASR 9001 is more sensitive with the longrange 
optics?
We have been using the same optics in a couple of 6500 SUP2t with X2 converters 
without issues but we cant seem to be bale to get a link on the ASR9001.
We are running 5.3.3 on these routers which might be an issue also we haven't 
tried downgrade them to something earlier.
Perhaps others has had the same issue?

//Gustav

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

[Gustav Ulander]

Hello.

Our experience is that if you are not happy with the engineer that is assigned 
you can always escalate to their suprevisor and ask for another engineer to be 
assigned. 

//gustav

-Ursprungligt meddelande-
Från: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] För Eric Van Tol
Skickat: den 11 maj 2016 11:48
Till: cisco-nsp@puck.nether.net
Ämne: [c-nsp] ASR920 stops routing unexpectedly

Hi all,
I am now on my third day with TAC on this problem and they are driving me up a 
wall. I have an ASR-920-24SZ-M that has been in service for almost a year, on 
3.15.0S running ISIS, BFD on one link, BGP, LDP, MPLS. Shortly after midnight 
this past Saturday, it stopped routing for no apparent reason. As we have it 
connected to an ethernet OOB network, I was able to get in it to take a look. 

The first thing we see is that BFD on one of the upstream links times out. Then 
*every* ISIS session on the router goes down and it stops processing ISIS 
updates. All the interfaces were up/up and doing a shut/no shut on them did not 
bring ISIS back up. Unfortunately, I wasn't thoughtful enough to do a simple 
ping across them to see if they were processing *anything*. The only way to 
recover appeared to be a reboot.

I'd chalk that up to a "network anomaly", but the following night it happened 
again right around the same time. Again, in my rush to get everything back up 
and running, I had to reboot it before I could gather much information (ie. no 
ping, like an idiot).

I'm running 3.15.0S, but don't want to upgrade without knowing what this is. I 
found this link to an old discussion: 

http://www.gossamer-threads.com/lists/cisco/nsp/191739#191739

But TAC is ignoring my request for details on this bug. The first level TAC 
engineer keeps focusing on the upstream link, completely ignoring the fact that 
the router stops processing routing protocol updates. Anyone else experience 
this kind of weirdness with the ASR? And if so, what can I tell the next TAC 
engineer in order to get past this "it looks like a link failure" tunnel vision 
bullshit that they so often like to have? 

-evt

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp 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 "console" port....ugh

[Gustav Ulander]

Yepp have had many onsite techies informing me of impending doom since the 
machine is broken... 

//Gustav

-Ursprungligt meddelande-
Från: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] För Adrian Minta
Skickat: den 2 februari 2016 19:30
Till: cisco-nsp@puck.nether.net
Ämne: Re: [c-nsp] ASR920 "console" portugh

Since is ASR920 bashing time ... anyone else noticed the red led ?
Apparently red is the new green.

-- 
Best regards,
Adrian Minta


___
cisco-nsp 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] NCS-5001 - sweet...got one in the lab

[Gustav Ulander]

Hello Aaron. 

That sounds nice could you give any feedback when you have done some more tests 
with it? 
We are looking at it as a replacement for our 6.5k P boxes. The spec sheet says 
that it would be a good fit but it would be interesting to get your opinion on 
them. :)

//Gustav

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert 
Doering
Sent: den 2 februari 2016 08:02
To: Aaron
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] NCS-5001 - sweet...got one in the lab

Hi,

On Mon, Feb 01, 2016 at 03:52:00PM -0600, Aaron wrote:
> wow, check out the interface names at the bottom of the list, yeah the 
> names that start with "H" !!

So, how's XR 6.0 like?  Is it true that it does no longer support EIGRP?

(The NCS5k feature list lists OSPF, ISIS etc., but EIGRP is suspiciously
missing...)

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] RFC 7432 (EVPN) support CPE devices.

[Gustav Ulander]

Hello.

Does anyone have any experience with any CPE that supports RFC 7432?
I know it is available in ASR9k but we would like to have a local CPE to hand 
it of to the customer.
As far as I understand there isn't one out yet that supports int?

The present solution would force us to switch all traffic towards the PE and 
encapsulate it at that point but we would rather use  a CPE at the customer 
location for this.
I would think that it should be in the pipeline for ASR920 perhaps.
Maybe the ISR series will support it?

We are also quite interested in the cross support in EVPN with different 
dataplanes? I would presume that some sort of bridging would be required for 
instance with MP-BGP Controlplane and a combination of VXLAN and MPLS 
dataplanes.


//Gustav

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

[Gustav Ulander]

Hello.

Got a tip of list to try and change the label mode which I did. 
Configuring the PE router with the IPV4 peer with per-ce and a reboot solved it 
for CSR1000v. :)

//Gustav 


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gustav 
Ulander
Sent: den 19 november 2015 08:29
To: 'cisco-nsp@puck.nether.net' <cisco-nsp@puck.nether.net>
Subject: Re: [c-nsp] Readvertising strangeness.

Hello.

So a little update and background. 
What iam trying to accomplish is to change the AS number in half the network 
since we are going to connect 2 different AS numbers. 
The idea was to connect the networks via IGP in the core nodes together with 
LDP to get transport labels across and then just peer between the 
Routereflectors to get vpnv4 advertisements across. With this setup we would be 
able to provision Customer IP-VPN across the 2  networks without having to 
stitch the VRFs or having all the traffic move between PE routers as in 
inter-as option 2 (which seems to be the closest to what iam thinking).

//Gustav


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gustav 
Ulander
Sent: den 17 november 2015 11:04
To: 'cisco-nsp@puck.nether.net'
Subject: Re: [c-nsp] Readvertising strangeness.

Hello people.

I have some strange things going on here.
Iam doing  some test configurations in the lab and are trying to see how 2 AS 
numbers behave when they peer via their respective route reflectors.
I am using CSR1000v for this lab as a start.
I have 2 AS numbers to start with. Every AS has 1 PE router, 1 P router and 1 
route reflector.
The PE and RR are doing IBGP and MPLS. The P router is doing IGP (OSPF) and 
MPLS. The 2 AS numbers are connected via IGP between P routers.
The two route reflectors are doing EBGP between themselves with next-hop 
unchanged to allow the PE routers to send traffic directly towards each other.
Everything Is working as expected and Iam able to import and export route 
targets across ASes when I have locally attached interfaces.
The strange part arises when I add EBGP links to the PE routers.
I can have a VRF that has a loopback in each PE router ping works perfectly 
between them and traceroute says that iam using the label switched path via P 
routers.
However If I introduce a EBGP link in the VRF the router that has the link can 
no longer ping the other PE router. The PE router that dosent have the link can 
ping the first PE router.
So it seems that when I introduce a EBGP link in the vrf the forwarding stops 
working.
The routes from the other is still in the table and labels are assigned and so 
forth. Anyone have any input?


//Gustav
___
cisco-nsp 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] Readvertising strangeness.

[Gustav Ulander]

Hello.

So a little update and background. 
What iam trying to accomplish is to change the AS number in half the network 
since we are going to connect 2 different AS numbers. 
The idea was to connect the networks via IGP in the core nodes together with 
LDP to get transport labels across and then just peer between the 
Routereflectors to get vpnv4 advertisements across. With this setup we would be 
able to provision Customer IP-VPN across the 2  networks without having to 
stitch the VRFs or having all the traffic move between PE routers as in 
inter-as option 2 (which seems to be the closest to what iam thinking).

//Gustav


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gustav 
Ulander
Sent: den 17 november 2015 11:04
To: 'cisco-nsp@puck.nether.net'
Subject: Re: [c-nsp] Readvertising strangeness.

Hello people.

I have some strange things going on here.
Iam doing  some test configurations in the lab and are trying to see how 2 AS 
numbers behave when they peer via their respective route reflectors.
I am using CSR1000v for this lab as a start.
I have 2 AS numbers to start with. Every AS has 1 PE router, 1 P router and 1 
route reflector.
The PE and RR are doing IBGP and MPLS. The P router is doing IGP (OSPF) and 
MPLS. The 2 AS numbers are connected via IGP between P routers.
The two route reflectors are doing EBGP between themselves with next-hop 
unchanged to allow the PE routers to send traffic directly towards each other.
Everything Is working as expected and Iam able to import and export route 
targets across ASes when I have locally attached interfaces.
The strange part arises when I add EBGP links to the PE routers.
I can have a VRF that has a loopback in each PE router ping works perfectly 
between them and traceroute says that iam using the label switched path via P 
routers.
However If I introduce a EBGP link in the VRF the router that has the link can 
no longer ping the other PE router. The PE router that dosent have the link can 
ping the first PE router.
So it seems that when I introduce a EBGP link in the vrf the forwarding stops 
working.
The routes from the other is still in the table and labels are assigned and so 
forth. Anyone have any input?


//Gustav
___
cisco-nsp 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] Readvertising strangeness.

[Gustav Ulander]

Hello people.

I have some strange things going on here.
Iam doing  some test configurations in the lab and are trying to see how 2 AS 
numbers behave when they peer via their respective route reflectors.
I am using CSR1000v for this lab as a start.
I have 2 AS numbers to start with. Every AS has 1 PE router, 1 P router and 1 
route reflector.
The PE and RR are doing IBGP and MPLS. The P router is doing IGP (OSPF) and 
MPLS. The 2 AS numbers are connected via IGP between P routers.
The two route reflectors are doing EBGP between themselves with next-hop 
unchanged to allow the PE routers to send traffic directly towards each other.
Everything Is working as expected and Iam able to import and export route 
targets across ASes when I have locally attached interfaces.
The strange part arises when I add EBGP links to the PE routers.
I can have a VRF that has a loopback in each PE router ping works perfectly 
between them and traceroute says that iam using the label switched path via P 
routers.
However If I introduce a EBGP link in the VRF the router that has the link can 
no longer ping the other PE router. The PE router that dosent have the link can 
ping the first PE router.
So it seems that when I introduce a EBGP link in the vrf the forwarding stops 
working.
The routes from the other is still in the table and labels are assigned and so 
forth. Anyone have any input?


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

Re: [c-nsp] Cisco ASR/CSR VXLAN

[Gustav Ulander]

Hello.

Iam quite curious regarding this also. 
As far as I understand you bind the VTEP interface to the L2 part of your 
network with a bridge-domain. 
Iam thinking that you could assign a BDI interface to the same bridge-domain? 
Logically it makes sence but I haven't tried it since iam lacking hardware at 
the moment to try on. 
This would perhaps also work without the service instance part so you can 
pinhole the VXLAN traffic to your PE/DCI routers actually route the 
broadcastdomain on the router itself. 
It would make implementing VXLAN as an alternative to STP abit easier I would 
think. 
Perhaps someone else has played some more with a similar concept? We are also 
looking into using ASR 9k routers instead of 1k ones. 


//Gustav

 

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Skeeve 
Stevens
Sent: den 4 november 2015 16:51
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Cisco ASR/CSR VXLAN

Hi all,

I presume this issue is the same on both the CSR1k and ASR1k platforms.

Given that VXLAN has to terminate on a Layer 3 interface... I am struggling to 
figure out how to terminate a VXLAN at layer 2 on the platform and then put 
layer 3 onto it (SVI style).

Anyone got any ideas?

...Skeeve

*Skeeve Stevens - Founder & The Architect* - eintellego Networks Pty Ltd
Email: ske...@eintellegonetworks.com ; Web: eintellegonetworks.com

Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve

Facebook: eintellegonetworks  ;
Twitter: eintellego 

LinkedIn: /in/skeeve  ; Expert360: Profile 
 ; Keybase: https://keybase.io/skeeve


Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises 
___
cisco-nsp 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] The Family of ASR902 - ASR903 - ASR907

[Gustav Ulander]

Hello.
+1 also

//Gustav


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dan 
Peachey
Sent: den 28 oktober 2015 13:16
To: Waris Sagheer (waris); cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] The Family of ASR902 - ASR903 - ASR907

On 28 October 2015 at 11:50, Adam Vitkovsky 
wrote:

> Hi Waris,
>
> > Waris Sagheer (waris)
> > Sent: Wednesday, October 28, 2015 3:46 AM
> >
> > Hi Aaron and team,
> > If there is an interest in the details of ASR903 RSP3, ASR907 RSP3,
> ASR902 &
> > ASR920  family, we can do a webinar on them. Let me know and I will 
> > schedule it.
> >
>
> Yes please webinar would be fantastic.
>
>
> adam
>
>
+1

Thanks,

Dan
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp 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 - ISR4431

[Gustav Ulander]

Hello Waris.
Yepp we looked at it but we can not provide access to some of our hardware to 
this and then the point is more or less gone as we see it.
Might be that our implementation is a corner case but that's the problem for us.

//Gustav

From: Waris Sagheer (waris) [mailto:wa...@cisco.com]
Sent: den 4 juni 2015 04:58
To: Gustav Ulander; Gert Doering; Nick Cutting
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ASR920 - ISR4431

Gustav,
Have you looked at smart licensing? I am hoping that should simplify the 
process.

Best Regards,

[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]


Waris Sagheer
Technical Marketing Manager
Service Provider Routing Segment
wa...@cisco.commailto:wa...@cisco.com
Phone: +1 408 853 6682
Mobile: +1 408 835 1389

CCIE - 19901



This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.

For corporate legal information go 
to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html



From: Gustav Ulander 
gustav.ulan...@telecomputing.semailto:gustav.ulan...@telecomputing.se
Date: Wednesday, June 3, 2015 at 5:18 AM
To: Gert Doering g...@greenie.muc.demailto:g...@greenie.muc.de, Nick 
Cutting ncutt...@edgetg.co.ukmailto:ncutt...@edgetg.co.uk
Cc: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net 
cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ASR920 - ISR4431

Hello all.
My take is that a consumption based sales model can be good as long as you are 
not hindered in your work because of it.
Hate when you have some late night work to be done that can't be completed 
because of some weird restriction dependent in some way on a license.
RTU licenses are the way from my way of looking at it however, I have a feeling 
that cisco is not equally impressed with RTU licenses.

//Gustav

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert 
Doering
Sent: den 3 juni 2015 13:55
To: Nick Cutting
Cc: Gert Doering; cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ASR920 - ISR4431

Hi,

On Wed, Jun 03, 2015 at 11:41:41AM +, Nick Cutting wrote:
Yep, I don't mind at all.  :)
Too many times it has been, should've gone cisco in terms of missing features 
stability etc.
At least with cisco I know what works and doesn't.

I used to say that, 15 years ago...

Then they decided to split the company into in-fighting BUs...

Nowadays, I know that it works if I've laid my hands on it and it actually 
did (and didn't lose the license to make it work on the next upgrade).

gert
--
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany 
g...@greenie.muc.demailto:g...@greenie.muc.de
fax: +49-89-35655025
g...@net.informatik.tu-muenchen.demailto:g...@net.informatik.tu-muenchen.de
___
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] ASR920 - ISR4431

[Gustav Ulander]

Hello all. 
My take is that a consumption based sales model can be good as long as you are 
not hindered in your work because of it. 
Hate when you have some late night work to be done that can't be completed 
because of some weird restriction dependent in some way on a license.  
RTU licenses are the way from my way of looking at it however, I have a feeling 
that cisco is not equally impressed with RTU licenses. 

//Gustav

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert 
Doering
Sent: den 3 juni 2015 13:55
To: Nick Cutting
Cc: Gert Doering; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ASR920 - ISR4431

Hi,

On Wed, Jun 03, 2015 at 11:41:41AM +, Nick Cutting wrote:
 Yep, I don't mind at all.  :)
 
 Too many times it has been, should've gone cisco in terms of missing 
 features stability etc. 
 
 At least with cisco I know what works and doesn't.

I used to say that, 15 years ago...

Then they decided to split the company into in-fighting BUs...

Nowadays, I know that it works if I've laid my hands on it and it actually 
did (and didn't lose the license to make it work on the next upgrade).

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] Nexus 9300

[Gustav Ulander]

Hello.

We are really happy with them L2 wise. 
Routing features are abit immature we feel. 

//Gustav

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
CiscoNSP List
Sent: den 25 maj 2015 20:05
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Nexus 9300


Hi Everyone,



We have some Cat4500X's that are running low on ports, and need to replace 
them.  They are only doing L2 (Data Centre core switch that TOR's terminate 
back to)



Looked at the Nexus 9300, and on paper, it appears to be ideal - N9K-C9372TX 
48p 1/10G-T and 6p 40G QSFP+  and price seems good also.



Any feedback on these would be greatly appreciated.



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] Fwd: BGP Signalled VPLS on ME3600

[Gustav . Ulander]

Hello.

Do you have a corresponding entry in the mpls forwarding database for the 
next hop address?

Bästa hälsningar / Best regards,

Gustav Uhlander
Communication  Infrastructure Engineer

Steria AB
Kungsbron 13
Box 169
SE-101 23  Stockholm
Sweden

Tel: +46 8 622 42 15
Fax: +46 8 622 42 23
Mobile: +46 70 962 71 03
gustav.ulan...@steria.se 
www.steria.se




From:   Nick Ryce n...@fluency.net.uk
To: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net
Date:   2013-06-06 20:11
Subject:[c-nsp] Fwd: BGP Signalled VPLS on ME3600
Sent by:cisco-nsp cisco-nsp-boun...@puck.nether.net




Hi,

Im having a strange issue with a BGP signalled VPLS on my ME3600.  I'm 
running 15.3.2(s).

The VFI comes up but the virtual circuit stays down with the following 
error:-

SW1.THN-LON#show mpls L2transport vc 501 detail
Local interface: VFI FLVPLS001 vfi up
  Interworking type is Ethernet
  Destination address: 46.226.0.10, VC ID: 501, VC status: down
Last error: MPLS dataplane reported a fault to the nexthop
Output interface: none, imposed label stack {}
Preferred path: not configured
Default path: no route
No adjacency
  Create time: 00:19:42, last status change time: 00:19:42
Last label FSM state change time: 00:19:42
  Signaling protocol: BGP
Status TLV support (local/remote)   : Not Applicable
  LDP route watch   : Not Applicable
  Label/status state machine: activating, LruRruD
  Last local dataplane   status rcvd: DOWN(pw-tx-fault)
  Last BFD dataplane status rcvd: Not Applicable
  Last BFD peer monitor  status rcvd: Not Applicable
  Last local AC  circuit status rcvd: No fault
  Last local AC  circuit status sent: DOWN(pw-rx-fault)
  Last local PW i/f circ status rcvd: No fault
  Last local LDP TLV status sent: Not Applicable
  Last remote LDP TLVstatus rcvd: Not Applicable
  Last remote LDP ADJstatus rcvd: Not Applicable
MPLS VC labels: local 27, remote 16
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
  Control Word: Off
  Dataplane:
SSM segment/switch IDs: 0/10075 (used), PWID: 12
  VC statistics:
transit packet totals: receive 0, send 0
transit byte totals:   receive 0, send 0
transit packet drops:  receive 0, seq error 0, send 0



The next hop is available and routable so not quite sure what the issue 
is.  Any help greatly appreciated.

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] Terminating lots of double-tagged vlans

[Gustav . Ulander]

Yes same here we terminated a couple of hundred doubletagged Vlans in a 
couple of our 3600X with EVCs works like a charm.

Bästa hälsningar / Best regards,

Gustav Uhlander
Communication  Infrastructure Engineer

Steria AB
Kungsbron 13
Box 169
SE-101 23  Stockholm
Sweden

Tel: +46 8 622 42 15
Fax: +46 8 622 42 23
Mobile: +46 70 962 71 03
gustav.ulan...@steria.se 
www.steria.se




From:   Pete Lumbis alum...@gmail.com
To: Simon Lockhart si...@slimey.org
Cc: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net
Date:   2013-05-23 19:48
Subject:Re: [c-nsp] Terminating lots of double-tagged vlans
Sent by:cisco-nsp cisco-nsp-boun...@puck.nether.net



EVCs might do the trick for you. On the 6k/7600 it requires ES/ES+ modules
I believe. ASR1k and me3600/3800 can do it out of the box.

http://www.cisco.com/en/US/docs/ios-xml/ios/cether/configuration/xe-3s/ce-ether-vc-infra-xe.html





On Thu, May 23, 2013 at 9:25 AM, Simon Lockhart si...@slimey.org wrote:

 On Wed Apr 17, 2013 at 12:57:05PM -0700, Bruce Pinsky wrote:
  Simon Lockhart wrote:
   I'm working on a project which uses GPON to connect tens of 
thousands
   of properties in a fibre-to-the-home environment. Each property will
   be handed off to me as a double-tagged vlan, one per property.
   Obviously I don't want to manually create tens of thousands of
   subinterfaces on a router, and I'm sure there's a better way of 
doing
   this.
 
 
 
http://www.cisco.com/en/US/docs/ios/lanswitch/configuration/guide/lsw_ieee_802.1q.html#wp1027258

 

 Well, I started down this route in the lab, and all was looking 
promising
 for
 the first ONT, running IPv4, and terminating onto an ASR1k IPv6 
didn't
 work, and a 2nd ONT wouldn't work.

 Then I found the caveat in the documentation - Only PPPoE is supported 
on
 ambiguous subinterfaces. Standard IP routing is not supported on 
ambiguous
 subinterfaces.

 PPPoE isn't going to work in our environment, as the ONT won't do it, 
and
 we're not mandating the use of a CPE router beyond the ONT (the user 
could
 plug their PC direct into the ONT).

 Is there any other way to make Standard IP routing work on ambiguous
 subinterfaces - i.e. using the encapsulation dot1q 101 second-dot1q 
any
 configuration syntax?

 Thanks in advance,

 Simon
 --
 Simon Lockhart |   * Server Co-location * ADSL * Domain Registration *
Director|  * Domain  Web Hosting * Connectivity * Consultancy *
   Bogons Ltd   | *  http://www.bogons.net/  *  Email: i...@bogons.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/

___
cisco-nsp 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] Ang: ME3600X Output Drops

[Gustav . Ulander]

We have the same problem on our 3600X devices.Look at buggCSCua16046We belive that is the bug that we are encountering. Havent updated software on the device yet though.-cisco-nsp-boun...@puck.nether.net skrev: -Till: cisco-nsp@puck.nether.netFrån: "Ivan" Sänt av: cisco-nsp-boun...@puck.nether.netDatum: 2012-08-21 01:49Ärende: [c-nsp] ME3600X Output DropsHi,I am seeing output drops on a ME3600X interface as shown belowGigabitEthernet0/2 is up, line protocol is up (connected)MTU 9216 bytes, BW 100 Kbit/sec, DLY 10 usec,  reliability 255/255, txload 29/255, rxload 2/255Encapsulation ARPA, loopback not setKeepalive set (10 sec)Full-duplex, 1000Mb/s, media type is RJ45input flow-control is off, output flow-control is unsupportedARP type: ARPA, ARP Timeout 04:00:00Last input 6w1d, output never, output hang neverLast clearing of "show interface" counters 00:12:56Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 231Queueing strategy: fifoOutput queue: 0/40 (size/max)30 second input rate 10299000 bits/sec, 5463 packets/sec30 second output rate 114235000 bits/sec, 12461 packets/sec  3812300 packets input, 705758638 bytes, 0 no buffer  Received 776 broadcasts (776 multicasts)  0 runts, 0 giants, 0 throttles  0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored  0 watchdog, 776 multicast, 0 pause input  0 input packets with dribble condition detected  9103882 packets output, 10291542297 bytes, 0 underruns  0 output errors, 0 collisions, 0 interface resets  0 unknown protocol drops  0 babbles, 0 late collision, 0 deferred  0 lost carrier, 0 no carrier, 0 pause output  0 output buffer failures, 0 output buffers swapped outI have read about similar issues on the list:http://www.gossamer-threads.com/lists/cisco/nsp/157217https://puck.nether.net/pipermail/cisco-nsp/2012-July/085889.html1. I have no QoS policies applied to the physical interface or EVCs. Would increasing the hold queue help? Is there a recommended value - themaximum configurable is 24. What is the impact on the 44MB of packetbuffer.2. If the hold queue isn't an option is configuring QoS required toincrease the queue-limit from the default 100us. Again are there anyrecommended values and what impact is there on the available 44MB ofpacket buffer.3. I have found that when applying policies to the EVCs the "show policymap" output does not have information for the queue-limit as I have seenwhen applying polices to the physical interface. Does this mean that EVCswill still suffer from output drops?ThanksIvan___cisco-nsp mailing list cisco-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsparchive 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] ISP Dual AS

[Gustav . Ulander]

Hello.We also run separate ASN.One for internet and one for VPN purposes.Gustav UhlanderCommunication  Infrastructure Engineer-cisco-nsp-boun...@puck.nether.net skrev: -Till: "'mert ozkul'" thesoulforged...@hotmail.com, cisco-nsp@puck.nether.netFrån: Adam Vitkovsky Sänt av: cisco-nsp-boun...@puck.nether.netDatum: 2012-12-06 15:21Ärende: Re: [c-nsp] ISP Dual ASHi Mert,AFAIK Tier1 ISPs are using backbone designs with several ASNs mainly fortheir routing architecture scalability, as well as stability purposes. They also tend to use separate ASNs for different services they offer (inetvs vpn) for manageability reasonsIn order to cope with network that encompasses thousands of nodes and spansacross the globe they tend to divide it into several ASNs based oncontinents/regions. First advantage is the possibility to deploy separate IGP domains (yes youcould accomplish that with confederations or hierarchical mpls) but I guessthis was voted as simplest option back in the late 90's. Another advantage is that the separate BGP RRs domains can be scaled down to"reasonable" number of VPN prefixes compared with a single ASN design. However the multi-as designs also suffer from several drawbacks, mostlyincreased complexity in service provisioning (inter-as: mpls-te, frr, vpws,vpls, )adam___cisco-nsp mailing list cisco-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsparchive 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] Ang: WLC with DHCP relay not working on in VRF

[Gustav . Ulander]

Hello Nasir.If you look at the DHCPD debug it mentions a different VRF.Dec 6 13:42:16.829 CET:  DHCPD: table id 1 = vrf VRF_GuestIt mentions vrf VRF_Guest as opposed to vrf Guests which would be the expeted one.Do you have a vrf namned VRF_Guest or know where that might come from?Gustav UhlanderCommunication  Infrastructure EngineerSteria ABKungsbron 13Box 169SE-101 23  StockholmSwedenTel: +46 8 622 42 15Fax: +46 8 622 42 23Mobile: +46 70 962 71 03gustav.ulan...@steria.se www.steria.se-cisco-nsp-boun...@puck.nether.net skrev: -Till: cisco-nsp@puck.nether.netFrån: "Nasir Shaikh" Sänt av: cisco-nsp-boun...@puck.nether.netDatum: 2012-12-06 16:48Ärende: [c-nsp] WLC with DHCP relay not working on in VRFHi,I encountered a problem whereby I have a Guest-LAN placed in the VRF and aguest tries to connect via a WLC which is configured as a dhcp-relay. Theguest does not get any IP address assigned by DHCP.Apparently the DHCP server functionality does not work properly in the VRFwhen a DHCP-relay is used, see below debug.First I thought it might be a bug in 12.4(20)T3 on the 2851 and 3845 onwhich I encountered the issue but had the same result on a 3945E running15.1 so it seems on all IOS'sProblem does not occur when using autonomous APs.WITH THE VRF we see the following debug info:Dec 6 13:42:16.829 CET: DHCPD: Sending notification of DISCOVER:Dec 6 13:42:16.829 CET:  DHCPD: htype 1 chaddr f87b.7a04.db2dDec 6 13:42:16.829 CET:  DHCPD: remote id 020ac0a80a02000300c0Dec 6 13:42:16.829 CET:  DHCPD: circuit id Dec 6 13:42:16.829 CET:  DHCPD: table id 1 = vrf VRF_GuestDec 6 13:42:16.829 CET: DHCPD: DHCPDISCOVER received from clientf87b.7a04.db2d through relay 192.168.9.193.Dec 6 13:42:16.829 CET: DHCPD: Seeing if there is an internally specifiedpool class:Dec 6 13:42:16.829 CET:  DHCPD: htype 1 chaddr f87b.7a04.db2dDec 6 13:42:16.829 CET:  DHCPD: remote id 020ac0a80a02000300c0Dec 6 13:42:16.829 CET:  DHCPD: circuit id Dec 6 13:42:16.829 CET:  DHCPD: table id 1 = vrf VRF_GuestDec 6 13:42:16.829 CET: DHCPD: there is no address pool for 192.168.9.193.WITHOUT THE VRF we see the following debug info:Dec 6 14:46:05.413 CET: DHCPD: Sending notification of DISCOVER:Dec 6 14:46:05.417 CET:  DHCPD: htype 1 chaddr f87b.7a04.db2dDec 6 14:46:05.417 CET:  DHCPD: remote id 020ac0a80a02000300c0Dec 6 14:46:05.417 CET:  DHCPD: circuit id Dec 6 14:46:05.417 CET: DHCPD: DHCPDISCOVER received from clientf87b.7a04.db2d through relay 192.168.9.193.Dec 6 14:46:05.417 CET: DHCPD: Seeing if there is an internally specifiedpool class:Dec 6 14:46:05.417 CET:  DHCPD: htype 1 chaddr f87b.7a04.db2dDec 6 14:46:05.417 CET:  DHCPD: remote id 020ac0a80a02000300c0Dec 6 14:46:05.417 CET:  DHCPD: circuit id Dec 6 14:46:05.417 CET: DHCPD: Allocate an address without classinformation (192.168.8.0)Dec 6 14:46:07.417 CET: DHCPD: Adding binding to radix tree (192.168.8.3)Dec 6 14:46:07.417 CET: DHCPD: Adding binding to hash treeDec 6 14:46:07.417 CET: DHCPD: assigned IP address 192.168.8.3 to clientf87b.7a04.db2d.Dec 6 14:46:07.417 CET: DHCPD: Sending DHCPOFFER to client f87b.7a04.db2d(192.168.8.3).Config is straightforward.ip dhcp pool Guestsvrf Guestsimport allnetwork 192.168.8.0 255.255.252.0default-router 192.168.10.1 dns-server 8.8.8.8 8.8.4.4lease 0 4!interface Vlan192description Guest access Internet (ISP Speed = 120M)ip forwarding vrf Guestsip address 192.168.10.2 255.255.252.0ip access-group 192 inAny ideas?RegardsNasir___cisco-nsp mailing list cisco-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsparchive 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] Copper SFP with ME3600X

[Gustav . Ulander]

We have the same issue.Booth on the 3600 and the ASR1001.From what we gather only some Copper SFPs are working.GLC-T is a hit miss type of thing.When using 3rd party SFPs it seems that using ones that dosent support 10/100/1000 but is fixed at 1000 mbit almost always solves the issue. Could it be that the 10/100/1000 portion of the GLC-T isnt supported in SFP+ ports?Gustav UhlanderCommunication  Infrastructure EngineerSteria ABKungsbron 13Box 169SE-101 23  StockholmSwedenTel: +46 8 622 42 15Fax: +46 8 622 42 23Mobile: +46 70 962 71 03gustav.ulan...@steria.se www.steria.se-cisco-nsp-boun...@puck.nether.net skrev: -Till: Tóth András diosbej...@gmail.comFrån: Lobo Sänt av: cisco-nsp-boun...@puck.nether.netDatum: 2012-12-10 21:30Kopia: Cisco-nsp cisco-nsp@puck.nether.netÄrende: Re: [c-nsp] Copper SFP with ME3600XAhhh interesting. So it looks like the GLC-T is actually NOT supported on those two SFP ports according to that matrix.BTW, this switch's client ports are copper 10/100/1000 RJ-45 so no SFP is required on them. Looks like this particular model number only supports the fiber based SFPs.Thanks!JoseOn 12/10/2012 2:55 PM, Tóth András wrote: GLC-T does not seem to be supported in the SFP+ port, only supported  in the client ports. http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6981.pdf If you move the SFP to a client port, does it work? Andras On Mon, Dec 10, 2012 at 8:44 PM, Lobo loboti...@gmail.com  mailto:loboti...@gmail.com wrote:   Normally I would agree with this command but it's not supported.The only "speed" command is nonegotiate and it doesn't make a   difference when plugging the SFP in.   Jose   On 12/10/2012 2:40 PM, Tóth András wrote:   Given that this is a 1G in a 10G port, you might need to add   "speed 1000" to the interface config?   Best regards,   Andras   On Mon, Dec 10, 2012 at 8:12 PM, Lobo loboti...@gmail.com   mailto:loboti...@gmail.com wrote: Hi everyone. Been having a hard time trying to get a copper SFP to work on our ME-3600X-24TS-Ms. According to Cisco documentation, the GLC-T SFP is supposed to be supported on one of the fiber ports. However every Cisco SFP we've tried always spits back an error message: Switch# *Dec 6 19:48:30.448: %PHY-4-SFP_NOT_SUPPORTED: The SFP in Te0/1 is not supported *Dec 6 19:48:30.448: %PM-4-ERR_DISABLE: gbic-invalid error detected on Te0/1, putting Te0/1 in err-disable state Switch# Has anyone had any success with trying to use these on this platform? Fiber based SFPs are fine so long as they're Cisco branded. Are there different versions of GLC-T that we may have the wrong type? Thanks. Jose ___ cisco-nsp mailing list cisco-nsp@puck.nether.net mailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/___cisco-nsp mailing list cisco-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsparchive 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] 2960 - 4948 - no more drops :)

[Gustav . Ulander]

Hello.Same here. Use theese for top of rack and some L2 distribution.Away with packetdrops. :)Gustav-cisco-nsp-boun...@puck.nether.net skrev: -Till: CiscoNSP_list CiscoNSP_list cisconsp_l...@hotmail.comFrån: Dan Letkeman Sänt av: cisco-nsp-boun...@puck.nether.netDatum: 2013-02-17 00:51Kopia: "cisco-nsp@puck.nether.net" cisco-nsp@puck.nether.netÄrende: Re: [c-nsp] 2960 - 4948 - no more drops :)Same here. We went from 3560G's to 4948's and it was night and day. Zerooutput drops now and a noticeable performance improvement, as we were usingthese switches for ISCSI traffic. No qos tuning or disabling helped oursituation on the 3560G's.What type of traffic were you sending through the 2960G?Dan.On Sat, Feb 16, 2013 at 5:15 PM, CiscoNSP_list CiscoNSP_list cisconsp_l...@hotmail.com wrote: Hi Guys, We recently upgraded a 2960G(Only doing L2) that was hitting ~500Mb/sec on one port, and we were seeing 40,000+ output drops (5Min) - Since the swap to the 4948, we see zero output drops. Is the difference in performance purely buffer size? I *think* the 2960 has 1.9Mb (Per ASIC) and the 4948 has 16Mb (total?)? 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.nethttps://puck.nether.net/mailman/listinfo/cisco-nsparchive 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] Choosing Switches to Support VM Clusters

[Gustav . Ulander]

We scrapped a bunch of 3560X after they suffered packetdrops on interfaces.Running 4948-E now and have been happy since. :)Gustav UhlanderCommunication  Infrastructure EngineerSteria ABKungsbron 13Box 169SE-101 23  StockholmSwedenTel: +46 8 622 42 15Fax: +46 8 622 42 23Mobile: +46 70 962 71 03gustav.ulan...@steria.se www.steria.se-cisco-nsp-boun...@puck.nether.net skrev: -Till: cisco-nsp@puck.nether.netFrån: Adam Greene Sänt av: cisco-nsp-boun...@puck.nether.netDatum: 2012-12-13 15:44Ärende: Re: [c-nsp] Choosing Switches to Support VM ClustersWe're about to deploy 3750X ... As per Dell, whose SANs we are deploying, this switch has been tested and is considered up to snuff by them.Real world experience ... none yet.On 12/13/2012 8:15 AM, Gordon Bryan wrote: Hi List, I'm involved in building a small split-site data centre, with the main focus on hosting primary/backup VM Clusters. I have seen and read many a post on this list regarding microbursts and have always tried to err on the side of caution when choosing switches and usually go for models with meaty buffers and was considering for this deployment the 4948E. I was also considering the 3750X but not sure how the buffers stack up against the 4948 as the old 3750 models were poor in this regard. However, I'm looking for any general advice for choosing switches to support a virtualised environment. Are there any particular features I should be looking for or are there any gotchas that I should be aware of? My exposure to VMs is very limited so I'm hoping that the expertise available on this group can guide me Thanks in advance   Gordon ___ cisco-nsp 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.nethttps://puck.nether.net/mailman/listinfo/cisco-nsparchive 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] GRE Throughput

[Gustav . Ulander]

We are pushing the Crypto license limit over a MPLS over GRE over IPSEC tunnel with a 2901.No HSEC license on it though so limit is 85Mbit.Gustav UhlanderCommunication  Infrastructure EngineerSteria ABKungsbron 13Box 169SE-101 23  StockholmSwedenTel: +46 8 622 42 15Fax: +46 8 622 42 23Mobile: +46 70 962 71 03gustav.ulan...@steria.se www.steria.se-cisco-nsp-boun...@puck.nether.net skrev: -Till: Samir Abidali sa...@gorannet.netFrån: Gert Doering <g...@greenie.muc.de>Sänt av: cisco-nsp-boun...@puck.nether.netDatum: 2013-03-18 14:44Kopia: "cisco-nsp@puck.nether.net" cisco-nsp@puck.nether.netÄrende: Re: [c-nsp] GRE ThroughputHi,On Mon, Mar 18, 2013 at 01:21:28PM +0300, Samir Abidali wrote: I wonder if someone can guide me for my search for that is a good Cisco device for GRE tunnel with a throughput of 100 mbps.What *else* is it supposed to do? 1 Gig ports, 10 Gig ports, BGP, ...?100 mbps of GRE should be doable with a 2800/2900 series router, butit very much depends on what else you need...gert-- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/Gert Doering - Munich, Germany   g...@greenie.muc.defax: +49-89-35655025g...@net.informatik.tu-muenchen.de___cisco-nsp mailing list cisco-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsparchive at http://puck.nether.net/pipermail/cisco-nsp/[bilagan "att99999.dat" borttagen av Gustav Ulander/SE/Steria_SC]___
cisco-nsp 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] Ang: Making SUP720 cope better under BGP load

[Gustav . Ulander]

Hello Simon.We are using asr1k for peering purposes and Sup2T in the core. We also have some sup 720 as PE routers.We find that the ASR1001 is alot faster at establishing our BGP sessions than both sup 720 and 2T. I would look into the ASR9001. Seems to be much better box than an ASR 1k box when you spec it to be able to push around 40G. Often turns out cheaper than ASR1k boxes also.Gustav UhlanderCommunication  Infrastructure EngineerSteria ABKungsbron 13Box 169SE-101 23  StockholmSwedenTel: +46 8 622 42 15Fax: +46 8 622 42 23Mobile: +46 70 962 71 03gustav.ulan...@steria.se www.steria.se-cisco-nsp-boun...@puck.nether.net skrev: -Till: cisco-nsp@puck.nether.netFrån: Simon Lockhart Sänt av: cisco-nsp-boun...@puck.nether.netDatum: 2012-12-07 14:29Ärende: [c-nsp] Making SUP720 cope better under BGP loadAll,I'm currently using SUP720-3BXL's in my BGP border devices. Obviously theSUP720 is not a particularly fast CPU, so it is pretty slow at bringing up alot of BGP sessions.On one particular box, I've got 250 BGP neighbours - 1 full table transit, 2IGP to route-reflectors, and the rest are peering sessions at an IXP. Recently,the IXP did maintenance causing the interface to drop, and it bought the box toits knees. The "BGP Router" process takes all the available CPU while it triesto re-establish the BGP sessions. While this is happening, the SUP720 seems togive up processing other stuff in a timely manner - and I see MPLS LDP drop,OSPF neighbours drop, and then BGP sessions drop due to hold timer expires.With all these drops, it causes even more CPU load, and the cycle continues.I've been talking to other SUP720 using ISPs, and it seems that some see thissame effect, and others don't.Currently running 12.2(33)SXJ3Are there any tweaks that I can apply to the IOS config to make the SUP720cope better in this sort of situation? I'd be happy for the BGP sessions totake a lot longer to re-establish, if it didn't kill everything else in theprocess...And, as a follow-on question, given that the SUP720 is so under-powered forBGP, what other options do I have which would cope better? SUP-2T? Or, ifI need to move away from the 6500, what's good for BGP routing with about 20-40G of throughput (i.e. 4-8 * 10GE ports)? How does the ASR9k or ASR1krange fair for BGP performance?Many thanks in advance,Simon___cisco-nsp mailing list cisco-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsparchive 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] Recommended P Nodes

[Gustav . Ulander]

We went with 6500 and sup2t for our P routers.Although today i would probably go for the ASR 9001 for theese things since you often do not require the ammounts of interfaces a 6500 plattform can hold.And you get IOS-XR with the ASR9k which is a plus.Pe is 6500 with sup7203B or me3600x for smaller sites.Works like a charm. Although we have issues with the 3600 and output drops.We will see what we will do about it either upgrade thoose to 6500 or other device.Gustav UhlanderCommunication  Infrastructure Engineer-cisco-nsp-boun...@puck.nether.net skrev: -Till: Gert Doering g...@greenie.muc.deFrån: Gordon Bryan Sänt av: cisco-nsp-boun...@puck.nether.netDatum: 2012-11-29 22:03Kopia: "cisco-nsp@puck.nether.net" cisco-nsp@puck.nether.netÄrende: Re: [c-nsp] Recommended P NodesHi Gert,Thanks for the advice on the flavour of supervisor. That should make the 6500 option fairly cheap.Definitely no full table requirements and all edge-type features will be handled by old failthful 7200VXR for now, hopefully upgrading to ASRs at some point in the future.RegardsGordonFrom: Gert Doering g...@greenie.muc.deTo: Gordon Bryan cisco_resou...@yahoo.co.uk Cc: "cisco-nsp@puck.nether.net" cisco-nsp@puck.nether.net Sent: Thursday, 29 November 2012, 19:47Subject: Re: [c-nsp] Recommended P NodesHi,On Thu, Nov 29, 2012 at 07:27:37PM +, Gordon Bryan wrote: Current thought process is steering me towards hardware-based platforms  such as the 7600/6500 with Sup720-3BXL as they'll be mainly responsible for  labelling/unlabelling/shifting packets and I'm keen on the performance  that these boxes deliver. Plus their scalability to 10Gb and beyond  is another tick in the box. Anyone using these models in the core?6500, definitely :-) - no XL needed if this is a pure P with no full table.Where the 6500 with Sup720 lacks is edge things (IPv6 uRPF, full netflow, IPv6 ACLs) and scalability to "huge" amounts of 10G - but as a P node,you don't need the edge things, and if "some 100 Gbit/s" is good enough foryou, it will do what you want.gert-- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/Gert Doering - Munich, Germany  g...@greenie.muc.defax: +49-89-35655025g...@net.informatik.tu-muenchen.de___cisco-nsp mailing list cisco-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsparchive 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] Confirmation of Gigabit Ethernet autonegotiation behavior

[Gustav . Ulander]

Hummm BT does it here in sweden also.
And yes same complaints here. 

Bästa hälsningar / Best regards,

Gustav Uhlander
Communication  Infrastructure Engineer

Steria AB
Kungsbron 13
Box 169
SE-101 23  Stockholm
Sweden

Tel: +46 8 622 42 15
Fax: +46 8 622 42 23
Mobile: +46 70 962 71 03
gustav.ulan...@steria.se 
www.steria.se




From:   Phil Mayers p.may...@imperial.ac.uk
To: cisco-nsp@puck.nether.net
Date:   2013-01-25 12:25
Subject:Re: [c-nsp] Confirmation of Gigabit Ethernet 
autonegotiation behavior
Sent by:cisco-nsp-boun...@puck.nether.net



On 01/25/2013 10:57 AM, Andriy Bilous wrote:
 I am still wondering - WHY? Our cable guys were always handing over

Yeah, BT do this in the UK. It's inexplicable and frustrating. In *some* 
cases, I've seen them present a circuit with autoneg off, then fail to 
wr mem the config, so when power loss occurs, it comes back up with 
autoneg *on*, and the line goes down. You then enable autoneg, and a few 
hours later their NMS / clueless ops staff disable it... and the line 
goes down!

I don't think it's technical TBH. I suspect it's just telco mindset - 
force all the params to on/fast/full and it's better, right?
___
cisco-nsp 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] IPAM for Service Provider - BRAS GGSN

[Gustav . Ulander]

Hello.
We went with PHPIpam in the end. 
Only other competitor for us was Efficentips system.


Bästa hälsningar / Best regards,

Gustav Uhlander
Communication  Infrastructure Engineer

Steria AB
Kungsbron 13
Box 169
SE-101 23  Stockholm
Sweden

Tel: +46 8 622 42 15
Fax: +46 8 622 42 23
Mobile: +46 70 962 71 03
gustav.ulan...@steria.se 
www.steria.se




From:   cisco-pe cisco.pe.1...@gmail.com
To: cisco-nsp cisco-nsp@puck.nether.net
Date:   2012-11-19 16:43
Subject:[c-nsp] IPAM for Service Provider - BRAS GGSN
Sent by:cisco-nsp-boun...@puck.nether.net



Hi Guys,

Is it possible to use IPAM to manage the local ip pool on BRAS and GGSN?

At this moment for the wireline user (BRAS) we are using PPP and for the
wirelless user  (GGSN) I need to confirm if we are using PPP, DHCP or GTP.

What are the main considerations to use IPAM for Service Provider ?

Any recommendation of IPAM vendors (dual stack) ?

Best Regards

Juan Carlos

Enviado desde mi BlackBerry de Movistar
___
cisco-nsp 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] EoMPLS with WS-X6724 and WS-X6704-10GE

[Gustav . Ulander]

We had issues with cat 6.5k and sup720 that we had to reload the box for 
PWs to come up. 
Not exactly ideal in production enviroments... 


Bästa hälsningar / Best regards,

Gustav Uhlander
Communication  Infrastructure Engineer

Steria AB
Kungsbron 13
Box 169
SE-101 23  Stockholm
Sweden

Tel: +46 8 622 42 15
Fax: +46 8 622 42 23
Mobile: +46 70 962 71 03
gustav.ulan...@steria.se 
www.steria.se




From:   Gert Doering g...@greenie.muc.de
To: zaid zaidoo...@yahoo.com
Cc: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net
Date:   2012-10-31 10:08
Subject:Re: [c-nsp] EoMPLS with WS-X6724 and WS-X6704-10GE
Sent by:cisco-nsp-boun...@puck.nether.net



Hi,

On Tue, Oct 30, 2012 at 11:12:17PM -0700, zaid wrote:
 I can't  deploy EoMpls between two routers7600 (R1 WS-X6724 facing 
core,R2 WS-X6704-10GE facing core) while  between two routers (WS-X6724 
facing core) the PW is up and running , is there any HW restrictions .

No restrictions for plain point-to-point EoMPLS. 

But 7600s are prone to SR* buggage.

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
[attachment attfs5p8.dat deleted by Gustav Ulander/SE/Steria_SC] 
___
cisco-nsp 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] Best Ipam software?

[Gustav . Ulander]

Thanks for some great feedback. 

I looked into the NOC project also but found the instructions rather 
lacking if you dont do russian. 
IPPlan is on our list for further tests then. 
Thanks a bunch.


Bästa hälsningar / Best regards,

Gustav Uhlander
Communication  Infrastructure Engineer

Steria AB
Kungsbron 13
Box 169
SE-101 23  Stockholm
Sweden

Tel: +46 8 622 42 15
Fax: +46 8 622 42 23
Mobile: +46 70 962 71 03
gustav.ulan...@steria.se 
www.steria.se




From:   Christian Meutes christ...@errxtx.net
To: Nick Hilliard n...@foobar.org, cisco-nsp@puck.nether.net, Josh 
Coleman jcole...@centauricom.com
Date:   2012-09-13 09:50
Subject:Re: [c-nsp] Best Ipam software?
Sent by:cisco-nsp-boun...@puck.nether.net



Sup,

On Sep 12, 2012, at 10:18 PM, Nick Hilliard n...@foobar.org wrote:

 I use netdot myself.  It's unashamedly web 1.0.  It won't do overlapping
 subnets and there are some aspects of it which need some work, but I 
find
 it to be very good (I'm the freebsd port maintainer for netdot).  If 
you're
 on linux, best to use one of the VM images to get this installed and
 working.  Alternatively, the freebsd port works well.


Using it under Debian. It's not just IPAM, it's also kind of Asset 
Management,
discovers all kind of information from your devices via snmp like mac  
arp
entries which in turn resolve internally to adjacent devices/interfaces, 
you
can see chains of neighbors, interfaces, routes and all the other h/w 
stuff.

Connected subnets don't need to be added manually as it will fill your
database inside of containers automatically.

Written in mod_perl it's fast and easily adaptable.

I tried also IPplan and some others, most of them are very immature. 

So for me it's 
netdot++
___
cisco-nsp 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] Best Ipam software?

[Gustav . Ulander]

Hello everyone.
I was a little bit curious as to what people are using to handle and 
manage their ip address spaces? 
I’m primarily looking for a system that can handle multiple instances of 
the same subnet existing. 
We are doing Outsourcing so we have a bunch of customers with overlapping 
Ip address spaces. 
Not a problem technically but a lot of the available ipam solutions seems 
to have a problem with this. 
Would be great to hear how other people have solved this problem. 

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