[c-nsp] ASR9K Max neighbors per bridge-domain & globally

[George Giannousopoulos]

Hello all,

I've been trying to find platform limits for the maximum supported number
of neighbors per bridge-domain and globally.

Command "sh l2vpn capability" offers some good data, but not the number of
max neighbors.

I've also found some scattered pages on Cisco but nothing specific for max
neighbors.

Does anyone have any clue?

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

Re: [c-nsp] ASR9k from 6.1.4 to 6.2.3

[George Giannousopoulos]

Hi Adam,

We recently upgraded without any issue.
Not using any exotic features though.. Mostly L2VPN (VPLS & VPWS) services
and MPLS L3VPN in smaller scale.

Beware of some rather minor syntax changes in the BNG config, that can can
ruin your whole day (or night..or both..)
You better try your config in a lab environment before upgrading production
boxes.

--
George

On Mon, May 28, 2018 at 7:49 PM,  wrote:

> Hi folks,
>
> Considering upgrade from ASR9k 6.1.4 to 6.2.3 (32bit)
> I'm especially curious about automation advantages so naturally my
> preference would be for the later code, but wanted to reach out to wider
> audience for a view.
> Anything to be aware of, some bridge SMUs or nasty bugs, please let me
> know.
> 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] PPPoE termination on ASR9K without SE linecards

[George Giannousopoulos]

Hi Brian,

Indeed in order to terminate PPPoE on the LC you need an SE LC.
The question  is what happens when you want to terminate the session on the
RSP. You certainly need the SE RSP but do you still need the SE LC?

Thanks,
George

On Thu, Mar 15, 2018 at 7:58 PM, Brian Turnbow <b.turn...@twt.it> wrote:

> Hi George
>
> I have always been told that TR cards do not support bng that you need for
> pppoe on asr.
> Same for the old trident cards.
> And even  if they did you would be severely limited in qos scaling. (if
> you need really  high qos scaling you should go tomahawk btw)
> There are some cisco live presentations deep diving the architecture and I
> remember some with the "not supported" for  bng as a feature for tr cards.
> Also on the cisco support forums the articles on bng by xander all cite
> the use of SE linecards for LC termination.
>
> You can do it on rsp as the 9001 supports bng just fine.
>
> regards
>
> Brian
>
>
>
>
> > -Original Message-
> > From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> > George Giannousopoulos
> > Sent: giovedě 15 marzo 2018 11:23
> > To: cisco-nsp
> > Subject: [c-nsp] PPPoE termination on ASR9K without SE linecards
> >
> > Hello all,
> >
> > I hope for a positive answer on this.. Has anyone tried to terminate
> PPPoE on
> > ASR9K *without SE LCs*, *but with SE RSPs*?
> >
> > I know I can terminate PPPoE on RSP which will affect system scalability
> in
> > terms of sessions, but is it mandatory to have SE LCs as well? When I
> asked
> > Cisco they suggested a SE LC with SE RSP, but they didn't provide a
> clear
> > answer *why* a SE LC is needed.
> >
> > Has anyone tried that or can confirm it's officially supported and why?
> >
> > Thanks,
> > George
> > ___
> > cisco-nsp 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] PPPoE termination on ASR9K without SE linecards

[George Giannousopoulos]

Hello all,

I hope for a positive answer on this.. Has anyone tried to terminate PPPoE
on ASR9K *without SE LCs*, *but with SE RSPs*?

I know I can terminate PPPoE on RSP which will affect system scalability in
terms of sessions, but is it mandatory to have SE LCs as well? When I asked
Cisco they suggested a SE LC with SE RSP, but they didn't provide a clear
answer *why* a SE LC is needed.

Has anyone tried that or can confirm it's officially supported and why?

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

Re: [c-nsp] ASr-920 CONSOLE USB - USB

[George Giannousopoulos]

Hi,

We also had some issues lately with the ASR900 family..

The ASR920-24SZ was working ok with the included USB cable, both on Windows
and Linux
The ASR903 refused to work with Linux-USB, but was working ok with
Linux-RJ45, Windows-RJ45 and Windows-USB
The ASR920-12SZ refused to work with Linux-USB, but was working ok
Windows-USB

It seems the Windows driver Cisco provides makes some difference..
Did you try to download the latest driver BTW?

--
George

On Mon, Mar 5, 2018 at 7:44 PM, Nick Cutting  wrote:

> I cannot for the life of me get the USB - USB console port to work on the
> 12 port ASR920
> It is running 3.18 - I see this because I can see text at boot time, but
> it will not let me type anything at all.
>
> The lead time at the moment on the EIA/232 converter is 75 days.  This is
> what I used to configure my 4 port 920 and it worked fine.
> I no longer have access to the converter.
>
> Here is the strange thing - The USBA - USBA works on the AS920 with 4
> ports running 3.18.1, but noton the 12 port one?
> I am using the exact same terminal emulation settings on the non-working
> 12 port 920.
>
>
> Ive tried Linux / Windows / macOS and all the stop bits flow control etc.
>
> Anyone got any secret tips for me - or I'll have to get my old converter
> sent out from Chicago.
>
> Thanks!
>
> 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] STM-1 over MPLS using ASR920

[George Giannousopoulos]

Hi,

My understanding is that the OC3 module must be used when you need to
transport channelized STM-1 or when you need to terminate multiple E1
circuits to a single STM-1 interface.
I think TSOP Smart SFP supports only clear channel STM-1.

I'm currently testing both scenarios and I'll be able to provide some
feedback within the next two weeks

--
George

On Wed, Jul 12, 2017 at 10:40 AM, Lukas Tribus  wrote:

> > This it ?
>
> The below. Looking for feedback from the field.
>
>
> TsoP Smart SFP [2]:
> ONS-SC-155-TSOP -> “TSoP Smart SFP” da inserire in uno slot SFP 1GE nel
> ASR920
>
> TsoP in OC3 module [1], [2]:
> Modulo A900-IMA4OS + SFP OC3 ONS-SI-155-I1 -> qua occupiamo lo slot nel
> ASR920
>
> VCoP Smart SFP [3]:
> ONS-SI-OC-VCOP: VCoP Smart SFP 155/622 in SFP o SFP+.
>
> Vedi anche:
> [1] ASR920 High-Port-Density Models Data Sheet
> http://www.cisco.com/c/en/us/products/collateral/routers/
> asr-920-series-aggregation-services-router/datasheet-c78-733397.html
>
> [2] ASR920 TDM Configuration Guide: Transparent SONET or SDH over Packet
> (TSoP) Protocol
> http://www.cisco.com/c/en/us/td/docs/routers/asr920/
> configuration/guide/tdm/tdm-asr920-book/tdm-asr920-book_chapter_0100.html
>
> [3] ASR920 TDM Configuration Guide: Configuring VCoP Smart SFP
> https://www.cisco.com/c/en/us/td/docs/routers/asr920/
> configuration/guide/tdm/tdm-asr920-book/tdm-asr920-book_chapter_0101.html
>
___
cisco-nsp 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] RSP failover vs Chassis failover for switch/router clusters

[George Giannousopoulos]

Hello all,

I'd like to hear the community's opinion and experience when working with
switch or router "clusters". By saying cluster I assume any kind of closely
coupled systems, active/active or active/standby, such as VSS, vPC, mLACP.

Also I assume that the cluster members will be physically close to each
other and all uplink/downlink devices will be dual homed on both cluster
members.

Given the above, I wonder if such systems should be equipped with dual RSPs
or not.

In case of dual RSPs, any RSP failure will trigger the standby RSP and the
device will try to maintain forwarding by transferring the execution of
processes to the previously standby RSP.

In case of single RSP, any RSP failure will trigger the clustering
mechanism and ideally the other member of the cluster should take over.

Would you prefer a chassis or an RSP failover having in mind the highest
possible service availability?

Thanks,
George
___
cisco-nsp 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 ?

[George Giannousopoulos]

Hi,

Concerning IOS-XR on ASR-900 series, during a recent meeting with Cisco we
were told that it's coming with RSP4..
Haven't heard anything for the ASR920 though..

--
George

On Wed, Apr 26, 2017 at 10:17 AM, CiscoNSP List 
wrote:

> Based on software roadmap, its running XE (Everest currently, then
> Polaris/unified stack(16.5.2))...they "appear" to be targeting sonet/sdh
> with it...Its an ASR920/ASR90x, so XE it has to be I guessunless they
> plan to transition it to XRall the other NCS platforms are XR (I
> believe..5xxx/6xxx are)...It would be like having the ASR9001 running XE,
> where all others run XR,just seems wrong lol.
>
>
> Cheers
>
>
> 
> From: Gert Doering 
> Sent: Wednesday, 26 April 2017 5:36 AM
> To: Erik Sundberg
> Cc: Pete Templin; Gert Doering; CiscoNSP List; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] NCS4200 - re-badged ASR920 / ASR900 ?
>
> Hi,
>
> On Tue, Apr 25, 2017 at 06:21:51PM +, Erik Sundberg wrote:
> > 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.
>
> Now the interesting question is, of course, *which* NCS code... as there
> seem to be a number of different "NCS*" families.
>
> An ASR920-style device with IOS XR on it, and actually doing all the
> nice XR things, I'd love to see that.  Even if software upgrades would
> suck.
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>//
> www.muc.de/~gert/
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-
> muenchen.de
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Building E-Trees

[George Giannousopoulos]

Hi,

There is a newer document about split horizon groups, which is more clear.
http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-1/lxvpn/configuration/guide/lesc51x/lesc51p2mps.html#68334

Split horizon groups are actually supported for PWs, provided that you have
a relatively recent IOS-XR version.

--
George

On Tue, Jan 17, 2017 at 10:01 PM, Pshem Kowalczyk  wrote:

> Hi,
>
> I think that might help, but I need to figure out a way for the packets to
> not be flooded to other PWE3. according to the docs:
> http://www.cisco.com/en/US/docs/routers/asr9000/software/
> mpls/configuration/guide/gcasr9kvpls.html#wp1171784
>
> *"Note *Split horizon groups are not supported for access PWs."
>
> I'll try to test that. Alternatively I'll try to see if I can move the
> neighbour statement to a vfi (and build a fake static VPLS).
>
> I actually wonder if there is any difference between having the neighbours
> directly under the bridge domain vs having a VFI under the bridge domain
> and neighbours under the VFI.
>
> kind regards
> Pshem
>
>
> On Tue, 17 Jan 2017 at 23:39  wrote:
>
> > Hi Pshem,
> >
> > > Pshem Kowalczyk
> > > Sent: Monday, January 16, 2017 9:25 PM
> > >
> > > Hi,
> > >
> > > We have a setup that currently uses a local bridge domain on asr9k, one
> > local
> > > physical interface and a number of P2P PWE3 that terminate on PWHE on
> > > other asr9ks. The setup is used for broadband termination. The P2P PWE3
> > go
> > > to BNGs.
> > > The main reason for using a bridge domain with multiple PWE3 so we can
> > > load-balance the subscribers among larger number of BNGs but also to
> > > provide more graceful fail-over to what can be achieved  with a backup
> > > PWE3.
> > >
> > > Currently the bridge domain learns MAC addresses, but as the number of
> > > subscriber grows that's likely to become a limiting factor.  In reality
> > we
> > need
> > > something like an e-tree where the BNGs are the leafs and the physical
> > > interface is the root but with limited MAC address learning. In fact
> what
> > all
> > > we need is one MAC address per BNG plus a 'default route' that points
> to
> > the
> > > physical interface.  Is there a way to define something like that?
> > >
> >
> > Have you considered disabling mac learning on the BD and defining mac
> > addresses of BNGs and GW statically please?
> >
> > RP/0/RP0/CPU0:router(config-l2vpn-bg)# bridge-domain bar
> > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd)# mac
> > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd-mac)# learning disable
> > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd-vfi)# neighbor 10.1.1.2 pw-id
> 1000
> > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd-vfi-pw)# static-mac-address
> 1.1.1
> > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd)# interface GigabitEthernet
> 0/1/0/0
> > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd-ac)# static-mac-address 2.2.2
> >
> > 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] MPLS load-balancing on ME-3800X

[George Giannousopoulos]

Hi James ,

I believe the ASR920 is capable of load balancing on egress port channel.
It depends of course on the hashing algorithm but certainly the actual
payload must "contain" several flows that will be identified and will be
sent to different members.

Is that your case?

--
George

On 15 Dec 2016 21:05, "James Jun"  wrote:

Hi Waris,

One question I have about load-balancing on ASR920.  If the device is
acting as PE for L2VPN, how does one actually achieve load balancing out to
the CE facing LAG interface?

The CE facing configuration is contained in an EFP, and according to IOS XE
documentation, EFPs inside a port-channel are not load balanced within
(i.e. egress traffic only goes out on one member links).

Consider this configuration on a sample PE below.  As you can see, the
attachment of the customer onto L2VPN is on an EFP.  Traffic exiting the
L2VPN/VFI and egressing port-channel20 toward the customer never gets
load-balanced and the entire EFP traffic is mapped to one member link.

James


!
port-channel load-balance-hash-algo src-dst-mixed-ip-port
!
l2 vfi test-vpls
 vpn id 98
 bridge-domain 20
 mtu 1500
 neighbor 10.1.100.34 encapsulation mpls
!
interface Port-channel20
 description LAG to Customer/CE
 service instance 1 ethernet
  description EFP for L2VPN Service
  encapsulation untagged
  l2protocol peer lacp
  bridge-domain 20
  mac security
 !
!
interface GigabitEthernet0/0/0
 description To CE: LAG Member #1 of 2
 channel-group 20 mode active
!
interface GigabitEthernet0/0/1
 description To CE: LAG Member #2 of 2
 channel-group 20 mode active
!
___
cisco-nsp 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] STM-1 over MPLS using ASR920

[George Giannousopoulos]

Hello all,

Has anyone ever tried to transport transparently STM-1 over MPLS using
ASR920?
Can you share your experiences and any issues you have possibly faced?

Consider the following topology

SDH #1 <=> ASR920 #1 <==MPLS==> ASR920 #2 <=> SDH #2

ASR920 supports the A900-IMA4OS which could be one solution.
(
http://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/tdm/atm-xe-3s-asr920-book/configuring_atm.html
)

It also supports the TSoP Smart SFP (
http://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/tdm/tdm-asr920-book/tdm-asr920-book_chapter_0100.html
)

All relative documents I've found aren't clear enough on what is supported
or not, and why I should choose one over the other, but maybe it's just me
not being familiar with TDM..

I had some discussions with our account team at Cisco, but I'd appreciate
some input from the community too.

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

Re: [c-nsp] asr 920 - lower mpls mtu?

[George Giannousopoulos]

Hi

I guess you are configuring using "old style" config.  Try using interface
pseudowire and configure MTU inside it.

--
George
On Jun 18, 2016 19:57, "Mike"  wrote:

>
> With all this talk of asr920, and having a new one in my trembling hands,
> I have been working on learning it and have run into an unanticipated
> problem. Trying to set up an EoMPLS tunnel, the mtu allowed for 'l2 vfi
> somename manual' is a bit short.. only 9180 bytes as opposed to 9216 for
> all the rest of my me3600's for example.
>
> asr920(config-vfi)#mtu ?
>   <1500-9180>  MTU size in bytes
>   
>
>
> I am trying to figure out why this is... am I being silly and this is too
> high and I should select a lower global default like 9100 or ?
>
> Mike-
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] EoMPLS VC on Cisco 7609 is up, but with very small MTU (42 bytes)

[George Giannousopoulos]

Hi,

Have you tried setting the MTU on the SVI to something more than the
default 1500?
Although 42 bytes isn't normal, you should anyway raise the MTU on each SVI
in order to reach 9000.

--
George

On Wed, May 18, 2016 at 5:00 PM, Saku Ytti  wrote:

> Hey Eric,
>
>
> I'd capture the frames and see what is happening.
>
> 42B does not sound like completely arbitrary value. 46B is minimum
> payload of L2, and you're adding one label, 4B to it, ending up with
> exactly 46B of payload, which is minimum possible payload on ethernet.
> Which implies perhaps somewhere MTU is configured below minimum, perhaps 0.
>
> ELAM capture for lookup results at 42B and 43B should be interesting,
> perhaps the lookup results are different (they should not be).
>
> You should check what the platform thinks MTU is, by looking at MLS
> CEF forwarding, sometimes next-hop MTU is incorrectly programmed, not
> same as in CLI. This can usually be fixed by manually changing MTU in
> CLI to something arbitrary and then back to what you actually want,
> which forces reprogramming of the HW adjacency MTU.
>
> The MTU you see in LDP signalling is completely meaningless, it's just
> control-plane signalling, it has nothing to do with forwarding.
>
> You also can't exclude something very odd happening, on ES+ had once
> bug on EoMPLS where it would change DADDR in payload by 1 every 5
> packets on a /24 border.
>
>
> On 18 May 2016 at 16:37, Eric Xu  wrote:
> > I have two directly connected Cisco 7609 routers running MPLS with OSPF
> > being IGP,  and a EoMPLS VC has been created.
> >
> > On router 1:
> >
> > interface Vlan100
> > ip address 192.168.168.2 255.255.255.0
> > xconnect 10.200.0.158 100 encapsulation mpls
> >
> > On router 2:
> >
> > interface Vlan100
> > ip address 192.168.168.3 255.255.255.0
> > xconnect 10.200.0.157 100 encapsulation mpls
> >
> > *VC is up on both routers with MTU 1500:*
> >
> > *router1#sh mpls l2transport vc 100 detail*
> > *Local interface: Vl100 up, line protocol up, Eth VLAN 100 up*
> > *Interworking type is Ethernet*
> > *Destination address: 10.200.0.158, VC ID: 100, VC status: up*
> > *Output interface: Te1/0/0.1864, imposed label stack {16}*
> > *Preferred path: not configured*
> > *Default path: active*
> > *Next hop: 10.200.0.38*
> > *Create time: 00:12:14, last status change time: 00:12:14*
> > *Last label FSM state change time: 00:12:14*
> > *Signaling protocol: LDP, peer 10.200.0.158:0 
> up*
> > *Targeted Hello: 10.200.0.157(LDP Id) -> 10.200.0.158, LDP is UP*
> > *Status TLV support (local/remote) : enabled/supported*
> > *LDP route watch : enabled*
> > *Label/status state machine : established, LruRru*
> > *Last local dataplane status rcvd: No fault*
> > *Last BFD dataplane status rcvd: Not sent*
> > *Last BFD peer monitor status rcvd: No fault*
> > *Last local AC circuit status rcvd: No fault*
> > *Last local AC circuit status sent: No fault*
> > *Last local PW i/f circ status rcvd: No fault*
> > *Last local LDP TLV status sent: No fault*
> > *Last remote LDP TLV status rcvd: No fault*
> > *Last remote LDP ADJ status rcvd: No fault*
> > *MPLS VC labels: local 214, remote 16*
> > *Group ID: local 0, remote 0*
> > *MTU: local 1500, remote 1500*
> > *Remote interface description:*
> > *Sequencing: receive disabled, send disabled*
> > *Control Word: On (configured: autosense)*
> >
> > *router2#sh mpls l2transport vc 100 detail*
> > *Local interface: Vl100 up, line protocol up, Eth VLAN 100 up*
> > *Interworking type is Ethernet*
> > *Destination address: 10.200.0.157, VC ID: 100, VC status: up*
> > *Output interface: Te2/11.1864, imposed label stack {214}*
> > *Preferred path: not configured*
> > *Default path: active*
> > *Next hop: 10.200.0.37*
> > *Create time: 00:13:06, last status change time: 00:12:53*
> > *Last label FSM state change time: 00:12:53*
> > *Signaling protocol: LDP, peer 10.200.0.157:0 
> up*
> > *Targeted Hello: 10.200.0.158(LDP Id) -> 10.200.0.157, LDP is UP*
> > *Status TLV support (local/remote) : enabled/supported*
> > *LDP route watch : enabled*
> > *Label/status state machine : established, LruRru*
> > *Last local dataplane status rcvd: No fault*
> > *Last BFD dataplane status rcvd: Not sent*
> > *Last BFD peer monitor status rcvd: No fault*
> > *Last local AC circuit status rcvd: No fault*
> > *Last local AC circuit status sent: No fault*
> > *Last local PW i/f circ status rcvd: No fault*
> > *Last local LDP TLV status sent: No fault*
> > *Last remote LDP TLV status rcvd: No fault*
> > *Last remote LDP ADJ status rcvd: No fault*
> > *MPLS VC labels: local 16, remote 214*
> > *Group ID: local 0, remote 0*
> > *MTU: local 1500, remote 1500*
> > *Remote interface description:*
> > *Sequencing: receive disabled, send disabled*
> > *Control Word: On (configured: autosense)*
> > *SSO Descriptor: 10.200.0.157/100 , local
> label:
> > 16*
> > *Dataplane:*
> > 

Re: [c-nsp] mpls and etherchannel

[George Giannousopoulos]

Hi,

Assuming that these devices are just P routers in your MPLS network, load
balancing between these two will be based on the bottom label(VC label).

So the only way to see traffic load balancing, is to have several different
EoMPLS pseudowires with different bottom labels.. The fewer you have, the
less the chances to see load balancing across your links.

Alternatively, if your PE routers support FAT pseudowires(eg ASR9K), you
could activate it and then load balancing will take place based on the flow
label. Of course that assumes your traffic is able to be split into
different flows..

Another alternative MPLS TE, where you statically specify which path to use
for each pseudowire. I don't recommend it though.. Not worth the
administrative burden.

If your devices are operating as PE routers, normally you'll be able to
load balance across your links on the egress direction without problems,
since the decision for the egress interface happens before adding the MPLS
labels.

Hope that helps..

--
George

On Wed, Apr 20, 2016 at 11:00 PM, Mike  wrote:

>
>
> On 04/20/2016 11:12 AM, Lukas Tribus wrote:
>
>>
>> Clarify:
>> - what platforms are you using (the LSR's doing ECMP or port-channeling
>>on those 2 wireless bridges)?
>> - what will your traffic look like once on mpls (unlabeled IP, vpnv4 or
>> l2vpn)?
>>
>> The platform would be ASR920 on one side and ME3600 on the other,
> and the bulk of the traffic will be l2vpn running thru it.
>
>
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ISSU on nexus 5k with vPC/lacp

[George Giannousopoulos]

Hi,

Today we upgraded a couple of N7Ks in one of our DCs.

Everytime we ask cisco about ISSU the answer is "it's supported, it works,
but why can't you perform a traditional upgrade?"
Also after some bad experiences with ISSU in the past, we decided to just
reload the boxes.

All servers are dual homed with vPC on both N7Ks, so the overall downtime
was about 10 sec for our services. Not bad..

--
George

On Mon, Mar 28, 2016 at 7:04 PM, Xavier Nicollet 
wrote:

> Our upgrade did not go very well: there was no ISSU, because of the LACP,
> we had some spanning tree issue on one port that made some VM in the blue
> for quite some time.
>
> We also  hit a bug in ntpd that ate the whole disk doing core dumps. Worked
> with TAC support to fix everything.
>
> Hope it might help other people considering upgrading.
>
>
> So in short: upgrade WAS a bit disruptive, but we survived.
>
>
> On Fri, Feb 19, 2016 at 12:15 AM, Xavier Nicollet 
> wrote:
>
> > Hi,
> >
> > we are about to upgrade a couple of nexus 5k switches, with fabric
> > extenders, plain simple ethernet connections and also most servers double
> > attached with a lacp port.
> >
> > I am not sure how lacp will react: we haven't put our servers in "slow
> > mode".
> > According to cisco documentation:
> >   ``Note that a Fast LACP timers (hello=1 sec, dead=3 sec) are not
> > supported with a nondisruptive ISSU.''
> >
> > According to this post:
> > http://www.networking-forum.com/viewtopic.php?f=33=272430 upgrading
> > should be seemless.
> >
> > What will happen during the ISSU upgrade on dual attached servers? (vpc)
> > What will happen on simple ethernet interfaces?
> >
> > Can anyone share about his experience upgrading NX-OS?
> >
> > Many thanks,
> >
> > --
> > Xavier Nicollet
> >
>
>
>
> --
> Xavier Nicollet
> ___
> cisco-nsp 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] traceroute from ASA with source IP from inside interface

[George Giannousopoulos]

Hi,

It's been a while since I tried that, but I think you are not allowed by
default to ping an outside host using an inside interface as the source.

Each interface can successfully ping only on it's egress direction unless
you change the rules.

--
George

On Wed, Mar 16, 2016 at 2:26 PM, "Rolf Hanßen"  wrote:

> Hi Nick,
>
> the outgoing packets are UDP but the packets coming back schould be icmp
> ttl expired, that is why I allowed icmp.
>
> I just tried to allow anything and out without any change, so I guess this
> is not rule-related at all.
>
> Any other ideas?
>
> kind regards
> Rolf
>
> > Traceroutes from ASA / routers use UDP not ICMP
> >
> > You can "inspect ICMP error" as well as allow the ICMP and UDP traceroute
> > versions of the message you need - this is my traceroute config I use on
> > client contexts:
> >
> > Note these firewalls are non-internet facing so security is less
> important
> > to me than troubleshooting.
> >
> > access-list outside_access_in extended permit icmp any any unreachable
> > access-list outside_access_in extended permit icmp any any traceroute
> > access-list outside_access_in extended permit icmp any any time-exceeded
> >
> > policy-map global_policy
> >  class inspection_default
> >   inspect icmp
> >   inspect icmp error
> >
> >
> > -Original Message-
> > From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> > "Rolf Hanßen"
> > Sent: 16 March 2016 10:58
> > To: cisco-nsp@puck.nether.net
> > Subject: [c-nsp] traceroute from ASA with source IP from inside interface
> >
> > Hi,
> >
> > I am new to ASA and wondering about the traceroute (and ping) behaviour.
> > I wanted to trace/ping with the IP address of the internal interface, but
> > anything I try results in stars:
> >
> > ASA# traceroute 8.8.8.8 source inside
> >
> > Type escape sequence to abort.
> > Tracing the route to 8.8.8.8
> >
> >  1   *  *  *
> >  2   *  *  *
> >
> > Tracing without setting a source (or "source outside") works fine.
> > I create a rule for the internal interface towards dst any service ip.
> > There is also a rule on the outside interface to allow icmp.
> > I replace "inside" with the IP.
> > Traceroutes from servers attached to the inside interface work fine.
> >
> > There is no control plane policy set.
> >
> > Is this a bug or some strange "security feature"?
> > Is there another part that maybe filters such traffic?
> > In the management access section I see only https/asdm/ssh/telnet.
> >
> > Maybe somebody can explain.
> >
> > kind regards
> > Rolf
> >
> >
> > ___
> > cisco-nsp 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] VPLS capable devices for two sites interconnect

