Re: [c-nsp] ASR9k question

[Vitkovský Adam]

> Nick Hilliard
> Sent: Wednesday, December 17, 2014 6:11 PM
> On 17/12/2014 09:14, R LAS wrote:
> > does anybody knows the maximum number of VPLS instances supported
> on
> > ASR9k ?
> >
> > Is there a reference on cisco.com ?
> > I was able to find numbers of pseudowires but I'm not currently sure
> > i'ts the same...
> 
> Router# show l2vpn capability
> 
> note that there are a pile of line-card dependencies here, and that the
> documentation says: "To achieve the scale values, subinterfaces must be
> evenly allocated between the line card's physical ports."
> 
> Nick
> 
Also if you have Trident LCs it also depends on whether you have L2 or L3 scale 
profile enabled. 

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/

Re: [c-nsp] Primer for IOS-XR

[Vitkovský Adam]

Hello Scott,

Since you have ASRs you should read through everything from Xander (Alexander 
Thuijs) on support forums including discussions under the articles -you can 
also post questions.
Oh and also watch Xander's presentations on cisco live.

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/

Re: [c-nsp] ASR 1K : EFP / XCONNECT / BDI

[Vitkovský Adam]

Hi Nicolas ,

Have you been able to figure this out please?
The configuration seems perfectly valid, one think that’s not clear to me is if 
both services are between the same ASR and ISR routers why the PW neighbor IP 
address is different on each: 2.2.2.2 vs 81.23.32.79.

adam

From: nico...@karp.fr [mailto:nico...@karp.fr] On Behalf Of Nicolas KARP
Sent: Thursday, December 04, 2014 11:52 PM
To: Vitkovský Adam
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ASR 1K : EFP / XCONNECT / BDI

Hi Adam, all,

I have now an issue when i configure a second xconnect under an efp. The idea 
is to create several xconnect between an ASR and a ISR 2801 to xconnect some 
vlans between the 2 platforms. As soon as I configure the 2nd xconnect and as 
soon as it comes UP, the trafic associated with the EVC is not going through.. 
In fact, all EVC under the interface g0/0/4 stop working...



  BDI4096
  BDI4093
ASR 1001x < xconnect MPLS ---> 2801
| |
| |
  switch   switch
vlan 4094 vlan 4094
vlan 4093 vlan 4093
vlan 4092 vlan 4092


Here is the config of the 1001x :


interface GigabitEthernet0/0/4
 mtu 1530
 no ip address
 load-interval 30
 negotiation auto
 service instance 4092 ethernet
 encapsulation dot1q 4092 exact
  rewrite ingress tag pop 1 symmetric
  xconnect 2.2.2.2 12 encapsulation mpls
!
 service instance 4093 ethernet
  encapsulation dot1q 4093 exact
  rewrite ingress tag pop 1 symmetric
  bridge-domain 4093
 !
 service instance 4094 ethernet
  encapsulation dot1q 4094
  rewrite ingress tag pop 1 symmetric
  bridge-domain 4096
 !
end


l2 vfi TEST2 manual (it's working when the service instance 4092 is not 
configured)
 vpn id 258
 bridge-domain 4093
 mtu 1530
 neighbor 81.23.32.79 11 encapsulation mpls
!

interface BDI4093
 mtu 1530
 ip vrf forwarding TEST2
 ip address 172.31.0.253 255.255.255.0
 standby 1 ip 172.31.0.254
 standby 1 priority 110
 standby 1 preempt delay minimum 60
end


interface BDI4096
 ip vrf forwarding TEST
 ip address 10.84.6.2 255.255.255.0
 standby 1 ip 10.84.6.1
 standby 1 priority 110
 standby 1 preempt delay minimum 60
end


and the config on the 2801 :


interface FastEthernet0/1.4092
 encapsulation dot1Q 4092
 no cdp enable
 xconnect 1.1.1.1 12 encapsulation mpls
end

interface FastEthernet0/1.4093
 encapsulation dot1Q 4093
 no cdp enable
 xconnect 1.1.1.1 11 encapsulation mpls
end





bridge domain when it works :

RTI-MPLS-SAB-01#show bridge-domain 4093
Bridge-domain 4093 (3 ports in all)
State: UPMac learning: Enabled
Aging-Timer: 300 second(s)
BDI4093  (up)
GigabitEthernet0/0/4 service instance 4093
vfi OCTEY neighbor 81.23.32.79 11
   AED MAC addressPolicy  Tag   Age  Pseudoport
   0   0024.E84F.9A87 forward dynamic   292  GigabitEthernet0/0/4.EFP4093
   -   881D.FCD4.293F to_bdi  static0BDI4093
   0   0022.195F.166B forward dynamic   279  GigabitEthernet0/0/4.EFP4093
   1   .. flood   static0OLIST_PTR:0x2edad820
   -   .0C07.AC01 to_bdi  static0BDI4093
   0   001B.213F.EDA8 forward dynamic   286  GigabitEthernet0/0/4.EFP4093


and when there is an issue :


RTI-MPLS-SAB-01#show  bridge-domain 4096
Bridge-domain 4096 (2 ports in all)
State: UPMac learning: Enabled
Aging-Timer: 300 second(s)
BDI4096  (up)
GigabitEthernet0/0/4 service instance 4094
   AED MAC addressPolicy  Tag   Age  Pseudoport
   -   881D.FCD4.293F to_bdi  static0BDI4096
   1   .. flood   static0OLIST_PTR:0x2edad810
   -   .0C07.AC01 to_bdi  static0BDI4096


The mac address of the switch behind the ASR disappeared... Not too sure why... 
If i remove the xconnect under the service instance 4092, it still doesn't 
work. I have to remove the xconnect and do a shut/no shut on the physical 
port...


Do you know what is happening ?

Thank you.


# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - -
# - -   Nicolas KARP
# - -   Network and Security Engineer
# - -Email : li...@karp.fr<mailto:nico...@karp.fr>
# - -Linkedin :  http://www.linkedin.com/in/nicolaskarp
# - -Viadeo : http://www.viadeo.com/fr/profile/nicolas.karp 
<http://www.viadeo.com/fr/profile/nicolas.karp%20>
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - -


2014-12-03 15:54 GMT+01:00 Nicolas KARP mailto:li...@karp.fr>>:
That's the point !! I modified the mtu under the bdi interface and i had to 
modify the mu under the l2 vfi interface in order to 

Re: [c-nsp] ME3600/A9K MVPN PIM VRF neighbour issues

[Vitkovský Adam]

Oh and if you have the loopback in BGP -do you also see it being advertised to 
the ME please? cmd: sh bgp ipv4 mdt vrf iptv advertised neighbor x.x.x.x 
-looopback of the ME. 

If yes then you should debug on ME why it is not accepting the route. 

adam
> -Original Message-
> From: Vitkovský Adam
> Sent: Wednesday, December 03, 2014 2:53 PM
> To: 'Jason Lixfeld'
> Cc: 
> Subject: RE: [c-nsp] ME3600/A9K MVPN PIM VRF neighbour issues
> 
> And do you see the 9k's global loopback in bgp right? cmd: "sh bgp ipv4 mdt
> vrf iptv x.x.x.x".
> -that's basically the source (s,g) info for the ME so that it knows who are 
> the
> sources for the default MDT group so that it can send join towards the
> sources building the default MDT.
> 
> Once that is done you should see the the (s,g) states for the default tree
> group cmd: "sh mrib route".
> 
> Once the default tree is built ME and A9k should form PIM neighborship
> (within the VRF context) -they should see each other over the tunnel like
> over a LAN.
> 
> 
> adam
> > -Original Message-
> > From: Jason Lixfeld [mailto:ja...@lixfeld.ca]
> > Sent: Wednesday, December 03, 2014 2:27 PM
> > To: Vitkovský Adam
> > Cc: 
> > Subject: Re: [c-nsp] ME3600/A9K MVPN PIM VRF neighbour issues
> >
> > No.  The 9K sees ME3600 global loopback in the VRF over the MDT SAFI,
> > but not the other way around.  I think that's where the issue is, but
> > I can't seem to pinpoint why.
> >
> > Sent from my iPhone
> >
> > > On Dec 3, 2014, at 4:32 AM, Vitkovský Adam 
> > wrote:
> > >
> > > Hi Jason,
> > >
> > > Have you been able to force the BGP to advertise its information via
> > > the
> > MDT SAFI?
> > >
> > > adam
> > >> -Original Message-
> > >> From: Jason Lixfeld [mailto:ja...@lixfeld.ca]
> > >> Sent: Monday, December 01, 2014 9:19 PM
> > >> To: Vitkovský Adam
> > >> Cc: 
> > >> Subject: Re: [c-nsp] ME3600/A9K MVPN PIM VRF neighbour issues
> > >>
> > >> Hi Adam,
> > >>
> > >> - Global space loopback is lo0.  This is the SIP for the MP-BGP bits.
> > >> - VRF TV loopback is lo2022
> > >> - Adding the PIM join TLV bits didn’t seem to help at all, but
> > >> thankfully it didn’t blow apart what was already working, so that’s
> > >> good, I guess :)
> > >> - VRF TV already has the mvpn AF configured.
> > >>
> > >> !
> > >> router bgp 21949
> > >> vrf tv
> > >>  rd 21949:2022
> > >>  address-family ipv4 unicast
> > >>   redistribute connected route-policy SOURCE--INTERNAL-CONNECTED
> > >>   redistribute static route-policy SOURCE--INTERNAL-STATIC
> > >>   redistribute eigrp 21949 route-policy SOURCE--INTERNAL-EIGRP  !
> > >>  address-family ipv4 mvpn
> > >>  !
> > >> !
> > >> !
> > >> multicast-routing
> > >> address-family ipv4
> > >>  interface Loopback0
> > >>   enable
> > >>  !
> > >>  nsf
> > >>  mdt source Loopback0
> > >>  rate-per-route
> > >>  interface all enable
> > >>  accounting per-prefix
> > >> !
> > >> vrf tv
> > >>  address-family ipv4
> > >>   mdt data 232.0.2.0/23
> > >>   mdt default ipv4 232.0.0.1
> > >>   mdt partitioned mldp ipv4 mp2mp
> > >>   rate-per-route
> > >>   interface all enable
> > >>   bgp auto-discovery mldp
> > >>   !
> > >>   accounting per-prefix
> > >>  !
> > >> !
> > >> !
> > >> router pim
> > >> address-family ipv4
> > >>  interface Loopback0
> > >>   enable
> > >>  !
> > >>  interface TenGigE0/2/0/2
> > >>   enable
> > >>   dr-priority 100
> > >>  !
> > >> !
> > >> vrf tv
> > >>  address-family ipv4
> > >>   rpf topology route-policy MLDP-TV
> > >>   mdt c-multicast-routing pim
> > >>announce-pim-join-tlv
> > >>   !
> > >>   interface Loopback2022
> > >>enable
> > >>   !
> > >>   interface TenGigE0/0/0/15
> > >>enable
> > >>   !
> > >>   interface TenGigE0/0/0/1.4006
> > >>enable
> > >>dr-priority 100
> > &g

Re: [c-nsp] ME3600/A9K MVPN PIM VRF neighbour issues

[Vitkovský Adam]

And do you see the 9k's global loopback in bgp right? cmd: "sh bgp ipv4 mdt vrf 
iptv x.x.x.x". 
-that's basically the source (s,g) info for the ME so that it knows who are the 
sources for the default MDT group so that it can send join towards the sources 
building the default MDT. 

Once that is done you should see the the (s,g) states for the default tree 
group cmd: "sh mrib route". 

Once the default tree is built ME and A9k should form PIM neighborship (within 
the VRF context) -they should see each other over the tunnel like over a LAN. 


adam
> -Original Message-
> From: Jason Lixfeld [mailto:ja...@lixfeld.ca]
> Sent: Wednesday, December 03, 2014 2:27 PM
> To: Vitkovský Adam
> Cc: 
> Subject: Re: [c-nsp] ME3600/A9K MVPN PIM VRF neighbour issues
> 
> No.  The 9K sees ME3600 global loopback in the VRF over the MDT SAFI, but
> not the other way around.  I think that's where the issue is, but I can't seem
> to pinpoint why.
> 
> Sent from my iPhone
> 
> > On Dec 3, 2014, at 4:32 AM, Vitkovský Adam 
> wrote:
> >
> > Hi Jason,
> >
> > Have you been able to force the BGP to advertise its information via the
> MDT SAFI?
> >
> > adam
> >> -Original Message-
> >> From: Jason Lixfeld [mailto:ja...@lixfeld.ca]
> >> Sent: Monday, December 01, 2014 9:19 PM
> >> To: Vitkovský Adam
> >> Cc: 
> >> Subject: Re: [c-nsp] ME3600/A9K MVPN PIM VRF neighbour issues
> >>
> >> Hi Adam,
> >>
> >> - Global space loopback is lo0.  This is the SIP for the MP-BGP bits.
> >> - VRF TV loopback is lo2022
> >> - Adding the PIM join TLV bits didn’t seem to help at all, but
> >> thankfully it didn’t blow apart what was already working, so that’s
> >> good, I guess :)
> >> - VRF TV already has the mvpn AF configured.
> >>
> >> !
> >> router bgp 21949
> >> vrf tv
> >>  rd 21949:2022
> >>  address-family ipv4 unicast
> >>   redistribute connected route-policy SOURCE--INTERNAL-CONNECTED
> >>   redistribute static route-policy SOURCE--INTERNAL-STATIC
> >>   redistribute eigrp 21949 route-policy SOURCE--INTERNAL-EIGRP  !
> >>  address-family ipv4 mvpn
> >>  !
> >> !
> >> !
> >> multicast-routing
> >> address-family ipv4
> >>  interface Loopback0
> >>   enable
> >>  !
> >>  nsf
> >>  mdt source Loopback0
> >>  rate-per-route
> >>  interface all enable
> >>  accounting per-prefix
> >> !
> >> vrf tv
> >>  address-family ipv4
> >>   mdt data 232.0.2.0/23
> >>   mdt default ipv4 232.0.0.1
> >>   mdt partitioned mldp ipv4 mp2mp
> >>   rate-per-route
> >>   interface all enable
> >>   bgp auto-discovery mldp
> >>   !
> >>   accounting per-prefix
> >>  !
> >> !
> >> !
> >> router pim
> >> address-family ipv4
> >>  interface Loopback0
> >>   enable
> >>  !
> >>  interface TenGigE0/2/0/2
> >>   enable
> >>   dr-priority 100
> >>  !
> >> !
> >> vrf tv
> >>  address-family ipv4
> >>   rpf topology route-policy MLDP-TV
> >>   mdt c-multicast-routing pim
> >>announce-pim-join-tlv
> >>   !
> >>   interface Loopback2022
> >>enable
> >>   !
> >>   interface TenGigE0/0/0/15
> >>enable
> >>   !
> >>   interface TenGigE0/0/0/1.4006
> >>enable
> >>dr-priority 100
> >>   !
> >>   interface TenGigE0/2/0/5.4006
> >>enable
> >>dr-priority 100
> >>   !
> >>   interface TenGigE0/0/0/11.4006
> >>enable
> >>dr-priority 100
> >>   !
> >>   interface GigabitEthernet0/1/0/0.958
> >>enable
> >>dr-priority 100
> >>   !
> >>  !
> >> !
> >> !
> >>
> >>
> >>
> >>>> On Nov 28, 2014, at 8:10 PM, Vitkovský Adam
> >>>> 
> >>> wrote:
> >>>
> >>> Hi Jason,
> >>>
> >>> Do you have the PE loopback enabled under the router pim and
> >>> multicast
> >> routing  (global IPv4 AF) please?
> >>> Do you have "mdt source Loopback0" under the multicast routing
> please?
> >>>
> >>>
> >>> Also once you have that working these helped in my case to get the
> >>> mLDP
> >>

Re: [c-nsp] ASR 1K : EFP / XCONNECT / BDI

[Vitkovský Adam]

Does the MTU match on both ends please?
You can see the MTU on both ends in the output of the cmd “sh mpls l2 vc det”

adam

From: nico...@karp.fr [mailto:nico...@karp.fr] On Behalf Of Nicolas KARP
Sent: Wednesday, December 03, 2014 12:29 PM
To: Vitkovský Adam
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ASR 1K : EFP / XCONNECT / BDI

I've found another thread where you were talking about router pw on an ASR1k.

He is the config i've done so far :

ASR 1001X :

l2 vfi TEST2 manual
 vpn id 258
 bridge-domain 4093
 neighbor 2.2.2.2 11 encapsulation mpls

interface BDI4093
 mtu 1530
 ip vrf forwarding TEST2
 ip address 172.31.0.253 255.255.255.0
 standby 1 ip 172.31.0.254
 standby 1 priority 110
 standby 1 preempt delay minimum 60
end

interface GigabitEthernet0/0/4
 no ip address
 load-interval 30
 negotiation auto
 service instance 4093 ethernet
  encapsulation dot1q 4093 exact
  rewrite ingress tag pop 1 symmetric
  bridge-domain 4093
 !


ISR 2801 :

interface FastEthernet0/1.4093
 encapsulation dot1Q 4093
 no cdp enable
 xconnect 1.1.1.1 11 encapsulation mpls


//

For some reason the xconnect is not coming up...


RTI-MPLS-SAB-01#sh xconnect all
DN pri  vfi OCTEYUP mpls 2.2.2.2:11<http://2.2.2.2:11>  
 DN
UP pri   bd 4093 UP  vfi TEST2UP


Thanks for your help.


# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - -
# - -   Nicolas KARP
# - -   Network and Security Engineer
# - -Email : li...@karp.fr<mailto:nico...@karp.fr>
# - -Linkedin :  http://www.linkedin.com/in/nicolaskarp
# - -Viadeo : http://www.viadeo.com/fr/profile/nicolas.karp 
<http://www.viadeo.com/fr/profile/nicolas.karp%20>
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - -


2014-12-03 11:14 GMT+01:00 Nicolas KARP mailto:li...@karp.fr>>:
Hi Adam,

I don't have the xconnect command under the bdi interface :

RTI-MPLS-SAB-01(config)#interface BDI4093
RTI-MPLS-SAB-01(config-if)#xconnect ?
% Unrecognized command

I'm using ASR1001X , ves 03.13.01.S


Any thought ?



# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - -
# - -   Nicolas KARP
# - -   Network and Security Engineer
# - -Email : li...@karp.fr<mailto:nico...@karp.fr>
# - -Linkedin :  http://www.linkedin.com/in/nicolaskarp
# - -Viadeo : http://www.viadeo.com/fr/profile/nicolas.karp 
<http://www.viadeo.com/fr/profile/nicolas.karp%20>
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - -


2014-12-03 10:21 GMT+01:00 Vitkovský Adam 
mailto:adam.vitkov...@swan.sk>>:
Hi Nicolas,

This is the config for mixing EFPs and PWs in a common BD + IP interface for 
the BD.
Manual hub and spoke type of configuration with IP address + VFR at the hub 
location.

interface TenGigabitEthernet0/3
 mtu 9000
 service instance 8000 ethernet
  description CUSTOMER-B
  encapsulation dot1q 20,30,40
  rewrite ingress tag pop 1 symmetric
  bridge-domain 8000

interface BDI8000
 mtu 9000
 vrf CUST-B
 ip add 192.0.2.1 255.255.255.0
 xconnect vfi CUST-B-BD

l2 vfi CUST-B-BD manual
 vpn id 1
 neighbor 10.0.1.3 100 encapsulation mpls
 neighbor 10.0.1.4 200 encapsulation mpls
 neighbor 10.0.1.5 300 encapsulation mpls

Spokes would have just EFPs with xconnect.


adam
> -Original Message-
> From: cisco-nsp 
> [mailto:cisco-nsp-boun...@puck.nether.net<mailto:cisco-nsp-boun...@puck.nether.net>]
>  On Behalf Of
> Nicolas KARP
> Sent: Tuesday, December 02, 2014 6:03 PM
> To: cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> Subject: [c-nsp] ASR 1K : EFP / XCONNECT / BDI
>
> Hi,
>
> I need to interconnect 2 platforms on 2 different datacenters.
>
> The idea is to create several EFPs on each PE (one at each side) and create a
> default xconnect pw in order to encapsulate the layer2 traffic over our MPLS
> network. I also have some layer 3 interfaces for different vlans which need to
> be used on both datacenters :
>
>
> *PE1 : (same config on PE2, except for the BDI interface)*
>
>
> *interface GigabitEthernet0/0/4*
> * no ip address*
> * load-interval 30*
> * negotiation auto*
>
> *## default XCONNECT to DC2*
> * service instance 1 ethernet*
> *  encapsulation default*
> *  xconnect 1.1.1.1  encapsulation mpls pw-class EOMPLS-ETH-TO-VLAN*
> * !*
>
> *## Layer 3 interface via BDI*
> * service instance 4093 ethernet*
> *  encapsulation dot1q 4093 exact*
> *  rewrite ingress tag pop 1 symmetric*
> *  bridge-domain 4093*
> * !*
>
> *interface BDI4093*
> * ip vrf forwarding TEST2*
> * ip address 172.31.0.253 255.255.255.0*
> * standby 1 ip 172.3

Re: [c-nsp] ME3600/A9K MVPN PIM VRF neighbour issues

[Vitkovský Adam]

Hi Jason,

Have you been able to force the BGP to advertise its information via the MDT 
SAFI?

adam
> -Original Message-
> From: Jason Lixfeld [mailto:ja...@lixfeld.ca]
> Sent: Monday, December 01, 2014 9:19 PM
> To: Vitkovský Adam
> Cc: 
> Subject: Re: [c-nsp] ME3600/A9K MVPN PIM VRF neighbour issues
> 
> Hi Adam,
> 
> - Global space loopback is lo0.  This is the SIP for the MP-BGP bits.
> - VRF TV loopback is lo2022
> - Adding the PIM join TLV bits didn’t seem to help at all, but thankfully it
> didn’t blow apart what was already working, so that’s good, I guess :)
> - VRF TV already has the mvpn AF configured.
> 
> !
> router bgp 21949
>  vrf tv
>   rd 21949:2022
>   address-family ipv4 unicast
>redistribute connected route-policy SOURCE--INTERNAL-CONNECTED
>redistribute static route-policy SOURCE--INTERNAL-STATIC
>redistribute eigrp 21949 route-policy SOURCE--INTERNAL-EIGRP
>   !
>   address-family ipv4 mvpn
>   !
>  !
> !
> multicast-routing
>  address-family ipv4
>   interface Loopback0
>enable
>   !
>   nsf
>   mdt source Loopback0
>   rate-per-route
>   interface all enable
>   accounting per-prefix
>  !
>  vrf tv
>   address-family ipv4
>mdt data 232.0.2.0/23
>mdt default ipv4 232.0.0.1
>mdt partitioned mldp ipv4 mp2mp
>rate-per-route
>interface all enable
>bgp auto-discovery mldp
>!
>accounting per-prefix
>   !
>  !
> !
> router pim
>  address-family ipv4
>   interface Loopback0
>enable
>   !
>   interface TenGigE0/2/0/2
>enable
>dr-priority 100
>   !
>  !
>  vrf tv
>   address-family ipv4
>rpf topology route-policy MLDP-TV
>mdt c-multicast-routing pim
> announce-pim-join-tlv
>!
>interface Loopback2022
> enable
>!
>interface TenGigE0/0/0/15
> enable
>!
>interface TenGigE0/0/0/1.4006
> enable
> dr-priority 100
>!
>interface TenGigE0/2/0/5.4006
> enable
> dr-priority 100
>!
>interface TenGigE0/0/0/11.4006
> enable
> dr-priority 100
>!
>interface GigabitEthernet0/1/0/0.958
> enable
> dr-priority 100
>!
>   !
>  !
> !
> 
> 
> 
> > On Nov 28, 2014, at 8:10 PM, Vitkovský Adam 
> wrote:
> >
> > Hi Jason,
> >
> > Do you have the PE loopback enabled under the router pim and multicast
> routing  (global IPv4 AF) please?
> > Do you have "mdt source Loopback0" under the multicast routing please?
> >
> >
> > Also once you have that working these helped in my case to get the mLDP
> and mGRE Rosens to live next to each other.
> >
> > router pim
> > vrf iptv
> >  address-family ipv4
> >   mdt c-multicast-routing pim
> >announce-pim-join-tlv <---that is on 4.3.4
> >
> > Prior to 4.3.0 there was a bug causing the PIM Join TLV not to be sent with
> dual scenario.
> >
> >
> > Also I'd like to ask did you have to enable mvpn AF under the VRF to get
> the mLDP mVPN working (to get the type 1 routes advertised)?
> > router bgp 65000
> > vrf iptv
> >  address-family ipv4 mvpn
> >
> >
> > adam
> >> -Original Message-
> >> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf
> >> Of Jason Lixfeld
> >> Sent: Friday, November 28, 2014 10:57 PM
> >> To: 
> >> Subject: [c-nsp] ME3600/A9K MVPN PIM VRF neighbour issues
> >>
> >> I’m trying to turn up MVPN between a 9K and an ME3600.
> >>
> >> - My default MDT seems OK; tunnel0 and mdt tunnels are up on the
> >> ME3600 and A9K, respectively.
> >> - Each box sees the correct PIM interfaces in the VRF, but only the
> >> 9K sees the ME3600 as a PIM neighbour over the tunnel, the ME3600
> >> doesn’t see a PIM adjacency over the tunnel.
> >> - The ME3600 (me3600-1) with the MVPN config is an MP-BGP neighbour
> >> of the A9K (a9k-1), but there are two other ME3600s in the middle
> >> that are not a part of the MVPN.  That said, each ME3600 is a PIM
> >> neighbor of the other in the global table, all the way along to the 9K.  
> >> That
> should be all I need.
> >> Everything else should happen over BGP and the non-MVPN ME3600s
> >> should be agnostic to any of that.
> >> - The BGP adjacency in the MDT SAFI between me3600-1 and a9k-1 is up,
> >> but what I think might be contributing to this is that the A9K sees a
> >> prefix in the MDT SAFI from me3600-1, but me3600-1 doesn’t see a
>

Re: [c-nsp] ASR 1K : EFP / XCONNECT / BDI

[Vitkovský Adam]

Hi Nicolas,

This is the config for mixing EFPs and PWs in a common BD + IP interface for 
the BD.
Manual hub and spoke type of configuration with IP address + VFR at the hub 
location.

interface TenGigabitEthernet0/3
 mtu 9000
 service instance 8000 ethernet
  description CUSTOMER-B
  encapsulation dot1q 20,30,40  
  rewrite ingress tag pop 1 symmetric
  bridge-domain 8000

interface BDI8000
 mtu 9000
 vrf CUST-B
 ip add 192.0.2.1 255.255.255.0
 xconnect vfi CUST-B-BD

l2 vfi CUST-B-BD manual
 vpn id 1
 neighbor 10.0.1.3 100 encapsulation mpls
 neighbor 10.0.1.4 200 encapsulation mpls
 neighbor 10.0.1.5 300 encapsulation mpls

Spokes would have just EFPs with xconnect.


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Nicolas KARP
> Sent: Tuesday, December 02, 2014 6:03 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ASR 1K : EFP / XCONNECT / BDI
> 
> Hi,
> 
> I need to interconnect 2 platforms on 2 different datacenters.
> 
> The idea is to create several EFPs on each PE (one at each side) and create a
> default xconnect pw in order to encapsulate the layer2 traffic over our MPLS
> network. I also have some layer 3 interfaces for different vlans which need to
> be used on both datacenters :
> 
> 
> *PE1 : (same config on PE2, except for the BDI interface)*
> 
> 
> *interface GigabitEthernet0/0/4*
> * no ip address*
> * load-interval 30*
> * negotiation auto*
> 
> *## default XCONNECT to DC2*
> * service instance 1 ethernet*
> *  encapsulation default*
> *  xconnect 1.1.1.1  encapsulation mpls pw-class EOMPLS-ETH-TO-VLAN*
> * !*
> 
> *## Layer 3 interface via BDI*
> * service instance 4093 ethernet*
> *  encapsulation dot1q 4093 exact*
> *  rewrite ingress tag pop 1 symmetric*
> *  bridge-domain 4093*
> * !*
> 
> *interface BDI4093*
> * ip vrf forwarding TEST2*
> * ip address 172.31.0.253 255.255.255.0*
> * standby 1 ip 172.31.0.254*
> * standby 1 priority 110*
> * standby 1 preempt delay minimum 60*
> *end*
> 
> *--> I'm missing a xconnect for the vlan 4093...*
> 
> 
> How can I create a layer3 interface and run a xconnect on the same EFP ?
> The idea would be to use the same vlans at both locations and terminate the
> Layer3 on a BDI interface in Datacenter1.
> 
> Do you think it's possible ?
> I'm not too sure if i'm really clear. Don't hesitate to ask me if you have any
> questions :)
> 
> Many Thanks for your help !
> 
> # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - -
> # - -   Nicolas KARP
> # - -   Network and Security Engineer
> # - -Email : li...@karp.fr 
> # - -Linkedin :  http://www.linkedin.com/in/nicolaskarp
> # - -Viadeo : http://www.viadeo.com/fr/profile/nicolas.karp
> 
> # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - -
> ___
> cisco-nsp 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] ME3600/A9K MVPN PIM VRF neighbour issues

[Vitkovský Adam]

Hi Jason,

Do you have the PE loopback enabled under the router pim and multicast routing  
(global IPv4 AF) please? 
Do you have "mdt source Loopback0" under the multicast routing please? 


Also once you have that working these helped in my case to get the mLDP and 
mGRE Rosens to live next to each other. 

router pim
 vrf iptv
  address-family ipv4
   mdt c-multicast-routing pim
announce-pim-join-tlv <---that is on 4.3.4

Prior to 4.3.0 there was a bug causing the PIM Join TLV not to be sent with 
dual scenario. 

 
Also I'd like to ask did you have to enable mvpn AF under the VRF to get the 
mLDP mVPN working (to get the type 1 routes advertised)? 
router bgp 65000
 vrf iptv
  address-family ipv4 mvpn


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Jason Lixfeld
> Sent: Friday, November 28, 2014 10:57 PM
> To: 
> Subject: [c-nsp] ME3600/A9K MVPN PIM VRF neighbour issues
> 
> I’m trying to turn up MVPN between a 9K and an ME3600.
> 
> - My default MDT seems OK; tunnel0 and mdt tunnels are up on the ME3600
> and A9K, respectively.
> - Each box sees the correct PIM interfaces in the VRF, but only the 9K sees
> the ME3600 as a PIM neighbour over the tunnel, the ME3600 doesn’t see a
> PIM adjacency over the tunnel.
> - The ME3600 (me3600-1) with the MVPN config is an MP-BGP neighbour of
> the A9K (a9k-1), but there are two other ME3600s in the middle that are not
> a part of the MVPN.  That said, each ME3600 is a PIM neighbor of the other in
> the global table, all the way along to the 9K.  That should be all I need.
> Everything else should happen over BGP and the non-MVPN ME3600s should
> be agnostic to any of that.
> - The BGP adjacency in the MDT SAFI between me3600-1 and a9k-1 is up, but
> what I think might be contributing to this is that the A9K sees a prefix in 
> the
> MDT SAFI from me3600-1, but me3600-1 doesn’t see a prefix from the A9K
> over the MDT SAFI; there doesn’t seem to be a locally originated prefix on
> the A9K.  On the ME3600, that locally sourced prefix is actually the loopback
> in the global table is the update-source and remote peering IP for the MP-
> BGP infrastructure.  This seems fine to me, because this link:
> 
> http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-
> 2/multicast/configuration/guide/b_mcast_cg42crs/b_mcast_cg42crs_chapter
> _00.html#task_2665897
> 
> Suggests that the default behaviour in XR is the same as what I’m seeing on
> the me3600-1, which is why the global loopback shows up as an BGP-MDT
> learned prefix.
> 
> It’s probably something dumb, but I’m having a hard time finding any
> troubleshooting docs that relate to A9K/IOS intermix for this sort of 
> topology.
> 
> I’ve already got LSM working across my A9K backbone; I just hope it’s not
> some odd interop thing that makes LSM and MVPN interoperability in the
> same VRF a problem there.
> 
> Can anyone see something I may have missed?
> 
> Topo:
> 
> ME3600 1 (MVPN) —— ME3600 2 (PIM) —— ME3600 3 (PIM) —— A9K 1
> (MVPN)
> 
> me3600-1#show ip pim neigh
> PIM Neighbor Table
> Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
>   P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
> Neighbor  InterfaceUptime/ExpiresVer   DR
> AddressPrio/Mode
> 72.15.51.236  TenGigabitEthernet0/101:09:45/00:01:27 v21 / S P G
> me3600-1#sh ip pim vrf tv neighbor
> PIM Neighbor Table
> Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
>   P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
> Neighbor  InterfaceUptime/ExpiresVer   DR
> Address
> 
> 
> 
> 
>   Prio/Mode 
> me3600-2sh ip pim neigh PIM
> Neighbor Table
> Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
>   P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
> Neighbor  InterfaceUptime/ExpiresVer   DR
> AddressPrio/Mode
> 72.15.51.6TenGigabitEthernet0/100:55:06/00:01:41 v21 / S P G
> 72.15.51.237  TenGigabitEthernet0/201:11:45/00:01:20 v21 / DR S P 
> G
> 
> 
> 
> 
> 
> me3600-3#show ip pim neigh
> PIM Neighbor Table
> Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
>   P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
> Neighbor  InterfaceUptime/ExpiresVer   DR
> AddressPrio/Mode
> 72.15.51.2TenGigabitEthernet0/100:55:26/00:01:39 v2100/ DR P G
> 72.15.51.7TenGigabitEthernet0/200:55:26/00:01:23 v21 / DR S P 
> G
> 
> 
> 
> 
> 
> a9k-1#show pim neighbor te0/2/0/2
> Fri Nov 28 16:23:16.113 EST
> 
> PIM nei

Re: [c-nsp] ASR vs 6807

[Vitkovský Adam]

Hi Gert,

> From: Gert Doering [mailto:g...@greenie.muc.de]
> Sent: Thursday, November 27, 2014 3:27 PM
> > What should we recommend to our customers Maserati or Ferrari - they
> both have a Ferrari engine inside though the price difference is huge.
> 
> Well, as the underlying architecture of ASR9k and 6807/6500 is way different
> (NPU vs. EARL), it is actually *not* the same engine inside.
> 
> Just some of the chassis paint comes from the same can :-)
I agree not a best comparison :-) 
I meant it more like though these boxes have lot of features in common there 
are applications where 6807 can't be used instead of ASR9k. 
So in this light they may seem similar and interchangeable though there's a 
reason (several actually) for a higher price of ASR9k.

 
> > Both ASR9k and C6800 were meant as L3 switch the selection of one over
> > the other should be based on the educated customer expectations met
> > with the project budget.
> 
> I think you're confusing N7K with ASR9K here :-) - ASR9K is "router", not "l3
> switch" (and N7K indeed shares the same engine with the 6500 family).
Here I meant the Cisco's original aim before the decision was made that the 
platform is going to end up as a router.

Nah guess it's not a good day for me to post to public mailing lists today.
Gonna stop confusing people and crawl under my rock :)

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/

Re: [c-nsp] ASR vs 6807

[Vitkovský Adam]

What should we recommend to our customers Maserati or Ferrari - they both have 
a Ferrari engine inside though the price difference is huge.
These types of questions might seem simple but they rather invoke more 
questions than answers...
I guess most of the times the decision factor is to get the biggest bang for 
the smallest buck - with the smallest buck part being the most important from 
the two. 
And I guess the most difficult part is to define what bang is expected as 
customers don't now (and don't really need to know) what are all the ways to 
skin the cat in other words to implement a given service.
So that leads back to you and your expertise and what do you think would be 
beneficial for the customer.

You mentioned VPLS -so does the customer have several DCs and would like to 
setup any-to-any type of connectivity between them via L2 or more like hub and 
spoke or maybe even p2p type of connectivity between the DCs please? 
By "VPLS" do you mean the legacy Cisco VPLS per se or VPLS as a LAN emulation 
over the MPLS (MEF: EP-LAN/EVP-LAN) type of service please that could be 
realized by a pure VPLS or PBB-VPLS or EVPN or PBB-EVPN?
What are their expectations regarding redundancy/load-sharing/fast failure 
recovery please?
Any expectations of excessive BUM traffic between the DCs please? 
How many MAC addresses are expected in this setup please any massive VM moves 
between the DCs expected? 

ASR9k supports many technologies that C6800 will probably never have since 
these boxes are positioned differently.
Both ASR9k and C6800 were meant as L3 switch the selection of one over the 
other should be based on the educated customer expectations met with the 
project budget.


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of R
> LAS
> Sent: Thursday, November 27, 2014 11:19 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ASR vs 6807
> 
> Discussing a new architecture of DCI (Data Center Interconnection), Cisco
> raccomends both ASR9k and 6807.
> The architecture requested by the customer forecast MPLS/VPLS supported
> by DCI.
> 
> From pricing point of view there is a quite big difference (win 6807), from
> feature point of view Cisco says the difference is "only" the number of mac-
> addresses supported and the sw modularity.
> 
> Can anybody help in digging more the "technical" difference ?
> 
> Greetings
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] routed PW in ASR1K

[Vitkovský Adam]

Hi James, folks,
I'm sorry I should have let you know folks. 
Yes please it is working fine now. 
Though it's a bit disappointing that in order for this to work, you still need 
a working dot1q trunk. 


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> James Bensley
> Sent: Tuesday, November 25, 2014 10:12 PM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] routed PW in ASR1K
> 
> Did you ever get this working Adam?
> 
> 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] Cisco IIH padding

[Vitkovský Adam]

Interesting I never heard of the "always" option one learns something new every 
day. 
Though there's still this IIH padding madness when it gets to the actual size 
of the IIH datagram and the allowed offset between CLNS MTU and the actual IIH 
size. 

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Pete Lumbis
> Sent: Tuesday, November 25, 2014 8:24 PM
> To: Alex K.
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Cisco IIH padding
> 
> "no hello padding always". The Always keyword has been hidden for a long
> time and was unhidden somewhat recently (I can't remember where). With
> "always" none of the hellos are padded.
> 
> On Tue, Nov 25, 2014 at 12:51 AM, Alex K.  wrote:
> 
> > Hello everybody,
> >
> > Although I have “no hello padding” configured, the adjacency won't
> > come up until I limit the CLNS MTU on some link in my network (there
> > is an MTU issue on that link, it's not 1500).
> >
> > As far as I remember, Cisco IOS implementation of IS-IS will *still
> > send out first* IIHs padded, never mind I had “no hello padding”
> *configured*.
> > On the other hand, it seems like that isn't documented. Can anybody
> > kindly point out for me (and probably, for the rest of the list) the
> > correct documentation for that and if this is still relevant for
> > modern IOS/IOS-XE versions?
> >
> >
> >  Thank you.
> > ___
> > cisco-nsp mailing list  cisco-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] MVPN vs. plain-old-multicast

[Vitkovský Adam]

Hi Jason,

I'm actually working on a rollout of one setup where I'm trying to combine 
Rosen mLDP with oldschool Rosen mGRE.
Though my setup is easy as the m-cast is going to be introduced only via one 
POP -so I don't need to do the RPF selection on nodes capable of Rosen mLDP.
In theory it's fairly easy but in practice one could hit several bumps on a way 
to a working setup.
 
E.g. right now I'm facing a problem that the streams work for around 45sec and 
then the head-end ASR stops transmitting to the Lmdtiptv and mdtiptv trees.


adam

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Jason Lixfeld
> Sent: Monday, November 24, 2014 10:08 PM
> To: 
> Subject: [c-nsp] MVPN vs. plain-old-multicast
> 
> Hi all,
> 
> We’ve got an A9K MPLS core that we do all sorts of fun stuff on, including
> LSM.  Yay for a PIM-free core!
> 
> We’ve also got a whack of ME3600 PEs in ring that hang off of the A9Ks.  Also
> fully MPLS enabled; all L3 ME3600 and A9K core.  While looking to bring
> multicast out to these ME3600 PEs, which don’t support LSM, we’re faced
> with whether or not we deploy MVPN or just plain-old-multicast.  In our
> particular deployment, multicast receivers, which we own and control, would
> be hanging off of our ME3600 PEs.  As such, all sources (behind the LSM core)
> and all receivers would all be in the same VRF.
> 
> In order to do MVPN, we’d have to enable PIM between the ME3600s and
> the A9Ks anyway, so since this is all in a common VRF, is there really any
> benefit to doing MVPN?
> 
> Thanks in advance for any insight.
> 
> 
> ___
> cisco-nsp 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] Draft Rosen (mvpn) interoperability - Cisco and Alcatel-Lucent 7750 SROS

[Vitkovský Adam]

Hi Arun,

According to the below snip from the RFC the option should be used only for 
PIM-DM is there a possibility that the ALU runs PIM-DM (or "sparse-dense" mode 
for that matter) over the Default MDT tunnel please? 

4.7.5.2. LAN Prune Delay Option


0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type = 2   |   Length = 4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|   LAN Prune Delay   |   Override Interval   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LAN_Prune_Delay option is used to tune the prune propagation
   delay on multi-access LANs.  The T bit is used by PIM-SM and SHOULD
   be set to 0 by PIM-DM routers and ignored upon receipt.  The LAN
   Delay and Override Interval fields are time intervals in units of
   milliseconds and are used to tune the value of the J/P Override
   Interval and its derived timer values.  Section 4.3.5 describes how
   these values affect the behavior of a router.  The LAN Prune Delay
   SHOULD be used by PIM-DM routers.

adam

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Arun Kumar
> Sent: Friday, November 21, 2014 5:45 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Draft Rosen (mvpn) interoperability - Cisco and Alcatel-
> Lucent 7750 SROS
> 
> Hi All,
> 
> I am evaluating Alcatel-Lucent 7750 SR-OS with Cisco IOS on Draft Rosen
> MVPN. PIM neighborship on VRF is not established. On doing debug, found
> "PIM(0): Ignored unknown option 2 in PIM Hello packet". On searching,
> found Cisco is not supporting 'lan prune delay' and hence could not establish
> PIM neighborship on VRF.
> 
> Is there any way where I can configure Cisco to talk to this LAN prune delay
> or in Alcatel-Lucent to disable it.
> 
> Please advise.
> 
> 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] Cisco ASR1K ISG - ARP broadcast

[Vitkovský Adam]

> Mihai Tanasescu
> Sent: Saturday, November 15, 2014 11:38 AM
> The problem I have experienced lately consists in the classic effect of a ping
> sweep on the whole subnet assigned on the ISG interface.
> It triggers a "storm" of "arp who has  tell  " messages that I
> would like to limit/not see being emitted by the ISG.

Hi Mihai,

Should the GW respond to the ARP requests to addresses from a local subnet? It 
doesn't seem right. Is it a property of the PPPoE setup? 
Well maybe you could police the ARP traffic coming from subscribers? 

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/

Re: [c-nsp] ASR1000 BGP advertise best-external FAIL

[Vitkovský Adam]

Hi Oliver,

> From: Oliver Boehmer (oboehmer) [mailto:oboeh...@cisco.com]
> Sent: Sunday, November 09, 2014 3:07 PM
> A RR needs to advertise the best path to each RR client, that's its job.

That's a good point I haven't considered that and now it makes sense.

> If it should also send the best-external (which would be, by definition, not
> the overall best path) to the clients, you need to use add-path as you need
> to advertise more than one path. Have you enabled both? can you share the
> config?
> IIRC this is the same on XR, you also need to enable add-path on the RR..
> 
>   oli

However in my setup I have a CE connected to two PEs and I use per PE per VRF 
RDs so prefix received over MP-iBGP and prefix received over eBGP should be 
considered as two unique prefixes rather than candidates for best path 
selection.
Ooooh and that answers my question geez I'm stupid :) what a bummer!
Sorry folks for wasting your time.

Thank you very much Oliver. 




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/

Re: [c-nsp] ASR1000 BGP advertise best-external FAIL

[Vitkovský Adam]

> From: Nick Hilliard [mailto:n...@foobar.org]
> Sent: Saturday, November 08, 2014 4:53 PM
> On 08/11/2014 14:29, Vitkovský Adam wrote:
> > Is there any reason why RR running XE can't advertise best external to its
> clients? That is nonsense!
> > Why XR doesn't have any problems with that?
> > From a business point of view I understand it very well as you need to buy
> 4 instead of two routers but otherwise...
> 
> i don't use this feature, but the docs say it's supported on RRs from 3.4S.
> 
> Nick
> 
Well yes it is but actually only for nonclients as one can't advertise best 
external to a RR client. 
So if there's a PE that happens to be a route reflector as well, then this 
feature is useless. 
On XR there's no such limitation. 
 

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/

[c-nsp] ASR1000 BGP advertise best-external FAIL

[Vitkovský Adam]

Hi Folks,

Is there any reason why RR running XE can't advertise best external to its 
clients? That is nonsense!
Why XR doesn't have any problems with that?
>From a business point of view I understand it very well as you need to buy 4 
>instead of two routers but otherwise...


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/

[c-nsp] routed PW in ASR1K

[Vitkovský Adam]

Hi folks,

Is there a support for routed PW in ASR1K please?

This is not working for some reason:


SRC

l2 vfi SRC manual
 vpn id 1
 neighbor 10.0.0.4 500 encap mpls
 bridge-domain 500

interface GigabitEthernet0/0/1
 service instance 500 ethernet
  encapsulation dot1q 500
  rewrite ingress tag pop 1 symmetric
  bridge-domain 500

int bd500
 ip add 192.0.1.1 255.255.255.252



DST

l2 vfi DST manual
 vpn id 1
 neighbor 10.0.0.3 500 encap mpls
 bridge-domain 500

interface GigabitEthernet0/0/1
 service instance 500 ethernet
  encapsulation dot1q 500
  rewrite ingress tag pop 1 symmetric
  bridge-domain 500

int bd500
 ip add 192.0.1.2 255.255.255.252


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/

Re: [c-nsp] Best design can fit DC to DC

[Vitkovský Adam]

Hi folks, 

OTV please ... 
If you have a unique opportunity to rebuild the DCs and their interconnect you 
can as well do it right. 
You may really want to use a full blown standards based MPLS solution for the 
DCI part. 
Then you can start small with just p2p PWs and a backup peers to create L2 
pipes between the DCs. 
Or you can use VPLS already to prepare for more than 2 DCs. 
Or you can use PBB-EVPN to get the best that is out there for DCI. 
 
If you want sub-sec convergence within the DC you may want to use any 
technology that allows you to build a link-bundle from a single access device 
to two upstream devices(VSS, V-PC, MC-LAG).  
Or you can get a rid of STP altogether by running L2MP like TRILL or FbricPath 
within the DC. 

 
adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of R
> LAS
> Sent: Friday, October 31, 2014 5:43 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Best design can fit DC to DC
> 
> Hi all
> a customer of mine is thinking to renew DC infrastructure and
> interconnection among the main (DC1) and secondary (DC2), with the
> possibility in the future to add another (DC3).
> 
> Main goal are: sub-second convergence in case of a single fault of any
> component among DC1 and DC2 (not DC3), to have the possibility to extend
> L2 and L3 among DCs, to provide STP isolation among DCs, to provide ports on
> the server at eth 1/10Gbs speed.
> 
> DC1 and DC2 are 35 km away, DC3 around 1000 km away from DC1 and DC2.
> 
> Customer would like to design using Cisco or Juniper and at the end to
> decide.
> 
> Talking about Juniper my idea was to build and MPLS interconnection with
> MX240 or MX104 in VC among DC1 and DC2 (tomorrow will be easy to add
> DC3) and to use QFX in a virtual chassis fabric configuration.
> 
> And if you would go with Cisco, what do you propose in this scenario ?
> 
> Rgds
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] IOS XR as-path-loopcheck and as-override

[Vitkovský Adam]

Hi James,

Ok now I understand the setup and the failure,
And based on the outputs the ASR9k in AS5 is suppressing the advertisement 
of the paths like the "as-path-loopcheck out" is still enabled or maybe there's 
another safeguard in effect still. 
The debugs should reveal what's troubling the box hopefully.


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> James Bensley
> Sent: Tuesday, October 28, 2014 9:14 PM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] IOS XR as-path-loopcheck and as-override
> 
> On 28 October 2014 12:39, Vitkovský Adam  wrote:
> > Hi James,
> >
> >> I can't get the ASR9K to send the route from either eBGP neighbour in
> >> AS 65001 to the other.
> >
> > May I know your reasoning behind this nonstandard setup please?
> > As the 9K1s should know the routes from each other via the intra-AS paths.
> 
> 
> Hi Adam,
> 
> Just imagine two CPEs both in AS 65001 with MPLS Opt B Peerings to PE in AS
> 5. That could be one use for the configuration I have provided.
> 
> 
> > From the top of my head I can't think of a reason why it should not work.
> > So the Ak9 in remote AS is advertising the routes over Opt.B to AS65001 but
> ASR9001s are dropping them please?
> > Or the Ak9 in remote AS is not even attempting to advertise the routes back
> to AS65001 please?
> 
> 192.168.1.2 in AS 65001 advertises 10.0.0.3/32 to ASR9K in AS 5.
> 192.168.1.6 in AS 65001 advertises 10.0.0.2/32 to ASR9K in AS 5.
> The ASR9K PE in AS 5 also has a loopback with 10.0.0.1/32 configured
> within the same VRF.
> 
> In the output I provided you can see that ASR9K has all three prefix present 
> in
> the VRF. The problem is that 192.168.1.6 has 10.0.0.2 and
> 10.0.0.1 inside the VRF. 192.168.1.2 has 10.0.0.3 and 10.0.0.1 inside the VRF.
> 
> Neither of the AS 65001 devices receive the /32 route from the other.
> The ASR9K that sits in the middle is not advertising between the eBGP CPEs.
> 
> 
> > The quickest way to figure things out is to use debug.
> > debug bgp update vpnv4 u in (rpl)
> > or
> > debug bgp update vpnv4 u out (rpl)
> 
> 
> Debug was next on the list, I'll see what I can find, I ran out of lab time 
> today.
> 
> 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] IOS XR as-path-loopcheck and as-override

[Vitkovský Adam]

Hi James,

> I can't get the ASR9K to send the route from either eBGP neighbour in AS 65001
> to the other. 

May I know your reasoning behind this nonstandard setup please? 
As the 9K1s should know the routes from each other via the intra-AS paths.  

>From the top of my head I can't think of a reason why it should not work. 
So the Ak9 in remote AS is advertising the routes over Opt.B to AS65001 but 
ASR9001s are dropping them please? 
Or the Ak9 in remote AS is not even attempting to advertise the routes back to 
AS65001 please? 

The quickest way to figure things out is to use debug. 
debug bgp update vpnv4 u in (rpl)
or
debug bgp update vpnv4 u out (rpl)

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> James Bensley
> Sent: Tuesday, October 28, 2014 11:32 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] IOS XR as-path-loopcheck and as-override
> 
> Hi All,
> 
> I can't seem to get these features to work on my lab ASR9K1 running 4.3.4. I
> have two eBGP neighbours in AS 65001 both advertising a /32 loopback to the
> ASR9K (MPLS Opt B peerings). As per the output below the ASR9K receives the
> /32 route from each eBGP neighbour.
> 
> I can't get the ASR9K to send the route from either eBGP neighbour in AS 65001
> to the other.
> 
> I have added "as-path-loopcheck out disable" under both address-families
> under BGP and under the test VRF "vrf". I have also configured "as-override" 
> on
> one of the neighbours (192.168.1.6) in both address-families.
> 
> I understand how both of those features work, I'm not sure whythough despite
> enabling them everywhere out of desperation I still don't advertise the /32
> route from 192.168.1.2 to 192.168.1.6 in the test VRF.
> 
> RP/0/RSP0/CPU0:ASR9001#show route vrf vrf1
> 
> L10.0.0.1/32 is directly connected, 20:25:10, Loopback1
> B10.0.0.2/32 [20/0] via 192.168.1.6 (nexthop in vrf default), 00:08:53
> B10.0.0.3/32 [20/0] via 192.168.1.2 (nexthop in vrf default), 17:03:24
> 
> RP/0/RSP0/CPU0:ASR9001#show bgp vpnv4 unicast neighbors 192.168.1.6
> advertised-routes
> 
> NetworkNext HopFromAS Path
> Route Distinguisher: 5:1
> 10.0.0.1/32192.168.1.5 Local   ?
> 
> Processed 1 prefixes, 1 paths
> 
> ASR9K:
> 
> router bgp 5
>  address-family ipv4 unicast
>   as-path-loopcheck out disable
>   allocate-label all
>  !
>  address-family vpnv4 unicast
>   as-path-loopcheck out disable
>  !
>  neighbor 192.168.1.2
>   remote-as 65001
>   address-family ipv4 labeled-unicast
>route-policy PASS in
>route-policy PASS out
>send-extended-community-ebgp
>next-hop-self
>   !
>   address-family vpnv4 unicast
>route-policy PASS in
>route-policy PASS out
>next-hop-self
>   !
>  !
>  neighbor 192.168.1.6
>   remote-as 65001
>   address-family ipv4 labeled-unicast
>route-policy PASS in
>route-policy PASS out
>as-override
>send-extended-community-ebgp
>next-hop-self
>   !
>   address-family vpnv4 unicast
>route-policy PASS in
>route-policy PASS out
>as-override
>next-hop-self
>   !
>  !
>  vrf vrf1
>   rd 5:1
>   address-family ipv4 unicast
>as-path-loopcheck out disable
>redistribute connected
>allocate-label all
> 
> 
> Any help would be greatly appreciated as I expected I have overlooked
> something really obvious.
> 
> 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/

[c-nsp] OSPFv3 in context mode on ASA 5500-X

[Vitkovský Adam]

Hi Folks,

Would you know what the plans are for adding the support for OSPFv3 in context 
mode to ASA 5500-X or any ipv6 capable routing protocol for that matter? 
Also since only two OSPFv2 processes are allowed and I already have two would I 
be able to add additional OSPFv3 process(es)? 
Thanks. 


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/

[c-nsp] IOS XR mLDP v mGRE rpf topology selection

[Vitkovský Adam]

Hi folks, 

It should be possible to make this selection based on the RT ext comm attached 
to MDT routes received from remote PEs right? 
This is just a test setup so far and the idea is that legacy PEs would attach 
the below RT to the MDT routes so that they receive the streams over the mGRE 
Rosen method. 
I can't get this to work though am I missing something please? 

How can I check the replication other than with the below cmd: 

sh mrib vrf iptv route 233.1.1.1
(192.0.2.9,233.1.1.1) RPF nbr: 192.0.2.9 Flags: L EID
  Up: 00:00:02
  Incoming Interface List
Loopback456 Flags: A, Up: 00:00:02
  Outgoing Interface List
mdtiptv Flags: F NS MI, Up: 00:00:02
Lmdtiptv Flags: F NS LMI, Up: 00:00:02


The config on headend PE:

extcommunity-set rt mGRE-Rosen
  65000:4
end-set
!
route-policy RP_ROSEN_MLDP
  if extcommunity rt matches-any mGRE-Rosen then
set core-tree pim-default
  else
set core-tree mldp-default
  endif
end-policy
!
router pim 
 vrf iptv
  address-family ipv4
   rpf topology route-policy RP_ROSEN_MLDP


sh pim vrf iptv rpf route-policy statistics 

RPF route-policy statistics for VRF iptv:
Route-policy name: RP_ROSEN_MLDP
Number of lookup requests 3
Pass 3, Drop 0
Default RPF Table selection 3, Specific RPF Table selection 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/

Re: [c-nsp] ME3600: EVC and PVST transparency

[Vitkovský Adam]

Please try it with xconncet under the EVC to see whether the BD is the problem 
or if accepting the BPDU frames on EVC is the problem. 

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Lukas Tribus
> Sent: Thursday, October 23, 2014 12:43 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ME3600: EVC and PVST transparency
> 
> Hi guys,
> 
> 
> I understand ME3600 only supports MST on EVC's, however I am quite
> surprised that I cannot even l2protocol "tunnel" or "forward" the (tagged)
> rapid-pvst BPDU's (DA: 01000CCD).
> 
> Is this really expected behavior? I'm mapping the service instance into a
> bridge-domain, its not an xconnect, but I expected this to work anyway.
> 
> 
> It currently looks like I can't provide PVST transparency on a bridge-domain
> based A to B transport, which works fine on non-EVC platforms (even on
> extinct dinosaurs like a Catalyst 3550).
> 
> 
> Maybe this works only on xconnect based EVCs (I don't know), but my actual
> requirement is to achieve this on a bridge-domain based transport.
> 
> Running 15.3(3)S3 btw.
> 
> 
> 
> Any hints appreciated.
> 
> 
> Lukas
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] CEM unusable on ME-3600X-24CX with 15.3.3.S4

[Vitkovský Adam]

It would be sooo great if CISCO would reveal the documentation related to the 
HW show commands so that we could check whether the HW is programed correctly 
ourselves.  
That way we could open up a TAC case pinpointing the issue so it could be sent 
to developers right away and we would not need to go through the obligatory 
pain of initial introductions to TAC engineers which consumes from one to three 
hours in a webex session where one can't do any other work. Then we need to 
wait for the developers to send us the HW show commands. 

The best would be to get full documentation to sdcli as well so we would be 
able to confirm the bug by fixing it temporarily on our own but of course that 
would allow us the full control over the chases (e.g. to carve up the TCAM as 
we which) so that's not going to happen. 
But at least the documentation to the show commands would be greatly 
appreciated. 
 
adam

> -Original Message-
> From: Mark Tinka [mailto:mark.ti...@seacom.mu]
> Sent: Saturday, October 11, 2014 11:19 AM
> To: cisco-nsp@puck.nether.net
> Cc: Vitkovský Adam
> Subject: Re: [c-nsp] CEM unusable on ME-3600X-24CX with 15.3.3.S4
> 
> On Thursday, October 09, 2014 02:29:57 PM Vitkovský Adam
> wrote:
> 
> > It's great platform for IP services with current
> > 15.3.3.S4 code is almost flawless. The only major bug seems to be
> > occasional Rosen mGRE mVPN mcast HW programing related issues.
> 
> I've also been hitting IPv6 ACL programming issues on the ME3600X lately -
> running 15.4(2)S.
> 
> In odd cases, IPv6 ACL's that do not block IPv6 traffic end up doing so, or
> leading to packet loss.
> 
> Interestingly, a reboot does not fix, but rather, removing and re-applying the
> ACL (a number of times) does.
> 
> Mark.

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

Re: [c-nsp] Me3800 EVC E-tree

[Vitkovský Adam]

Hi Darwin,

This is where the mef-cecp would get handy as I'm not 100% sure what you mean 
by e-tree. 
But this is what you can do: 

interface gi0/0
 service instance 123 ethernet 
   description Link to E-Tree root
   encap dot1q 10 ethernet
   rewrite ingress tag pop 1 symmetric
   bridge-domain 123

l2 vfi E-Tree 
 vpn id 1
 bridge-domain 123
 neighbor x.x.x.x 100 encapsulation mpls 
 neighbor y.y.y.y 200 encapsulation mpls 


You can also associate VLAN interface with this setup to have a L3 interface. 

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Darwin L.
> Sent: Friday, October 10, 2014 1:59 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Me3800 EVC E-tree
> 
> Hi Guys,
> 
> Anybody know how I can do a configuration rooted to multipoint (e-tree) on
> L2 in the Cisco me3800 using iOS 15.3.
> 
> Thanks in advance.
> 
> << Darwin Santana >>
> ___
> cisco-nsp 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] CEM unusable on ME-3600X-24CX with 15.3.3.S4

[Vitkovský Adam]

Hi folks,

Just a quick heads up regarding CEM services on ME3600-CX

Unfortunately once again due to terrible HW programing issues this platform has 
to bear CEM services are not usable in production.
As every time you play with CEM settings traffic from PW to CEM interface stops 
flowing and once this condition appears it requires reload to restore the 
operation and removing of xconnect to reset the tLDP sessions (removing tLDP 
sessions with no prior reload does not help).

It's great platform for IP services with current 15.3.3.S4 code is almost 
flawless. 
The only major bug seems to be occasional Rosen mGRE mVPN mcast HW programing 
related issues. 


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/

Re: [c-nsp] ME3600 support for Xconnect as a Client of BFD

[Vitkovský Adam]

I have just realized there's no such an option like in BGP to set hello and 
hold timers for LDP sessions.
So there's actually seem to be no workaround for this.

adam
From: Vitkovský Adam
Sent: Tuesday, October 07, 2014 11:13 AM
To: cisco-nsp@puck.nether.net
Subject: ME3600 support for Xconnect as a Client of BFD

Hi Folks, Waris,

Would anyone know if there are plans to add support the "Xconnect as a Client 
of BFD" feature please?

We came across an interesting issue with pseudowire redundancy.
If the CE-PE link fails on the primary PE the primary PW is thorn down and 
backup PW is brought up immediately no issues.
However if you just power down the primary PE it has no time to signal to 
ingress PE that the PW is down so the ingress PE just sits there for around 3 
minutes until the tLDP session times out.

A possible workaround would be to pre-configure the tLDP session manually with 
more aggressive timers but I don't like that one.

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/

[c-nsp] ME3600 support for Xconnect as a Client of BFD

[Vitkovský Adam]

Hi Folks, Waris,

Would anyone know if there are plans to add support the "Xconnect as a Client 
of BFD" feature please?

We came across an interesting issue with pseudowire redundancy.
If the CE-PE link fails on the primary PE the primary PW is thorn down and 
backup PW is brought up immediately no issues.
However if you just power down the primary PE it has no time to signal to 
ingress PE that the PW is down so the ingress PE just sits there for around 3 
minutes until the tLDP session times out.

A possible workaround would be to pre-configure the tLDP session manually with 
more aggressive timers but I don't like that one.

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/

Re: [c-nsp] Understanding ASR1k / ESP40 capacity

[Vitkovský Adam]

Hi Simon,

In the presentation Steven specifically mentioned at around 35min when talking 
about sys bw that all you care about is the capacity of the link between the 
QFP and the central buss -that link is full duplex (shame I could not find it 
written anywhere in the docs). 
So if the QFP is e.g. 10 gig that link is 10gbps+overhead so if you have 10gig 
coming in from any of the IOs you're done. 
Getting it out doesn't count as the link is full duplex so once you can get it 
in you can get it out.

So this supports your claims that you should be able to get 40gbps full-duplex 
out of the QFP i.e. 40gig in and 40gig out. 

  
adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Simon Lockhart
> Sent: Monday, October 06, 2014 5:25 PM
> To: Pete Lumbis
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Understanding ASR1k / ESP40 capacity
> 
> Pete,
> 
> Thanks for this - I'll watch that preso and see if it adds anything useful.
> 
> You seem to be supporting my viewpoint, and I've also had an off-list reply
> supporting TAC's viewpoint - so I'm not sure I'm any further forwards.
> 
> I'm currently working on a plan to replace the ESP40 with an ESP100 - but as
> the ESP100 isn't supported in the ASR1004, I'll also have to do a chassis swap
> to an ASR1006. My only remaining concern with this plan is whether the SIP40
> can really do 40Gbps. If I stick 4 * 10G SPA's into a SIP40, can I run those 
> 10G
> ports at line-rate (assuming sufficient ESP capacity)?
> 
> Many thanks,
> 
> Simon
> 
> 
> 
> On Sat Oct 04, 2014 at 11:56:45AM -0400, Pete Lumbis wrote:
> > It would be a single pass through the QFP. The SIP could also be a
> > limiting factor, but since you are split between SIPs that shouldn't be an
> issue.
> > The SIP 40 has 2x 40Gig lanes on the backplane. Are you doing crypto
> > or anything like that which would impact performance?
> >
> > There is a great Cisco Live preso on the ASR1k architecture that might
> > help you get some ammo to go back to TAC with.
> > http://d2zmdbbm9feqrf.cloudfront.net/2014/usa/pdf/BRKARC-2001.pdf
> >
> > -Pete
> >
> > On Sat, Oct 4, 2014 at 4:56 AM, Simon Lockhart  wrote:
> >
> > > All,
> > >
> > > I'm banging my head against a brick wall trying to get sensible
> > > answers from Cisco TAC, so thought I'd ask the educated masses who
> > > may have come across this before...
> > >
> > > I've got a Cisco ASR1004 with RP2, ESP40, 2 * SIP40's, and 8 * 10GE ports.
> > >
> > > A snapshot of usage on these ports at peak is:
> > >
> > > Interface RxBps RxPps  TxBps TxPps
> > > Te0/0/0   4,385,563,000   515,508906,118,000   339,997
> > > Te0/1/0   3,942,338,000   419,696984,150,000   358,436
> > > Te0/2/0   3,949,993,000   425,192933,257,000   349,145
> > > Te0/3/0   4,375,526,000   512,858873,284,000   334,751
> > > Te1/0/0   1,186,440,000   454,714  5,474,029,000   630,916
> > > Te1/1/0 622,154,000   244,056  3,181,689,000   338,190
> > > Te1/2/0 711,493,000   253,275  3,211,560,000   340,950
> > > Te1/3/0   1,218,873,000   437,195  4,831,708,000   568,488
> > >
> > > TOTAL20,392,380,000 3,262,494 20,395,795,000 3,260,873
> > >
> > > I'm seeing throughput issues on a portchannel consisting of Te0/0/0
> > > and
> > > Te0/3/0
> > > (it won't go over 10Gbps aggregate)
> > >
> > > Cisco TAC are telling me if I add TxBps and RxBps totals together, I
> > > get 40Gbps, so I've reached capacity of the QFP (i.e. ESP40).
> > >
> > > My arguement against this is that a packet which enters the router
> > > on Te0/0/0, goes through the SIP40 in slot 0, through the ESP40,
> > > through the SIP40 in slot 1, and out through Te1/0/0 is still just
> > > one packet, so should only need to be counted once through the ESP,
> > > and once for each SIP. Hence, the throughput on the ESP is only
> > > 20.3Gbps on those numbers above.
> > >
> > > If I poll ceqfpUtilProcessingLoad by SNMP, I see peaks of around
> > > 65%, which would correlate with this level of throughput.
> > >
> > > I'm assuming there are others of you using this platform. What sort
> > > of throughput are you seeing? Am I right, or is the Cisco TAC engineer?
> > >
> > > TIA,
> > >
> > > Simon
> > > ___
> > > cisco-nsp 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 IOS 15.4(2)T unified mpls send-label

[Vitkovský Adam]

Hi Tim,

Labels allocated by BGP for loopback IP of PE in a remote area are not 
dependent on labels allocated by LDP for a next-hop IP(ABR loopback IP) on a 
path to that remote PE.
So if this remote PE’s loopback IP is actually an IPv6 address and BGP would 
allocate a label for it the forwarding would have worked up from ingress PE 
through local ABR until the packet hits the ABR in remote area where the BGP 
label would have been POP-ed and the packet is expected to be switched based on 
the remaining LDP label.
And since LDP does not allocate labels for IPv6 prefixes the packet would not 
be label-switched to the egress PE.

adam

From: Tim Durack [mailto:tdur...@gmail.com]
Sent: Tuesday, September 30, 2014 2:25 PM
To: Vitkovský Adam
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Cisco IOS 15.4(2)T unified mpls send-label

Thanks for the response. The missing piece for me was understanding that 
send-label depends on labels allocated by ldp(v4).

On Tue, Sep 30, 2014 at 4:31 AM, Vitkovský Adam 
mailto:adam.vitkov...@swan.sk>> wrote:
> I would like to enable send-label on ipv6 bgp neighbors, and move vpnv6
> over to ipv6.

Even though you'd be able to advertise PE loopbacks along with their labels via 
ipv6 bgp transport sessions.
These PE loopbacks still needs to be IPv4 addresses so that LDP can allocate 
labels for them within the particular area.
So you would not be able to move VPNv6 to IPv6 anyways.

adam
> -Original Message-
> From: cisco-nsp 
> [mailto:cisco-nsp-boun...@puck.nether.net<mailto:cisco-nsp-boun...@puck.nether.net>]
>  On Behalf Of
> Tim Durack
> Sent: Friday, September 26, 2014 8:31 PM
> To: cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> Subject: [c-nsp] Cisco IOS 15.4(2)T unified mpls send-label
>
> I am lab testing "unified mpls" using bgp send-label. This is working well for
> ipv4/vpnv4/vpnv6.
>
> I would like to enable send-label on ipv6 bgp neighbors, and move vpnv6
> over to ipv6.
>
> Doesn't look like send-label is a supported feature in 15.4(2)T1 for ipv6 bgp
> neighbors unless I am missing something.
>
> Anyone else run into this?
>
> --
> Tim:>
> ___
> cisco-nsp mailing list  
> cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



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

Re: [c-nsp] Peer pointing default route to us

[Vitkovský Adam]

Hi Gert, 

> From: Gert Doering [mailto:g...@greenie.muc.de]
> Sent: Tuesday, September 30, 2014 1:39 PM
> > It is really easy.
> > Just check the routes you advertise via BGP to your upstreams and create
> filters based on the outputs.
> > Apply the filters in the out direction.
> > If someone starts to complain they are definitely doing something fishy.
> 
> This is actually pretty poor advice if you have downstream BGP that
> frequently (for whatever reasons) changes the prefix set they announce to
> you.

Of course there are corner cases and this should not be performed during busy 
hours. 
Also customers as well as network OPS should be informed in advance what to 
look for if things break. 

> 
> BCP38 should be applied on ingress to your network (so you can see *who*
> is sending you garbage), not on egress - and for BGP customers, it should not
> be done by "looking at routes" but be integrated into the tool set that
> updates your BGP ingress filters to update the ingress ACL right away.
> 
Agreed, it is an ideal solution.  
Though it's not so appealing for a busy network engineer that needs to deal 
with the problem asap. 
Anyways so the above is how you guys have implemented the BCP 38 network wide 
right? 


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/

Re: [c-nsp] Peer pointing default route to us

[Vitkovský Adam]

Hi Lukas,


> -Original Message-
> From: Lukas Tribus [mailto:luky...@hotmail.com]
> Sent: Tuesday, September 30, 2014 10:49 AM
> To: Vitkovský Adam; cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] Peer pointing default route to us
> 
> Hi,
> 
> 
> > But most importantly.
> > Even though the above is not implemented they should not be able to
> > exit your network via your upstream or peering links if you have the
> > BCP 38 filtering implemented.
> 
> BCP 38 is about ingress filtering on customer links, not egress filtering on
> peers/upstream links, or am I missing something? 
Yes ideally. 



> > Would you please consider implementing filters on your upstream links
> > to only allow prefixes that you actually advertise to your upstreams
> > to exit your network?
> >
> > It is really easy.
> > Just check the routes you advertise via BGP to your upstreams and
> > create filters based on the outputs.
> > Apply the filters in the out direction.
> 
> Are you talking about static ACLs matching source IPs and applying it in the
> egress direction on peers/upstreams?
> 
> I don't see how that is supposed to scale.
It depends on the network scale. If you are advertising 10k+ prefixes it might 
be cumbersome. 


> BCP38 (ingress filtering) sure, but egress filtering will just break your
> network, imho.
How? 

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/

Re: [c-nsp] Cisco IOS 15.4(2)T unified mpls send-label

[Vitkovský Adam]

> I would like to enable send-label on ipv6 bgp neighbors, and move vpnv6
> over to ipv6. 

Even though you'd be able to advertise PE loopbacks along with their labels via 
ipv6 bgp transport sessions. 
These PE loopbacks still needs to be IPv4 addresses so that LDP can allocate 
labels for them within the particular area. 
So you would not be able to move VPNv6 to IPv6 anyways. 

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Tim Durack
> Sent: Friday, September 26, 2014 8:31 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Cisco IOS 15.4(2)T unified mpls send-label
> 
> I am lab testing "unified mpls" using bgp send-label. This is working well for
> ipv4/vpnv4/vpnv6.
> 
> I would like to enable send-label on ipv6 bgp neighbors, and move vpnv6
> over to ipv6.
> 
> Doesn't look like send-label is a supported feature in 15.4(2)T1 for ipv6 bgp
> neighbors unless I am missing something.
> 
> Anyone else run into this?
> 
> --
> Tim:>
> ___
> cisco-nsp 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] Peer pointing default route to us

[Vitkovský Adam]

As Saku and Mark mentioned already peering boxes should not have a default 
route or full BGP table. 
You could either use a dedicated box or a vrf that carries only customer 
prefixes.  

But most importantly. 
Even though the above is not implemented they should not be able to exit your 
network via your upstream or peering links if you have the BCP 38 filtering 
implemented. 
Would you please consider implementing filters on your upstream links to only 
allow prefixes that you actually advertise to your upstreams to exit your 
network? 

It is really easy. 
Just check the routes you advertise via BGP to your upstreams and create 
filters based on the outputs. 
Apply the filters in the out direction. 
If someone starts to complain they are definitely doing something fishy. 


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> redscorpion69
> Sent: Monday, September 29, 2014 3:12 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Peer pointing default route to us
> 
> This is not Cisco-centric question, but maybe you could help me out.
> 
> What is the best way to filter traffic comming in from one of our peers and
> going upstream. Basically we see the peer is sending traffic to IPs we're not
> announcing to them. They may very well have a default route pointing to us
> as well.
> 
> Not going into fact that this is breaking peering policy rules, is there a
> dynamic way to filter this on (Juniper/Cisco) ?
> 
> Regards
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] Traffic engineering in mixed OSPF/iBGP environment

[Vitkovský Adam]

Hi Garry,

Seems you are struggling with the Type-1 vs Type-3 LSAs problem that we dealt 
with on the list a few weeks back. 

Consider the below from a view point of CoreR1. 

It's because intra-area LSAs are preferred compared to inter-area LSAs. 
The super-backbone(MP-BGP->OSPF) introduces LSAs from the remote site as Type-3 
into the LSDB of a local PE and if the local PE happens to have a Type-1 LSA 
from a directly connected link than that one is preferred (even though it has a 
higher metric). So you can either make both LSAs to appear as Type-1 using 
sham-link or you can make both to be type-3 using different areas on each site. 

 
adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Garry
> Sent: Tuesday, September 23, 2014 12:37 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Traffic engineering in mixed OSPF/iBGP environment
> 
> Hi,
> 
> I've been trying to figure this out for a while now, but can't get a grasp on
> how to get this to work the way I want to ...
> 
> In essence, here's the relevant part as a small drawing:
> 
> CPR1--CPR2
>  | |
> PER1 VSwitch
>  | |\
> PR1| \
>  : |  CPR3..CPR6
> PRn|
>\   /\___DSLGW-CPR7..CPR12
> \ /
>  CoreR1---CustomerFW--Internet
> 
> 
> We have a customer network with a redundant connectivity, running as a
> distinct MPLS VRF in our backbone. Both links are terminated with a separate
> router (CPR1 & 2). Link 1 at CPR2 goes to a virtual WAN switch with additional
> sites as well as a link to our backbone (CoreR1). We have OSPF running in that
> broadcast domain, as well as between the two
> CPR1/2 routers, distributing the different subnets that are reachable.
> Link 2 between CPR1 and PER1 is also running OSPF, though in the MPLS
> backbone, routes from the VRFs are learned through a route reflector;
> PER1 redistributes the RR routes to CPR1 via OSPF.
> Additionally, there are some DSL locations which are also terminated through
> another router at the CoreR1 location. Again, locally the routes are learned
> through OSPF and redistributed to the BGP RR.
> 
> At this point, all routing and redundancy is working fine. If links go down,
> routing is recalculated and converges in satisfactory time.
> 
> As for the problem I have: the customer is running applications at a service
> provider that is connected to the network via CPR3. Traffic from
> CPR1/CPR2 as well as the other customer locations correctly take the route
> through the VSwitch. Now, traffic to the Internet (in essence everything that
> is not a connected destination inside the VRF but the default route) from
> CPR1/CPR2 is supposed to be routed via the PER1...
> connection, utilizing the otherwise unused backup link. This is where I'm
> having trouble. If the whole network were running on OSPF, putting a higher
> OSPF cost on the CoreR1 towards the VSwitch link would more or less ensure
> that the link would only be used as a backup, otherwise CPR1 has PER1 as
> lower cost towards the CustomerFW, while the traffic to CPR3 is still cheaper
> towards the VSwitch. But with the BGP-redistributed routes at the PER1-
> CPR1 link, the OSPF cost metrics do not help. I've already tried messing
> around with the redistribute statements a bit, but even with altering the
> BGP-learned routes to be imported to OSPF as E2 routes, the routing still
> kept the vswitch routing up. I'm somewhat out of ideas on how to
> implement this while still keeping redundancies operational (with either
> traffic able to be routed via either link) and not using error-prone hacks ...
> any pointers?
> 
> Thanks, -garry
> 
> 
> 
> ___
> cisco-nsp 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] next-hop-self under address-family vpnv4 also?

[Vitkovský Adam]

Next-hop-self is enabled automatically under vpnvX AF. 

If the code supports it I'd recommend:

address-family vpnv4
  bgp advertise-best-external  <-- enables best-external + pic(if supported). 
  no bgp recursion host <--disables recursive lookup for BGP NHs. 
  bgp nexthop route-map BGP_NHT <--specifies which prefixes qualify as BGP NHs. 
  bgp nexthop trigger delay 0 <--allows BGP to act on IGP events 
immediately(enable if FRR backup is available for the BGP NH). 

route-map BGP_NHT permit 10 
 match ip address prefix-list PE_LOOPBACKS
 match source-protocol "igp" <--if you are using hierarchical MPLS you need to 
add BGP there as well.
route-map BGP_NHT permit 20
 match source-protocol connected


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> CiscoNSP List
> Sent: Friday, September 19, 2014 3:32 AM
> To: Will Tardy; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] next-hop-self under address-family vpnv4 also?
> 
> Cheers.
> 
> Any other "tweaks" to default config you recommend?  i.e. timers etc?
> 
> 
> > From: will.ta...@vocus.com.au
> > To: cisco-nsp@puck.nether.net
> > Date: Fri, 19 Sep 2014 00:42:23 +
> > Subject: Re: [c-nsp] next-hop-self under address-family vpnv4 also?
> >
> > It¹s not needed.
> >
> >
> > "address-family vpnv4" section is used to define which routers
> > participate in the VPNv4.  The underlying MPLS network will forward
> > labels between the
> > VPNv4 end-point CE's. Next-hop-self isn¹t required. All that¹s
> > required is MPLS and IGP reachability between the CE¹s participating
> > in the vpnv4 domain.
> >
> > On 19/09/2014 10:31 am, "CiscoNSP List" 
> wrote:
> >
> > >Is it recommended to add it under vpnv4 also?
> > >
> > >i.e.
> > >
> > >router bgp xx
> > >...
> > >neighbor iBGP-IPv4-PEERS update-source Loopback0 neighbor
> > >iBGP-IPv4-PEERS next-hop-self neighbor xxx.xxx.xxx.xxx peer-group
> > >iBGP-IPv4-PEERS...
> > >address-family vpnv4
> > >  bgp redistribute-internal
> > >  neighbor  iBGP-IPv4-PEERS send-community extended
> > >  neighbor iBGP-IPv4-PEERS next-hop-self
> > >  neighbor xxx.xxx.xxx.xxx activate
> > >
> > >Cheers.
> > >
> > >
> > >
> > >___
> > >cisco-nsp mailing list  cisco-nsp@puck.nether.net
> > >https://puck.nether.net/mailman/listinfo/cisco-nsp
> > >archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> >
> > ___
> > cisco-nsp mailing list  cisco-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> ___
> cisco-nsp 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] E1 via pseudowire on me3600x-cx

[Vitkovský Adam]

Hi folks,

Is anyone running E1 successfully via me3600x-cx mpls pseudowire?
The PW comes up no problems but the E1 tester still shows error seconds.
Not sure if it's clocking related or what might be causing the errors.

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/

Re: [c-nsp] I-BGP/IGP question

[Vitkovský Adam]

> Spyros Kakaroukas
> Sent: Tuesday, September 16, 2014 8:48 AM
> Lately, there have been a few designs that offer extreme scalability, based
> on rfc3107 ( bgp-lu ) , but I've yet to hear of anyone actually implementing
> them . 

Actually rfc3107 is really old and is usually used by folks who use Inter-AS 
MPLS Opt-C to keep/scale IGP per AS. 
Lately it was somehow re-invented (introduced to larger audience) by RAN folks 
to scale IGPs when MPLS is used all the way throughout the RAN. 

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/

Re: [c-nsp] ME3600 - SVI's + Service Instances

[Vitkovský Adam]

There's some performance degradation when using BDI instead of sub-interfaces

adam

From: CiscoNSP List [mailto:cisconsp_l...@hotmail.com]
Sent: Tuesday, September 16, 2014 1:19 AM
To: b.turn...@twt.it; Vitkovský Adam; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] ME3600 - SVI's + Service Instances


Thanks Brian - re service instances on the ASR, are there any negatives in 
doing this (As opposed to standard dot1q subints).


I will certainly be reading the config Guide, and will watch Waris's 
presentation  - Cheers.



> Subject: RE: [c-nsp] ME3600 - SVI's + Service Instances
> Date: Mon, 15 Sep 2014 18:34:26 +0200
> From: b.turn...@twt.it<mailto:b.turn...@twt.it>
> To: cisconsp_l...@hotmail.com<mailto:cisconsp_l...@hotmail.com>; 
> adam.vitkov...@swan.sk<mailto:adam.vitkov...@swan.sk>; 
> cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
>
> Hi,
>
> I suggest you read the configuration Guide and there is a really good 
> presentation from Waris at the cisco live site on the me series..
> http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-4_2_S/configuration/guide/3800x3600xscg/swevc.html
>
> Yes under the physical interface you will have the service instances that 
> match your vlans and get placed into a bridge domain .
> You can then place it in an svi to terminate ip o to another instance for l2 
> so you can use a service instance on the port towards your asr as well.
> The rewrite ingress tag removes/adds one vlan tag on the port so you may not 
> need that going back twords the asr1000 if you want to maintain the same 
> vlan, or can use it to map to another vlan.
> For the ASR you can check out service instances there as well or stay with 
> sub int depending on what you need to do.
>
>
> Regards
>
> Brian
>
> > -Original Message-
> > From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> > CiscoNSP List
> > Sent: lunedì 15 settembre 2014 01:46
> > To: Vitkovský Adam; 
> > cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> > Subject: Re: [c-nsp] ME3600 - SVI's + Service Instances
> >
> > Thanks very much Adam! - Much appreciated.
> >
> > So each service instance goes "under" the physical Interface where we
> > expect that vlan to be presented? And bridge-domain (100) associates it with
> > vlan100? So on this phyiscal Int, we will have 100+ service instances under
> > it?(I wont have access to an ME to test until later this afternoon).
> >
> > We will be doing IPTransit + Peering to customers on the ASR1001's, and one
> > IPTransit provider hands off the IPTransit service on there AGG's (That
> > connect to the 4948's) as a vlan - Therefore, we need to get that vlan up to
> > the ASR1001's(As we receive full tables) - Would the trunk port connecting 
> > to
> > the ASR -> ME3600 be configured in a similar way to how you have described
> > below on the ME? And on the ASR, can we continue to just use a physical
> > port, which dot1Q subints? (Note we will also be running a p-t-p connection
> > between the ASR1001 +ME and running MPLS+iBGP+OSPF).I was going to
> > use a dedicated port(s) for this(As each POP will have 2 x ASR1001's and 2 x
> > ME3600's) connected via a mesh.
> >
> > Thanks again for your help
> >
> >
> > > From: adam.vitkov...@swan.sk<mailto:adam.vitkov...@swan.sk>
> > > To: cisconsp_l...@hotmail.com<mailto:cisconsp_l...@hotmail.com>; 
> > > cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> > > Subject: RE: [c-nsp] ME3600 - SVI's + Service Instances
> > > Date: Sun, 14 Sep 2014 14:59:53 +
> > >
> > > Hi,
> > >
> > > I'd use the service instances as it's more convenient.
> > >
> > > interface GigabitEthernet0/3
> > > description dot1q trunk to agg 4948
> > > switchport trunk allowed vlan none <--no vlans are accepted except those
> > specified under service instances.
> > > switchport mode trunk
> > > dampening
> > > mtu 9100
> > > load-interval 30
> > > !
> > > service instance 100 ethernet
> > > description agg-circuit-to-end-customer-100
> > > encapsulation dot1q 100 <--frames with topmost tag 100 will be accepted
> > by this service instance and the bridge domain specified below.
> > > rewrite ingress tag pop 1 symmetric <--vlan interface will accept only
> > untagged frames.
> > > service-policy input customer-100_in <--service policies are attached
>

Re: [c-nsp] ME3600 - SVI's + Service Instances

[Vitkovský Adam]

Hi,

I'd use the service instances as it's more convenient. 

interface GigabitEthernet0/3
 description dot1q trunk to agg 4948
 switchport trunk allowed vlan none <--no vlans are accepted except those 
specified under service instances. 
 switchport mode trunk
 dampening
 mtu 9100
 load-interval 30
!
 service instance 100 ethernet
  description agg-circuit-to-end-customer-100
  encapsulation dot1q 100 <--frames with topmost tag 100 will be accepted by 
this service instance and the bridge domain specified below.  
  rewrite ingress tag pop 1 symmetric   <--vlan interface will accept only 
untagged frames. 
  service-policy input customer-100_in <--service policies are attached under 
the service instance rather than vlan int. 
  service-policy output customer-100_out
  bridge-domain 100 <--this will associate the service instance with a BD 100 
and vlan interface 100. 

interface Vlan100
 description agg-circuit-to-end-customer-100
 bandwidth 1
 vrf forwarding customer-100
 ip address 100.1.1.1 255.255.255.252
no ip proxy-arp


adam

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> CiscoNSP List
> Sent: Sunday, September 14, 2014 3:31 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ME3600 - SVI's + Service Instances
> 
> Hi Everyone,
> 
> Very new to the ME3600 platform, so hoping someone can assist with the
> following:
> 
> We currently have 4948's connecting to various carriers - Each port is a 
> trunk,
> and has a vlan per tail.
> i.e.
> 
> int gig1/1
> desc AGG_TO_CARRIER_A
> switchport trunk encapsulation dot1q
> switchport mode trunk
> switchport trunk allowed vlan 10,20,30
> 
> We then have another port on the 4948's (Trunk), that allows all vlans from 
> all
> the carrier AGG ports that connects to 7200's or ASR1000's (We have multiple
> POP's), and each vlan is then added to dot1q subint and thrown into a vrf or
> standard "Inet" Interfacewe also apply service-policys (egress
> shaping/ingress marking) on the L3 Interfaces
> 
> We are wanting to run MPLS on the ME3600s, and do all the L3 stuff on them
> rather than the 7200'sand ASR's - So, we will still have the 4948's, multiple
> carrier AGG's, multiple vlans's but the trunk port(From the 4948s) that
> currently goes to the 7200's and ASR's will now go to the ME3600s - So, a few
> questions:
> 
> 1. What would the ME3600 Trunk port(That connects back to the 4948) config
> look like?  i.e. Similar to how we currently do it (switchport trunk allowed 
> vlan
> 10,20.30,40...), and then create SVI's for each vlan and apply L3/VRF/service
> policies? Or do SVI's not support service policies and we would need to use
> service instances? (The 4948's typically have ~100+ vlans(tails) from the
> various carrriers)
> 
> 2. If service instances are required, can anyone please provide an example of
> how the config would look (Or point me to some documentation please?)
> 
> Thanks in advance for your help.
> 
> 
> 
> ___
> cisco-nsp 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] ASR1001 and ME3600X licensing

[Vitkovský Adam]

Hi,

If you ordered it as such the licenses should be preinstalled at least that's 
my experience. 
If not you'd have to use the PAK # and serial # to obtain the license file from 
Cisco then copy it to the device and install it yourself. 
And yes you can check with sh lic blah blah. 


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> CiscoNSP List
> Sent: Wednesday, September 10, 2014 8:25 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ASR1001 and ME3600X licensing
> 
> Hi Everyone,
> 
> We have purchased a number of the above devices and also purchased Adv
> IP(For all the ASR's) and Adv Metro IP for all the ME3600's - We were told a
> "paper license" was sent for the adv ip(For all ASR's and ME3600's), which we
> have been unable to locate...a week later of constant e-mails to disty/Cisco
> AM the disty is now stating that the "licenses" are already installed on all 
> the
> devices - I dont have physical access to the devices until tomorow, but do
> you need register the PAK for each device, and then install the license
> keyor would they have come "pre-installed"?  Once I have access to each
> device, would sh ver or sh licenses tell me if adv IP was "active"?
> 
> 
> I cant believe how difficult this has beenand how lacking in knowledge of
> the licensing both our Disty and Cisco AM have been.
> 
> Cheers.
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs

[Vitkovský Adam]

Hi Saku,

> Saku Ytti
> Sent: Tuesday, September 02, 2014 4:09 PM
> If I understood that correctly, you propose in OptC we verify the top label,
> we distributed it, so we should be able to verify it is one of ours.  
> However, I
> don't think this brings us any security? Because the 2nd label, may be
> another PE box, so attack is just going to have to take round-trip via one of
> the allowed egress PE boxes, before going to the target PE?
> 
> For OptB, I think verification should be stack is 1 label deep, and we've just
> ourselves advertised the label, so there should be no room for spoofing.
> 
I see now.
You are right this only works if the single label in the stack is the VPN label 
allocated by us. 
And the only profile that matches this is OptB. 

It would be great though if the local PE or ASBR could receive the VPN label 
that was advertised to the foreign CEs or PEs so that it could use it during 
the label-stack check. This way the PE or ASBR would be able to verify stack 
that is two labels deep. 

Some knob or AF in BGP that would tell the ASBR, hey we know you don't have any 
VPNs configured but just keep the VPN labels (for all  the Inter-AS prefixes) 
so that you can reference to them while doing label stack verification. 

This could also work for L2VPNs where BGP is used to advertise L2VPN label 
(EVPN) or PW label (standard L2VPN). 

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/

Re: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs

[Vitkovský Adam]

Hi Saku,

I see, as the Cisco mpls label sec checks only the top-most label we have to 
make sure the topmost label is indeed the VPN label which applies only to opt.B 
with direct link peering and explicit null sig. scenario and possibly it could 
work in Option C where the PE (acting as ASBR&Inter-AS-RR) BGP-peers with CE 
via a direct link so that there is just the VPN label in the label stack. 
Or am I getting it wrong? 

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Saku Ytti
> Sent: Saturday, August 30, 2014 11:09 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs
> 
> On (2014-08-29 22:43 +), Vitkovský Adam wrote:
> 
> Hi Adamn,
> 
> > I would recommend Option C + RFC3107.
> > That is couple of MP-eBGP sessions from CE to local RRs and RFC3107 to
> carry loopbacks and their particular labels between PEs and CEs (No LDP).
> > BGP sessions will be protected so that customer can not inject false
> prefixes or labels should the CE be replaced by a rouge device.
> 
> Customer can inject labels to wire to reach arbitrary customer. As labels are
> not allocated random, it's quite easy, then you can inject traffic to 
> customer,
> but not receive anything from customer. But some other attack vector could
> be used to compromise that direction, such as if provider offers bgp flowspec
> and is not careful, you could use flowspec to ask diversion of packets to your
> VRF (And bridge them back via your OptC hack for transparent
> sniffing)
> 
> How likely this is, is of course very debatable. But if your main product is
> L3 MPLS VPN, might be good idea to keep exposure to minimum.
> OptB with label checking reduces risk to 'shared' customer, so customer can
> hop between /their/ vrfs, but that is fine, because they can do it anyhow by
> moving LAN ports.
> 
> --
>   ++ytti
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-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 to Customer (Option B) / Multiple VRFs on CPEs

[Vitkovský Adam]

Hi James,

I would recommend Option C + RFC3107. 
That is couple of MP-eBGP sessions from CE to local RRs and RFC3107 to carry 
loopbacks and their particular labels between PEs and CEs (No LDP). 
BGP sessions will be protected so that customer can not inject false prefixes 
or labels should the CE be replaced by a rouge device. 
  

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> James Bensley
> Sent: Tuesday, August 26, 2014 10:56 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs
> 
> Hi All,
> 
> I know this has been discussed before (more on the NANOG list) but what
> are people doing regarding MPLS down to the CPE?
> 
> Even though we own our CPEs and customers typically don't have access to
> them (or perhaps restricted show commands) it is a security concern that
> customers can send labelled packets back into the network if we enable
> MPLS on the CE facing interface on our PE. There is also the concern of route
> injection but I believe that risk can be removed by enabling MD5 on BGP and
> LDP sessions between CE and PE.
> 
> (i) My first idea was uRPF, on the 12000 routers it seems that uRFP can
> inspect MPLS;
> 
> From :
> http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/srpf_gsr.h
> tml
> "All Layer 2 encapsulation and transport types are supported, including ATM
> AAL5, ATM cell relay, Ethernet (VLAN and port modes), Frame Relay, HDLC,
> and PPP over MPLS; for more information, refer to Any Transport over
> MPLS."
> ...
> "Although the Unicast RPF in Strict Mode feature filters only IPv4 packets in
> IP or MPLS traffic, you can configure IOS software features that manage
> other traffic on the same interface, such as IP forwarding, MPLS features,
> Frame Relay switching, ATM switching, and Any Transport over ATM (AToM)
> connections. However, Unicast RPF filtering is only applied to incoming 
> traffic
> on IP routing interfaces and not on packets processed by Frame Relay or
> ATM switching or transmitted over AToM pseudowire commendations."
> 
> We aren't using 12000 though; At the access layer we're using
> ME3600/ME3800/6500/7600/ASR1K and we're looking at 6880-X to remove
> the smaller access layer 6504/6505/7604/7607 type chassis. I can't find any
> indication that any of those can support MPLS in uRPF so I think that idea is
> useless unless someone else can show me some contradictory information?
> 
> (ii) My second idea was label value range restrictions
> 
> Since the average CPE may have 3-5 VRFs on it with say 10 routes in each we
> could perhaps fiddle with the label allocation rules by setting 1000-1999 to 
> be
> the usable range at PoP A, and 2000-2999 at PoP B and so on. We can restrict
> the routes that enter the LFIB at the PEs and which ones get labels allocated
> to them. Techniques like this reduce the surface area of potential attack and
> make it difficult to send in packets with a valid label (or label stack) but 
> they
> seem more like security through obscurity to me.
> 
> (iii) Additional options...
> 
> I'm all ears! Is anyone running MPLS to the customer rather than multiple
> option A perings to each CPE? When we do large roll outs of
> 1000 CPEs with each CPE having a minimum of 3 and maximum of ~10 VRFs
> we end up having thousands of peerings. MPLS to the customer really would
> be a lot simpler for config generation, automation, monitoring etc (also when
> we want PWE3/AToM) between two CPEs at different sites).
> 
> 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] CRS PRP management eth interface limits

[Vitkovský Adam]

Hello Valeriu,

So increasing the global per flow limits did not help? 
I'm pretty sure management ports are protected by the LPTS as well. 
There just doesn't seem to be any way of altering or viewing the default 
limits. 
 
adam
> -Original Message-
> From: Valeriu Vraciu [mailto:vvra...@iasi.roedu.net]
> Sent: Friday, August 29, 2014 9:06 AM
> To: Vitkovský Adam; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] CRS PRP management eth interface limits
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello Adam, all
> 
> On 12/08/14 17:39, Vitkovský Adam wrote:
> > Hello Valeriu,
> >
> > I think that even for Management Ethernet ports - these limits are
> > controlled by the LPTS process.
> >
> > However on ASR9k I'm not able to view or change the policers for the
> > Managemet Ethernet ports (Route Switch Procesor location)
> >
> > You can try to check yours with: "sh lpts pifib hardware police
> > location" -look for PRP CPU And you try to change them with: " lpts
> > pifib hardware police location" -look for PRP CPU
> >
> > Or alternatively you can try setting the limits globally per flow:
> > "lpts pifib hardware police flow icmp" and maybe it'll get applied to
> > the PRP as well.
> >
> 
> Thank you for ideas.
> I did not find any clue with lpts related to management Ethernet ports,
> but:
> 
> Related to resulted traffic on 100G circuit, 2 stupid mistakes of mine:
> - - although I used 2 machines with different OS-es, I did not check the
> default IP TTL used, it was 64 on both of them (Linux and MacOS)
> - - did not estimate in advance how much traffic should be on 100G interface
> as result of the routing loop.
> After increasing default TTL to 255 traffic on 100G interface jumped to ~60
> Gbps.
> So my goal is accomplished, but I am still digging about the limits on
> management interface.
> 
> Regards,
> valeriu.
> 
> > adam
> >> -Original Message- From: cisco-nsp
> >> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Valeriu
> >> Vraciu Sent: Tuesday, August 12, 2014 1:47 PM To:
> >> cisco-nsp@puck.nether.net Subject: [c-nsp] CRS PRP management eth
> >> interface limits
> >>
> > Hello,
> >
> > Are there any limitations (rate limits) for traffic, applied to
> > management Ethernet interface of a CRS3 PRP (Performance Route
> > Processor) ? Temporarily changing those limits, if possible, would be
> > great for our experiment. I was not able to find related information
> > while searching (Cisco, Google), so any hint is appreciated.
> >
> > What I try to achieve is to fill a 100 Gbps circuit between 2 CRSs for
> > 50% or more. Using MGEN on a laptop with gigabit eth and a routing
> > loop this probably can be done. The problem is that each of the 2
> > routers has at this moment only 100G interfaces, so the only way to
> > inject traffic is through management eth. What happens is that the
> > traffic on this interface does not exceed the following values (bps
> > and pkts/s), no matter how much I increase MGEN parameters above
> 4
> > UDP pkts/s (each packet 1460 bytes):
> >
> > input:  480634000 bps, 4 pkts/s output:88 bps,  1000
> > pkts/s (these are merely ICMP unreachables)
> >
> >
> > MGEN was run like this:
> >
> > mgen event "ON 1 UDP DST 192.168.255.1/5000 PERIODIC [PKTS 1460]"
> >
> > where PKTS was 10K, 20K, 40K, 60K and 80K. Traffic on 100G link was
> > growing until it reached and remained at about 15 Gbps for 40K and
> > above. Achieved maximum traffic was 30 Gbps (15 Gbps for each PRP eth
> > interface, 2 x PRP on each router).
> >
> >
> > 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/
> 
> - --
> Valeriu Vraciu
> RoEduNet Iasi
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> 
> iEYEARECAAYFAlQAJm4ACgkQncI+CatY948c5wCfbechxYFY1ae23Arkk9yPUn7
> A
> 7SsAn04EJVWGFxf/jHCWIcEfglIfvlqq
> =h/GV
> -END PGP SIGNATURE-

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

Re: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs

[Vitkovský Adam]

> Yeah I new the ASR9K could fo it but nothing smaller I know of. Yes our
> ME3x00's are happy to QoS to one label although I was thinking of MPLS
> down to CPE with AToM L2VPNs so a 2nd label is required; perhaps a method
> of copying the EXP from the bottom label to the top label so it can become
> subject to QoS would be useful. 

Well you could do L2TPv3 for L2 services between CEs. 
During the imposition all labels in the label stack gain the same label. 

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/

Re: [c-nsp] Remote LFA Deployments on ASR9K/ME3600X/ME3800X/ASR903

[Vitkovský Adam]

Hi Waris,

We are using rLFA on ASR9k and ME3600. 
On ASR9k there are no issues so far. 
On ME3600 well you know the story but with the latest fixes we should finally 
have BFD error free code. 

The rLFA feature is priceless indeed we gained 100% coverage across all our 
ring topologies. 
The switchover on DF link failures is instant so one is only limited by the 
speed of BFD on other types of links. 
Unfortunately minimum hello interval on me3600 is 50ms so can't get sub 50ms 
convergence there. 

I had rLFA on ASR903 only in lab environment and did not spot any issues.


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Waris Sagheer (waris)
> Sent: Wednesday, August 27, 2014 8:07 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Remote LFA Deployments on
> ASR9K/ME3600X/ME3800X/ASR903
> 
> Hi Folks,
> Can you please share your feedback on Remote LFA on ASR9K, ME3600X,
> ME3800X and ASR903? How many of you are using this feature and what's
> your feedback?
> Any challenges?
> We have also started shipping ASR920 which is the evolution of ME3400E and
> ASR903 RSP2. Both the new platforms are supporting Remote LFA.
> Thank you.
> 
> Best Regards,
> 
> [http://www.cisco.com/web/europe/images/email/signature/horizontal06.j
> pg]
> 
> Waris Sagheer
> Technical Marketing Manager
> Service Provider Access Group (SPAG)
> wa...@cisco.com
> Phone: +1 408 853 6682
> Mobile: +1 408 835 1389
> 
> CCIE - 19901
> 
> 
> 
> 
> 
> 
> This email may contain confidential and privileged material for the sole use 
> of
> the intended recipient. Any review, use, distribution or disclosure by others
> is strictly prohibited. If you are not the intended recipient (or authorized 
> to
> receive for the recipient), please contact the sender by reply email and
> delete all copies of this message.
> 
> For corporate legal information go
> to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] Remote LFA Deployments on ASR9K/ME3600X/ME3800X/ASR903

[Vitkovský Adam]

> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Nick Hilliard
> Sent: Wednesday, August 27, 2014 6:45 PM
> Specifically remote LFA or just LFA?  I got hit earlier today with
> CSCui74304: Remote MPLS ping fails in LFA when SVI is one of the core
> interfaces.  Are there plans to fix this?
> 

A while back we experienced several occurrences of an issue on me3600 where all 
transit traffic got dropped (traffic originated/terminated on the box itself 
worked) when VLAN interface was primary link and newly configured physical 
interface was computed as a backup. As soon as the physical interface was 
disabled the traffic was restored. 
Since then we are not using VLAN interfaces anywhere in the core. 

Not sure whether this was LFA or rLFA related. I'd say this was just pure LFA. 

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/

Re: [c-nsp] ME3600 BFD flapping

[Vitkovský Adam]

Well that applies only to me3600x-cx as only those have BFD hardware offload 
for async mode

adam

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> James Bensley
> Sent: Wednesday, August 27, 2014 10:09 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] ME3600 BFD flapping
> 
> On 27 August 2014 08:44, Vitkovský Adam 
> wrote:
> > Hi Jure,
> >
> > 35 is a lot of BFD sessions and on ME3600X BFD is handled by CPU.
> 
> 
> Not if "no echo" is supported on the BFD interface;
> 
> http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/s
> oftware/release/15-
> 2_2_S/chassis/configuration/guide/3600x_24cxscg/swbfd.html
> 
> 
> 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] ME3600 BFD flapping

[Vitkovský Adam]

Hi Jure,

35 is a lot of BFD sessions and on ME3600X BFD is handled by CPU.

You can check the CPU queues BFD uses queue 1: 
Take these two or three times in a row: 
show platform aspdma all_counters 0 
or 
show platform aspdma all_counters 1 
and 
show platform qos policer cpu 1 0 

Then you can check for BGD drops: 
show bfd drops 

Or you can check if there are some interface discard counters incrementing:
show interfaces counters errors


Oh and in order to take the above cmds you might need to enable service internal
conf t
 service internal
exit


