Re: [j-nsp] R: EX4550: storm-control on commit
Hi,
I also have 2 x EX4550 in VC with storm-control enabled, but it never
happens to me to get that message on commit;
I have this configuration for storm-control:
set ethernet-switching-options storm-control interface all
I am wondering what is your configuration for the ae2.0 interface:
can you check that ? which physical interfaces are on ae2 ? what are
their configurations? Maybe there is a loop somewhere in between
those.
we have this one:
interface all {
level 1;
}
ae2 is actually a LACP channel containing 2x 10GE to a customer.
Generally yes there might be a potential loop behind. The curious part
is however that this message mostly appears on commits and not
necessarily also without a commit. This is not limited to our EX4550 VC
but can also be seen on some EX3300 ToR switches. Typically all with
storm-control level 1-5 configured.
Also, can you check your log messages ? if you do a "help syslog
ESWD_ST_CTL_ERROR_IN_EFFECT" it tells you:
Yes, that happens every once in a while. Although I cannot guarantee
this is not loop-caused, the impact to our network caused by loops is
was typically clearly visible by disappearing ARP entries on the routers
and/or jumping MACs (at least until we set storm-control low enough
which is even < 1% so we use the bandwidth option here).
Best,
Jeff
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NAT & routing instances
Perfect thanks! I plan to test it next week but great to hear that my
understanding is correct. Unfortunately the Juniper SRX documentation is
very sparse on how this exactly works.
Best,
/
On Fri, Jan 27, 2017 at 5:39 AM, Per Westerlund wrote:
> That should be enough. Forward traffic destination is resolved in the
> target RI, and the return traffic egress interface is determined by the
> session set up by the first packet. Note that the security policies should
> match on post-NAT zones/addresses.
>
> /Per
>
> > 27 jan. 2017 kl. 09:52 skrev Brian Spade :
> >
> > Hey juniper friends,
> >
> > I have a few ISP links connected to an SRX. The ISP interfaces are in
> the
> > UNTRUST zone and routing instance. I want to setup some static NATs to
> LAN
> > side devices that reside in the master routing instance and also the DMZ
> > routing instance. There is no leaking down between the master and DMZ
> > routing instances to the UNTRUST routing instance, except for the UNTRUST
> > leaking a 0/0 route.
> >
> > Can I just use the 'routing-instance' option to allow a packet that
> > ingresses the untrust to reach a host in the DMZ routing instance? Does
> > this just work, or do I still need to leak routes from DMZ to UNTRUST?
> >
> > rule-set STATIC-NAT {
> >from zone UNTRUST;
> >rule STATIC-NAT {
> >match {
> >destination-address-name STATIC-NAT-EXT-1;
> >destination-port 443;
> >}
> >then {
> >static-nat {
> >prefix-name {
> >STATIC-NAT-INT-1;
> >mapped-port 4443;
> >routing-instance DMZ; <- THIS
> >}
> >}
> >}
> >}
> > }
> >
> > Thanks!
> > /bs
> > ___
> > 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] BGP add-path on QFX
❦ 27 janvier 2017 20:08 +0300, Alexandre Snarskii : >> > No ideas on what can be wrong with your configuration :( >> > We run add-path on most MXes without any problems. Just tried with QFX >> > (not running bgp actually), add-path command is not hidden for me and >> > commit >> > check succeeds: >> >> Thanks for checking, that's helpful! >> >> In fact, I am using routing instances. Like you, I can get add-path >> send/receive outside a routing instance, but inside, add-path is >> hidden. I assumed this was independent of the routing instance >> (configured type virtual-router), so I didn't bother to check that. >> >> Does "set routing-instances rr1 protocols bgp group apath family inet >> unicast add-path ..." complete for you? > > Looks like routing-instances is the difference. Within routing-instance > add-path does not complete for me too, neither on QFX nor on MX. Thanks for the confirmation. That's a pity for a control-plane feature. I will rework the configuration to not use routing instances. -- If one cannot enjoy reading a book over and over again, there is no use in reading it at all. -- Oscar Wilde ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP add-path on QFX
On Fri, Jan 27, 2017 at 05:00:59PM +0100, Vincent Bernat wrote:
> >> I have upgraded some QFX to 16.1R3 but there is no difference with
> >> 14.1X53-D40: add-path is an hidden command and only "receive" is
> >> available ("send" is not accepted):
> >>
> >> set protocols bgp group batman family inet unicast add-path send ...
> >>
> >> I have also tried on MX104 running 14.1R8. Feature explorer says this
> >> should be supported since 13.2R2. But I am in the exact same situation:
> >> add-path is a hidden command and only "receive" is available.
> >>
> >> I wonder if I am not missing something obvious. Any tip would be
> >> appreciated!
> >
> > No ideas on what can be wrong with your configuration :(
> > We run add-path on most MXes without any problems. Just tried with QFX
> > (not running bgp actually), add-path command is not hidden for me and
> > commit
> > check succeeds:
>
> Thanks for checking, that's helpful!
>
> In fact, I am using routing instances. Like you, I can get add-path
> send/receive outside a routing instance, but inside, add-path is
> hidden. I assumed this was independent of the routing instance
> (configured type virtual-router), so I didn't bother to check that.
>
> Does "set routing-instances rr1 protocols bgp group apath family inet
> unicast add-path ..." complete for you?
Looks like routing-instances is the difference. Within routing-instance
add-path does not complete for me too, neither on QFX nor on MX.
> --
> ROMEO:Courage, man; the hurt cannot be much.
> MERCUTIO: No, 'tis not so deep as a well, nor so wide
> as a church-door; but 'tis enough, 'twill serve.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP add-path on QFX
❦ 27 janvier 2017 18:34 +0300, Alexandre Snarskii :
>> I have upgraded some QFX to 16.1R3 but there is no difference with
>> 14.1X53-D40: add-path is an hidden command and only "receive" is
>> available ("send" is not accepted):
>>
>> set protocols bgp group batman family inet unicast add-path send ...
>>
>> I have also tried on MX104 running 14.1R8. Feature explorer says this
>> should be supported since 13.2R2. But I am in the exact same situation:
>> add-path is a hidden command and only "receive" is available.
>>
>> I wonder if I am not missing something obvious. Any tip would be
>> appreciated!
>
> No ideas on what can be wrong with your configuration :(
> We run add-path on most MXes without any problems. Just tried with QFX
> (not running bgp actually), add-path command is not hidden for me and commit
> check succeeds:
Thanks for checking, that's helpful!
In fact, I am using routing instances. Like you, I can get add-path
send/receive outside a routing instance, but inside, add-path is
hidden. I assumed this was independent of the routing instance
(configured type virtual-router), so I didn't bother to check that.
Does "set routing-instances rr1 protocols bgp group apath family inet
unicast add-path ..." complete for you?
--
ROMEO: Courage, man; the hurt cannot be much.
MERCUTIO: No, 'tis not so deep as a well, nor so wide
as a church-door; but 'tis enough, 'twill serve.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP add-path on QFX
On Fri, Jan 27, 2017 at 03:02:09PM +0100, Vincent Bernat wrote:
> Hey!
>
> I am using some QFX as route reflectors and would like to use BGP
> add-path feature. The documentation says that QFX is a supported
> platform[0] while the feature explorer says no QFX has support for
> that[1].
>
> [0]:
> http://www.juniper.net/techpubs/en_US/junos16.1/topics/example/bgp-add-path.html
> [1]:
> https://pathfinder.juniper.net/feature-explorer/feature-info.html?fKey=3294&fn=For+internal+BGP+(IBGP),+advertise+multiple+paths+to+a+destination
>
> I have upgraded some QFX to 16.1R3 but there is no difference with
> 14.1X53-D40: add-path is an hidden command and only "receive" is
> available ("send" is not accepted):
>
> set protocols bgp group batman family inet unicast add-path send ...
>
> I have also tried on MX104 running 14.1R8. Feature explorer says this
> should be supported since 13.2R2. But I am in the exact same situation:
> add-path is a hidden command and only "receive" is available.
>
> I wonder if I am not missing something obvious. Any tip would be
> appreciated!
No ideas on what can be wrong with your configuration :(
We run add-path on most MXes without any problems. Just tried with QFX
(not running bgp actually), add-path command is not hidden for me and commit
check succeeds:
--- JUNOS 14.1X53-D35.3 built 2016-02-29 23:35:46 UTC
[...]
snar@QFX5100# set protocols bgp group apath family inet unicast ?
Possible completions:
<[Enter]>Execute this command
> accepted-prefix-limit Limit maximum number of prefixes accepted from a peer
> add-path Advertise multiple paths to peer
> aigp Allow sending and receiving of AIGP attribute
+ apply-groups Groups from which to inherit configuration data
[...]
snar@QFX5100# show | compare
[edit protocols]
+ bgp {
+ group apath {
+ family inet {
+ unicast {
+ add-path {
+ send {
+ path-count 6;
+ }
+ }
+ }
+ }
+ }
+ }
{master:0}[edit]
snar@QFX5100# commit check
[edit protocols]
'bgp'
warning: requires 'bgp' license
configuration check succeeds
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP add-path on QFX
❦ 27 janvier 2017 14:17 GMT, :
>> I am using some QFX as route reflectors and would like to use BGP add-path
>> feature. The documentation says that QFX is a supported platform[0] while
>> the feature explorer says no QFX has support for that[1].
>>
>> [0]:
>> http://www.juniper.net/techpubs/en_US/junos16.1/topics/example/bgp-
>> add-path.html
>> [1]: https://pathfinder.juniper.net/feature-explorer/feature-
>> info.html?fKey=3294&fn=For+internal+BGP+(IBGP),+advertise+multiple+pat
>> hs+to+a+destination
>>
>> I have upgraded some QFX to 16.1R3 but there is no difference with
>> 14.1X53-D40: add-path is an hidden command and only "receive" is available
>> ("send" is not accepted):
>>
>> set protocols bgp group batman family inet unicast add-path send ...
>>
>> I have also tried on MX104 running 14.1R8. Feature explorer says this
> should
>> be supported since 13.2R2. But I am in the exact same situation:
>> add-path is a hidden command and only "receive" is available.
>>
>
> Is the RR use in MPLS-VPNs environment or just pure L3-IPv4/6 environment?
> If it's MPLS-VPNs environment, then you don't need add-path.
It's in a pure L3-IPv4/IPv6.
> Also if ORR is supported on QFX by any chance you might want to try that
> instead of add-path.
> Does it take the below?
> set protocols bgp group batman optimal-route-reflection
Yes, it's accepted. But my goal is to get load balancing to a set of
hosts, not optimal path (all routes are equal in my setup). My
understanding of the above option is that it still selects only one
route.
--
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP add-path on QFX
Hi Vincent,
> Vincent Bernat
> Sent: Friday, January 27, 2017 2:02 PM
>
> Hey!
>
> I am using some QFX as route reflectors and would like to use BGP add-path
> feature. The documentation says that QFX is a supported platform[0] while
> the feature explorer says no QFX has support for that[1].
>
> [0]:
> http://www.juniper.net/techpubs/en_US/junos16.1/topics/example/bgp-
> add-path.html
> [1]: https://pathfinder.juniper.net/feature-explorer/feature-
> info.html?fKey=3294&fn=For+internal+BGP+(IBGP),+advertise+multiple+pat
> hs+to+a+destination
>
> I have upgraded some QFX to 16.1R3 but there is no difference with
> 14.1X53-D40: add-path is an hidden command and only "receive" is available
> ("send" is not accepted):
>
> set protocols bgp group batman family inet unicast add-path send ...
>
> I have also tried on MX104 running 14.1R8. Feature explorer says this
should
> be supported since 13.2R2. But I am in the exact same situation:
> add-path is a hidden command and only "receive" is available.
>
Is the RR use in MPLS-VPNs environment or just pure L3-IPv4/6 environment?
If it's MPLS-VPNs environment, then you don't need add-path.
Also if ORR is supported on QFX by any chance you might want to try that
instead of add-path.
Does it take the below?
set protocols bgp group batman optimal-route-reflection
adam
netconsultings.com
::carrier-class solutions for the telecommunications industry::
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] BGP add-path on QFX
Hey!
I am using some QFX as route reflectors and would like to use BGP
add-path feature. The documentation says that QFX is a supported
platform[0] while the feature explorer says no QFX has support for
that[1].
[0]:
http://www.juniper.net/techpubs/en_US/junos16.1/topics/example/bgp-add-path.html
[1]:
https://pathfinder.juniper.net/feature-explorer/feature-info.html?fKey=3294&fn=For+internal+BGP+(IBGP),+advertise+multiple+paths+to+a+destination
I have upgraded some QFX to 16.1R3 but there is no difference with
14.1X53-D40: add-path is an hidden command and only "receive" is
available ("send" is not accepted):
set protocols bgp group batman family inet unicast add-path send ...
I have also tried on MX104 running 14.1R8. Feature explorer says this
should be supported since 13.2R2. But I am in the exact same situation:
add-path is a hidden command and only "receive" is available.
I wonder if I am not missing something obvious. Any tip would be
appreciated!
--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NAT & routing instances
That should be enough. Forward traffic destination is resolved in the target
RI, and the return traffic egress interface is determined by the session set up
by the first packet. Note that the security policies should match on post-NAT
zones/addresses.
/Per
> 27 jan. 2017 kl. 09:52 skrev Brian Spade :
>
> Hey juniper friends,
>
> I have a few ISP links connected to an SRX. The ISP interfaces are in the
> UNTRUST zone and routing instance. I want to setup some static NATs to LAN
> side devices that reside in the master routing instance and also the DMZ
> routing instance. There is no leaking down between the master and DMZ
> routing instances to the UNTRUST routing instance, except for the UNTRUST
> leaking a 0/0 route.
>
> Can I just use the 'routing-instance' option to allow a packet that
> ingresses the untrust to reach a host in the DMZ routing instance? Does
> this just work, or do I still need to leak routes from DMZ to UNTRUST?
>
> rule-set STATIC-NAT {
>from zone UNTRUST;
>rule STATIC-NAT {
>match {
>destination-address-name STATIC-NAT-EXT-1;
>destination-port 443;
>}
>then {
>static-nat {
>prefix-name {
>STATIC-NAT-INT-1;
>mapped-port 4443;
>routing-instance DMZ; <- THIS
>}
>}
>}
>}
> }
>
> Thanks!
> /bs
> ___
> 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] R: EX4550: storm-control on commit
Hi there, I also have 2 x EX4550 in VC with storm-control enabled, but it never happens to me to get that message on commit; I have this configuration for storm-control: set ethernet-switching-options storm-control interface all I am wondering what is your configuration for the ae2.0 interface: can you check that ? which physical interfaces are on ae2 ? what are their configurations? Maybe there is a loop somewhere in between those. Also, can you check your log messages ? if you do a "help syslog ESWD_ST_CTL_ERROR_IN_EFFECT" it tells you: Name: ESWD_ST_CTL_ERROR_IN_EFFECT Message: : storm control in effect on the port Help: Storm control error in effect an interface Description: This condition occurs when storm control error condition is detected. Type: Error: An error occurred Severity: alert Facility: LOG_DAEMON So I think it can´t be overlooked. I hope this helps you Cheers Lucio -Messaggio originale- Da: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Per conto di Jeff Meyers Inviato: giovedì 26 gennaio 2017 11:56 A: juniper-nsp@puck.nether.net Oggetto: [j-nsp] EX4550: storm-control on commit Hello everybody, we are having a kind of strange haviour here. It's not really an issue but at least a curiousity. On a couple of EX4550 in VC we have storm-control enabled. This works fine so far. But on every commit, we see a "storm-control in effect" message in our logs: Jan 26 11:50:45 cs0 eswd[1298]: ESWD_ST_CTL_ERROR_IN_EFFECT: ae2.0: storm control in effect on the port Jan 26 11:51:47 cs0 eswd[1298]: ESWD_ST_CTL_ERROR_IN_EFFECT: ae2.0: storm control in effect on the port I wonder where this comes from. I doubt that this is real since most commits only contain a vlan configuration change for some ports but no major adjustments. Maybe someone can bring some light in this. Thanks! ___ 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] NAT & routing instances
Hey juniper friends,
I have a few ISP links connected to an SRX. The ISP interfaces are in the
UNTRUST zone and routing instance. I want to setup some static NATs to LAN
side devices that reside in the master routing instance and also the DMZ
routing instance. There is no leaking down between the master and DMZ
routing instances to the UNTRUST routing instance, except for the UNTRUST
leaking a 0/0 route.
Can I just use the 'routing-instance' option to allow a packet that
ingresses the untrust to reach a host in the DMZ routing instance? Does
this just work, or do I still need to leak routes from DMZ to UNTRUST?
rule-set STATIC-NAT {
from zone UNTRUST;
rule STATIC-NAT {
match {
destination-address-name STATIC-NAT-EXT-1;
destination-port 443;
}
then {
static-nat {
prefix-name {
STATIC-NAT-INT-1;
mapped-port 4443;
routing-instance DMZ; <- THIS
}
}
}
}
}
Thanks!
/bs
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