[George Giannousopoulos]

Hi Adam,

> The mLACP feature is not available on cheap Cisco devices (ASR920)

I've seen a few documentation pages about mLACP on ASR920, like the
following

http://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/lanswitch/lanswitch-ethernet-channel-xe-3s-asr920-book/lsw_mlacp.html#GUID-FBD980FB-D9DF-4075-B1AC-A353DDB0E0C8

Do you have any information or personal experience that it's not working as
described?

Thanks
George

On Sun, Mar 6, 2016 at 11:38 AM, Adam Vitkovsky 
wrote:

> > Robert Hass
> > Sent: Saturday, March 05, 2016 10:00 PM
> >
> > Hi
> > I'm looking for Cisco devices suitable for do interconnect of two sites.
> I also
> > need redundancy at each site - so two clusters of two devices are
> required -
> > mLACP capable for CE side. I cannot use regular L2 PortChannels as we're
> > looking for pure => L3 solution.
> >
> > I know that ASR9001 will do the job. But I'm looking for something
> cheaper.
> > What you can recommend ? I need total 4 x 10GE interfaces and two
> > redundant AC power supplies.
> >
> > Maybe choice of VPLS is bad choice and I should look at VXLAN or OTV ?
> But
> > what benefits will these technologies give me above VPLS ?
> >
> Hi Robert,
>
> If it's pure L3 solution you don't really need VPLS nor mLACP.
> You just need two separate links extended via PWs to other site and L3
> load-sharing.
> So ASR920 will do.
>
> The mLACP feature is not available on cheap Cisco devices (ASR920)
> And Cisco supports only active/passive mLACP last time I looked.
> With load-sharing if one of the links/PWs fails, then only half of the
> traffic will be affected.
>
>
> adam
>
>
>
>
>
>
>
>
>
>
>
>
> Adam Vitkovsky
> IP Engineer
>
> T:  0333 006 5936
> E:  adam.vitkov...@gamma.co.uk
> W:  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
>
> 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.
>
>
> ___
> cisco-nsp 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] Nexus / VPC - Management port "needed" in VPC?

[George Giannousopoulos]

Hi,

I suggest you take a look at
http://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/sw/design/vpc_design/vpc_best_practices_design_guide.pdf
I believe it will answer most (if not all) of your concerns

--
George

On Thu, Nov 19, 2015 at 11:07 PM, CiscoNSP List 
wrote:

> Hi Everyone(Sent this yesterday, but it seems to have not made it to the
> list?),
>
>
> We have a customer that is wanting to do VPC on some N9Ks and also N3Ks -
> I "thought" VPC would be similar to VSS...i.e. dual link between the
> switches...but my (brief) reading up on the setup, I see some setup guides
> where there are dual links(2 x 10Gb, or 2 x 40Gb), plus the use of the
> management port for vPC peer keepalives?
>
>
>
> http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-685753.html
>
> Any info on the "correct"  method to setup VPC on the Nexus would be
> greatly appreciated
>
>
>
> Thanks.
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASR903 Service instance MTU

[George Giannousopoulos]

Hi,

I can't really test it right now, but you should be able to adjust MTU as a
sub-command of xconnect, under the service instance.

--
George

On Sat, Nov 7, 2015 at 12:03 AM, Mohammad Khalil 
wrote:

> Hi all
> I was wondering on ASR903 , can I adjust MTU under the service instance ?
> I can do that under the BDI interface , but that will do it for me ?
>
> BR,
> Mohammad
>
> ___
> cisco-nsp 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 Microbursts

[George Giannousopoulos]

Hi,

Are you sure the drops are due to microbursts?

We have an ongoing issue with drops on ASR920 and TAC informed us that the
same counter is used for the mismatched encapsulation packets too.

That means, no matter how big your buffer is, you may still see some drops
on your interface, depending on your configuration..

--
George


On Tue, Aug 4, 2015 at 5:46 PM, Jordi Magrané Roig jordimagr...@hotmail.com
 wrote:

 Dear Colleagues,



 Recently I have installed one ASR920 and I have configured on 1G interface
 one service instance with an outbound policy-map shaping to 30 Mbps. The
 problem is that I noticed that the ASR920 has the same microburst issue
 than
 the ME3600. I have tried to adjust the queue-limit in order to avoid drops
 but then the latency increments. I have configured:



 policy-map POLICY_CUSTOMER_EGRESS_30Mbps

 class class-default

   shape average 3000



 I have tried also with different classes of service but the issue still
 persist.



 I would like to know the recommendation about the queue-limit size, the
 relation with the values of burst committed and then what should be the
 recommended configuration of shaping, recommendations about fine tunning
 the
 shaping. I have noticed that there Cisco platforms that shape better, for
 example the ASR9001 or 7600 with ES+ shape better than ASR1000 with
 SPA-5X1GE-V2 or ME3600.



 Another problem is that I didn’t find enough information about QoS on
 ASR920
 platform. Somebody knows the default queue size of 1G port? How the packet
 buffer works? Is it like ME3600 (shared queue buffer per ASIC)?



 Thanks!





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

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

Re: [c-nsp] ASR 903 RSP2 Control Plane Traffic QOS

[George Giannousopoulos]

Hi Waris,

Can you please let me know if this doc is specific to the ASR903 or is it
common for the ASR9xx family?

Thanks

On Thu, Jul 30, 2015 at 3:40 AM, Waris Sagheer (waris) wa...@cisco.com
wrote:

 Let me know if the following paper answers your question. If not I’ll ask
 my team to send out an updated document.

 https://drive.google.com/file/d/0B5Q6qCRMe89_YTlxbGNoU3l5REU/view

 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


 http://www.cisco.com/



 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: cisco-nsp-boun...@puck.nether.netmailto:
 cisco-nsp-boun...@puck.nether.net cisco-nsp-boun...@puck.nether.net
 mailto:cisco-nsp-boun...@puck.nether.net on behalf of Caillin Bathern 
 caill...@commtelns.commailto:caill...@commtelns.com
 Date: Thursday, July 23, 2015 at 6:57 PM
 To: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net 
 cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] ASR 903 RSP2 Control Plane Traffic QOS

 Just wondering if anybody has managed to configure traffic
 marking/scheduling for control and management plane traffic on the ASR 903
 RSP2 (or ASR920)?
 Configuring a control plane output service policy fails if you have any
 ACLs in your class maps..

 Out of curisotiy, why are you applying an output policy, the norm is to
 configure an input policy? Are you trying to re-mark control-plane traffic?

 Indeed, I would like to be able to re-mark control plane traffic and also
 define queue parameters.

 Failing an ability to configure this, does anyone know how control plane
 traffic on these devices is actually queued on output? Is it in a dedicated
 queue? CBWFQ or strict? Policed, shaped or unlimited?

 Cheers,
 Caillin
 --
 This transmission or any part of it is intended solely for the named
 addressee.  It is confidential.  The copying or distribution of this
 transmission or any information it contains, by anyone other than the
 addressee, is prohibited. CommTel Network Solutions cannot be held
 accountable for any comments, statements or attachments.

 If you have received this transmission in error, please phone
   +61 3 8340 6100  or by reply e-mail to the sender.  If you are not the
 named addressee, you must destroy the original transmission and its
 contents.

 You may not rely on electronically transmitted material unless
 requested that the transmission is subsequently confirmed by fax or letter.
 Material transmitted to you should also be checked by reference
 to a hard copy of that material printed directly from our word processing
 system.

 Message  protected by MailGuard: e-mail anti-virus, anti-spam and content
 filtering.http://www.mailguard.com.au/mg

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

___
cisco-nsp 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] me3800x IOS

[George Giannousopoulos]

Our experience with 15.3(3)S3 has been very good too.
I can't recall any serious issues since we started using it.

We primarily use OSPF/MPLS with LDP to implement L2VPNs

--
George

On Wed, Jul 29, 2015 at 12:23 AM, James Bensley jwbens...@gmail.com wrote:

 On 27 July 2015 at 17:25, Tim Densmore tdensm...@tarpit.cybermesa.com
 wrote:
  Hi Folks,
 
  I'm looking for recommendations for the best (least buggy) IOS for the
  3800x.  If anyone wants to share their opinion, or well-known gotchas,
 I'd
  appreciate it.  For now, all we really need is basic L2/L3 MPLS, OSPF,
 and
  usual L2 features.  Nothing fancy.
 
  Thanks!
 
  Tim Densmore

 15.3(3)S5 is good and stable on 3800's. It's good and stable on 3600's
 too although today I have opened another TAC case as I think I just
 found a new bug but TAC need to confirm, or if it's by design, which
 will be a shame because this has been a good image so far.

 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] 7600 on 15.3(3)S5

[George Giannousopoulos]

Hi,

The only issue we had when we upgraded to 15.3.(3)S4 was some unsupported
10G transceivers..
Don't forget to check the SFP compatibility matrix before you proceed..

In our case we had a couple of XFP10GLR-192SR-L and XFP10GER-192IR-L on a
76-ES+T-4TG, which aren't supported anymore.

--
George

On Fri, Jul 10, 2015 at 1:08 PM, James Bensley jwbens...@gmail.com wrote:

 Hi All,

 What are you running on your 7600's that are performing typical PE
 services such as MPLS L2  L3 VPNs, transit, peering. I have a couple
 with RSP720-3CXL-10GEs I want to move up to 15.3(3)S5 (don't ask where
 they are coming from!).

 I wznted the commnuity feedback, anyone running this, how is it for
 you? Are you running a 15.4 instead perhaps? I have more live
 experiance with the version I have chosen on other platforms so that
 is my reasoning for not choosing a 15.4 image.

 I've got a TAC case open too but their opinion will likely be biased.

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

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

Re: [c-nsp] Shaping pseudowire on ME3600-ME3600 (L2)

[George Giannousopoulos]

It works but you may need to include a dummy class, besides the
class-default, in your policy map..

--
George

On Wed, Jul 8, 2015 at 5:24 PM, Nick Hilliard n...@foobar.org wrote:

 On 08/07/2015 01:15, CiscoNSP List wrote:
  Question (As I dont have a pair of 3600's handy that I can test on until
  later in the week), but can you shape a L2 x-connect?

 yes, it works as expected.

 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] Shaping pseudowire on ME3600-ME3600 (L2)

[George Giannousopoulos]

Hi,

In some certain cases you are not allowed to apply a policy-map which
includes *only* class-default
To workaround the issue you have to add a dummy class like the following
example

class-map match-any dummy
 match qos-group 99

policy-map 50M-OUTPUT-POLICY
 class dummy
 class class-default
  shape average 5000
  queue-limit 2000 packets

Just make sure you don't match anything useful in the dummy class-map :-)

On Wed, Jul 8, 2015 at 11:54 PM, CiscoNSP List cisconsp_l...@hotmail.com
wrote:



 It works but you may need to include a dummy class, besides the
 class-default, in your policy map..


 Thanks George - Can you please elaborate on the dummy class?  i.e. what
 additional class may I need to add to policy-map (And for what reason?)


 Cheers.


 --
 George

 On Wed, Jul 8, 2015 at 5:24 PM, Nick Hilliard n...@foobar.org wrote:

  On 08/07/2015 01:15, CiscoNSP List wrote:
   Question (As I dont have a pair of 3600's handy that I can test on
 until
   later in the week), but can you shape a L2 x-connect?
 
  yes, it works as expected.
 
  Nick
  ___
  cisco-nsp mailing list  cisco-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/cisco-nsp
  archive at http://puck.nether.net/pipermail/cisco-nsp/
 
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] OSPF per-prefix LFA

[George Giannousopoulos]

Hi Mohammad,

It's not one or the other..
With OSPF tuning you improve convergence for sure and as others said, it's
a good practice to do so.
If you also implement LFA, you have an extra bonus in convergence time.

On Tue, Jun 2, 2015 at 11:36 AM, Mohammad Khalil eng_m...@hotmail.com
wrote:

 Hi all
 Thanks for the replies
 Yes Adam it's supported , am using it on a virtual machine :)
 I guess me using virtualized environment might caused the LFA not to work
 the way it should , but what am confused about now is to use LFA or to just
 manipulate the timers ?

 Thanks again

 BR,
 Mohammad

 From: adam.vitkov...@gamma.co.uk
 To: eng_m...@hotmail.com
 CC: cisco-nsp@puck.nether.net
 Subject: RE: [c-nsp] OSPF per-prefix LFA
 Date: Thu, 28 May 2015 13:43:39 +

 Hi Mohammad,



 I have never had to tune IGP to get sub 50ms LFA failover times.

 The failover times have nothing to do with IGP.

 Actually the switchover itself (from primary to backup path) is done in
 couple of usec (microseconds).

 So what you need to fight against is actually the time it takes the HW to
 realize there's no light on the link.

 As it was suggested already tuning the carrier-delay down to 0 is an
 absolute must.



 Yes tuning:

 timers throttle lsa,

 timers lsa arrival,

 timers pacing flood

 - is vital to propagate the information across the backbone as fast as
 possible so BGP can switch to backup NH ASAP if primary NH is unreachable.

 But that's a different story altogether.



 I think it's really hard to tell what's actually going on in virtual
 environments.

 Looks like in your case LFA is really slow so SFP kicks in sooner than LFA
 that's why tuning SPF got you better results.

 You might want to check how your virtual environment reports link failures
 (at what time intervals).

 Is LFA actually supported on CSR?



 adam



   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/

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

Re: [c-nsp] OSPF per-prefix LFA

[George Giannousopoulos]

Hi,

In a similar case TAC advised that we should also enable OSPF tuning.
Actually OSPF tuning is considered a prerequisite in order to take full
advantage of the LFA feature..

Have you tried that?

--
George

On Thu, May 28, 2015 at 2:53 PM, Nick Hilliard n...@foobar.org wrote:

 This has nothing to do with OSPF virtual links.  I'm talking about the
 virtual ethernet interfaces defined in your virtual lab.

 You can test out whether it's doing what I suggested by changing the
 hellotime value on the relevant interfaces.

 Nick

 On 28/05/2015 12:50, Mohammad Khalil wrote:
  Hi Nick and thanks for the reply
  All my routers are participating in area 0 , no virtual-link in place
  I shutdown the interface connected to R2 (from CSR or R1 side)
 
  BR,
  Mohammad
 
  Date: Thu, 28 May 2015 12:36:50 +0100
  From: n...@foobar.org
  To: eng_m...@hotmail.com; cisco-nsp@puck.nether.net
  Subject: Re: [c-nsp] OSPF per-prefix LFA
 
  On 28/05/2015 12:24, Mohammad Khalil wrote:
   When I shutdown the interface with R2 (as I do not want to turn off
 the
   remote interface on R2 as I cannot turn on BFD on GNS3) and I have
   checked the route to 2.2.2.2 , it took about 5-6 seconds to install
 the
   same route via the backup path (via R3)
 
  did you try this by shutting down both sides of the virtual link at the
  same time? The remote side will not detect carrier loss on a virtual
 link,
  so ospf failover will be detected by according to the ospf deadtime.
 
  If you handle this with bfd, the failover time should be much faster.
 Last
  time I measured this (me3600/100ms bfd), the failover time for l2vpn lsp
  rerouting was reliably less than 400ms. I.e. the failover for regular ip
  service should be a little less.
 
  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] OSPF per-prefix LFA

[George Giannousopoulos]

Actually I was referring to the following timers

timers throttle spf X X X
timers throttle lsa X X X
timers lsa arrival X
timers pacing flood X


On Thu, May 28, 2015 at 3:17 PM, Mohammad Khalil eng_m...@hotmail.com
wrote:

 Hi

 Now , the main link is active again with hello/dead intervals adjsuted

 CSR#sh ip ospf interface gigabitEthernet 1 | inc Dead
   Timer intervals configured, Hello 1, Dead 4, Wait 4, Retransmit 5

 R2#sh ip ospf int f0/0 | inc Dead
   Timer intervals configured, Hello 1, Dead 4, Wait 4, Retransmit 5

 CSR#sh ip route 2.2.2.2
 Routing entry for 2.2.2.2/32
   Known via ospf 1, distance 110, metric 2, type intra area
   Last update from 192.168.12.2 on GigabitEthernet1, 00:01:33 ago
   Routing Descriptor Blocks:
   * 192.168.12.2, from 2.2.2.2, 00:01:33 ago, via GigabitEthernet1
   Route metric is 2, traffic share count is 1
   Repair Path: 192.168.13.3, via GigabitEthernet2

 CSR#sh ip cef 2.2.2.2
 2.2.2.2/32
   nexthop 192.168.12.2 GigabitEthernet1
 repair: attached-nexthop 192.168.13.3 GigabitEthernet2

 CSR#sh ip route repair-paths 2.2.2.2
 Routing entry for 2.2.2.2/32
   Known via ospf 1, distance 110, metric 2, type intra area
   Last update from 192.168.12.2 on GigabitEthernet1, 00:02:08 ago
   Routing Descriptor Blocks:
   * 192.168.12.2, from 2.2.2.2, 00:02:08 ago, via GigabitEthernet1
   Route metric is 2, traffic share count is 1
   Repair Path: 192.168.13.3, via GigabitEthernet2
 [RPR]192.168.13.3, from 2.2.2.2, 00:02:08 ago, via GigabitEthernet2
   Route metric is 3, traffic share count is 1

 The outputs as I understood the feature is fine and backup route is in
 place , but I was asking about the time it should take the backup path to
 be installed in the RIB?

 Thanks again

 BR,
 Mohammad

  Date: Thu, 28 May 2015 13:02:08 +0100
  From: d...@illusionnetworks.com
  To: cisco-nsp@puck.nether.net
  Subject: Re: [c-nsp] OSPF per-prefix LFA
 
  On 28 May 2015 at 12:24, Mohammad Khalil eng_m...@hotmail.com wrote:
 
   Hi all
   I am trying to test the feature
   My topology consists of three routers (one of them is CSR1000v) and the
   other two are 3725 all simulated via GNS3
  
   R1(CSR) is connected to R2 and R3 , there is a direct connection as
 well
   between R2 and R3
   All routers are configured with a loopback interface with the form of
   x.x.x.x/32 where x is the router number
  
   Now , R1 is learning R2 loopback interface normally and logically
 through
   the direct link with R2
  
   When I shutdown the interface with R2 (as I do not want to turn off the
   remote interface on R2 as I cannot turn on BFD on GNS3) and I have
 checked
   the route to 2.2.2.2 , it took about 5-6 seconds to install the same
 route
   via the backup path (via R3)
  
   Now , I have configured the feature on the CSR
   CSR(config)#router ospf 1
   CSR(config-router)#fast-reroute per-prefix enable area 0
 prefix-priority
   high
  
   And I repeat the same test it took about 4 seconds to learn the prefix
 via
   the backup path
  
   Is this the expected behavior or it should be less than that?
  
   Thanks in advance
  
   BR,
   Mohammad
  
  
 
  Hi Mohammed,
 
  What's the output of 'show ip repair-paths' and 'show ip cef 2.2.2.2' on
 R1
  when the link between R1 and R2 is up? You should see an RPR route for R2
  loopback via R3.
 
  If you don't see any RPR route, you may also need to force
 prefix-priority
  of loopbacks to high with something like:
 
  ip prefix-list LOOPBACK-PREFIXES seq 5 permit 2.2.2.2/32
  !
  route-map OSPF-SPF-PRIORITY permit 10
   match ip address prefix-list LOOPBACK-PREFIXES
  !
  router ospf 1
   prefix-priority high route-map OSPF-SPF-PRIORITY
  !
 
  I've had to do this on IOS before - not sure about XE.
 
  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/

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

Re: [c-nsp] OSPF per-prefix LFA

[George Giannousopoulos]

I guess it depends on the values you configure.. But you need to be extra
careful if you are going to apply on a production device..

As you have probably already noticed, after OSPF timers tuning, the
convergence is quite fast even without the LFA.. So why would you bother to
configure LFA in the fiirst place?

My concern though is that according to RFC6571: *Behavior of LFAs is an
automated process that makes fast restoration an intrinsic part of the IGP,
with no additional configuration burden **in the IGP or any other protocol.*


As I see it, the requirement for IGP tuning in order to make LFA work as
expected is somewhat illegal.. If anyone else can explain that, I'd be
glad to hear..

--
George


On Thu, May 28, 2015 at 3:43 PM, Mohammad Khalil eng_m...@hotmail.com
wrote:

 Hi
 Dan , carrier-delay did not do the trick for me
 George , I have configured the below
 router ospf 1
 timers throttle spf 777 888 999

 And , yes it made a difference :)
 Now , the question in my mind is that if I changed these timers to lower
 values than the default , will that affect the performance of the router or
 the SPF calculations negatively ?

 BR,
 Mohammad

 --
 From: ggian...@gmail.com
 Date: Thu, 28 May 2015 15:19:38 +0300
 Subject: Re: [c-nsp] OSPF per-prefix LFA
 To: eng_m...@hotmail.com
 CC: d...@illusionnetworks.com; cisco-nsp@puck.nether.net


 Actually I was referring to the following timers

 timers throttle spf X X X
 timers throttle lsa X X X
 timers lsa arrival X
 timers pacing flood X


 On Thu, May 28, 2015 at 3:17 PM, Mohammad Khalil eng_m...@hotmail.com
 wrote:

 Hi

 Now , the main link is active again with hello/dead intervals adjsuted

 CSR#sh ip ospf interface gigabitEthernet 1 | inc Dead
   Timer intervals configured, Hello 1, Dead 4, Wait 4, Retransmit 5

 R2#sh ip ospf int f0/0 | inc Dead
   Timer intervals configured, Hello 1, Dead 4, Wait 4, Retransmit 5

 CSR#sh ip route 2.2.2.2
 Routing entry for 2.2.2.2/32
   Known via ospf 1, distance 110, metric 2, type intra area
   Last update from 192.168.12.2 on GigabitEthernet1, 00:01:33 ago
   Routing Descriptor Blocks:
   * 192.168.12.2, from 2.2.2.2, 00:01:33 ago, via GigabitEthernet1
   Route metric is 2, traffic share count is 1
   Repair Path: 192.168.13.3, via GigabitEthernet2

 CSR#sh ip cef 2.2.2.2
 2.2.2.2/32
   nexthop 192.168.12.2 GigabitEthernet1
 repair: attached-nexthop 192.168.13.3 GigabitEthernet2

 CSR#sh ip route repair-paths 2.2.2.2
 Routing entry for 2.2.2.2/32
   Known via ospf 1, distance 110, metric 2, type intra area
   Last update from 192.168.12.2 on GigabitEthernet1, 00:02:08 ago
   Routing Descriptor Blocks:
   * 192.168.12.2, from 2.2.2.2, 00:02:08 ago, via GigabitEthernet1
   Route metric is 2, traffic share count is 1
   Repair Path: 192.168.13.3, via GigabitEthernet2
 [RPR]192.168.13.3, from 2.2.2.2, 00:02:08 ago, via GigabitEthernet2
   Route metric is 3, traffic share count is 1

 The outputs as I understood the feature is fine and backup route is in
 place , but I was asking about the time it should take the backup path to
 be installed in the RIB?

 Thanks again

 BR,
 Mohammad

  Date: Thu, 28 May 2015 13:02:08 +0100
  From: d...@illusionnetworks.com
  To: cisco-nsp@puck.nether.net
  Subject: Re: [c-nsp] OSPF per-prefix LFA
 
  On 28 May 2015 at 12:24, Mohammad Khalil eng_m...@hotmail.com wrote:
 
   Hi all
   I am trying to test the feature
   My topology consists of three routers (one of them is CSR1000v) and the
   other two are 3725 all simulated via GNS3
  
   R1(CSR) is connected to R2 and R3 , there is a direct connection as
 well
   between R2 and R3
   All routers are configured with a loopback interface with the form of
   x.x.x.x/32 where x is the router number
  
   Now , R1 is learning R2 loopback interface normally and logically
 through
   the direct link with R2
  
   When I shutdown the interface with R2 (as I do not want to turn off the
   remote interface on R2 as I cannot turn on BFD on GNS3) and I have
 checked
   the route to 2.2.2.2 , it took about 5-6 seconds to install the same
 route
   via the backup path (via R3)
  
   Now , I have configured the feature on the CSR
   CSR(config)#router ospf 1
   CSR(config-router)#fast-reroute per-prefix enable area 0
 prefix-priority
   high
  
   And I repeat the same test it took about 4 seconds to learn the prefix
 via
   the backup path
  
   Is this the expected behavior or it should be less than that?
  
   Thanks in advance
  
   BR,
   Mohammad
  
  
 
  Hi Mohammed,
 
  What's the output of 'show ip repair-paths' and 'show ip cef 2.2.2.2' on
 R1
  when the link between R1 and R2 is up? You should see an RPR route for R2
  loopback via R3.
 
  If you don't see any RPR route, you may also need to force
 prefix-priority
  of loopbacks to high with something like:
 
  ip prefix-list LOOPBACK-PREFIXES seq 5 permit 2.2.2.2/32
  !
  route-map OSPF-SPF-PRIORITY permit 10
   match ip 

[c-nsp] ASR920 mLACP experience

[George Giannousopoulos]

Hello all,

ASR920 seems to support mLACP with the Advanced Metro IP License.
Has anyone experienced issues while using it in production network?

I'm specifically interested in VPWS, where two Active/Active or
Active/Standby pseudowires from a UNI are terminating on a couple of ASR920
implementing mLACP.

Regards,
George
___
cisco-nsp 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] ASR903 AToM

