Well using the one word for both of them as bridging sounds good as it
actually is using bridging protocol for learn, forwarding, flooding,
filtering, and aging which is what is being done in case of
ethernet-switching too. Whether bridging Interfaces or Vlans :).
Atif Saleem
On Wed, Aug 15,
On (2012-08-14 13:09 -0700), Jonathan Lassoff wrote:
Moral of the story, as I see it: avoid static routing.
This is bit circular. Vendor had software defect in ARP and you arrived to
conclusion consequently we should not use static routing, but dynamic.
However our choice of configuration
On Wed, Aug 15, 2012 at 12:13 AM, Saku Ytti s...@ytti.fi wrote:
On (2012-08-14 13:09 -0700), Jonathan Lassoff wrote:
Moral of the story, as I see it: avoid static routing.
This is bit circular. Vendor had software defect in ARP and you arrived to
conclusion consequently we should not use
On (2012-08-15 00:21 -0700), Jonathan Lassoff wrote:
My thing was more along the lines that routing (RIB) / next-hop path
information ought to be learned and/or monitored over protocols that
ride that same path, so that any path failures are detected and routed
around.
In static route they
There is no difference between the two.
...Until You jump on an SRX branch where you use both for completely different
things (eg: transparent mode) ; )
My (albeit limited) understanding is that bridging interfaces/bridge-domains
aren't bound to a specific ingress VLAN tag, allowing you
Hi,
I have a design question regarding MPLS.
I'm planning to create a MPLS rings with 4-8 SRX240 devices in packet mode
and the main purpose is L3VPN/VPLS
p1-p2-p3-p4-p5-p1 (p5 connects back to p1)
My budget is low for this and the srx240 is cheap, we will push max 1Gbps.
For example in some
On 15/08/12 15:29, Johan Borch wrote:
Hi,
I have a design question regarding MPLS.
I'm planning to create a MPLS rings with 4-8 SRX240 devices in packet mode
and the main purpose is L3VPN/VPLS
p1-p2-p3-p4-p5-p1 (p5 connects back to p1)
My budget is low for this and the srx240 is cheap, we
Phill,
Could ou please share some juniper links or configurations on how about
to configure SRX boxes with MPLS in a RING topology ?
Are you using L3 MPLS VPN or L2 VPLS or EoMPLS ?
Is it possible to share some configurations or links ?
Thanks a lot,
Giuliano
On 15/08/12 15:29, Johan
On 15/08/12 16:50, GIULIANO (WZTECH) wrote:
Phill,
Could ou please share some juniper links or configurations on how about
to configure SRX boxes with MPLS in a RING topology ?
Sure.
I'm assuming you have a basic Juniper layer3 provider core configured.
In particular, you'll want an IGP
I'm wondering if I can do a simple server load balancer using a SRX.
Example:
Server A offers up service on port .
Server B has the same service.
If Server A goes offline, send traffic over to server B.
Resume when Server A becomes available again.
One thought is to use something like
The SRX isn't a loadbalancer.
Use something sensible like haproxy, nginx, etc.
Scott
On Wed, Aug 15, 2012 at 12:07 PM, OBrien, Will obri...@missouri.edu wrote:
I'm wondering if I can do a simple server load balancer using a SRX.
Example:
Server A offers up service on port .
Server B
Maybe d-nat pool is what you are looking for. I am not sure if there
is a health-check though - you may need to read documentation on that.
nick
On Wed, Aug 15, 2012 at 8:07 PM, OBrien, Will obri...@missouri.edu wrote:
I'm wondering if I can do a simple server load balancer using a SRX.
On 8/15/12 9:34 AM, Scott T. Cameron wrote:
The SRX isn't a loadbalancer.
Use something sensible like haproxy, nginx, etc.
We do layer 3 ecmp in front of our load balancer tier and I imagine that
would be fairly straight forward to implement with an srx. each
destination to be load balanced
On Wed, Aug 15, 2012 at 12:53 PM, joel jaeggli joe...@bogus.com wrote:
On 8/15/12 9:34 AM, Scott T. Cameron wrote:
The SRX isn't a loadbalancer.
Use something sensible like haproxy, nginx, etc.
We do layer 3 ecmp in front of our load balancer tier and I imagine that
would be fairly
Hi JP and all,
thanks for all the replies. show policer shows:
ad...@ffm01.rt show policer
Policers:
Name Packets
__default_arp_policer__ 1140304
__policer_tmpl__-term 0
__policer_tmpl__-fc0
it represents that the default arp pollicer is dropping the arp packets.
You dont need to apply this filter on any interface. It is applied on all
interfaces by default ... Default values of the arp policer is fine-tuned
such that it does not interrupt normal arp mechanism .. the counter in the
Test
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Johan,
You might want to know that VRRPv6 isn't supported on the branch SRX so if you
need IPv6 resiliency, you're out of luck.
If you need both v4 and v6 node resiliency, the only way to do it now is
clustering which is a whole different beast altogether.
On Aug 15, 2012, at 10:29 PM, Johan
18 matches
Mail list logo