Re: [j-nsp] MX Lab config for virtual-switch

[Joshua Morgan]

Why not set a vlan-id at the bridge domain level? That will take care of
normalising the VLAN IDs.

Josh

On Friday, 3 June 2016, Matthew Crocker  wrote:

>
> Hello,
>
>  I’m trying to lab out the following scenario.  Running into a couple
> snags, hoping someone can point me to the right documentation.
>
>  I have 17 SRX300s connected to a WAN that I want to link together into
> the same virtual-switch/bridge/VPLS/??? in my MX240.   The SRXs will enter
> the MX240 over a couple different interfaces on a dozen or so different
> VLANs from different carriers.   I want to merge all of the traffic
> together so the SRXs and be on the same broadcast domain, L2 network so
> they can talk to each other (same /24 subnet) and handle MPLS.  QinQ from
> the SRXs isn’t needed.  The MX240 needs to pass the traffic but not
> participate in the MPLS or L3 traffic at all, just handle the bridging.
>
>  I have a ping running that goes though ge-2/1/5.200 to ge-2/3/9.10.
>  Wireshark on the ge-2/3/9 side shows the ARP requests coming in with VLAN
> 200 tag still attached.  I need the MX240 to pop the 200 tag and add the 10
> tag (or 20,21,22, etc depending on the unit).
>
>  I tried input-vlan-map pop and output-vlan-map push on the interfaces but
> then I see the ARP requests with no VLAN tag.
>
> Should I use a different instance-type  (vpls, l2vpn??)
>
>
> I’m set this up in my lab as a virtual-switch
> routing-instance {
>
> SRXNET {
> description “A bunch of SRXes";
> instance-type virtual-switch;
> bridge-domains {
> SRXNET {
> domain-type bridge;
> interface ge-2/1/5.200;
> interface ge-2/3/9.10;
> interface ge-2/3/9.20;
> interface ge-2/3/9.21;
> interface ge-2/3/9.22;
> interface ge-2/3/9.23;
> interface ge-2/3/9.24;
> interface ge-2/3/9.25;
> interface ge-2/3/9.26;
> }
> }
> }
>
> ge-2/1/5 {
> flexible-vlan-tagging;
> encapsulation flexible-ethernet-services;
>
> unit 200 {
> encapsulation vlan-bridge;
> vlan-id 200;
> family bridge;
> }
> }
>
> ge-2/3/9 {
> flexible-vlan-tagging;
> speed 100m;
> encapsulation flexible-ethernet-services;
> unit 10 {
> encapsulation vlan-bridge;
> vlan-id 10;
> family bridge;
> }
> unit 20 {
> encapsulation vlan-bridge;
> vlan-id 20;
> family bridge;
> }
> unit 21 {
> encapsulation vlan-bridge;
> vlan-id 21;
> family bridge;
> }
> unit 22 {
> encapsulation vlan-bridge;
> vlan-id 22;
> family bridge;
> }
> unit 23 {
> encapsulation vlan-bridge;
> vlan-id 23;
> family bridge;
> }
> unit 24 {
> encapsulation vlan-bridge;
> vlan-id 24;
> family bridge;
> }
> unit 25 {
> encapsulation vlan-bridge;
> vlan-id 25;
> family bridge;
> }
> unit 26 {
> encapsulation vlan-bridge;
> vlan-id 26;
> family bridge;
> }
>
>
> Thanks
>
>
> —
>
> Matthew Crocker
> President - Crocker Communications, Inc.
> Managing Partner - Crocker Telecommunications, LLC
> E: matt...@corp.crocker.com 
> E: matt...@crocker.com 
>
>
>
> ___
> 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

[j-nsp] MX Lab config for virtual-switch

[Matthew Crocker]

Hello,

 I’m trying to lab out the following scenario.  Running into a couple snags, 
hoping someone can point me to the right documentation.

 I have 17 SRX300s connected to a WAN that I want to link together into the 
same virtual-switch/bridge/VPLS/??? in my MX240.   The SRXs will enter the 
MX240 over a couple different interfaces on a dozen or so different VLANs from 
different carriers.   I want to merge all of the traffic together so the SRXs 
and be on the same broadcast domain, L2 network so they can talk to each other 
(same /24 subnet) and handle MPLS.  QinQ from the SRXs isn’t needed.  The MX240 
needs to pass the traffic but not participate in the MPLS or L3 traffic at all, 
just handle the bridging.

 I have a ping running that goes though ge-2/1/5.200 to ge-2/3/9.10.   
Wireshark on the ge-2/3/9 side shows the ARP requests coming in with VLAN 200 
tag still attached.  I need the MX240 to pop the 200 tag and add the 10 tag (or 
20,21,22, etc depending on the unit).

 I tried input-vlan-map pop and output-vlan-map push on the interfaces but then 
I see the ARP requests with no VLAN tag.

Should I use a different instance-type  (vpls, l2vpn??)


I’m set this up in my lab as a virtual-switch
routing-instance {

SRXNET {
description “A bunch of SRXes";
instance-type virtual-switch;
bridge-domains {
SRXNET {
domain-type bridge;
interface ge-2/1/5.200;
interface ge-2/3/9.10;
interface ge-2/3/9.20;
interface ge-2/3/9.21;
interface ge-2/3/9.22;
interface ge-2/3/9.23;
interface ge-2/3/9.24;
interface ge-2/3/9.25;
interface ge-2/3/9.26;
}
}
}

ge-2/1/5 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;

unit 200 {
encapsulation vlan-bridge;
vlan-id 200;
family bridge;
}
}

ge-2/3/9 {
flexible-vlan-tagging;
speed 100m;
encapsulation flexible-ethernet-services;
unit 10 {
encapsulation vlan-bridge;
vlan-id 10;
family bridge;
}
unit 20 {
encapsulation vlan-bridge;
vlan-id 20;
family bridge;
}
unit 21 {
encapsulation vlan-bridge;
vlan-id 21;
family bridge;
}
unit 22 {
encapsulation vlan-bridge;
vlan-id 22;
family bridge;
}
unit 23 {
encapsulation vlan-bridge;
vlan-id 23;
family bridge;
}
unit 24 {
encapsulation vlan-bridge;
vlan-id 24;
family bridge;
}
unit 25 {
encapsulation vlan-bridge;
vlan-id 25;
family bridge;
}
unit 26 {   
encapsulation vlan-bridge;
vlan-id 26;
family bridge;
}


Thanks


—

Matthew Crocker
President - Crocker Communications, Inc.
Managing Partner - Crocker Telecommunications, LLC
E: matt...@corp.crocker.com
E: matt...@crocker.com



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

Re: [j-nsp] force-64bit

[Chris Adams]

Once upon a time, Jesper Skriver  said:
> The flip side is that all pointers are twice the size, in an application like 
> rpd I'd expect most of the memory usage to be pointers, so we can expect ~2x 
> the memory usage. That coupled with memory access typically being the 
> bottleneck makes it less obvious that the same code will run faster when 
> compiled as 64bit. 

That's the eternal argument around larger address space.  But the
previous post was right; the 32-bit x86 architecture is pretty severely
register limited, and the 64-bit x86_64 extentsions helped with that a
lot.  Lots of things that had to go to RAM and back in 32-bit code can
now be passed in registers, which saves a lot of overhead (this is shown
in lots of places).

In architectures without the limited register set, moving from 32 to 64
bit was not as clear cut, but x86 to x86_64 is a big improvement.

Also, you'd only see double the RAM usage if every single thing stored
was a pointer (and no actual data was stored somehow).  Since that's
obviously not the case, RAM usage would be nowhere near double.

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

Re: [j-nsp] force-64bit

[Jesper Skriver]

> On 01 Jun 2016, at 21:29, Vincent Bernat  wrote:
> 
> The other benefit would be the ability for rpd to make use of more CPU
> registers and to be faster. On average, one could expect a 20% speedup
> when recompiling for x86-64. I have absolutely no idea if such number
> would apply to rpd.

The flip side is that all pointers are twice the size, in an application like 
rpd I'd expect most of the memory usage to be pointers, so we can expect ~2x 
the memory usage. That coupled with memory access typically being the 
bottleneck makes it less obvious that the same code will run faster when 
compiled as 64bit. 

/Jesper


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

Re: [j-nsp] force-64bit

[raf]

Le 02/06/2016 à 00:02, Olivier Benghozi a écrit :

This is not completely contradictory with the Juniper doc ; as usual with the 
Juniper doc written with feet, you have to read between the lines:

-> Written in the doc: "Tip: You need not restart the routing protocol process (rpd) 
to use the 64-bit mode"
-> To be understood: "Joke: You need not restart rpd yourself, because it will be 
done automatically at the commit and ruin your network for about 10 minutes".




The famous commit roulette :)
It was a good addition if juniper can provide a way of seeing what will 
be impacted during a commit. (with a pub/sub model it should be trivial).


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