[George Giannousopoulos]

oops.. my mistake..

You need to configure *l2vpn vfi* instead of *l2vpn xconnect*
Take a look at
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l2_vpns/configuration/xe-3s/asr903/mp-l2-vpns-xe-3s-asr903-book/mp-vpls.html

On Sun, Apr 19, 2015 at 6:41 PM, Mohammad Khalil eng_m...@hotmail.com
wrote:

 Hi when i configure the l2vpn xconnect context i cannot bind the service
 instance 1

 --
 From: ggian...@gmail.com
 Date: Sun, 19 Apr 2015 18:04:09 +0300
 Subject: Re: [c-nsp] ASR903 AToM
 To: eng_m...@hotmail.com
 CC: adam.vitkov...@gamma.co.uk; cisco-nsp@puck.nether.net


 Hi,

 I'd use the following config for the service instances and the L2VPN
 I guess you can't use the service instance in the L2VPN, because of the
 bridge-domain command inside the service instance.

 service instance 1 ethernet
   encapsulation dot1q 100,200,300
   rewrite ingress tag pop 1 symmetric

 l2vpn xconnect context L2VPN
 member GigabitEthernet0/0/0 service instance 1
 member GigabitEthernet0/1/0 service instance 1
 member pseudowire 20

 Maybe the trunk keyword in the service instance plays some role..

 --
 George


 On Sun, Apr 19, 2015 at 3:34 PM, Mohammad Khalil eng_m...@hotmail.com
 wrote:

 I have applied the configuration and The same
 The circuit is up but no ping between the CEs
 I issued the command show monitor event-trace atom and mismatched c-bit
 message appeared

 From: adam.vitkov...@gamma.co.uk
 To: eng_m...@hotmail.com; cisco-nsp@puck.nether.net
 Subject: RE: [c-nsp] ASR903 AToM
 Date: Sun, 19 Apr 2015 09:10:40 +

 Hi Mohamad,



 I'm not sure if this new-style config works yet.



 This is how it would look like using the old-style



 ASR903

 interface GigabitEthernet0/0/0

   service instance trunk 1 ethernet

 encapsulation dot1q 100,200,300

 rewrite ingress tag pop 1 symmetric

 xconnect 2.2.2.2 20 encapsulation mpls



 ! interface GigabitEthernet0/1/0

 !  service instance trunk 1 ethernet

 !encapsulation dot1q 100,200,300

 !rewrite ingress tag pop 1 symmetric

 !xconnect 2.2.2.2 40 encapsulation mpls

 ! -- config related to backup PW--



 Also on ME I'd recommend using xconnect under the service instance rather
 than attaching the service instance to a BD and configuring xconnect under
 the VLAN interface. Because if you attach a service instance to a BD by
 default MAC learning is in place and you don't want that for a simple p2p
 PW (MAC learning can be disabled using cmd:  no mac learning under the BD
 config).



 ME3600

 interface GigabitEthernet0/x

   service instance trunk 1 ethernet

 encapsulation dot1q 100,200,300

 rewrite ingress tag pop 1 symmetric

 xconnect 1.1.1.1 20 encapsulation mpls

 ! backup peer 1.1.1.1 40 encapsulation mpls

 ! -- config related to backup PW--



 adam

  -Original Message-

  From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of

  Mohammad Khalil

  Sent: 18 April 2015 01:08

  To: cisco-nsp@puck.nether.net

  Subject: [c-nsp] ASR903 AToM

 

  Hi all

  I have the below setup

  I have ASR903 connected to ME3600 (both are acting as PEs)

  The ASR903 is part of REP ring consisting of other 3400 switches with
 ASR903

  being the primary

  I have two CEs , one is directly connected to the ME3600 box , and the
 other

  CE is connected to one of the 3400 switches which are part of the REP
 ring

  What am trying to do is to establish AToM (Xconnect) between the two CEs

  The Vlan used for testing is 100 (there are other Vlans passing through
 the

  trunks that are not for MPLS service)

 

  ASR903

  interface GigabitEthernet0/0/0

   description Connected-To-AS1-G0/2

   no ip address

   negotiation auto

   rep segment 20 edge primary

   rep preempt delay 30

   rep block port 3 vlan 1-4094

   service instance trunk 1 ethernet

encapsulation dot1q 100,200,300

rewrite ingress tag pop 1 symmetric

bridge-domain from-encapsulation

 

 

  interface GigabitEthernet0/1/0

   description Connected-To-AS2-G0/2

   no ip address

   negotiation auto

   rep segment 20 edge preferred

   rep preempt delay 30

   service instance trunk 1 ethernet

encapsulation dot1q 100,200,300

rewrite ingress tag pop 1 symmetric

bridge-domain from-encapsulation

 

  interface pseudowire 20

  encapsulation mpls

  neighbor 2.2.2.2 20

 

  l2vpn xconnect context L2VPN

  member GigabitEthernet0/0/0 -- When I tried to put service-instance ,
 it did

  not accept the command

  member pseudowire 20

 

  ME3600

  interface vlan 100

  no ip address

  xconnect 1.1.1.1 20 encapsulation mpls

 

  Now , the xconnect came up as shown in the output below

 

  ME3600X#show mpls l2transport vc 20

 

  Local intf Local circuit  Dest addressVC ID
 Status

  -  -- --- --
 --

  Vl100  Eth VLAN 100   1.1.1.1 20 UP

 

  

Re: [c-nsp] ASR903 AToM

[George Giannousopoulos]

Hi,

I'd use the following config for the service instances and the L2VPN
I guess you can't use the service instance in the L2VPN, because of the
bridge-domain command inside the service instance.

service instance 1 ethernet
  encapsulation dot1q 100,200,300
  rewrite ingress tag pop 1 symmetric

l2vpn xconnect context L2VPN
member GigabitEthernet0/0/0 service instance 1
member GigabitEthernet0/1/0 service instance 1
member pseudowire 20

Maybe the trunk keyword in the service instance plays some role..

--
George


On Sun, Apr 19, 2015 at 3:34 PM, Mohammad Khalil eng_m...@hotmail.com
wrote:

 I have applied the configuration and The same
 The circuit is up but no ping between the CEs
 I issued the command show monitor event-trace atom and mismatched c-bit
 message appeared

 From: adam.vitkov...@gamma.co.uk
 To: eng_m...@hotmail.com; cisco-nsp@puck.nether.net
 Subject: RE: [c-nsp] ASR903 AToM
 Date: Sun, 19 Apr 2015 09:10:40 +

 Hi Mohamad,



 I'm not sure if this new-style config works yet.



 This is how it would look like using the old-style



 ASR903

 interface GigabitEthernet0/0/0

   service instance trunk 1 ethernet

 encapsulation dot1q 100,200,300

 rewrite ingress tag pop 1 symmetric

 xconnect 2.2.2.2 20 encapsulation mpls



 ! interface GigabitEthernet0/1/0

 !  service instance trunk 1 ethernet

 !encapsulation dot1q 100,200,300

 !rewrite ingress tag pop 1 symmetric

 !xconnect 2.2.2.2 40 encapsulation mpls

 ! -- config related to backup PW--



 Also on ME I'd recommend using xconnect under the service instance rather
 than attaching the service instance to a BD and configuring xconnect under
 the VLAN interface. Because if you attach a service instance to a BD by
 default MAC learning is in place and you don't want that for a simple p2p
 PW (MAC learning can be disabled using cmd:  no mac learning under the BD
 config).



 ME3600

 interface GigabitEthernet0/x

   service instance trunk 1 ethernet

 encapsulation dot1q 100,200,300

 rewrite ingress tag pop 1 symmetric

 xconnect 1.1.1.1 20 encapsulation mpls

 ! backup peer 1.1.1.1 40 encapsulation mpls

 ! -- config related to backup PW--



 adam

  -Original Message-

  From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of

  Mohammad Khalil

  Sent: 18 April 2015 01:08

  To: cisco-nsp@puck.nether.net

  Subject: [c-nsp] ASR903 AToM

 

  Hi all

  I have the below setup

  I have ASR903 connected to ME3600 (both are acting as PEs)

  The ASR903 is part of REP ring consisting of other 3400 switches with
 ASR903

  being the primary

  I have two CEs , one is directly connected to the ME3600 box , and the
 other

  CE is connected to one of the 3400 switches which are part of the REP
 ring

  What am trying to do is to establish AToM (Xconnect) between the two CEs

  The Vlan used for testing is 100 (there are other Vlans passing through
 the

  trunks that are not for MPLS service)

 

  ASR903

  interface GigabitEthernet0/0/0

   description Connected-To-AS1-G0/2

   no ip address

   negotiation auto

   rep segment 20 edge primary

   rep preempt delay 30

   rep block port 3 vlan 1-4094

   service instance trunk 1 ethernet

encapsulation dot1q 100,200,300

rewrite ingress tag pop 1 symmetric

bridge-domain from-encapsulation

 

 

  interface GigabitEthernet0/1/0

   description Connected-To-AS2-G0/2

   no ip address

   negotiation auto

   rep segment 20 edge preferred

   rep preempt delay 30

   service instance trunk 1 ethernet

encapsulation dot1q 100,200,300

rewrite ingress tag pop 1 symmetric

bridge-domain from-encapsulation

 

  interface pseudowire 20

  encapsulation mpls

  neighbor 2.2.2.2 20

 

  l2vpn xconnect context L2VPN

  member GigabitEthernet0/0/0 -- When I tried to put service-instance ,
 it did

  not accept the command

  member pseudowire 20

 

  ME3600

  interface vlan 100

  no ip address

  xconnect 1.1.1.1 20 encapsulation mpls

 

  Now , the xconnect came up as shown in the output below

 

  ME3600X#show mpls l2transport vc 20

 

  Local intf Local circuit  Dest addressVC ID
 Status

  -  -- --- --
 --

  Vl100  Eth VLAN 100   1.1.1.1 20 UP

 

  ASR903#sh xconnect all

  Legend:XC ST=Xconnect State  S1=Segment1 State  S2=Segment2 State

UP=Up   DN=DownAD=Admin Down  IA=Inactive

SB=Standby  HS=Hot Standby RV=Recovering  NH=No Hardware

 

  XC ST  Segment 1 S1 Segment 2
  S2

 
 --+-+--+-+--

  UP pri mpls 2.2.2.2:20   UP   ac Gi0/0/0:6(Ethernet)
   UP

 

  No ping between the two sites , I tried to modify the MTU vlaue on the

  interfaces going to the CE side , and the xconnect is down directly

  I have tested 

Re: [c-nsp] power requirement for WS-X614E-GE-45AT in reverse POE mode

[George Giannousopoulos]

Hi Gert,

I have to admit your workaround came as a shock to me :)
I can't help you on that, but I really wonder..

Even if it eventually works, will you trust it on your production network?
Maybe it's ok for 1-2 days, but can you rely on that?
What if a POE+ injector fails?

Personally, in such an urgent, I'd try to get a redundant power supply from
another similar chassis..

--
George



On Wed, Apr 1, 2015 at 10:38 AM, Gert Doering g...@greenie.muc.de wrote:

 Hi,

 quick question, because I cannot find the answer on cisco.com.

 If I run a WS-X6148E-GE-45AT in reverse POE mode (feeding power into
 the 6500), but do not use the ports for actual switching, will the line
 card still require power?

 Background: I urgently need a few 10GE ports in a location, and have a
 spare 6504 chassis, Sup720 and 6704-10GE lying around, but no power
 supplies,
 so we decided to power the chassis by using 20 POE+ injectors, feeding
 30W each (= 600W in total) into a WS-X6148E-GE-45AT POE+ capable line card.

 This is just enough to power Sup720-3B (280W) and 6704-10GE (295W), but
 not enough if the 6148E also needs power for itself in that configuration.

 Adding more POE+ injectors could be done, but would be somewhat of a hassle
 as we only have 20 on-site, and the cabling gets even harder to manage if
 we need to add more POE+ injectors...

 thanks for your advice,

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

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

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

[George Giannousopoulos]

Hi,

I had the same issue while evaluating the box..

Unfortunately the documentation includes many features not currently
supported by the platform.
Personally I didn't find a better doc.

To tell you the truth, I don't expect the documentation to be fixed, unless
a customer complains.
They'll probably include the missing features in an upcoming
release(hopefully soon).

So, actually, it depends on the aspect from which you are looking.
They are not copying documentation from other platforms, they are just
being way ahead writing the documentation for the ASR920 :-)

George

On Sat, Nov 22, 2014 at 1:56 PM, Eric Van Tol e...@atlantech.net wrote:

 Hi all,
 We've finally taken delivery of our first ASR920 after ordering it more
 than two months ago (yay!) and I'm trying to configure it using some of the
 documentation at:


 http://www.cisco.com/c/en/us/support/routers/asr-920-series-aggregation-services-router/products-installation-and-configuration-guides-list.html

 What I'm finding is that it is very much like the existing ME3600/3800,
 which is great for ease and consistency.  However, there are some minor
 differences and the documentation, in some areas, is just plain wrong.
 Even though the link above shows Cisco ASR 920 Series next to all the
 links, the docs appear to be general IOS-XE documentation, which shows a
 lot of configuration and commands that the ASR920 doesn't support.

 Questions - Is anyone else using/evaluating the ASR920?  If so, do you
 have a link or source for better ASR920-specific docs?

 Thanks,
 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] ME3600X - Hairpinning/Local Connect