adam

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> jure brkljacic
> Sent: Tuesday, August 26, 2014 1:50 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ME3600 BFD flapping
> 
> Hi,
> 
> We have a huge problems with BFD flapping on ME3600.It`s random event on
> two 3600 connected to the "same" end system.
> 
> a.) First we thought that interface output drops causing BFD flapping.Than
> we configure a
>  a output queue policy to eliminate interface output drops. BFD flapping
> still there :(
> 
> Code running:me360x-universalk9-mz.153-3.S3
> Number of BFD sessions: ~35
> timers:150 multiplier 3
> CPU:~10%
> 
> Any help will be greatly appreciated.
> ___
> cisco-nsp 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] MTU on XR

[Vitkovský Adam]

Yeah it's very confusing.  
Personally I don't trust the auto adjustment as it doesn't always work out as 
expected. 
So I hardcode the MTU on sub-interfaces(L2 and L3) based on the number of tags. 

Also my experience is that on the (l2transport) interfaces the Pseudowire MTU 
is adjusted automatically based on the tag rewrite operation performed so on 
the remote(IOS) end of the PW you need to adjust the interface MTU based on the 
XR interface MTU - L2 overhead and + or - the number of push-ed or pop-ed tags 
respectfully. 


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Mikael Abrahamsson
> Sent: Monday, August 25, 2014 1:36 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] MTU on XR
> 
> 
> Hello.
> 
> http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-
> software/116350-trouble-ios-xr-mtu-00.html
> 
> What I can check personally with machines I have available, the above article
> is correct in saying that vlan tags does not count when it comes to 
> configuring
> MTU. XR will automatically add number of vlan tags when programming MTU
> to the hardware, no care has to be taken to configuring it, at least not for 
> L3
> interfaces.
> 
> On an interface with MTU 9200 on the main interface, the subinterface has
> this:
> 
> #show im database interface Te0/3/0/0.101 Interface TenGigE0/3/0/0.101,
> ifh 0x06001340 (up, 9204)
>Interface flags:  0x00800597 (ROOT_IS_HW|IFINDEX
> 
> |SUP_NAMED_SUB|BROADCAST|CONFIG|VIS|DATA|CONTROL)
>Encapsulation:dot1q
>Interface type:   IFT_VLAN_SUBIF
>Control parent:   TenGigE0/3/0/0
>Data parent:  TenGigE0/3/0/0
>Views:GDP|LDP|L3P|OWN
> 
>ProtocolCaps (state, mtu)
>-
>Nonevlan_jump (up, 9204)
>Nonedot1q (up, 9204)
>ipv6ipv6_preswitch (up, 9186)
>ipv6ipv6 (up, 9186)
> 
> so this single tagged subinterface has automatically had its MTU raised to
> 9204 to accomodate the vlan tag, even though config says 9200. The IPv6
> MTU ends up being 9186.
> 
> This for instance contradicts what AMSIX has written on this page:
> 
> https://ams-ix.net/technical/specifications-descriptions/config-guide
> 
> "5.7. MTU Config
> 
> On Cisco IOS, the interface IP MTU should be set to 1500. MTU configurations
> for IOS-XR include the Layer-2 headers, and need to be adjusted when using
> VLAN tags."
> 
> So which one is correct? I have talked to numerous people and they have
> different experience and results are contradicting.
> 
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
> ___
> cisco-nsp 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] ASR9k 4.3.4 vs 5.1.3

[Vitkovský Adam]

Hi folks, Jared, Nick,

I'm wondering what influenced your decision to go/risk it with 5.1.x rather 
than 4.3.4 ? 
Was it any must have feature, hardware support requirement or bug fixes or a 
bit of all please? 
I'm asking as personally I'm really afraid of the 5.x.x train and thus decided 
to go with 4.3.4 which is being evaluated currently. 
Thank you,

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/

Re: [c-nsp] ME3800: Error on delete SVI with MPLS enabled

[Vitkovský Adam]

Hi folks,

If you plan to implement network-wide IOS update I'd recommend to wait for 
15.3(3)S4 and hope for the best. 
I've got two major bugs fixed on the engineering release based on 15.3(3)S3 and 
one still pending to get fixed.

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> bleearg
> Sent: Thursday, August 21, 2014 3:58 PM
> To: 
> Subject: Re: [c-nsp] ME3800: Error on delete SVI with MPLS enabled
> 
> We have personally found that 15.3(3)S2 is very stable and fixes several bugs
> (not listed in the release notes) related to MPLS over SVI that are persistent
> in 15.3(3)S.
> 
> -evt
> 
> 
> On Thu, Aug 21, 2014 at 8:55 AM, Jason Lixfeld  wrote:
> 
> > Yikes, that was dumb.  Let me try that again.
> >
> > If you are running 15.3(3)S, try 15.3(3)S2 or above.  S2 is Cisco's
> > recommended point release.  S3 is not.
> >
> > Also, for all the hype about 15.4, I'd stay on 15.3.  With all the
> > problems with this code since ME3x00 FCS, I think that you're asking
> > for trouble if you expect 15.4 to somehow, magically be any more stable.
> > Especially so early on.
> >
> > My $0.02.
> >
> > Sent from my iPhone
> >
> > > On Aug 21, 2014, at 8:45 AM, Jason Lixfeld  wrote:
> > >
> > > 15.3(3)3S or 15.3(3)S2?  If former, try the latter or above.
> > >
> > > Sent from my iPhone
> > >
> > >>> On Aug 21, 2014, at 5:52 AM, James Bensley 
> > wrote:
> > >>>
> > >>> On 13 June 2014 09:39, James Bensley  wrote:
> > >>> Hi All,
> > >>>
> > >>> I had off-list contact, it seems to be CSCup00831.
> > >>>
> > >>> Cheers,
> > >>> James.
> > >>
> >  -Original Message-
> >  From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On
> >  Behalf
> > Of
> >  James Bensley
> >  Sent: Thursday, June 12, 2014 4:39 PM
> >  To: cisco-nsp@puck.nether.net
> >  Subject: [c-nsp] ME3800: Error on delete SVI with MPLS enabled
> > 
> >  Hi All,
> > 
> >  Just wanted to quickly testing if MPLS is supported over an SVI
> >  on an
> >  ME3800 running 15.3(3).S, I got this error when deleting the SVI
> > agian,
> >  anyone seen this, anything to be worried about do you think?
> > 
> >  http://pastebin.com/raw.php?i=dp9xYFwi
> > 
> >  The interface is gone from "show ip int br".
> > 
> >  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/
> > >>
> > >>
> > >>
> > >> Hi All,
> > >>
> > >> Just an FYI I have seen some further issues on 15.3.3(S) on ME3600
> > >> again, now similar to before (more reasons to move on to 15.4).
> > >> This time on two service instances where one had the wrong dot1q
> > >> tags overlapping with another (service instance 5 has outer tag 5 &
> > >> inner
> > >> 34 instead of outer tag 5 & inner 2047):
> > >>
> > >> pe1.lx(config)#int gi0/21
> > >> pe1.lx(config-if)#service instance 534 ethernet
> > >> pe1.lx(config-if-srv)#description XYZ
> > >> pe1.lx(config-if-srv)#encapsulation dot1q 5 second-dot1q 34 !!
> > >> Outer Vlan 5, and Inner Vlan-ids 34 already configured under some
> > >> service instance pe1.lx(config-if-srv)#exit
> > >> pe1.lx(config-if)#service instance 5 ethernet
> > >> pe1.lx(config-if-srv)#description ABC
> > >> pe1.lx(config-if-srv)#encapsulation dot1q 5 second-dot1q 2047
> > >> pe1.lx(config-if-srv)# Aug 21 2014 09:38:50.171 UTC: platform
> > >> assert failure: 0:
> > >> ../src-nile/src-common/qos/nqm_ccrm.c: 1624:
> > >> nq_ccrm_update_non_match_efps_in_port
> > >> Aug 21 2014 09:38:50.171 UTC: -Traceback= 72FD88z 25A9884z 2905E10z
> > >> 2A4BC0Cz 28CF2D8z 28CF8F0z 28DB834z 291F188z 291F5C0z 2AA10B0z
> > >> 2AA3F00z 27D789Cz 3218A74z 322B6ECz 1A94358z 1A953E0z Aug 21 2014
> > >> 09:38:50.175 UTC: platform assert failure: 0:
> > >> ../src-nile/src-common/qos/nqm_ccrm.c: 1599:
> > >> nq_ccrm_update_non_match_efps_in_port
> > >> Aug 21 2014 09:38:50.175 UTC: -Traceback= 72FD88z 25A9884z 2905D18z
> > >> 2A4B11Cz 28CDFC0z 28CE1BCz 28DB884z 291F198z 291F5C0z 2AA10B0z
> > >> 2AA3F00z 27D789Cz 3218A74z 322B6ECz 1A94358z 1A953E0z
> > >> pe1.lx(config-if-srv)#bridge-domain 2047 pe1.lx(config-if-srv)# Aug
> > >> 21 2014 09:38:54.391 UTC: platform assert failure: 0:
> > >> ../src-nile/src-common/qos/nqm_ccrm.c: 1624:
> > >> nq_ccrm_update_non_match_efps_in_port
> > >> Aug 21 2014 09:38:54.391 UTC: -Traceback= 72FD88z 25A9884z 2905E10z
> > >> 2A4BC0Cz 28CF2D8z 28CF8F0z 28DB834z 291F188z 291F5C0z 2AA10B0z
> > >> 2AA3F00z 27D789Cz 22B9FA8z 22BA184z 22BC8C8z 22B7AE4z Aug 21 2014
> > >> 09:38:54.395 UTC: platform assert failure: 0:
> > >> ../src-nile/src-common/qos/nqm_ccrm.c: 1599:
> > >> nq_ccrm_update_non_match_efps_in_port
> > >> Aug 21 2014 09:38:54.395 UTC: -Traceback= 72FD88z 25A9884z 2905D18z
> > >> 2A4B11Cz 28CDFC0z 28CE1BCz 28DB884z 291

Re: [c-nsp] CRS PRP management eth interface limits

[Vitkovský Adam]

Hello Valeriu,

I think that even for Management Ethernet ports - these limits are controlled 
by the LPTS process. 

However on ASR9k I'm not able to view or change the policers for the Managemet 
Ethernet ports (Route Switch Procesor location)

You can try to check yours with: "sh lpts pifib hardware police location" -look 
for PRP CPU
And you try to change them with: " lpts pifib hardware police location" -look 
for PRP CPU

Or alternatively you can try setting the limits globally per flow: "lpts pifib 
hardware police flow icmp" and maybe it'll get applied to the PRP as well. 

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Valeriu Vraciu
> Sent: Tuesday, August 12, 2014 1:47 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] CRS PRP management eth interface limits
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello,
> 
> Are there any limitations (rate limits) for traffic, applied to management
> Ethernet interface of a CRS3 PRP (Performance Route
> Processor) ? Temporarily changing those limits, if possible, would be great 
> for
> our experiment. I was not able to find related information while searching
> (Cisco, Google), so any hint is appreciated.
> 
> What I try to achieve is to fill a 100 Gbps circuit between 2 CRSs for 50% or
> more. Using MGEN on a laptop with gigabit eth and a routing loop this
> probably can be done. The problem is that each of the 2 routers has at this
> moment only 100G interfaces, so the only way to inject traffic is through
> management eth.
> What happens is that the traffic on this interface does not exceed the
> following values (bps and pkts/s), no matter how much I increase MGEN
> parameters above 4 UDP pkts/s (each packet 1460 bytes):
> 
> input:  480634000 bps, 4 pkts/s
> output:88 bps,  1000 pkts/s (these are merely ICMP unreachables)
> 
> 
> MGEN was run like this:
> 
> mgen event "ON 1 UDP DST 192.168.255.1/5000 PERIODIC [PKTS 1460]"
> 
> where PKTS was 10K, 20K, 40K, 60K and 80K. Traffic on 100G link was growing
> until it reached and remained at about 15 Gbps for 40K and above. Achieved
> maximum traffic was 30 Gbps (15 Gbps for each PRP eth interface, 2 x PRP on
> each router).
> 
> 
> Regards.
> - --
> Valeriu Vraciu
> RoEduNet Iasi
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> 
> iEYEARECAAYFAlPp/q0ACgkQncI+CatY949K1QCeKjrqU6fSMbJU/sn97g2WTiT+
> u0gAniWXCvPSm1NGMiy9EMC9LvMFd/JF
> =igVR
> -END PGP SIGNATURE-
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] ME3600 config help, Q in Q

[Vitkovský Adam]

Hi James, 

Under each Ethernet service instance you can define the following. 

1) What frames arriving from the trunk port are to be associated with the 
particular service instance. 
-that is accomplished with the "encapsulation" command. 
-in your case "encapsulation dot1q 1048" dictates that service instance 10 will 
accept only frames with top VLAN tag 1048 followed by any subsequent VLAN 
tag(s) or data(IP packet). 

2) Ingres VLAN tag manipulation removing, adding or translating 1 or 2 topmost 
tags. 
-that is accomplished with the "rewrite" command.
-in your case pop-ing the first/single topmost VLAN tag. 

3) Bridging operation aka what to do next with the frame (complete frame i.e. 
data and possibly adjacent/remaining VLAN tags). 
-that is accomplished with the "bridge-domain" command. 
- in your case the frame ends within bridge-domain 10. 

IP interface for bridge-domain 10 is interface vlan 10. 
But as Pshem already mentioned IP operation can be done only on untagged 
frames. 

Though I don't understand, how the service is supposed to operate, from your 
other email. 
Because if the provider is creating a platform for the hub and spoke setup than 
they are responsible for pop-ing the top tag 1048. 



adam

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> james edwards
> Sent: Friday, August 08, 2014 6:17 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ME3600 config help, Q in Q
> 
> I am trying to configure an interface on a ME3600 to accept Q in Q from a
> provider. The p-vlan the provider is using is 1048 and they are carrying
> customer vlans (c-vlan) 1058-1098, one from each site. I'm new to the 3600
> and have not done Q in Q on it yet. I've worked up this much of the config
> but it does not seem right. Can anyone give me some pointers or links to help
> me along ? I've only got one customer site configed, there will be 14.
> 
> 
> !
> vlan 1048
>  name WINDSTREAM
> !
> vlan 1058
>  name WINDSTREAM-HOBBS
> !
> interface GigabitEthernet0/6
>  description Windstream VLS IP.LVXX.xx..WCI.001  port-type nni
> switchport trunk allowed vlan none  switchport mode trunk  service instance
> 10 ethernet
>   encapsulation dot1q 1048
>   rewrite ingress tag pop 1 symmetric
>   bridge-domain 10
>  !
> !
> interface Vlan1048
>  description Windstream VLS
>  no ip address
> !
> interface Vlan1058
>  description WINDSTREAM-HOBBS
>  ip address xxx.xx.xx.1 255.255.255.0
> 
> 
> 
> Thanks,
> 
> 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] RPR in MetroE

[Vitkovský Adam]

Oh my bad, sorry about the confusion, as Saku mentioned already REP is what you 
should be looking for to build L2 rings.
RPR/SPR is for the optical domain.

adam

From: thiyagarajan b [mailto:bn.thiyagara...@gmail.com]
Sent: Monday, August 04, 2014 10:05 AM
To: Vitkovský Adam
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] RPR in MetroE

Thanks Adam for your suggestion, It takes lot of setup change for implementing 
MPLS in ME so I would rather go for RPR for now. But I am finding only Cisco 
10700 series supports RPR when I refer to the cisco feature navigator.

Warm Regards,
Thiyagarajan B.

On Sat, Aug 2, 2014 at 1:58 PM, Vitkovský Adam 
mailto:adam.vitkov...@swan.sk>> wrote:
Hi,
Sure 802.17 RPR is meant to supersede the STP for loop avoidance, faster 
convergence and better BW efficiency.
However in order to deploy it all nodes in the ring have to support it.
All ME series switches should support it.
Though I'd recommend upgrading the kit to MPLS capable ME switches and to use 
rLFA to achieve sub 50ms convergence.


adam
> -Original Message-
> From: cisco-nsp 
> [mailto:cisco-nsp-boun...@puck.nether.net<mailto:cisco-nsp-boun...@puck.nether.net>]
>  On Behalf Of
> thiyagarajan b
> Sent: Friday, August 01, 2014 3:07 PM
> To: cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> Subject: [c-nsp] RPR in MetroE
>
> Hi,
>
> Can Resilient Packet Ring can be used in Metro Ethernet (L2) for loop
> avoidance instead of MSTP?
>
> Warm Regards,
> Thiyagarajan B.
> ___
> cisco-nsp mailing list  
> cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] RPR in MetroE

[Vitkovský Adam]

Hi,
Sure 802.17 RPR is meant to supersede the STP for loop avoidance, faster 
convergence and better BW efficiency. 
However in order to deploy it all nodes in the ring have to support it. 
All ME series switches should support it. 
Though I'd recommend upgrading the kit to MPLS capable ME switches and to use 
rLFA to achieve sub 50ms convergence. 


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> thiyagarajan b
> Sent: Friday, August 01, 2014 3:07 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] RPR in MetroE
> 
> Hi,
> 
> Can Resilient Packet Ring can be used in Metro Ethernet (L2) for loop
> avoidance instead of MSTP?
> 
> Warm Regards,
> Thiyagarajan B.
> ___
> cisco-nsp 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-cx FIB-to-RIB prefix count discrepancy

[Vitkovský Adam]

Thank you for mentioning adjacencies. 
The delta is indeed in FIB adjacencies namely:  drop, multicast, attached and 
receive. 
Hence the "sh ip cef sum" or the " sh ip cef plat int" and the particular per 
VRF counts are much more accurate. 

There are still some discrepancies but it's just +/- couple of prefixes so no 
biggie. 

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Phil Mayers
> Sent: Tuesday, July 29, 2014 12:23 PM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] me3600x-cx FIB-to-RIB prefix count discrepancy
> 
> On 25/07/2014 12:39, Vitkovský Adam wrote:
> 
> > And I can't figure out where I should be looking for these delta prefixes.
> 
> Adjacencies i.e. ARP entries?
> ___
> cisco-nsp 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-cx FIB-to-RIB prefix count discrepancy

[Vitkovský Adam]

Hi James,

I summed up the "Total Subnets" counts from sh ip ro vrf xxx sum of all VRF's 
(which in our case is pretty much the same as the "sh ip b vpnv4 a s" PfxRcd 
count from RRs). 
And compared it with output from the "sh platform tcam utilization ucastv4" cmd.
The code is 15.3(3)S3

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> James Bensley
> Sent: Tuesday, July 29, 2014 10:22 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] me3600x-cx FIB-to-RIB prefix count discrepancy
> 
> Hi Adam,
> 
> What commands did you use to determine these figures and what IOS are
> you running?
> 
> 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] Cisco 6880 - EVC/MPLS Limitations

[Vitkovský Adam]

I'd be interested in that as well. 
In particular whether all the tag manipulation pop/push/translate is possible 
when the EVC is mapped to a BD or PW. 


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Chris Jones
> Sent: Tuesday, July 29, 2014 4:36 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Cisco 6880 - EVC/MPLS Limitations
> 
> Hi All,
> 
> Trying to clarify some limitations surrounding the 6880X platform, in terms of
> its support for MPLS and EVC.  Specifically, the combination of the two of
> them.
> 
> From looking at the latest configuration guide (SUP2T/15.1SY) -
> http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-
> 1SY/config_guide/sup2T/15_1_sy_swcg_2T/ethernet_virtual_connection.ht
> ml#pgfId-1081503 - it initially looks as though EVC is reasonably well
> supported - until you get to the paragraph around restrictions.  Specifically,
> what isn't supported on EVCs seems to include EoMPLS, QinQ and Bridge
> Domain Routing.
> 
> In short - is it possible to terminate a pseudowire - or other MPLS L2
> machinery - into an EVC, either directly, or via a bridge-domain, on the 6880?
> 
> 
> Regards,
> 
> Chris
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] IOS XR - CBAC/ZBF or similar

[Vitkovský Adam]

These are not supported and since there's no NBAR in XR they wouldn't be of 
much help either.

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Ivan
> Sent: Monday, July 28, 2014 11:12 PM
> To: cisco-nsp
> Subject: [c-nsp] IOS XR - CBAC/ZBF or similar
> 
> I have been unable to find CBAC/ZBF or similar on IOS XR.  I suspect these
> featires are not available but would be happy if someone could prove me
> wrong.
> 
> 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-cx FIB-to-RIB prefix count discrepancy

[Vitkovský Adam]

Hi folks,

I have noticed an interesting discrepancy in the number of IPv4 prefixes in FIB 
compared to RIB prefix count. 
For example on one box: 
there are 9253 VPN prefixes (sum from all VRFs). 
global routing table has 834 prefixes. 
together that is 10087 prefixes. 
however TCAM shows 11621 prefixes. 

So the delta is 1534 prefixes (cca 13%) which is quite a lot. 

On a non-production box the sum of global + VRF prefixes is 1487 though TCAM 
shows 1510. 
-delta is 23 prefixes (cca 1.5%). 


And I can't figure out where I should be looking for these delta prefixes. 
I thought it might be something with the backup paths but those doesn't fit the 
counts anyhow. 
It's hard to do any capacity planning as I can't predict how the RIB counts are 
gonna be translated into FIB counts. 
I'd appreciate any pointers. 



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/

Re: [c-nsp] why there are no plans for A903-RSP2B-240 please?????

[Vitkovský Adam]

> From: Mark Tinka [mailto:mark.ti...@seacom.mu]
> Sent: Tuesday, July 22, 2014 11:02 PM
> > LFA yes. No rLFA support as far as I know.
> 
> None in general, in Junos (the way we know it in Cisco, anyway).
> 
> In Junos, rLFA can be manually configured across a TE tunnel, and running LFA
> on that tunnel. Not dynamic, but achieves the same thing. 

Nah I could live with manual rLFA (it's the way we've been doing it on XR when 
there was no support for rLFA). 
On the other hand it would involve enabling TE on me3600 along with the rLFA 
and stuff which might be like opening the Pandora box. 

 
> I've been asking for dynamically-signaled LDP tunnels for rLFA on Junos, but
> it's like pulling teeth. 

Oh I can imagine. 
And one can only wish it I'll get there involving no major bugs. 



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/

Re: [c-nsp] why there are no plans for A903-RSP2B-240 please?????

[Vitkovský Adam]

This C6880-X is a very interesting box, very powerful indeed.
The only drawback is that it doesn’t have redundant RSP/Sup however it can be 
stacked together.

Would have to read through the documentation to find out about the MPLS 
features’ availability.
Though the data-sheet claims full MPLS/VPLS functionality.
Since it is Sup-2T based it should have the same features as 7600 right?


adam

From: Tim Durack [mailto:tdur...@gmail.com]
Sent: Tuesday, July 22, 2014 3:54 PM
To: Vitkovský Adam
Cc: sth...@nethelp.no; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] why there are no plans for A903-RSP2B-240 please?

May not have all of the SP features you need, but the C6880-X is an interesting 
semi-fixed platform.

On Tue, Jul 22, 2014 at 9:41 AM, Vitkovský Adam 
mailto:adam.vitkov...@swan.sk>> wrote:
> From: sth...@nethelp.no<mailto:sth...@nethelp.no> 
> [mailto:sth...@nethelp.no<mailto:sth...@nethelp.no>]
> Sent: Tuesday, July 22, 2014 3:21 PM
>
> > MX240 is too big however MX104 is exactly what I was talking about.
>
> MX104 is a very nice box, as long as you can live with its limited CPU
> horsepower. We'll be installing several of them soon.
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no<mailto:sth...@nethelp.no>
Well I'm pretty annoyed by the asr903 limited CPU horsepower.
Reloading the box takes ages also saving config introduces a very 90's style 
delay.

Does MX104 support LFA or rLFA please?

adam

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



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

Re: [c-nsp] why there are no plans for A903-RSP2B-240 please?????

[Vitkovský Adam]

> From: sth...@nethelp.no [mailto:sth...@nethelp.no]
> Sent: Tuesday, July 22, 2014 3:21 PM
> 
> > MX240 is too big however MX104 is exactly what I was talking about.
> 
> MX104 is a very nice box, as long as you can live with its limited CPU
> horsepower. We'll be installing several of them soon.
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no

Well I'm pretty annoyed by the asr903 limited CPU horsepower. 
Reloading the box takes ages also saving config introduces a very 90's style 
delay. 

Does MX104 support LFA or rLFA please?

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/

Re: [c-nsp] why there are no plans for A903-RSP2B-240 please?????

[Vitkovský Adam]

MX240 is too big however MX104 is exactly what I was talking about.

adam
> -Original Message-
> From: sth...@nethelp.no [mailto:sth...@nethelp.no]
> Sent: Tuesday, July 22, 2014 2:38 PM
> To: Vitkovský Adam
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] why there are no plans for A903-RSP2B-240 please?
> 
> > Really to get over 20K prefixes in HW with Metro-E+MPLS features we all
> are willing to install huge 10RU boxes almost as thick as high all around the
> place?
> > That just doesn't sound right.
> > Or does it?
> 
> Juniper MX240, 5U. But definitely more expensive than metro/switch class
> equipment.
> 
> I think Cisco, Juniper and others are afraid of destroying the nice profit
> margins on their higher end boxes. But maybe that's just me...
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no

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

[c-nsp] why there are no plans for A903-RSP2B-240 please?????

[Vitkovský Adam]

Hi folks,

Wouldn't there be an interest for a solid PE router in a small form chases that 
could handle 80k ipv4 prefixes and 40k ipv6 prefixes? 
And supports redundant RSPs redundant power and 6 slots for line-cards and 
4x10GE ports per linecard? 

Of course the later is possible with A903-RSP2A-240, however that one can only 
support up to 20K prefixes. 

Really to get over 20K prefixes in HW with Metro-E+MPLS features we all are 
willing to install huge 10RU boxes almost as thick as high all around the place?
That just doesn't sound right. 
Or does it? 


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/

Re: [c-nsp] Cisco 7600 pseudowire ping

[Vitkovský Adam]

And how about the regular mpls ping does that perform right?

I'd check the rate limiters:
 
show mls rate-limit
and look for UCAST IP OPTION -is it ON or OFF
though it should be off by default

adam

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Ivan
> Sent: Sunday, July 20, 2014 12:58 AM
> To: Peter Persson
> Cc: cisco-nsp
> Subject: Re: [c-nsp] Cisco 7600 pseudowire ping
> 
> No CoPP. Direct ping is fine.  Just the PW ping having issues.
> 
> On 20/Jul/2014 2:13 a.m., Peter Persson wrote:
> > Do you have any Control-plane policing?
> > As i understand your email, you are pinging between two 7600's
> > directly and not anything behind it?
> >
> >
> >
> >
> > 2014-07-19 13:47 GMT+02:00 Ivan  > >:
> >
> > I have found that mpls pseudowire pings to some 7600s running
> > 15.2(4)S4a go missing - I see about 95/100 success rate.  On other
> > devices with older software I have no loss.  The problem is not seen
> > if the ping interval is increased to 100ms.  Also pinging over the
> > VC shows no loss.
> >
> > Given the above I suspect some rate-limiting may be taking place.  I
> > am hoping someone will be able to confirm and ideally share some
> > commands that show come counters for the drops as so far I have had
> > no success.
> >
> > c7600s72033-advipservicesk9-__mz.152-4.S4a.bin
> > WS-X6704-10GE
> > WS-SUP720-3BXL
> >
> > 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/

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

Re: [c-nsp] QOS on asr901

[Vitkovský Adam]

Hi Pshem,

Thank you very much for sharing the insight.
I guess I’d have to struggle through it.
But it seems this box can’t be used to terminate services/customers aggregated 
via attached L2 switch so only one customer/service per port.
Regarding the QOS per EVC I remember ME3600 having similar problems when 
modifying service-policies already applied to EVC.

As far as the new chipset for ASR901 goes maybe Waris could share some insight 
on that.


adam

From: Pshem Kowalczyk [mailto:pshe...@gmail.com]
Sent: Sunday, June 22, 2014 11:18 AM
To: Vitkovský Adam
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] QOS on asr901

Hi,

ASR901 has a very odd qos implementation due to the fact it's based on a 
stock-standard Broadcom chip. From my experience - only basic stuff actually 
works (regardless of what docs say). On a single port you can effectively have 
only one egress policy (regardless of the number of the EVCs you have), ingress 
direction allows you one policy per EVC. The only classifier on egress is 
qos-group (that you have to set on ingress).

From my experience - it can be made to work on the policing (ingress), 
shaping/scheduling (egress) front, but requires a lot of testing and 
experimentation. For example - I've noticed that If you try to modify some qos 
settings on a map already applied to an interface/evc - it gets detached 
quietly, but remains in the config as if it was ok. Also - the whole EVC has to 
be nuked if you want to modify a policy to make sure it actually gets applied 
correctly (it helps to modify the service instance id).
If you think your core link might congest - pay close attention to the markings 
of control plane packets - we've seen links drop because BFD wasn't scheduled 
as priority.

I was told that next revision will use a better chipset, but I don't know the 
timeframes.

Have you considered an ME1200 (if you don't need the 10G)? 
http://www.cisco.com/c/en/us/products/switches/me-1200-series-carrier-ethernet-access-devices/index.html

kind regards
Pshem



On 21 June 2014 02:15, Vitkovský Adam 
mailto:adam.vitkov...@swan.sk>> wrote:
Hi folks,

I'm just evaluating asr901 and came across some QOS issues.
Anyone using egress QOS with priority and random-detect discard-class-based on 
ASR901 please?
I'm getting so many errors and limitations.

Had to strip the priority queue config to basically this:
class core_realtime
  priority percent xx

-as it seems you can't use police even though the queue is marked as priority 
-though the documentation says it's possible.

And even than I got this errors
Jun 20 21:21:46.562:  Data Qualify failed(2):-7
Jun 20 21:21:46.562:  Error in programming Exp:-7

I guess it's because of
class class-default
  random-detect discard-class-based
  random-detect discard-class 0 20 30 10

Also are there any plans for supporting QOS under service instances please?

Thank you


adam


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

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

Re: [c-nsp] IOS: catch 22 when enabling new bgp neighbors

[Vitkovský Adam]

> [neighbor 192.0.2.100 remote-as 64511 shutdown]
> 
> >Wow, you can do that? I feel really really dumb now...
> 
> so do I ;-)
> 
>   oli
> 

Same here :D. 
That's why I love this as one can learn something new each day. 

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/

[c-nsp] QOS on asr901

[Vitkovský Adam]

Hi folks,

I'm just evaluating asr901 and came across some QOS issues. 
Anyone using egress QOS with priority and random-detect discard-class-based on 
ASR901 please? 
I'm getting so many errors and limitations. 

Had to strip the priority queue config to basically this: 
class core_realtime
  priority percent xx

-as it seems you can't use police even though the queue is marked as priority 
-though the documentation says it's possible. 

And even than I got this errors
Jun 20 21:21:46.562:  Data Qualify failed(2):-7
Jun 20 21:21:46.562:  Error in programming Exp:-7

I guess it's because of
class class-default
  random-detect discard-class-based
  random-detect discard-class 0 20 30 10

Also are there any plans for supporting QOS under service instances please? 

Thank you


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/

Re: [c-nsp] sdn/nfv

[Vitkovský Adam]

I think vendors have grasped this emerging opportunity very well. 
Take Cisco for example the openflow APIs are available to the majority of their 
high-end products and they have virtualized their OSes as well. 
 
I know for a fact that majority of SPs use some kind of NFV already. 
However I'd be interested to know how many SP the use SDN. 

How I understand it is that SDN is network that orchestrates/provisions itself 
based on the traffic flows or application signaled requirements of course 
within operator's defined boundaries for a given service/customer/application. 
NFV on the other hand is using "cheap" processing power to offload network 
functions that don't have "high" pps requirements. 
The first think that comes to mind is control-plane (like Mark is doing with 
RRs) also some data-plane functions can be offloaded to servers like CGN or FW. 
And the nice think about NFV is that since you can do it in a "cloud" if 
designed correctly it should never go down. 


adam

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Aaron
> Sent: Thursday, June 19, 2014 10:33 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] sdn/nfv
> 
> I hope you all don't mind the off-topic question in this cisco mail list.
> you all are such a broad and smart and experienced group that I wanted to
> reach out to everyone out there in the trenches to get a feel for what you all
> know about sdn/nfv and do you see any movement on it yet, etc.
> 
> 
> 
> I have been reading a little bit about sdn/nfv/openflow and it seems that
> these are radical, new ideas that seem that they could really change a lot
> about what we've know about networks for the past decades.
> 
> 
> 
> Is anyone out there yet working with any sdn controllers? or nfv objects 
> in
> servers. or openflow?
> 
> 
> 
> Does sdn/nfv scare the heck out of equipment manufacturers ?
> 
> 
> 
> Aaron
> 
> 
> 
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] BGP vs OSPF (CE -> PE)

[Vitkovský Adam]

It's because intra-area LSAs are preferred compared to inter-area LSAs. 
The super-backbone(MP-BGP->OSPF) introduces LSAs from the remote site as Type-3 
into the LSDB of a local PE and if the local PE happens to have a Type-1 LSA 
from a directly connected link than that one is preferred. So you can either 
make both LSAs to appear as Type-1 using sham-link or you can make both to be 
type-3 using different areas on each site. 

Or you can use BGP as everyone else and can forget about all this mess above. 

adam

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> CiscoNSP List
> Sent: Wednesday, June 18, 2014 7:12 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] BGP vs OSPF (CE -> PE)
> 
> Hi Everyone,
> 
> We typically use OSPF (CE/PE) so customer can advertise routes into their
> VRF - We have issues with failover (When customer site has 2 links) but the
> links go to different PE"s of ours (We only have agg's from carriers on 
> certain
> PE's)..
> 
> eg.
> 
> Customer(vrf) has a site(foo) connected to PE A + B (PE B is "failover" link)
> 
> Same customer has another site(bar) connected to PE B.
> 
> Traffic from site "bar" to "foo" will go via PE B, which is not what we
> want...we have manipulated this to work via longer subnets (i.e. failover link
> advertising a /23 instead of a /24), but this isnt always feasible.
> 
> Would BGP(Instead of OSFP) help in this situation...i.e. Can we manipulate
> how the routes are advertised(PE A/B) within the vrf more easily if the CE
> advertises via BGP vs OSPF? Or any other suggestions?
> 
> Cheers
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] Is the Nexus 3064PQ usable ?

[Vitkovský Adam]

> Dale W. Carder
> Sent: Thursday, June 12, 2014 5:40 PM
> 
> We have nexus 5k's and 7k's at the distribution layer for exactly these
> reasons (well, and cat6.8k wasn't available at the time).
> 
> Only downside may be anemic buffering, but we keep a keen eye on packet
> loss. 


Can you please expand on that? I was under the impression that 5ks and 7ks 
since position for DC deployments have decent buffer sizes at least compared to 
6500 line-cards. 

 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/

Re: [c-nsp] ME3800: Error on delete SVI with MPLS enabled

[Vitkovský Adam]

Hi James,
I've never came across this type of malfunction. 

In the latest releases VLAN interfaces are indeed usable as core MPLS links. 
However there are limitations, 

The most dangerous is you can't use IPFRR/LFA when VLAN interfaces are used 
otherwise you can hit a bug where if VLAN interface is the primary path and 
switch calculates and installs a backup path via any other physical interface 
or port-channel than switch stops forwarding all transit traffic. 
(this bug has been there for quite some time). 

The other one I came across is you can't use Draft Rosen MVPN when core 
interface is VLAN int. 

I really do recommend 15.3(3)S3, guys really did a great job on that one. 
It's the first release that fixes all our outstanding bugs and doesn't 
introduce any new so far (we are running it in limited deployment phase) so 
we'll see, hopefully it's the code we've been waiting for. 



adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> James Bensley
> Sent: Thursday, June 12, 2014 4:39 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ME3800: Error on delete SVI with MPLS enabled
> 
> Hi All,
> 
> Just wanted to quickly testing if MPLS is supported over an SVI on an
> ME3800 running 15.3(3).S, I got this error when deleting the SVI agian,
> anyone seen this, anything to be worried about do you think?
> 
> http://pastebin.com/raw.php?i=dp9xYFwi
> 
> The interface is gone from "show ip int br".
> 
> 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/

[c-nsp] mac 4000.3e11.xxxx anyone?

[Vitkovský Adam]

Hi folks,

Has anyone seen a mac addresses that starts with 4000.3e11.? 
Just got a weird issue reported where me3600-cx flooded a downstream switch 
with plethora of the above addresses on two VLANs. 
Unfortunately no one captured the mac table from CX itself so I don't know what 
the mac addresses type was STATIC/DYNAMIC/. and where they were coming from? 
Anyways this is just an EFP to a VLAN interface in VRF. 
Shut/ no shut of the VLAN interface helped. 


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/

Re: [c-nsp] ASR903 BDI interface (how to do L3 on a VLAN?)

[Vitkovský Adam]

I guess it's some bug

adam
> -Original Message-
> From: Pshem Kowalczyk [mailto:pshe...@gmail.com]
> Sent: Tuesday, June 03, 2014 11:28 PM
> To: Vitkovský Adam
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] ASR903 BDI interface (how to do L3 on a VLAN?)
> 
> Hi,
> 
> Your config should work. Do you have 'bridge-domain 10' in your config as
> well?
> 
> kind regards
> Pshem
> 
> On 4 June 2014 02:14, Vitkovský Adam  wrote:
> > Hi folks,
> > How do you guys configure L3 routing for VLANs on ASR903 please?
> > I have tried with BDI interface and can't get it to work.
> > Comes with a warning:
> > WARNING:Routing may not work properly if you have a BDI and a tagged
> EFP together on a Bridge Domain.
> > So I've tried putting "encapsulation dot1q 10" under the BDI than tried to
> remove the pop operation on a service instance but no change.
> > Still can't ping across
> >
> > Do I need to enable integrated routing and bridging or what am I missing
> please?
> >
> > Original configs:
> >
> > ASR903":
> >  interface GigabitEthernet0/1/2
> >  description [TAG] to a901-03 g0/0
> >  dampening
> >  mtu 9000
> >  no ip address
> >  load-interval 30
> >  negotiation auto
> >  service instance 10 ethernet
> >   description [TAG] to a901-06 g0/10
> >   encapsulation dot1q 10
> >   rewrite ingress tag pop 1 symmetric
> >   bridge-domain 10
> >  !
> > interface BDI10
> >  description [TAG] to a901-06 int vlan 10  ip address 13.6.20.6
> > 255.255.255.0
> >
> > a903-02#sh arp
> > Protocol  Address  Age (min)  Hardware Addr   Type   Interface
> > Internet  13.6.20.6   -   d0c2.8217.37bf  ARPA   BDI10
> >
> >
> > ASR901:
> > interface GigabitEthernet0/10
> >  description [TAG] to a903-02 gi0/1/2
> >  negotiation auto
> >  service instance 10 ethernet
> >   description [TAG] to a903-02 gi0/1/2
> >   encapsulation dot1q 10
> >   rewrite ingress tag pop 1 symmetric
> >   bridge-domain 10
> >  !
> > interface Vlan10
> >  description [TAG] to a903-02 int vlan 10  ip address 13.6.20.20
> > 255.255.255.0
> >
> > a901-06#sh arp
> > Protocol  Address  Age (min)  Hardware Addr   Type   Interface
> > Internet  13.6.20.6   0   Incomplete  ARPA
> > Internet  13.6.20.20  -   4055.3989.7350  ARPA   Vlan10
> >
> > 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/

[c-nsp] ASR903 BDI interface (how to do L3 on a VLAN?)

[Vitkovský Adam]

Hi folks,
How do you guys configure L3 routing for VLANs on ASR903 please? 
I have tried with BDI interface and can't get it to work. 
Comes with a warning:
WARNING:Routing may not work properly if you have a BDI and a tagged EFP 
together on a Bridge Domain. 
So I've tried putting "encapsulation dot1q 10" under the BDI than tried to 
remove the pop operation on a service instance but no change.
Still can't ping across

Do I need to enable integrated routing and bridging or what am I missing please?

Original configs:

ASR903":
 interface GigabitEthernet0/1/2
 description [TAG] to a901-03 g0/0
 dampening
 mtu 9000
 no ip address
 load-interval 30
 negotiation auto
 service instance 10 ethernet
  description [TAG] to a901-06 g0/10
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 10
 !
interface BDI10
 description [TAG] to a901-06 int vlan 10
 ip address 13.6.20.6 255.255.255.0

a903-02#sh arp 
Protocol  Address  Age (min)  Hardware Addr   Type   Interface
Internet  13.6.20.6   -   d0c2.8217.37bf  ARPA   BDI10


ASR901:
interface GigabitEthernet0/10
 description [TAG] to a903-02 gi0/1/2
 negotiation auto
 service instance 10 ethernet
  description [TAG] to a903-02 gi0/1/2
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 10
 !
interface Vlan10
 description [TAG] to a903-02 int vlan 10
 ip address 13.6.20.20 255.255.255.0

a901-06#sh arp
Protocol  Address  Age (min)  Hardware Addr   Type   Interface
Internet  13.6.20.6   0   Incomplete  ARPA   
Internet  13.6.20.20  -   4055.3989.7350  ARPA   Vlan10

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/

Re: [c-nsp] IOS XR object tracking route reachability

[Vitkovský Adam]

Funny stuff. 

Played with it a bit and unfortunately debug is useless and documentation 
doesn't list any prerequisites or restrictions for that matter. 
Route tracking is obviously broken in 4.3.4. 
However if you indeed would like to track based on the 8.0.0.0/8 rather than 
the /9 than you can track based on 8.128.0.0/8 -which is outside of the 
8.0.0.0/9. 
This will change the state of the tracked object Up. 

It almost appears that that the logic behind tracking is that if you enter 
"track ipv4 8.0.0.0/8" XR tries to find "8.0.0.1" and figures out that the 
tracked 8.0.0.0/8 is not the best path for "8.0.0.1" so it puts the object to 
Down. 
Notice how in each example they are using host routes not network routes for 
tracking, maybe to avoid the random host route selection :) 



adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Aivars
> Sent: Monday, June 02, 2014 9:30 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] IOS XR object tracking route reachability
> 
>   I am trying to achieve conditional default route injection in VRF on
>   ASR9k running 4.3.4. Similar configuration works on 7600 perfectly.
>   I configured default static to null and attached track to it. When I
>   started to configure tracks on 9k, I noticed that all of them are
>   down. By the customer request I am tracking some classfull routes
>   like 4.0.0.0/8 and 8.0.0.0/8. The configuration seemed to be pretty
>   straight forward at first:
> 
> track 100
>  type route reachability
>   vrf x
>   route ipv4 4.0.0.0/8
> !
> track 101
>  type route reachability
>   vrf x
>   route ipv4 8.0.0.0/8
> 
>   As I mentioned, both are down, however I see the corresponding
>   routes in the routing table:
> 
>   Routing entry for 4.0.0.0/8
> Known via "bgp ", distance 200, metric 0
> Tag , type internal
> Installed Jun  2 08:03:36.518 for 07:17:30
> Routing Descriptor Blocks
>   x.x.x.x, from x.x.x.x
> Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id:
> 0xe000
> Route metric is 0
> No advertising protos.
> 
> Routing entry for 8.0.0.0/8
>   Known via "bgp ", distance 200, metric 0
>   Tag , type internal
>   Installed Jun  2 13:58:48.932 for 01:23:29
>   Routing Descriptor Blocks
> x.x.x.x, from x.x.x.x
>   Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id:
> 0xe000
>   Route metric is 0
>   No advertising protos.
> 
>   Then I copied the configuration on one track to another 9k and got
>   the same result - down. When playing around I changed the tracked
>   prefix mask to /9 and got state UP. This is really confusing. I have
>   both 8.0.0.0/8 and 8.0.0.0/9 in the routing table towards the same
>   next hop and same metrics:
> 
> Routing entry for 8.0.0.0/8
>   Known via "bgp x", distance 20, metric 0
>   Tag , type external
>   Installed Jun  2 02:03:09.123 for 19:49:09
>   Routing Descriptor Blocks
>x.x.250.145, from x.x.250.145, BGP external
>   Route metric is 0
>   Label: None
>   Tunnel ID: None
>   Extended communities count: 0
>   Route version is 0xab (171)
>   No local label
>   IP Precedence: Not Set
>   QoS Group ID: Not Set
>   Route Priority: RIB_PRIORITY_RECURSIVE (8) SVD Type
> RIB_SVD_TYPE_LOCAL  Download Priority 3, Download Version 1129312968
>   No advertising protos.
> RP/0/RSP0/CPU0:BIP-P3#sh route vrf INET 8.0.0.0/9 detail Mon Jun  2
> 21:52:43.134 EEST
> 
> Routing entry for 8.0.0.0/9
>   Known via "bgp x", distance 20, metric 0
>   Tag 3356, type external
>   Installed Jun  2 02:03:09.123 for 19:49:34
>   Routing Descriptor Blocks
> x.x.250.145, from x.x.250.145, BGP external
>   Route metric is 0
>   Label: None
>   Tunnel ID: None
>   Extended communities count: 0
>   Route version is 0xab (171)
>   No local label
>   IP Precedence: Not Set
>   QoS Group ID: Not Set
>   Route Priority: RIB_PRIORITY_RECURSIVE (8) SVD Type
> RIB_SVD_TYPE_LOCAL  Download Priority 3, Download Version 1129312956
>   No advertising protos.
> 
>   Can someone please tell me where is the catch?
> 
> ___
> cisco-nsp 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] ME3600-X 15.4(2)S ERSPAN not supported?

[Vitkovský Adam]

Hi Joeri,
Search the archives for: ME3600 PW SPAN
External loopback is your friend. 

Oh and regarding the code, I think it's unusable in production and barely 
usable in lab. 


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> JV
> Sent: Monday, June 02, 2014 10:34 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ME3600-X 15.4(2)S ERSPAN not supported?
> 
> Hi all,
> 
> 
> I tried to configure ERSPAN on the ME3600-X running the latest IOS 15.4(2)S
> but I receive the following message "ERROR Unsupported span Session".
> I checked the documentation and feature navigator and it seems that only
> SPAN is supported:
> http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/s
> oftware/release/15-
> 4_1_S/configuration/guide/3800x3600xscg/swSPAN.html
> Can someone confirm whether this should work or not? Or is this on the
> roadmap ?
> 
> We also receive some platform assert failures and have issues running
> multicast with this release. But I guess this is a case for TAC support :)
> 
> "*Jun  2 08:45:23.288 GMT+1: ELB FID allocation failed *Jun  2 08:45:23.288
> GMT+1: platform assert failure: 0:
> ../src-nile/src-asic-nile/nile_adjmgr.c: 11824:
> adjmgr_l3_create_fwd_info_flow
> *Jun  2 08:45:23.288 GMT+1: -Traceback= 760764z 27DDFC4z 29064FCz
> 333E9F8z 329B6FCz 32AC044z 33250B8z 332F900z 3346CC8z 334DD10z
> 334E094z 334A364z 3346A6Cz 3341C70z 337F374z 337A660z *Jun  2
> 08:45:23.288 GMT+1: platform assert failure: 0:
> ../src-nile/src-asic-nile/nile_adjmgr.c: 12388: adjmgr_get_fid_index *Jun  2
> 08:45:23.288 GMT+1: -Traceback= 760764z 27DDFC4z 28FBC2Cz 333EA58z
> 329B6FCz 32AC044z 33250B8z 332F900z 3346CC8z 334DD10z 334E094z
> 334A364z 3346A6Cz 3341C70z 337F374z 337A660z "
> 
> Thanks
> 
> Joeri Vanthienen
> ___
> cisco-nsp 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] static mroute asr9k

[Vitkovský Adam]

Hello,
In XR you should be using the following to configure a static route meant for 
RPF checking. 

multicast-routing
 address-family ipv4
  static-rpf "prefix" "mask" "NH-int" "NH-ip"



adam

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> redscorpion69
> Sent: Tuesday, May 27, 2014 5:36 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] static mroute asr9k
> 
> Hello.
> 
> How do I make IOSXR use configuration in "router static address-family ipv4
> multicast" for rpf check instead of default unicast table? I couldn't really 
> find
> documentation on this. I don't want to create additional topologies.
> 
> 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/

[c-nsp] m3600x-cx tx/rx of transit traffic STOPS when LFA repair path found (int enabled), 15.3(3)S1a; 15.3(3)S2.

[Vitkovský Adam]

Hi Folks,

Has anyone encountered an issue where me3600 stops forwarding transit traffic 
when LFA repair path is found over a newly enabled interface please?
This is on 15.3(3)S1a a well as on 15.3(3)S2.
Ping to directly connected interfaces works however anything behind the box 
either in global or VRF table is unreachable.

Only other thing that could cause this is that rLFA LDP tunnel is terminated at 
this router (i.e. this router is rLFA for some other box in the ring).

In any case once the ring is setup so that the router doesn't calculate (r)LFA 
it starts forwarding transit traffic again.

This behavior is persistent across reloads.

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/

Re: [c-nsp] apply rate limit to VFI interface

[Vitkovský Adam]

Hello Alejandro,
I think you can only rate-limit on EFPs ingress/egress to/from a particular PW.


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Alejandro Aristizabal
> Sent: Friday, May 23, 2014 5:13 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] apply rate limit to VFI interface
> 
> 
> Good,
> 
> 
> 
> Any one knows how to aplly rate limit to VFI interfaces on IOS XR?, thnks.
> 
> Id appreciate it.
> 
> good luck
> 
> 
> --
> Alejandro Aristizabal
> Analista de Interconexión
> Email: aaristiza...@mediacommerce.net.co
> Móvil: 3206777514
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] Multicast group but no traffic

[Vitkovský Adam]

The C flag indicates there’s a directly connected receiver for this group (that 
would be the VLC player connected to the GigabitEthernet0/1.902 int).
If that’s the case you should see this receiver being registered with igmp for 
this particular group (sh ip igmp group).

adam

From: Scott Voll [mailto:svoll.v...@gmail.com]
Sent: Wednesday, May 14, 2014 11:50 PM
To: Vitkovský Adam
Cc: Phil Mayers; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Multicast group but no traffic

Why would I see this on my WAN router?

(*, 225.5.5.5), 02:02:57/00:03:29, RP 10.255.255.2, flags: S
  Incoming interface: GigabitEthernet0/0, RPF nbr 10.0.1.3
  Outgoing interface list:
GigabitEthernet0/1.902, Forward/Sparse, 00:42:16/00:03:29

if I have an incoming and outgoing interface shouldn't I see an SC flag?

TIA

Scott


On Sat, May 10, 2014 at 12:20 AM, Vitkovský Adam 
mailto:adam.vitkov...@swan.sk>> wrote:
Well talking multicast you need to specify what route (state) are you seeing as 
well as which PIM mode are you running across your WAN.

So you see either just the (*,g) state -means the designated router for the LAN 
segment as displayed by the cmd: " sh ip pim int" (Nexus) has translated the 
IGMP membership reports(igmp joins) into PIM Joins and sent them towards the RP 
(would be good to know which of your routers is RP).
You might actually be getting the stream if PIM is running in BIDIR or Dense 
mode -the stream can be checked via "sh ip mroute active".

Or you see also the (s,g) state -means the RP has an active source for the 
previously requested group or has send a register message towards the source.
In either case as the source starts to send traffic down the shared tree (*,g) 
this is how the Nexus will learn about the source of the source for the group 
and can join source tree by sending PIM Join towards the Source (s,g) state.  
-the stream can be checked via "sh ip mroute active".


adam
> -Original Message-
> From: cisco-nsp 
> [mailto:cisco-nsp-boun...@puck.nether.net<mailto:cisco-nsp-boun...@puck.nether.net>]
>  On Behalf Of
> Scott Voll
> Sent: Friday, May 09, 2014 9:38 PM
> To: Phil Mayers
> Cc: cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> Subject: Re: [c-nsp] Multicast group but no traffic
>
> VLC Player with TTL 10.  Connected to 3560 to Nexus 55xx with Layer 3.
>  connection to 3845 over WAN to remote site, to 2911 to 2960 layer 2 switch.
>
> I can see on Nexus, 3845 and 2911 the IP Mroute for the group I'm sending.
>  Via a packet capture I can see the multicast local to the Nexus on multiple
> vlan's
>
> I can see on the 2960 the groups and interfaces.  But a wire capture on the
> local PC all I see is the join packets, no traffic.
>
> Other ideas?
>
> Scott
>
>
> On Fri, May 9, 2014 at 11:28 AM, Phil Mayers
> mailto:p.may...@imperial.ac.uk>>wrote:
>
> > On 09/05/2014 18:53, Scott Voll wrote:
> >
> >> I'm working on rolling out my Multicast across my WAN.
> >>
> >> I can see the Multicast group on the WAN router and I can see it on
> >> the switch interface, but I'm not getting the traffic.  What should I
> >> be looking at?
> >>
> >
> > That's a bit vague. John has made some good suggestions but you'd get
> > more specific answers if you can specify the topology in detail.
> >
> > How are you determining you're not "seeing" the traffic? No video at
> > receiver app? If so, check again with tcpdump/wireshark and look out
> > for software firewalls. That one catches me a lot - I always forget
> > iptables on my laptop :o(
> >
> > "sh ip mr active" and "sh ip mr count" are useful at L3 hops. L2 hops
> > are far harder to debug, unfortunately.
> >
> > ___
> > cisco-nsp mailing list  
> > cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> ___
> cisco-nsp mailing list  
> cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] Cisco ME3x00 Egress Policie - Denied by Cisco/IOS!

[Vitkovský Adam]

> On the unit in the field (with the same IOS version, 15.3(3)s) when either
> trying to apply the child policy PE-QOS-CPE-OUT (which just uses
> percentages) under the PARENT policy (which is suppose to provide the
> shape) or by first creating the 11 shapers and childs and then trying to apply
> the service policy to the interface, it gives the same error through both
> methods;

And that is the "beauty" of me3x00 boxes, there are no two alike.
And they behave differently in the lab and in production so only several cases 
can be recreated in the lab even with the same exact config, IOS code and 
topology.

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/

Re: [c-nsp] Multicast group but no traffic

[Vitkovský Adam]

Well talking multicast you need to specify what route (state) are you seeing as 
well as which PIM mode are you running across your WAN. 

So you see either just the (*,g) state -means the designated router for the LAN 
segment as displayed by the cmd: " sh ip pim int" (Nexus) has translated the 
IGMP membership reports(igmp joins) into PIM Joins and sent them towards the RP 
(would be good to know which of your routers is RP). 
You might actually be getting the stream if PIM is running in BIDIR or Dense 
mode -the stream can be checked via "sh ip mroute active". 

Or you see also the (s,g) state -means the RP has an active source for the 
previously requested group or has send a register message towards the source. 
In either case as the source starts to send traffic down the shared tree (*,g) 
this is how the Nexus will learn about the source of the source for the group 
and can join source tree by sending PIM Join towards the Source (s,g) state.  
-the stream can be checked via "sh ip mroute active". 


adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Scott Voll
> Sent: Friday, May 09, 2014 9:38 PM
> To: Phil Mayers
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Multicast group but no traffic
> 
> VLC Player with TTL 10.  Connected to 3560 to Nexus 55xx with Layer 3.
>  connection to 3845 over WAN to remote site, to 2911 to 2960 layer 2 switch.
> 
> I can see on Nexus, 3845 and 2911 the IP Mroute for the group I'm sending.
>  Via a packet capture I can see the multicast local to the Nexus on multiple
> vlan's
> 
> I can see on the 2960 the groups and interfaces.  But a wire capture on the
> local PC all I see is the join packets, no traffic.
> 
> Other ideas?
> 
> Scott
> 
> 
> On Fri, May 9, 2014 at 11:28 AM, Phil Mayers
> wrote:
> 
> > On 09/05/2014 18:53, Scott Voll wrote:
> >
> >> I'm working on rolling out my Multicast across my WAN.
> >>
> >> I can see the Multicast group on the WAN router and I can see it on
> >> the switch interface, but I'm not getting the traffic.  What should I
> >> be looking at?
> >>
> >
> > That's a bit vague. John has made some good suggestions but you'd get
> > more specific answers if you can specify the topology in detail.
> >
> > How are you determining you're not "seeing" the traffic? No video at
> > receiver app? If so, check again with tcpdump/wireshark and look out
> > for software firewalls. That one catches me a lot - I always forget
> > iptables on my laptop :o(
> >
> > "sh ip mr active" and "sh ip mr count" are useful at L3 hops. L2 hops
> > are far harder to debug, unfortunately.
> >
> > ___
> > cisco-nsp 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] bvi stays up even when no pw's are up in bridge-domain - XR 4.1.2

[Vitkovský Adam]

Than it is a bug.

adam
> -Original Message-
> From: Aaron [mailto:aar...@gvtc.com]
> Sent: Monday, May 05, 2014 4:38 PM
> To: Vitkovský Adam; cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] bvi stays up even when no pw's are up in bridge-domain
> - XR 4.1.2
> 
> No.  no ac's are active (up).  There are 2 configured ac pw's in bridge 
> domain,
> but they are both down, and bvi remains up why ?
> 
> Copied from previous posting...
> 
> RP/0/RSP0/CPU0:9k#sh run l2v br gr v45
> l2vpn
> bridge group v45
>   bridge-domain v45
>neighbor 10.101.12.250 pw-id 45
> backup neighbor 10.101.12.251 pw-id 45
>routed interface BVI45
> 
>  it shows one AC up, but that's the BVI AC.  Shouldn't the BVI go down
> when those 2 pw's are down. ?
> 
> RP/0/RSP0/CPU0:9k#sh l2v br gr v45
> Bridge group: v45, bridge-domain: v45, id: 4, state: up, ShgId: 0,
> MSTi: 0
>   Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
>   Filter MAC addresses: 0
>   ACs: 1 (1 up), VFIs: 0, PWs: 2 (0 up), PBBs: 0 (0 up)
>   List of ACs:
> BV45, state: up, BVI MAC addresses: 2
>   List of Access PWs:
>   Neighbor 10.101.12.250 pw-id 45, state: down, Static MAC addresses: 0
>   Neighbor 10.101.12.251 pw-id 45, state: down, Static MAC addresses: 0,
> backup
>   List of VFIs:
> 
>  BVI is still UP!
> 
> RP/0/RSP0/CPU0:9k#sh ip vrf one int br bvi 45 Fri May  2 16:17:16.744 CDT
> 
> Interface  IP-Address  Status
> Protocol
> BVI45  1.2.3.3UpUp
> 
> 
> 
> -Original Message-
> From: Vitkovský Adam [mailto:adam.vitkov...@swan.sk]
> Sent: Saturday, May 03, 2014 7:50 AM
> To: Aaron; cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] bvi stays up even when no pw's are up in bridge-domain
> - XR 4.1.2
> 
> Hi Aaron,
> 
> Are there any attachment circuits active in the bridge-domain?
> The BVI is supposed to stay up only if there is any active bridge port being 
> it
> an AC or PW.
> And the line protocol is up when BD is up and the IP is not in conflict.
> 
> adam
> > -Original Message-
> > From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf
> > Of Aaron
> > Sent: Friday, May 02, 2014 11:21 PM
> > To: cisco-nsp@puck.nether.net
> > Subject: [c-nsp] bvi stays up even when no pw's are up in
> > bridge-domain - XR
> > 4.1.2
> >
> > Anyone know why this bvi stays up up even though there aren't any L2
> > interfaces/pw's up in this bridge-domain?
> >
> > I would like the BVI interface to go down down when there are no
> > underlying layer 2 connections to be serviced.
> >
> > This was the way ios switches have always operated. not sure why this
> > isn't acting the same.
> >
> > Aaron
> 


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

[c-nsp] me3600x-cx 15.4(2)S interface description mess

[Vitkovský Adam]

Hi Folks,

After upgrade/ first boot from 15.3(2)S2 to 15.4(2)S strange things started to 
happen with interface descriptions. 
Like when I delete interface configuration, the description still remains in 
the "show interface description" output. 
Or when I change description it's not reflected in the running config of the 
interface so after "wr" and reload the change in description disappears. 
And after another reload it all vanishes and the box starts to behave as 
expected. 
This is consistent across at least two me3600x-cx boxes. 

Anyone noticed this please or it's just me having a lucky HW revision? 


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/

Re: [c-nsp] bvi stays up even when no pw's are up in bridge-domain - XR 4.1.2

[Vitkovský Adam]

Hi Aaron,

Are there any attachment circuits active in the bridge-domain? 
The BVI is supposed to stay up only if there is any active bridge port being it 
an AC or PW. 
And the line protocol is up when BD is up and the IP is not in conflict. 

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Aaron
> Sent: Friday, May 02, 2014 11:21 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] bvi stays up even when no pw's are up in bridge-domain - XR
> 4.1.2
> 
> Anyone know why this bvi stays up up even though there aren't any L2
> interfaces/pw's up in this bridge-domain?
> 
> 
> 
> I would like the BVI interface to go down down when there are no underlying
> layer 2 connections to be serviced.
> 
> 
> 
> This was the way ios switches have always operated. not sure why this isn't
> acting the same.
> 
> 
> 
> Aaron
> 
> 
> 
> 
> 
> RP/0/RSP0/CPU0:9k#sh run l2v br gr v45
> 
> 
> 
> l2vpn
> 
> bridge group v45
> 
>   bridge-domain v45
> 
>neighbor 10.101.12.250 pw-id 45
> 
> backup neighbor 10.101.12.251 pw-id 45
> 
> !
> 
>!
> 
>routed interface BVI45
> 
>   !
> 
> !
> 
> !
> 
> 
> 
> 
> 
> RP/0/RSP0/CPU0:9k#sh l2v br gr v45
> 
> 
> 
> Bridge group: v45, bridge-domain: v45, id: 4, state: up, ShgId: 0, MSTi: 0
> 
>   Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
> 
>   Filter MAC addresses: 0
> 
>   ACs: 1 (1 up), VFIs: 0, PWs: 2 (0 up), PBBs: 0 (0 up)
> 
>   List of ACs:
> 
> BV45, state: up, BVI MAC addresses: 2
> 
>   List of Access PWs:
> 
>   Neighbor 10.101.12.250 pw-id 45, state: down, Static MAC addresses: 0
> 
>   Neighbor 10.101.12.251 pw-id 45, state: down, Static MAC addresses: 0,
> backup
> 
>   List of VFIs:
> 
> 
> 
> RP/0/RSP0/CPU0:9k#ibv1 bvi 45
> 
> RP/0/RSP0/CPU0:9k#sh ip vrf one int br bvi 45
> 
> Fri May  2 16:17:16.744 CDT
> 
> 
> 
> Interface  IP-Address  Status
> Protocol
> 
> BVI45  1.2.3.3UpUp
> 
> 
> 
> ___
> cisco-nsp 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] ME3600 PW SPAN

[Vitkovský Adam]

Hi Jason,

And what about the xconnect from the g0/1 on local me3600 to g0/4 on remote 
me3600, wouldn't that work? 
On the g0/1 on local me3600 create service instance with "encapsulation 
default" and do the xconnect under the service instance. 

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/

Re: [c-nsp] 6880-X XL vs. ASR

[Vitkovský Adam]

On 30/04/14 14:19, Mark Mason wrote:
> Looking at some potential edge redesign options when comparing 
> 6880-X-XL [larger route table @ 2M IPv4] & ASR1004/1006 platforms.
> Thinking about leaving the edge routers to ASR's (could be more than
> 4 carriers - 1 per ASR) and then route-reflecting down to the new L3 
> core/distribution. Moving the L3 / HSRP from the ASR edge down to the
> 6880 level and disposing of HSRP. Thoughts? Current designs? Thinking 
> VSS @ the 6880 level good choice/bad choice? Would like to you know 
> your thoughts...

Unless you need some XE specific features you can do it solely with a pair 
6880s.
(Vanilla IOS 15.3 supports BGP Attribute Filter and Enhanced Attribute Error 
Handling features).  
Since these are going to perform L3 termination point for all the VLANs there's 
no need for VSS and I think the better option is to keep two separate brains. 

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/

Re: [c-nsp] Tracking state of non-directly connected link

[Vitkovský Adam]

Well than you might need to rely on the options that the CE provides if any 
(RIP maybe).

adam
From: redscorpion69 [mailto:redscorpio...@gmail.com]
Sent: Tuesday, April 29, 2014 11:56 PM
To: Vitkovský Adam
Cc: Velimir Filipov; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Tracking state of non-directly connected link

Yes, but CE has to check it's own part. For example CE is multihoming and using 
static routes, it also has to check for other end?
Regards

On Tue, Apr 29, 2014 at 11:51 PM, Vitkovský Adam 
mailto:adam.vitkov...@swan.sk>> wrote:
For simple link availability check you don't need the SLA responder at the 
other end.
Just have the ping running and define how many failed pings result in positive 
action.

adam
> -Original Message-
> From: cisco-nsp 
> [mailto:cisco-nsp-boun...@puck.nether.net<mailto:cisco-nsp-boun...@puck.nether.net>]
>  On Behalf Of
> redscorpion69
> Sent: Tuesday, April 29, 2014 11:33 PM
> To: Velimir Filipov
> Cc: cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> Subject: Re: [c-nsp] Tracking state of non-directly connected link
>
> Hello,
>
> Yeah I forgot to mention ip sla, I had it in my head. But what if CE is a 
> small
> non-cisco router that doesn't have ip sla/static bfd?
>
> Regards
>
>
> On Tue, Apr 29, 2014 at 3:59 PM, Velimir Filipov
> mailto:vfili...@evolink.com>>wrote:
>
> >
> > Hello.
> >
> > You could use ip sla and object tracking to achieve that.
> >
> >
> > http://www.cisco.com/c/en/us/td/docs/ios/dial/configuration/guide/12_2
> > sr/dia_12_2sr_book/dia_rel_stc_rtg_bckup.html
> >
> >
> > > Hello,
> >
> >
> > > What would be the best method of actively/passively keeping track of
> > > validity of static route over GPON interfaces for example?
> >
> > > We want to give an option of backup floating static route over
> > > backup interface, but need to be aware of primary link failure.
> >
> > > I could think of something like static bfd, which isn't available on
> > > all platforms, or maybe GRE tunnel will keepalives?
> >
> > > Regards
> >
> >
> ___
> cisco-nsp mailing list  
> cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] Tracking state of non-directly connected link

[Vitkovský Adam]

For simple link availability check you don't need the SLA responder at the 
other end.
Just have the ping running and define how many failed pings result in positive 
action.

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> redscorpion69
> Sent: Tuesday, April 29, 2014 11:33 PM
> To: Velimir Filipov
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Tracking state of non-directly connected link
> 
> Hello,
> 
> Yeah I forgot to mention ip sla, I had it in my head. But what if CE is a 
> small
> non-cisco router that doesn't have ip sla/static bfd?
> 
> Regards
> 
> 
> On Tue, Apr 29, 2014 at 3:59 PM, Velimir Filipov
> wrote:
> 
> >
> > Hello.
> >
> > You could use ip sla and object tracking to achieve that.
> >
> >
> > http://www.cisco.com/c/en/us/td/docs/ios/dial/configuration/guide/12_2
> > sr/dia_12_2sr_book/dia_rel_stc_rtg_bckup.html
> >
> >
> > > Hello,
> >
> >
> > > What would be the best method of actively/passively keeping track of
> > > validity of static route over GPON interfaces for example?
> >
> > > We want to give an option of backup floating static route over
> > > backup interface, but need to be aware of primary link failure.
> >
> > > I could think of something like static bfd, which isn't available on
> > > all platforms, or maybe GRE tunnel will keepalives?
> >
> > > Regards
> >
> >
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] EIGRP Authentication on IOS XR

[Vitkovský Adam]

Hi,
What does the debug says please?

adam
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> M K
> Sent: Tuesday, April 29, 2014 10:47 AM
> To: Oliver Boehmer (oboehmer); Pete Lumbis
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] EIGRP Authentication on IOS XR
> 
> Hi and sorry for the late reply
> I have tried it and did not work the relation kept down
> 
> BR,
> 
> > From: oboeh...@cisco.com
> > To: gunner_...@live.com; alum...@gmail.com
> > CC: cisco-nsp@puck.nether.net
> > Subject: Re: [c-nsp] EIGRP Authentication on IOS XR
> > Date: Wed, 23 Apr 2014 21:40:00 +
> >
> > can you add "send-lifetime .." to the key? It might not be active
> > without it..
> >
> > key chain KEY
> >  key 1
> >   key-string password cisco
> >   cryptographic-algorithm md5
> >   send-lifetime 01:01:00 january 01 2014 infinite
> >
> >
> >
> > -Original Message-
> > From: M K 
> > Date: Wednesday, 23 April 2014 16:49
> > To: Pete Lumbis 
> > Cc: "cisco-nsp@puck.nether.net" 
> > Subject: Re: [c-nsp] EIGRP Authentication on IOS XR
> >
> > >No , the only option under the interface is authentication keychain
> > >command The cryptographic-algorithm MD5 command is under the key
> > >chain command , I have tried it but did not work for me !
> > >
> > >Date: Tue, 22 Apr 2014 13:16:14 -0400
> > >Subject: Re: [c-nsp] EIGRP Authentication on IOS XR
> > >From: alum...@gmail.com
> > >To: gunner_...@live.com
> > >CC: cisco-nsp@puck.nether.net
> > >
> > >I think the next line after "authentication keychain" is
> > >"cryptographic-algorithm MD5"
> > >
> > >
> > >On Tue, Apr 22, 2014 at 10:55 AM, M K  wrote:
> > >
> > >Hi all
> > >
> > >I am facing an issue when configuring EIGRP authentication between
> > >IOS and IOS XR
> > >
> > >
> > >
> > >R1#sh run | sec key chain
> > >
> > >key chain KEY
> > >
> > > key 1
> > >
> > >   key-string cisco
> > >
> > >
> > >
> > >R1#sh run int f0/0 | inc authen
> > >
> > > ip authentication mode eigrp 1 md5
> > >
> > > ip authentication key-chain eigrp 1 KEY
> > >
> > >
> > >
> > >RP/0/0/CPU0:XR1#sh run key chain
> > >
> > >Tue Apr 22 17:54:14.480 UTC
> > >
> > >key chain KEY
> > >
> > > key 1
> > >
> > >  key-string password cisco
> > >
> > >
> > >
> > >router eigrp EIGRP_PROCESS
> > >
> > > address-family ipv4
> > >
> > >  autonomous-system 1
> > >
> > >  interface Loopback0
> > >
> > >  !
> > >
> > >  interface GigabitEthernet0/0/0/0
> > >
> > >   authentication keychain KEY
> > >
> > >
> > >
> > >Under the interface GigabitEthernet0/0/0/0 located under the EIGRP
> > >process , I did not find an option for choosing MD5
> > >
> > >
> > >
> > >Any ideas?
> > >
> > >
> > >
> > >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/
> >
> 
> ___
> cisco-nsp 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] asr9001 4 x integrated 10 GE SFP+slots - does 1GE sfp work?

[Vitkovský Adam]

Hi folks,
Has anyone tried using 1GE sfp in the integrated 4 x 10 GE SFP+ slots please?
Thank you

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/

[c-nsp] ME3600 15.3(3)S2 BFD stays down after reload

[Vitkovský Adam]

Hi Folks,

If you are using BFD async mode (the only mode with HW offload on CX) -the BFD 
session stays in admindown after reload. 
Just got a confirmation it's identified as bug CSCum08918. 
Supposed to be fixed on 154-2.S * -where also the bug screwing the tLDP 
sessions is supposed to be fully fixed already. 


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/

Re: [c-nsp] static nat from vrf to global

[Vitkovský Adam]

Hi Vladimir,
Try to google for: 
asr1001 Match-in-VRF Support for NAT

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/