Re: [j-nsp] QFX 5100 can you mix vlan-ccc + vlan-bridge on the same interface with 14.1X53-D43.7

2017-09-28 Thread Alain Hebert 

    Well problem[S],

    That why I'm looking to see if our lab is working out of luck, 
because we're mixing vlan-bridge and vlan-ccc units on the same ae0 and 
xe-*, and everything is fine for over a month of burn testing.


    Thanks for your time.


-


The context,

    Our 17.x lab of QFX with a MX240 and vMX is working fine.

    We got a pretty good MPLS alphabet soup recipe ready for 
production.  MPLS+ISIS+BGP Underlay, aeX + vlan-bridge + ccc mixing 
together, EVPN+VXLAN on their own port, VRFs, without any data plane 
drama, etc.


    So taking from that success...


The problem,

    We're running some QFX5100 in VCF in production, with 14.x, and 
added a VLAN-CCC on a port with other unit's in VLAN-BRIDGE which pretty 
much made the data plane hate us about 10h later, when we tried to 
figure out why there was no data thru that circuit.


    And by hating, I mean spewing ~300k/pps of unknowned traffic badly 
encapsulated.


    ( The fix was delete the port configuration, commit, rollback 2, 
commit )


    Jeff pretty much pointed us to a PR mentioning that type of 
behavior on 14.x train...



The solution,

    Was to hairpin 2 ports on the QFX5100/VCF stack.  1 port being only 
the 2 vlan-ccc and the other being the 2 vlan-bridge of the VLANs we 
wanted to CCC out of that aeX.


-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 09/28/17 12:47, Pavel Lunin wrote:

I really doubt that it's supported on QFX5100. Not 100% sure though.

But what's your problem? It does not work in this combination or does 
not work at all?


IIRC, ex4600/qfx5100 do not support control word on pseudowires as 
well (like ex4500/4550). So if you have something like an MX on the 
other side, Martini signaling comes up but you see no traffic, try 
no-control-word.


Kind regards,
Pavel

28 сент. 2017 г. 4:12 ПП пользователь "Alain Hebert" 
> написал:


Been crashing hard on google this morning...  Cannot find any hint
of limitations on the QFX platform for this case.

    Sample config

flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 111 {
    encapsulation vlan-ccc;
    vlan-id 111;
    input-vlan-map pop;
    output-vlan-map push;

}
unit 222 {
    encapsulation vlan-ccc;
    vlan-id 222;
    input-vlan-map pop;
    output-vlan-map push;

}
unit 333 {
    encapsulation vlan-bridge
    vlan-id 333;
}

    Just no input / output with:

        Model: qfx5100-48s-6q
        Junos: 14.1X53-D43.7

    But it works in our lab

        Model: qfx5100-48s-6q
        Junos: 17.2R1.13

-- 
-

Alain Hebert aheb...@pubnix.net 
PubNIX Inc.
50 boul. St-Charles

P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net   Fax:
514-990-9443 

___
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] deactivate routing-options forwarding-table

2017-09-28 Thread craig washington 
Awesome.

Thanks again. I went ahead and ran the below and it removed the deactivate 
command and no impact 


"delete routing-options forwarding-table export exp-to-fwd"


show | compare

-   inactive: forwarding-table {
-   export exp-to-fwd;
-   }



From: juniper-nsp  on behalf of Eric Van 
Tol 
Sent: Thursday, September 28, 2017 5:11 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] deactivate routing-options forwarding-table

> I do see where it looks like an export policy was applied but there is
> nothing in it
>
> "set routing-options forwarding-table export exp-to-fwd"
>
> show configuration policy-options policy-statement exp-to-fwd (no output)
>
>
> show configuration | display set | match exp-to-fwd (only thing found)
> set routing-options forwarding-table export exp-to-fwd

My guess is that someone deleted the exp-to-fwd policy, tried to commit, and 
saw it was being called from within the forwarding table. Rather than delete 
that line, they deactivated it, perhaps with a reason, but there should be no 
issues just removing that line altogether. The 'deactivate' just ignores the 
configuration altogether, essentially the same as not having any explicit 
forwarding-table configuration.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
juniper-nsp Info Page - 
puck.nether.net
puck.nether.net
To see the collection of prior postings to the list, visit the juniper-nsp 
Archives. Using juniper-nsp: To post a message to all the list members ...


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

Re: [j-nsp] deactivate routing-options forwarding-table

2017-09-28 Thread Eric Van Tol 
> I do see where it looks like an export policy was applied but there is
> nothing in it
> 
> "set routing-options forwarding-table export exp-to-fwd"
> 
> show configuration policy-options policy-statement exp-to-fwd (no output)
> 
> 
> show configuration | display set | match exp-to-fwd (only thing found)
> set routing-options forwarding-table export exp-to-fwd

My guess is that someone deleted the exp-to-fwd policy, tried to commit, and 
saw it was being called from within the forwarding table. Rather than delete 
that line, they deactivated it, perhaps with a reason, but there should be no 
issues just removing that line altogether. The 'deactivate' just ignores the 
configuration altogether, essentially the same as not having any explicit 
forwarding-table configuration.

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

Re: [j-nsp] QFX 5100 can you mix vlan-ccc + vlan-bridge on the same interface with 14.1X53-D43.7

2017-09-28 Thread Pavel Lunin 
I really doubt that it's supported on QFX5100. Not 100% sure though.

But what's your problem? It does not work in this combination or does not
work at all?

IIRC, ex4600/qfx5100 do not support control word on pseudowires as well
(like ex4500/4550). So if you have something like an MX on the other side,
Martini signaling comes up but you see no traffic, try no-control-word.

Kind regards,
Pavel

28 сент. 2017 г. 4:12 ПП пользователь "Alain Hebert" 
написал:

> Been crashing hard on google this morning...  Cannot find any hint of
> limitations on the QFX platform for this case.
>
> Sample config
>
> flexible-vlan-tagging;
> mtu 9216;
> encapsulation flexible-ethernet-services;
> unit 111 {
> encapsulation vlan-ccc;
> vlan-id 111;
> input-vlan-map pop;
> output-vlan-map push;
>
> }
> unit 222 {
> encapsulation vlan-ccc;
> vlan-id 222;
> input-vlan-map pop;
> output-vlan-map push;
>
> }
> unit 333 {
> encapsulation vlan-bridge
> vlan-id 333;
> }
>
> Just no input / output with:
>
> Model: qfx5100-48s-6q
> Junos: 14.1X53-D43.7
>
> But it works in our lab
>
> Model: qfx5100-48s-6q
> Junos: 17.2R1.13
>
> --
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> 
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>
> ___
> 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] deactivate routing-options forwarding-table

2017-09-28 Thread craig washington 
Hello all,


I am going through some configurations on some of our routers and noticed one 
router has the below command on it:

"deactivate routing-options forwarding-table"

Trying to understand what this command is actually doing as the forwarding 
table has routes and the router is working as expected.

Will activating this cause a service disruption?

I do see where it looks like an export policy was applied but there is nothing 
in it

"set routing-options forwarding-table export exp-to-fwd"

show configuration policy-options policy-statement exp-to-fwd (no output)


show configuration | display set | match exp-to-fwd (only thing found)
set routing-options forwarding-table export exp-to-fwd

My overall intention is to add a load balance policy to the device but saw this 
so I wanted to investigate.

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

Re: [j-nsp] RSTP best practices on ELS switching (EX2300/3400/4300)

2017-09-28 Thread Chuck Anderson 
Yes, I'm using bpdu-block-on-edge with disable-timeout 3600 (1 hour).
I'm also using mac-limits with port shutdown.

Until a location is ready for IPv6:

set interfaces interface-range EDGE member-range ge-0/0/0 to ge-0/0/47
set interfaces interface-range EDGE unit 0 family ethernet-switching filter 
input DROP-IPv6
set interfaces interface-range EDGE unit 0 family ethernet-switching filter 
output DROP-IPv6
set firewall family ethernet-switching filter DROP-IPv6 term DROP-IPv6 from 
ether-type 0x86dd
set firewall family ethernet-switching filter DROP-IPv6 term DROP-IPv6 then 
discard
set firewall family ethernet-switching filter DROP-IPv6 term DROP-IPv6 then 
count DROP-IPv6
set firewall family ethernet-switching filter DROP-IPv6 term ACCEPT then accept

Storm-Control set to 100 Mbps (this needs to be adjusted according to normal 
baseline):

set interfaces interface-range EDGE unit 0 family ethernet-switching 
storm-control SC-EDGE
set forwarding-options storm-control-profiles SC-EDGE all bandwidth-level 10

BPDU block:

set protocols layer2-control bpdu-block disable-timeout 3600
set protocols rstp interface EDGE edge
set protocols rstp bpdu-block-on-edge

MAC-limit (adjust for normal baseline of # of MACs per port):

set switch-options interface EDGE interface-mac-limit 16
set switch-options interface EDGE interface-mac-limit packet-action shutdown

On Thu, Sep 28, 2017 at 09:43:26PM +1000, Chris Lee via juniper-nsp wrote:
> Hi All,
> 
> Interested to know what others have as their RSTP best practice setups for
> access-layer switches in the ELS platform, specifically EX2300/3400/4300's
> 
> Until today I had thought that having defined my access interfaces (to end
> devices like PC's/printers etc) with "edge" and "no-root-port" was offering
> protection from people plugging in random stuff like other switches.
> 
> After some more research it looks like I should probably be defining
> bpdu-block-on-edge,so interested to know if others are defining this along
> with a disable-timeout setting like 5 minutes, or do you not generally
> bother with a disable-timeout and manually clear these if they occur ?
> 
> Options I'm looking at defining :-
> 
> [edit protocols]
> +   layer2-control {
> +   bpdu-block {
> +   disable-timeout 300;
> +   }
> +   }
> [edit protocols rstp]
> +   bpdu-block-on-edge;
> 
> Thanks,
> Chris
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] QFX 5100 can you mix vlan-ccc + vlan-bridge on the same interface with 14.1X53-D43.7

2017-09-28 Thread Alain Hebert 
    Been crashing hard on google this morning...  Cannot find any hint 
of limitations on the QFX platform for this case.


    Sample config

flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 111 {
    encapsulation vlan-ccc;
    vlan-id 111;
    input-vlan-map pop;
    output-vlan-map push;

}
unit 222 {
    encapsulation vlan-ccc;
    vlan-id 222;
    input-vlan-map pop;
    output-vlan-map push;

}
unit 333 {
    encapsulation vlan-bridge
    vlan-id 333;
}

    Just no input / output with:

        Model: qfx5100-48s-6q
        Junos: 14.1X53-D43.7

    But it works in our lab

        Model: qfx5100-48s-6q
        Junos: 17.2R1.13

--
-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

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

[j-nsp] RSTP best practices on ELS switching (EX2300/3400/4300)

2017-09-28 Thread Chris Lee via juniper-nsp 
Hi All,

Interested to know what others have as their RSTP best practice setups for
access-layer switches in the ELS platform, specifically EX2300/3400/4300's

Until today I had thought that having defined my access interfaces (to end
devices like PC's/printers etc) with "edge" and "no-root-port" was offering
protection from people plugging in random stuff like other switches.

After some more research it looks like I should probably be defining
bpdu-block-on-edge,so interested to know if others are defining this along
with a disable-timeout setting like 5 minutes, or do you not generally
bother with a disable-timeout and manually clear these if they occur ?

Options I'm looking at defining :-

[edit protocols]
+   layer2-control {
+   bpdu-block {
+   disable-timeout 300;
+   }
+   }
[edit protocols rstp]
+   bpdu-block-on-edge;

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