[George Giannousopoulos]

Hi,

This feature is supported in 15.3(2)S and newer images.
Check
http://www.cisco.com/c/en/us/td/docs/ios/15_3s/release/notes/15_3s_rel_notes/15_3s_feats_important_notes_15_3_2s.html

I've tested it successfully in 15.3(3)S1a

Best regards
George


On Thu, Feb 20, 2014 at 4:45 AM, Ivan cisco-...@itpro.co.nz wrote:

 Hi,

 I have seen in the config guides at way of send traffic in and out the
 same port or even different ports


 http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-3_1_S/configuration/guide/3800x3600xscg/swevc.html#wp1051612

 I was looking to use the connect statement which seems to be there but
 maybe not supported??  Here is what I was trying

 interface GigabitEthernet0/5
 description Local Connect Test
 switchport trunk allowed vlan none
 switchport mode trunk
 mtu 9216
 load-interval 30
 no cdp enable
 spanning-tree portfast
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable
 service instance 123 ethernet
  encapsulation dot1q 123
  no rewrite ingress tag pop 1 symmetric
  no shut

 interface GigabitEthernet0/6
 description Local Connect Test
 switchport trunk allowed vlan none
 switchport mode trunk
 mtu 9216
 load-interval 30
 no cdp enable
 spanning-tree portfast
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable
 service instance 123 ethernet
  encapsulation dot1q 123
  no rewrite ingress tag pop 1 symmetric
  no shut

 ME1(config)#connect test gigabitEthernet 0/5 123 gigabitEthernet 0/6  123
 %CONN: invalid segment 1
 %CONN: Invalid Command
 ME1(config)#

 IOS is me360x-universalk9-mz.153-1.S1.bin.  Have I done something wrong or
 is this not supported?

 Thanks

 Ivan

 ___
 cisco-nsp 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] ME3600X 24CX experience feedback

[George Giannousopoulos]

Hello all,

We've been using the ME3600x for quite a long time without major issues.
We are now considering using the ME3600X 24CX in cases we need higher 10G
port density.

Can anyone provide feedback about it?
There is a different image for the 24CX model. Have you seen anything
operating differently than the normal ME3600x?
Are you aware of any peculiarities specific to this model?

Thanks in advance
George
___
cisco-nsp 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] Port-based EoMPLS treatment of l2protocol packets

[George Giannousopoulos]

Hi,

That's correct..
forwarded l2protocols are incompatible with tunneled l2protocols

Actually there are differences among Cisco platforms in respect to their
ability to handle PDUs, which makes interoperability quite difficult some
times.

The ME3400 can only tunnel
The ME3800x can tunnel and forward
The 7600 until recently could only forward. After the 15.3.1S version it
can also tunnel..

George

On Wed, Feb 5, 2014 at 11:09 PM, Jason Lixfeld ja...@lixfeld.ca wrote:

 Hi,

 Sanity check -

 Would it be fair to say that the way a port-based EoMPLS port treats
 l2protocol packets is essentially the same as if someone were to configure
 l2protocol forward?  That is, the packets are just forwarded along the PW
 unprocessed.  Whereas l2protocol tunnel (like on an ME3400) will rewrite
 the destination MAC making it incompatible with a 'forward'ed l2protocol
 packet?

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

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

Re: [c-nsp] Outdoor-hardened metro service platform?

[George Giannousopoulos]

You could check the ASR901
It is hardened and it supports an extended temperature range

Currently it only supports MPLS/EoMPLS, but VPLS is coming this summer

George



On Tue, Feb 4, 2014 at 12:28 PM, Richard Hartmann 
richih.mailingl...@gmail.com wrote:

 Dear all,

 weirdly, the archives don't seem to handle this use case, thus I am
 starting a new thread.

 We are using a mix of C6500 and ME3600 to collect Metro services
 (plain Internet upstream, BGP, OSPF, M/VPLS P and PE, QinQ, ideally
 service instances).

 As our network grows, we are increasingly faced with outdoor POPs
 being the only viable choice.

 That means
 * condensing humidity
 * wide temperature ranges
 * short unit depths


 Given the requirements above, what would be a decent hardware platform
 for us? Both new and near-EoL equipment would be fine.



 Thanks,
 Richard
 ___
 cisco-nsp 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] OSPF cost calculation on ASR9K

[George Giannousopoulos]

Hi,

I've noticed that the ASR9K ignores the bandwidth command when it
calculates the OSPF cost for an interface.
No matter what the configured bandwidth is, the device calculates the cost
according to the physical interface bandwidth.

Is that normal or am I missing something?

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

Re: [c-nsp] OSPF cost calculation on ASR9K

[George Giannousopoulos]

Hi,

The auto-cost reference bandwidth is enabled and set at 100G

I've verified it on both CRS  ASR9K 4.2.3

George

On Wed, Jan 8, 2014 at 1:38 PM, Xuhu jstuxuhu0...@gmail.com wrote:

 Cannot be, I remember we got few configs changed interface cost.
 Which version u r running.

 Br,

 On 8 Jan, 2014, at 3:33 pm, George Giannousopoulos ggian...@gmail.com
 wrote:

 Hi,

 I've noticed that the ASR9K ignores the bandwidth command when it
 calculates the OSPF cost for an interface.
 No matter what the configured bandwidth is, the device calculates the cost
 according to the physical interface bandwidth.

 Is that normal or am I missing something?

 Thanks
 George
 ___
 cisco-nsp 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] EVC Question/Clarification

[George Giannousopoulos]

Hi,

EVCs are used with CFM.
In order to enable transparent flow of CFM packets through a service
instance, you must associate the service instance with the evc.
This is used only when the ME3600x/ME3800x itself, has globally enabled the
CFM functionality.
If CFM is not enabled on the device, then CFM frames are forwarded
transparently without the specific evc config.

It's been a while since I used it, so some of the above may be outdated..

George


On Sat, Dec 14, 2013 at 4:30 AM, Eric Van Tol e...@atlantech.net wrote:

 Hi all,
 Can I get some clarification on exactly what the usage is of the global
 'ethernet evc name' configuration is on the ME3600?  What is the effect
 or significance of this configuration, especially when it is called from an
 EFP (service instance 100 ethernet name)?  There really doesn't seem to
 be much you can configure under this global command besides OAM and UNI
 stuff.  Is it just used as a template to define these parameters, much like
 the 'pw-class' configuration for pseudowires?

 Thanks,
 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] MPLS QOS on ME3600 not working???

[George Giannousopoulos]

This could be a counter issue..
If the traffic is transit you can try to match it at the egress interface,
without any policy at the ingress.
You could also match it at the ingress of the next device to verify that.




On Tue, Nov 12, 2013 at 4:16 PM, Adam Vitkovsky adam.vitkov...@swan.skwrote:

 15.3(3)S, 15.3(3)S1, 15.3(2)S3



 adam



 From: Pete Lumbis [mailto:alum...@gmail.com]
 Sent: Tuesday, November 12, 2013 3:01 PM
 To: Adam Vitkovsky
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] MPLS QOS on ME3600 not working???



 What version of code?



 On Tue, Nov 12, 2013 at 8:39 AM, Adam Vitkovsky adam.vitkov...@swan.sk
 wrote:

 Hi Folks,

 Is anyone using MPLS QOS on ME3600 platform please or I am the only one
 hitting the issue?
 As seen below all traffic is matched into the first class defined in the
 policy-map no matter how the packets are marked.
 If I would remove the class core_class7 from the policy-map (and might have
 then add it back so that it would appears at the bottom) all the traffic is
 going to be matched by the next class that happens to be at the top of the
 policy-map which would be core_class6 and so on and so on.
 This is seen on all boxes and across couple of different IOS versions.

 Somehow I fail to convince Cisco that my MPLS traffic patterns are not
 changing from EXP7/Prec7 to EXP6/Prec6 to ... miraculously as I'm changing
 the inbound policy-map on some random PE even though I showed them that the
 neighboring P-core sees a variety of EXP5 to EXP1 marked packets in output
 policy-maps in direction towards the ME3600.

 sh policy-map int te0/1 in
  TenGigabitEthernet0/1

   Service-policy input: core_policy_ver5.0_input

 Class-map: core_class7 (match-any)
   74193994 packets, 7015406412 bytes
   30 second offered rate 33000 bps, drop rate  bps
   Match: mpls experimental topmost 7
   Match:  precedence 7
 set qos-group 7
 set discard-class 7

 Class-map: core_class6 (match-any)
   0 packets, 0 bytes
   30 second offered rate  bps, drop rate  bps
   Match: mpls experimental topmost 6
   Match:  precedence 6
   Match: access-group name AL_BFD
 set qos-group 6
 set discard-class 6

 Class-map: core_class5 (match-any)
   0 packets, 0 bytes
   30 second offered rate  bps, drop rate  bps
   Match: mpls experimental topmost 5
   Match:  precedence 5
 set qos-group 5
 set discard-class 5

 Class-map: core_class4 (match-any)
   0 packets, 0 bytes
   30 second offered rate  bps, drop rate  bps
   Match: mpls experimental topmost 4
   Match:  precedence 4
 set qos-group 4
 set discard-class 4

 Class-map: core_class3 (match-any)
   0 packets, 0 bytes
   30 second offered rate  bps, drop rate  bps
   Match: mpls experimental topmost 3
   Match:  precedence 3
 set qos-group 3
 set discard-class 3

 Class-map: core_class2 (match-any)
   0 packets, 0 bytes
   30 second offered rate  bps, drop rate  bps
   Match: mpls experimental topmost 2
   Match:  precedence 2
 set qos-group 2
 set discard-class 2

 Class-map: core_class1 (match-any)
   0 packets, 0 bytes
   30 second offered rate  bps, drop rate  bps
   Match: mpls experimental topmost 1
   Match:  precedence 1
 set qos-group 1
 set discard-class 1

 Class-map: class-default (match-any)
   0 packets, 0 bytes
   30 second offered rate  bps, drop rate  bps
   Match: any
 set qos-group 0
 set discard-class 0



 adam

 ___
 cisco-nsp 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] FAT PW between 7600 - ASR9K

[George Giannousopoulos]

Thanks for your feedback

Oliver, since the documentation is very very limited, I'd appreciate if you
could provide some info on how each PE will identify the flow labels.
Is there a predefined range that is used only for the flow labels as Phil
previously mentioned?

George



On Fri, Nov 1, 2013 at 8:42 AM, Oliver Boehmer (oboehmer) 
oboeh...@cisco.com wrote:

 
 
 Does anyone have experience with FAT PW between 7600 and ASR9K?
 
 The ASR9K supports it for sure and it has been verified.
 The 7600, according to the doc, supports it only for VPLS with the
 addition
 of a global command platform vfi load-balance-label vlan .
 
 We have implemented all the above, the pseudowires come up, but the flow
 label capability is not negotiated between 7600-ASR9K.
 
 Apart from that, there is no traffic flow over the pseudowires in the
 direction 7600-ASR9K.
 After we remove the platform vfi load-balance-label vlan  command
 from the 7600, traffic starts flowing.

 looks like the 7600 doesn't support signalled FAT PW today, hence you need
 to configure static flow-label (load-balancing flow-label both static)
 on the ASR9k peer.

 oli


___
cisco-nsp 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] FAT PW between 7600 - ASR9K

[George Giannousopoulos]

Ok. Got it.

Thanks again



On Fri, Nov 1, 2013 at 11:28 AM, Oliver Boehmer (oboehmer) 
oboeh...@cisco.com wrote:

 George,

 Oliver, since the documentation is very very limited, I'd appreciate if
 you could provide some info on how each PE will identify the flow labels.
 Is there a predefined range that is used only for the flow labels as Phil
 previously mentioned?

 you can check http://tools.ietf.org/html/rfc6391 how this works, there are
 no constraints on the flow label value other than it must not be a
 reserved label value (0-15). The label value is only significant for the
 encapsulating/ingress PE, it just ensures to allocate and use the same
 label for all indivisible flows, to ensure those flows are sent via the
 same ECMP path. Section 3 of the RFC talks a bit about who the PE should
 allocate and assign labels. The egress PE just needs to know that there is
 a flow label present on the PW (statically or signalled via LDP), and it
 just pops it.

 hope this helps..

 oli




___
cisco-nsp 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] FAT PW between 7600 - ASR9K

[George Giannousopoulos]

Hello all,

Does anyone have experience with FAT PW between 7600 and ASR9K?

The ASR9K supports it for sure and it has been verified.
The 7600, according to the doc, supports it only for VPLS with the addition
of a global command platform vfi load-balance-label vlan .

We have implemented all the above, the pseudowires come up, but the flow
label capability is not negotiated between 7600-ASR9K.

Apart from that, there is no traffic flow over the pseudowires in the
direction 7600-ASR9K.
After we remove the platform vfi load-balance-label vlan  command
from the 7600, traffic starts flowing.

Any ideas?

Thanks
George
___
cisco-nsp 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] ASR901 - L2 tunneling

[George Giannousopoulos]

