Re: [j-nsp] Juniper vMX limitations

[Ben Dale]

> On 30 Jul 2015, at 11:11 pm, Chris Adams  wrote:
> 
> Once upon a time, Phil Bedard  said:
>> I’m sure they’ve had it running in VMWare, but it’s a little more difficult 
>> and you need the Enterprise Plus version of vSphere to get virtual serial 
>> ports. I’d be more comfortable running it under KVM myself.   
> 
> Just an FYI: if you are looking for a KVM-based virtualization setup
> that has more of the functionality of VMWare (not just CLI-based local
> VMs), check out oVirt .

And similarly ProxMox -  - I haven’t 
tried vMX on it yet, but it’s a pretty nice ESX replacement for general purpose 
use


> -- 
> Chris Adams 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] l2circuit between ASR9k and MX80

[Saku Ytti]

On (2015-07-31 12:41 +0200), Marcin Kurek wrote:

Hey Marcin,

> I wanted to ask about a particular piece of config.
> I would expect that it shouldn't work, but it works perfectly, so I'm a bit
> confused.

I'm answering for 7600/ES+ perspective (which is same as original ASR9k
linecard).
I too had similar situation and was confused why it works.

> interface TenGigE0/0/1/5.3101 l2transport
>  encapsulation dot1q 3101
>  rewrite ingress tag pop 1 symmetric

>  ge-1/0/1 {
> description "ESXi 2 VMNIC3";
> flexible-vlan-tagging;
> encapsulation flexible-ethernet-services;
> unit 3101 {
> encapsulation vlan-ccc;
> vlan-id 3101;

So what happens here is Cisco somehow dynamically determines what is required.
In 7600 with this config 3101 _Will be popped_ and _internal VLAN_ will be
pushed, before sending it out to MPLS network.
But as it works with you, it is probably pushing 3101 again.
Magically same config in Cisco works against untagged and tagged EoMPLS. Sadly
it's not even possible to explictly/self-documenting configure it 'correctly',
as what you'd want to configure is:

I would recommend adding to junos config output-vlan-map swap, so you can deal
with different SVLAN in each end.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] l2circuit between ASR9k and MX80

[Marcin Kurek]

Hello,

I'm doing some interoperability tests between Cisco and Juniper routers 
and I wanted to ask about a particular piece of config.
I would expect that it shouldn't work, but it works perfectly, so I'm a 
bit confused.


There is a l2vpn circuit between ASR9k and MX80 running in VLAN mode (VC 
Type 4).


--- ASR9k 

interface TenGigE0/0/1/5.3101 l2transport
 encapsulation dot1q 3101
 rewrite ingress tag pop 1 symmetric

l2vpn
!
 pw-class PW_TYPE_VLAN
  encapsulation mpls
   transport-mode vlan
  !
 !
!
 xconnect group XCONNECT_GROUP_2
  p2p PW2
   interface TenGigE0/0/1/5.3101
   neighbor ipv4 3.3.3.3 pw-id 101
pw-class PW_TYPE_VLAN
   !
  !
 !
--- MX80 -

 ge-1/0/1 {
description "ESXi 2 VMNIC3";
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 3101 {
encapsulation vlan-ccc;
vlan-id 3101;

protocols {
 l2circuit {
neighbor 4.4.4.4 {
interface ge-1/0/1.3101 {
virtual-circuit-id 101;
no-control-word;
encapsulation-type ethernet-vlan;
}
}
}
}

In my understanding following things should happen:
- a frame coming to ASR9k from a CE is tagged with VLAN 3101
- we are doing VLAN tag manipulation on ASR9k, the tag is popped
- since we are using VC type 4, the PW forwarder adds a dummy tag 0 
before forwarding the frame

- MX80 should get the frame with tag 0 imposed

If above is true, how does the MX handle the dummy tag?


Thanks,
Marcin







___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Policing On LAG's

[Mark Tinka]

Hi all.

So just an update on this - Junos has a mechanism that divides the
policer parametres equally across the member links in a LAG. Juniper
call this a "carve-up factor".

In the case of 2x member links in a LAG, the carve-up factor is 0.5,
regardless of whether the member links are on the same or different MPC.

When looking at the PFE programming of the policer on each MPC, I
noticed that the carve-up factor was 1.0. This means each MPC was
policing at the CIR, meaning any customers attached to that LAG were
getting double the bandwidth.

The only solution was to delete, commit, re-configure and re-commit the
policer on the affected customer ports. This, then, correctly programmed
the PFE with the right carve-up factor.

Theories abound as what triggers application of the wrong carve-up
factor, and that is what Juniper and we are investigating.

For the archives in case anyone hits this issue.

Mark.

On 24/Apr/15 17:18, Mark Tinka wrote:
>
> On 24/Apr/15 16:07, Tima Maryin wrote:
>> Hi Mark,
>>
>>
>> So which steps make the box to 2nd scenario?
>>
>>
>> p.s. https://prsearch.juniper.net/PR1056098
> The changes are random, but I had a feeling it could be something like
> this, where the router ignores the configuration due to a change. So I
> did a "commit full" just to be sure, but that didn't help.
>
> My next step was to restart the MPC's so that the PFE can be freshly
> re-programmed, but that would require a maintenance window.
>
> At any rate, I have also randomly changed policer settings on the one
> which is working as expected, so while I suspect it could be a PFE issue
> to some extent, it's not yet clear what steps lead to it.
>
> That said, it may be an issue in my release of code (which is an
> engineering version of 14.2), and the fix could be in 14.2R3 as
> indicated in the PR. Will ping JTAC on this.
>
> Many thanks, Tima.
>
> Mark.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp