Re: [j-nsp] fxp0.0 interface match in firewall filter doesn't work in JUNOS 12.3R5.7
HI Tore,
Thanks for the heads up - I had earmarked this version for a project so
I'll test around this first.
Cheers,
Graham
On 21 January 2014 14:35, Tore Anderson wrote:
> This is a heads-up to anyone planning to upgrade to 12.3R5.7, especially
> if you don't have easy access to the serial console, but only a firewall
> term such as:
>
> term allow-oob-management {
> from {
> interface fxp0.0;
> }
> then accept;
> }
>
> ...in your lo0.0 input filter (which presumably then goes on to drop all
> unmatched traffic): It simply doesn't work.
>
> I've confirmed on both MX80 and MX240, several times. After a reboot,
> the term just gets skipped, it seems. Deactivating the term, committing,
> and then reactivating it fixes the problem but that might of course be
> easier said than done if locked out of the box.
>
> Terms doing source-address matches seems to work fine.
>
> Tore
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Graham Brown
Twitter - @mountainrescuer
LinkedIn
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] fxp0.0 interface match in firewall filter doesn't work in JUNOS 12.3R5.7
This is a heads-up to anyone planning to upgrade to 12.3R5.7, especially
if you don't have easy access to the serial console, but only a firewall
term such as:
term allow-oob-management {
from {
interface fxp0.0;
}
then accept;
}
...in your lo0.0 input filter (which presumably then goes on to drop all
unmatched traffic): It simply doesn't work.
I've confirmed on both MX80 and MX240, several times. After a reboot,
the term just gets skipped, it seems. Deactivating the term, committing,
and then reactivating it fixes the problem but that might of course be
easier said than done if locked out of the box.
Terms doing source-address matches seems to work fine.
Tore
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VLAN sub-ints and VPLS
Hi Tom, > > Great, no more errors, try to commit again: > > # commit > [edit interfaces ge-0/0/12] > 'unit 0' >vlan map ge-0/0/12: input-vlan-map and output-vlan-map are valid > on untagged interfaces only for ethernet-ccc and ethernet-vpls > encapsulations > error: configuration check-out failed > > But you just told me I need to use tagging? And there is no > ethernet-vpls encapsulation for units. wtf? > > Maybe its just not possible on an SRX, perhaps it doesnt have the > smarts, or maybe Im just missing something really obvious. > > Any help appreciated. Cheers! Switch your physical interface encapsulation to vlan-vpls and try committing again Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VLAN sub-ints and VPLS
Thanks for the responses so far, heres a few more details about what
Im experiencing at the moment.
So I start with something like this:
# show interfaces ge-0/0/12
description "VPLS test interface";
encapsulation ethernet-vpls;
unit 0 {
family vpls;
}
And I want to pop the VLAN header on output and push it on input:
# show interfaces ge-0/0/12
description "VPLS test interface";
encapsulation ethernet-vpls;
unit 0 {
##
## Warning: Only compatible with vpls vlan encapsulations
##
input-vlan-map {
push;
tag-protocol-id 0x8100;
vlan-id 123;
}
##
## Warning: Only compatible with vpls vlan encapsulations
##
output-vlan-map pop;
family vpls;
}
Ok, apply a unit wise encap:
# show interfaces ge-0/0/12
description "VPLS test interface";
encapsulation ethernet-vpls;
unit 0 {
encapsulation vlan-vpls;
input-vlan-map {
push;
tag-protocol-id 0x8100;
vlan-id 123;
}
output-vlan-map pop;
family vpls;
}
No errors, try to commit:
# commit
error: VLAN Encapsulation: Not allowed on untagged interfaces
[edit interfaces ge-0/0/12]
'unit 0'
invalid encapsulation
error: configuration check-out failed
Ok, lets add some VLAN tagging (I did also try regular "vlan-tagging"):
# set interfaces ge-0/0/12 flexible-vlan-tagging
[edit]
# show interfaces ge-0/0/12
description "VPLS test interface";
##
## Warning: Only compatible with vpls vlan encapsulations
##
flexible-vlan-tagging;
encapsulation ethernet-vpls;
unit 0 {
encapsulation vlan-vpls;
input-vlan-map {
push;
tag-protocol-id 0x8100;
vlan-id 123;
}
output-vlan-map pop;
family vpls;
}
Alright we'll change the encap:
# show interfaces ge-0/0/12
description "VPLS test interface";
vlan-tagging;
encapsulation vlan-vpls;
unit 0 {
encapsulation vlan-vpls;
input-vlan-map {
push;
tag-protocol-id 0x8100;
vlan-id 123;
}
output-vlan-map pop;
family vpls;
}
Great, no more errors, try to commit again:
# commit
[edit interfaces ge-0/0/12]
'unit 0'
vlan map ge-0/0/12: input-vlan-map and output-vlan-map are valid
on untagged interfaces only for ethernet-ccc and ethernet-vpls
encapsulations
error: configuration check-out failed
But you just told me I need to use tagging? And there is no
ethernet-vpls encapsulation for units. wtf?
Maybe its just not possible on an SRX, perhaps it doesnt have the
smarts, or maybe Im just missing something really obvious.
Any help appreciated. Cheers!
On 20 January 2014 04:01, Will Orton wrote:
>> ge-0/0/12 {
>> encapsulation ethernet-vpls;
>> unit 0 {
>> encapsulation vlan-vpls;
>> input-vlan-map {
>> push;
>> tag-protocol-id 0x8100;
>> vlan-id 123;
>> }
>> output-vlan-map pop;
>> family vpls;
>> }
>> }
>>
>> but I dont seem to be able to get the right combination of
>> encapsulations and other settings to be able to commit.
>>
>> Q2. Does anyone have a working example I could look at?
>
>
> This works for me on MX to swap .1q 2700 to 603 in the VPLS.
>
> ge-1/0/4 {
> flexible-vlan-tagging; // plain vlan-tagging would be ok too
> encapsulation flexible-ethernet-services;
> unit 2700 {
> encapsulation vlan-vpls;
> vlan-tags outer 2700;
> input-vlan-map {
> swap;
> vlan-id 603;
> }
> output-vlan-map swap;
> family vpls;
> }
>
> So your example looks okay except the encaps on the phys interface.
> I haven't tried on SRX (yet); not sure what is correct if you don't
> want or can't do flexible-ethernet-services.
>
>
>> Also, are VPLS and L2VPN the same thing or different? Once source I
>> read said L2VPN is ptp while VPLS is ptmp.
>
> That's basically it. VPLS being multi-point means your PE routers are
> mac-learning, snd you can of course have a full range of issue like
> layer-2 loops (hence STP coming into play sometimes too). l2vpn is
> simpler.
>
> -Will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mutli-Chassis LAG is not supported on SRX cluster
On Mon, Jan 20, 2014 at 05:37:11AM +, OBrien, Will wrote: > I'm gonna go ahead and say nope. > > SRX supports reth with active/passive nodes. > It doesn't support a lag that uses both nodes active/active as part of the > same ae. > > You can build a reth with multiple ports that uses LACP to build a lag on > each node however. > > I recommend not using AE at all on SRX. It will bring you pain. Just build > them as reth. You can configure LACP on the reth to bundle the links. As the docs from Juniper about LACP+reth http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/interface-security-aggregated-ethernet-lacp-chassis-cluster-understanding.html are not very enlightening, you may want to look at these sample configs: http://juniperguru.wordpress.com/2013/08/04/srx-chassis-cluster-with-redundant-lacp-lag-trunk/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