Hi Psem,

We also did some tests with the ASR901 and we had issues with l2protocol
forwarding
After some research with cisco, we concluded that

- L2protocol tunnelling is not supported and there is no plan to support it
- L2protocol forwarding is supported on EFPs only for untagged PDUs
- L2protocol forwarding for tagged PDUs is only supported locally on BD
- L2protocol forwarding for both tagged and untagged PDUs is supported with
port-based EoMPLS

George


On Mon, Aug 26, 2013 at 3:24 AM, Pshem Kowalczyk pshe...@gmail.com wrote:

 Hi,

 I'm trying to asses if we could use asr901 for our usual metro-E
 deployments (where we currently use ME3600x). L3 on the ASR901 seems
 to work well enough, but with L2 I've encountered some issues,
 especially around L2 tunneling.
 I've already managed to confirm with Cisco, that some of the
 functionality is not there yet, but determining what actually works
 proven to be more difficult. So I'm looking for any input regarding
 the subject.

 I've tried to set up a simple dot1q to dot1q (both ends ASR901) xconnect:

 interface GigabitEthernet0/4
  description tester (slave)
  no ip address
  negotiation auto
  l2proto-forward tagged
  service-policy output PM-CUST-DEFAULT-10M-OUT
  service instance 1 ethernet
   encapsulation dot1q 17
   xconnect 10.122.129.254 4545 encapsulation mpls
mtu 9000

 (and identical setup on the other device)
 The xconnect comes up fine and forwards standard ethernet frames no
 issues. I can't get any of the L2 (STP, LLDP) stuff to work though.
 The frames simply don't leave the box (I don't think there is a way to
 do port-mirror on ASR901, so I have to capture the frames on the next
 device).

 I've got confirmation from Cisco that this wouldn't work with
 encapsulation 'default', but I hoped to get it going with explicit
 tag, especially with the ' l2proto-forward tagged' command. But
 documentation is scarce.
 Has anyone managed to configure this and get it working?

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

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

Re: [c-nsp] Routed Pseudowire

[George Giannousopoulos]

Hi Antonis,

What IOS version are you running on the 7600?

If you are on a 15.x train, you need at least 15.2(4)M
In fact it is referenced in the 15.2(2)S release notes.



On Mon, Apr 15, 2013 at 7:39 PM, Antonis Vosdoganis avo...@gmail.comwrote:

 Hello Arie

 We are using  ES20+

 Regards

 Antonis
 Στις 15 Απρ 2013 6:36 μ.μ., ο χρήστης Arie Vayner (avayner) 
 avay...@cisco.com έγραψε:

  Antonis,
 
  What kind of HW do you have on your 7600? You need ES20/ES+ on the
  interface facing the ME3600 to be able to terminate a PW on a L3
 interface.
 
  Arie
 
  -Original Message-
  From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
  Antonis Vosdoganis
  Sent: Monday, April 15, 2013 05:49
  To: cisco-nsp@puck.nether.net
  Subject: [c-nsp] Routed Pseudowire
 
  Hi
 
  We are trying to establish ip connectivity a host and an SVI
 
  HOST(192.168.33.2/24)-ME3600--7609(SVI:192.168.33.1/24)
 
  ME3600
 
  vlan 250
  name RPW
 
  interface GigabitEthernet0/23
  switchport trunk allowed vlan none
  switchport mode trunk
  service instance 250 ethernet
  encapsulation untagged
  bridge-domain 250
 
 
  interface Vlan250
  no ip address
  xconnect 172.16.0.0 250 encapsulation mpls
 
 
  7609
 
  vlan 250
  name RPW
 
 
  interface Vlan250
  ip address 192.168.33.2 255.255.255.0
  xconnect 172.18.0.17 250 encapsulation mpls
 
 
  Keep in mind 7609 has only one core facing L3 interface.
 
 
  From mpls l2 detailed
 
 
  7609
 
 
  VC statistics:
  transit packet totals: receive 29, send 0 transit byte totals:  receive
  4252, send 0 transit packet drops:  receive 0, seq error 0, send 0
 
 
  3600
 
  VC statistics:
 
  transit packet totals: receive 0, send 31 transit byte totals:  receive
 0,
  send 4496 transit packet drops:  receive 0, seq error 0, send 0
 
  Packet recieved from 3600 no packets send from 7609.
  Any ideas? I have read that this is a working scenario.
  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/

___
cisco-nsp 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 7609-S - ME3600 / xconnect up - ac down

[George Giannousopoulos]

Hello,

Are the two devices connected back to back?
In order to use SVI based EoMPLS from 7600 to me3600x, you need the egress
interface on the 7600 towards the me3600x to be on a ES+ module AND it must
be configured as L3 ptp.

Is that your case?

George


On Mon, Apr 8, 2013 at 4:51 PM, Antonis Vosdoganis avo...@gmail.com wrote:

 Hello

  We are trying to set up a pseudowire connection between a Cisco 7609-S and
 ME3600.

 When xconnect is applied on physical interface or service instance there is
 no problem.

 When we are moving to interface vlan xconnect is up but ac is down.

 Cisco 7609 is using a 7600-ES+20G3CXL gigabit port NOT RSP720 and IOS
 version c7600rsp72043-advipservicesk9-mz.153-1.S.bin

 ME3600 is using IOS version me360x-universalk9-mz.153-1.S1.bin

 We have successfully set up the same scenario with 2 ME3600.

 Please check attached files for sample configurations and show - debugs
 commands.

  Regards

  Antonis.

 ___
 cisco-nsp 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] ME3600X - tunning the output queues

[George Giannousopoulos]

Hi Pshem,

We have seen the same issue with the 3800x
In our case we use the maximum allowed packet number
 queue-limit 2457 packets

If I'm not mistaken, there are improvements coming to the default queue
sizes with the 15.3 train

George

On Mon, Mar 25, 2013 at 4:25 AM, Pshem Kowalczyk pshe...@gmail.com wrote:

 Hi,

 We have a couple of ME3600X (24cx) providing MPLS-based L2 services to
 anywhere between 20 and 80 customers per chassis. For the last few
 weeks we've been chasing a packet loss issue with some of those
 customers. It looks like the issue is more likely to happen on
 interfaces with multiple service instances then those with just a few.
 In most extreme cases we have customers doing 700Mb/s on a single port
 with the default queue depth (~ 50KB) and not a single dropped packet
 one one hand and a bunch of 10Mb/s on another dropping packets all
 the time.

 Initially we used the following QoS (per service instance):

 policy-map PM-CUST-DEFAULT-100M-OUT
  class class-default
   shape average 1

 This was causing massive drops even for services that were only
 transmitting 5-15Mb/s. Since queue-depth couldn't be applied with just
 the default class, we ended up with something like this:

 policy-map PM-CUST-DEFAULT-100M-OUT
  class CM-DUMMY
  class class-default
   shape average 1
   queue-limit 1536000 bytes

 (where CM-DUMMY matches non-existing qos-group).

 This made things significantly better, but I feel that the queue of
 1.5MB per service is quite excessive (bearing in mind that the device
 has only 22MB in total for shared queues on 1G ports). I was told by
 the TAC engineer that the memory is allocated dynamically, so it's
 save to oversubscribe it.

 At this stage I'm still waiting to learn if its possible to monitor
 the utilisation of that RAM.

 But the other question still lingers - what do you use as the
 queue-limit? I know it's traffic-dependant but with only 3 profiles
 available there is not much room to move (we use one profile for the
 core-facing classes, this is the second one) and a fairly universal
 depth has to be used. On top of that we don't really know what our
 customers use the service for, so the visibility is very limited.

 So if you use the platform - what's your magic number?

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

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

Re: [c-nsp] ASR901 to ME3600X xconnect

[George Giannousopoulos]

Hello all,

As far as I know, the MPLS-TE functionality is not supported on ASR901 yet
We should expect it after mid 2013..

From
http://www.cisco.com/en/US/docs/wireless/asr_901/Configuration/Guide/mpls_te-frr.html
*The MPLS TE is supported on the Cisco ASR 901 router to enable only the
FRR. The traffic engineering aspects of MPLS TE is currently not supported.*


regards
George


On Thu, Feb 28, 2013 at 11:34 PM, Pshem Kowalczyk pshe...@gmail.com wrote:

 Hi,

 I'm testing an asr901. We're looking at using for l2vpn termination.
 For some reason the xconnect refuses to stand up between asr901 and
 me3600x. Similar setup between two 3600x works fine.

 Relevant config on the asr901:

 !
 hostname asr901A
 !

 boot system flash:/asr901-universalk9-mz.152-2.SNH1.bin



 mpls label protocol ldp
 mpls ldp discovery targeted-hello accept
 mpls traffic-eng tunnels
 bridge-domain 2

 l2 router-id 10.123.129.3
 !
 interface Loopback0
  ip address 10.123.129.3 255.255.255.255
 !
 interface Tunnel3000
  ip unnumbered Loopback0
  mpls ip
  tunnel mode mpls traffic-eng
  tunnel destination 10.123.129.1
  tunnel mpls traffic-eng autoroute announce
  tunnel mpls traffic-eng path-option 1 dynamic
  tunnel mpls traffic-eng record-route
  tunnel mpls traffic-eng fast-reroute
 !
 interface GigabitEthernet0/0
  duplex full
  no negotiation auto
  service instance 1 ethernet
   encapsulation dot1q 17
   rewrite ingress tag pop 1 symmetric
   xconnect 10.123.29.1 4321 encapsulation mpls
mtu 1500
  !
 !
 interface Vlan2
  mtu 9216
  description to me3600x
  ip address 10.123.29.6 255.255.255.252
  ip router isis vc-core
  mpls traffic-eng tunnels
  clns mtu 9083
  isis network point-to-point
  isis metric 10
 !
 router isis vc-core
  net 49.0001.0101.2312.9003.00
  is-type level-2-only
  ispf level-2
  metric-style wide
  set-overload-bit on-startup wait-for-bgp
  spf-interval 5 50 200
  prc-interval 5 50 200
  lsp-gen-interval 5 50 200
  log-adjacency-changes
  passive-interface default
  no passive-interface Vlan2
  mpls traffic-eng router-id Loopback0
  mpls traffic-eng level-2


 on the ME3600X the xconnect looks like this:

 interface GigabitEthernet0/11
  description not in use
  switchport trunk allowed vlan none
  switchport mode trunk
  mtu 9100
  service-policy output PM-INT-1G-OUT
  service instance 17 ethernet
   encapsulation dot1q 4094
   rewrite ingress tag pop 1 symmetric
   xconnect 10.123.29.3 4321 encapsulation mpls
mtu 1500

 I can see the ISIS and LDP up between asr901 and me3600x:

 asr901A#sh mpls ldp neighbor
 Peer LDP Ident: 10.123.129.1:0; Local LDP Ident 10.123.129.3:0
 TCP connection: 10.123.129.1.646 - 10.123.129.3.26629
 State: Oper; Msgs sent/rcvd: 1207/1201; Downstream
 Up time: 17:22:15
 LDP discovery sources:
   Targeted Hello 10.123.129.3 - 10.123.129.1, active, passive
   Targeted Hello 10.123.129.3 - 10.123.29.1, active
 Addresses bound to peer LDP Ident:
   10.123.129.110.123.29.5 10.123.29.1

 asr901A#sh isis neighbors

 Tag vc-core:
 System Id  Type Interface   IP Address  State Holdtime Circuit Id
 accr01cgr  L2   Vl2 10.123.29.5 UP24   01


 Yet the actual vc doesn't come up:

 asr901A#sh mpls l2transport vc detail
 Local interface: Gi0/0 up, line protocol up, Eth VLAN 17 up
   Destination address: 10.123.29.1, VC ID: 4321, VC status: down
 Last error: Local peer access circuit is down
 Output interface: none, imposed label stack {}
 Preferred path: not configured
 Default path: no route
 No adjacency
   Create time: 00:17:34, last status change time: 00:13:54
   Signaling protocol: LDP, peer 10.123.129.1:0 up
 Targeted Hello: 10.123.129.3(LDP Id) - 10.123.29.1, LDP is DOWN, no
 binding
 Status TLV support (local/remote)   : enabled/None (no remote binding)
   LDP route watch   : disabled
   Label/status state machine: local ready, LruRnd
   Last local dataplane   status rcvd: No fault
   Last BFD dataplane status rcvd: Not sent
   Last BFD peer monitor  status rcvd: No fault
   Last local AC  circuit status rcvd: No fault
   Last local AC  circuit status sent: Not sent
   Last local LDP TLV status sent: No fault
   Last remote LDP TLVstatus rcvd: None (no remote binding)
   Last remote LDP ADJstatus rcvd: None (no remote binding)
 MPLS VC labels: local 16, remote unassigned
 Group ID: local 0, remote unknown
 MTU: local 1500, remote unknown
 Remote interface description:
   Sequencing: receive disabled, send disabled
   Control Word: On (configured: autosense)
   Dataplane:
 SSM segment/switch IDs: 0/0 (used), PWID: 2
   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 error 'Local peer access circuit is down' is all I get 

Re: [c-nsp] me3400 EVC config help needed

[George Giannousopoulos]

On the 7600 side I'd use only the svlan encapsulation

interface GigabitEthernet3/1
no ip address
no cdp enable
spanning-tree bpdufilter enable
service instance 3 ethernet
  description Customer-10
  encapsulation dot1q 10
  xconnect x.x.x.x 1227 encapsulation mpls

Which ios version are you using on the ME3400?
Is it a ME3400EG or ME3400G?

George

On Wed, Oct 31, 2012 at 5:32 PM, William Jackson 
william.jack...@gibtele.com wrote:

 Hi all

 I can't find a solution on the net and whilst TAC is currently on the
 case!!!

 Maybe someone can throw me a quick fastball.

 I want to have the following setup

 CEme3400---76xx---mpls network

 I want my uni port on the me3400 to accept any CVLAN tags and untagged
 frames.
 I want all CVLANs to get stuck into SVLAN 10 and sent up to the NNI port.
 I also want to l2-protocol tunnel any CVLANs.

 I want to use the EVC setup as I have the future requirement for CFM/OAM
 stuff.

 I have the following at the moment:
 But doesn't seem to be working:

 Me3400:

 ethernet cfm ieee
 ethernet cfm global
 ethernet cfm domain testnet level 4
 service cust1 vlan 10
   continuity-check
   continuity-check interval 1s
 !
 ethernet evc cust1  == do these have to be the
 same?
 oam protocol cfm svlan 10 domain testnet
 !
 ethernet lmi global

 interface FastEthernet0/3
 switchport trunk allowed vlan none
 switchport mode trunk
 speed 100
 duplex full
 ethernet cfm mep domain testnet mpid 1 service cust1
   cos 7
 ethernet uni id END1
 ethernet uni bundle all-to-one
 service instance 1 ethernet cust1
   ethernet lmi ce-vlan map 1-4094,untagged
 !
 !

 interface GigabitEthernet0/1
 port-type nni
 switchport mode trunk
 !

 76xx:
 interface GigabitEthernet3/1
 no ip address
 no cdp enable
 spanning-tree bpdufilter enable
 service instance 3 ethernet
   description Customer-10
   encapsulation dot1q 10 second-dot1q 1-4094
   xconnect x.x.x.x 1227 encapsulation mpls
 !
 end

 Is this the correct config?  I cannot find any decent documentation on
 this and how all the commands interact.

 Many thanks


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

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

Re: [c-nsp] ASR901 EoMPLS Customer COS bits trashed

[George Giannousopoulos]

Hello Caillin,

We have also seen some issues with the ASR901 QoS
In fact the config is very restricting at the moment..

What I know for sure is that the ingress cos markings are copied to the
MPLS EXP bit, so you can try to remark your customer traffic at the other
end

George


On Wed, Oct 10, 2012 at 7:50 AM, Caillin Bathern caill...@commtelns.comwrote:

 Hi list,



 I am seeing some odd behaviour in the lab and I am wondering if anyone
 else knows why this is happening or any alternative...



 I have a simple setup - CE---PE(ASR901)---EoMPLS---PE(ASR901)---CE - I
 also have inline packet capturing devices on all physical links and MPLS
 explicit null turned on to ensure EXP marking is carried through.

 A single VLAN (10) in a service instance is been xconnected through on
 the ASR901s as follows:



 pseudowire-class eth

 encapsulation mpls

 interworking ethernet

 !

 interface GigabitEthernet0/1

 service instance 10 ethernet

   encapsulation dot1q 10

   xconnect 6.6.6.6 10 encapsulation mpls pw-class eth

 !



 The CE is a network tester sending VID10 with COS 3, this traffic is
 received on the remote CE however my COS 3 marking is lost...

 This behaviour is consistent with tag pop/no tag pop, Ethernet or VLAN
 interworking, service policies or no service policies.



 Why are my customer COS markings being destroyed by the ASR901 when
 within an EoMPLS circuit and is there a way to fix this?



 Cheers,

 Caillin

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

[George Giannousopoulos]

If I remember correctly, 2457 packets is the maximum on this platform
We weren't given any specific version for the increase default values

In case you get anything extra from your SR, it would be nice to share it
with us

George

On Thu, Aug 23, 2012 at 12:10 PM, Ivan cisco-...@itpro.co.nz wrote:

 Thanks George.  I am raising a SR to get some more information too. Are
 you able to explain how the queue-limit of 2457 was selected? Also were you
 given a version for the increase in the default queue size?  I am running
 me360x-universalk9-mz.152-2.**S1.bin

 Cheers

 Ivan



 On 23/Aug/2012 5:48 p.m., George Giannousopoulos wrote:

 Hi Ivan,

 In fact the default queue limit in 3800x/3600x is quite small
 We also had issues with drops in all interfaces, even without congestion

 After some research and an SR with Cisco, we have started applying qos on
 all interfaces

 policy-map INTERFACE-OUTPUT-POLICY
   class dummy
   class class-default
shape average X
queue-limit 2457 packets


 The dummy class does nothing.
 It is just there because IOS wouldn't allow changing queue limit otherwise

 Also there were issues with the policy counters which should be resolved
 after15.1(2)EY2
 Cisco said they would increase the default queue sizes in the second half
 of 2012..
 So, I suggest you try the latest IOS version and check again

 10G interfaces had no drops in our setup too.

 Regards
 George


 On Thu, Aug 23, 2012 at 1:34 AM, Ivan cisco-...@itpro.co.nz mailto:
 cisco-...@itpro.co.nz** wrote:

 Replying to my own message

 * Adjusting the hold queue didn't help.

 * Applying QOS and per referenced email stopped the drops
 immediately - I
 used something like the below:

 policy-map leaf
 class class-default
 queue-limit 491520 bytes

 policy-map logical
 class class-default
 service-policy leaf

 policy-map root
 class class-default
 service-policy logical

 * I would be interested to hear if others have ended up applying a
 similar
 policy to all interfaces.  Any gotchas?  I expect any 10Gbps
 interfaces
 would be okay without the QoS - haven't seen any issue on these
 myself.

 *Apart from this list I have found very little information around this
 whole issue.  Any pointers to other documentation would be
 appreciated.

 Thanks

 Ivan

 Ivan

  Hi,
 
  I am seeing output drops on a ME3600X interface as shown below
 
  GigabitEthernet0/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/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is RJ45
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 6w1d, output never, output hang never
Last clearing of show interface counters 00:12:56
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output
 drops: 231
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 10299000 bits/sec, 5463 packets/sec
30 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 out
 
  I have read about similar issues on the list:
  
 http://www.gossamer-threads.**com/lists/cisco/nsp/157217http://www.gossamer-threads.com/lists/cisco/nsp/157217
  https://puck.nether.net/**pipermail/cisco-nsp/2012-July/**
 085889.htmlhttps://puck.nether.net/pipermail/cisco-nsp/2012-July/085889.html
 
  1. I have no QoS policies applied to the physical interface or EVCs.
  Would increasing the hold queue help?  Is there a recommended
 value - the
  maximum configurable is 24.  What is the impact on the 44MB
 of packet
  buffer.
 
  2. If the hold queue isn't an option is configuring QoS required to
  increase the queue-limit from the default 100us.  Again are
 there any
  recommended values and what impact is there on the available 44MB of
  packet buffer.
 
  3. I have found that when applying policies to the EVCs the
 show policy
  map output does not have information for the queue-limit as I

Re: [c-nsp] asr901 - vlan-based eompls (l2vpn) supported ?

[George Giannousopoulos]

Hi Aaron,

You aren't doing anything wrong..
SVI based EoMPLS isn't supported on ASR901 yet

It is expected in Q1 2013..

Cheers
George

On Thu, Aug 23, 2012 at 4:49 PM, Aaron aar...@gvtc.com wrote:

 does vlan-based eompls l2vpn work on asr901 ?  ...in 15.1(2)SNH ?  i can't
 get it to work using the following config...am i doing something wrong ?



 901#sh ver | in IOS

 Cisco IOS Software, 901 Software (ASR901-UNIVERSALK9-M), Version
 15.1(2)SNH,
 RELEASE SOFTWARE (fc2)



 901#conf t

 Enter configuration commands, one per line.  End with CNTL/Z.

 901(config)#int vl 20

 901(config-if)#xconnect 1.1.0.3 20 encapsulation mpls

 The Vl20 a vlan interface - command rejected.



 901(config-if)#xconnect 1.1.1.1 ?

   1-4294967295  Enter VC ID value



 901(config-if)#xconnect 1.1.1.1 20 ?

   encapsulation  Data encapsulation method

   pw-class   Pseudowire-class to use for encapsulation and protocol
 configuration



 901(config-if)#xconnect 1.1.1.1 20 encapsulation ?

   l2tpv3  Use L2TPv3 encapsulation

   mplsUse MPLS encapsulation



 901(config-if)#xconnect 1.1.1.1 20 encapsulation mpls ?

   manualManually configure MPLS session parameters

   pw-class  Optional pseudowire-class to use for advanced configuration

   cr



 901(config-if)#xconnect 1.1.1.1 20 encapsulation mpls

 The Vl20 a vlan interface - command rejected.

 901(config-if)#







 *

  PORT-BASED is working.

 *



 901#sh run in g0/3

 Building configuration...



 Current configuration : 170 bytes

 !

 interface GigabitEthernet0/3

 no negotiation auto

 service instance 1 ethernet

   encapsulation untagged

   xconnect 1.1.0.3 20 encapsulation mpls

mtu 1500

 !

 end



 901#sh xcon

 901#sh xconnect all | in 0/3

 UP ac   Gi0/3:1(Ethernet)UP mpls 1.1.0.3:20
 UP

 901#





 *

 *** VLAN-BASED is working on my me3600...

 *





 3600#sh run in vl 12

 Building configuration...



 Current configuration : 123 bytes

 !

 interface Vlan12

 ip address 1.1.5.10 255.255.255.0

 load-interval 30

 xconnect 1.2.0.2 312 encapsulation mpls

 end





 3600#sh xconnect all

 Legend:XC ST=Xconnect State  S1=Segment1 State  S2=Segment2 State

   UP=Up   DN=DownAD=Admin Down  IA=Inactive

   SB=Standby  HS=Hot Standby RV=Recovering  NH=No Hardware



 XC ST  Segment 1 S1 Segment 2
 S2


 --+-+--+
 -+--

 UP pri   ac Vl12:12(Eth VLAN)UP mpls 1.2.0.2:312
 UP





 3600#sh ver | in IOS

 Cisco IOS Software, ME360x Software (ME360x-UNIVERSALK9-M), Version
 15.2(2)S, RELEASE SOFTWARE (fc1)

 3600#















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

[George Giannousopoulos]

Hi Ivan,

In fact the default queue limit in 3800x/3600x is quite small
We also had issues with drops in all interfaces, even without congestion

After some research and an SR with Cisco, we have started applying qos on
all interfaces


policy-map INTERFACE-OUTPUT-POLICY
 class dummy
 class class-default
  shape average X
  queue-limit 2457 packets



The dummy class does nothing.

It is just there because IOS wouldn't allow changing queue limit otherwise


Also there were issues with the policy counters which should be
resolved after 15.1(2)EY2

Cisco said they would increase the default queue sizes in the second
half of 2012..

So, I suggest you try the latest IOS version and check again


10G interfaces had no drops in our setup too.


Regards

George



On Thu, Aug 23, 2012 at 1:34 AM, Ivan cisco-...@itpro.co.nz wrote:

 Replying to my own message

 * Adjusting the hold queue didn't help.

 * Applying QOS and per referenced email stopped the drops immediately - I
 used something like the below:

 policy-map leaf
 class class-default
 queue-limit 491520 bytes

 policy-map logical
 class class-default
 service-policy leaf

 policy-map root
 class class-default
 service-policy logical

 * I would be interested to hear if others have ended up applying a similar
 policy to all interfaces.  Any gotchas?  I expect any 10Gbps interfaces
 would be okay without the QoS - haven't seen any issue on these myself.

 *Apart from this list I have found very little information around this
 whole issue.  Any pointers to other documentation would be appreciated.

 Thanks

 Ivan

 Ivan

  Hi,
 
  I am seeing output drops on a ME3600X interface as shown below
 
  GigabitEthernet0/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/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is RJ45
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 6w1d, output never, output hang never
Last clearing of show interface counters 00:12:56
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 231
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 10299000 bits/sec, 5463 packets/sec
30 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 out
 
  I have read about similar issues on the list:
  http://www.gossamer-threads.com/lists/cisco/nsp/157217
  https://puck.nether.net/pipermail/cisco-nsp/2012-July/085889.html
 
  1. I have no QoS policies applied to the physical interface or EVCs.
  Would increasing the hold queue help?  Is there a recommended value - the
  maximum configurable is 24.  What is the impact on the 44MB of packet
  buffer.
 
  2. If the hold queue isn't an option is configuring QoS required to
  increase the queue-limit from the default 100us.  Again are there any
  recommended values and what impact is there on the available 44MB of
  packet buffer.
 
  3. I have found that when applying policies to the EVCs the show policy
  map output does not have information for the queue-limit as I have seen
  when applying polices to the physical interface.  Does this mean that
 EVCs
  will still suffer from output drops?
 
  Thanks
 
  Ivan



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