Your best bet is probably to write an "event-script" that looks for VRRP
fail-over, and then changes the OSPF metric for the interface.
> So, I've got 2 J6350s in full flow-mode guise on 11.4, but not a cluster.
> I am trying to use VRRP for some HA though.
> Because they're both "on" the same ne
On Thu, Sep 27, 2012 at 9:15 PM, Julien Goodwin
wrote:
>> some hard-coded CoPP "accept" rules that you cannot override by
> I know Trident+ (which this uses) has some weird limitations around this
> area, any idea if this actually is one?
No, I believe it is a choice by Juniper not to change it,
On 28/09/12 10:21, Jeff Wheeler wrote:
> We haven't done any L3 or QFabric. The reason for no L3 is there are
> some hard-coded CoPP "accept" rules that you cannot override by
> configuration which make the switch unusually vulnerable to a DoS
> attack. Juniper says they will not address this, so
On Thu, Sep 27, 2012 at 1:49 PM, Jo Rhett wrote:
> I don't know when Juniper broke this
Hey, Jo, I remember Junos working like this since forever. I'm 100%
sure it has worked like this since way before MX80 existed.
--
Jeff S Wheeler
Sr Network Operator / Innovative Network Concepts
___
On Thu, Sep 27, 2012 at 7:13 PM, Dave Peters - Terabit Systems
wrote:
> We are considering deploying these for a customer's TOR, but I don't have any
> experience with them.
>
> Anybody out there have experience or comments good/bad on these? Anything I
> should know going in?
We have several
We are considering deploying these for a customer's TOR, but I don't have any
experience with them.
Anybody out there have experience or comments good/bad on these? Anything I
should know going in?
Thanks a bunch.
--Dave Peters
___
juniper-nsp mai
On Sep 27, 2012, at 1:21 PM, Kevin Wormington wrote:
> I haven't tested this but I think:
>
> term term1 {
>from {
>protocol [ direct static ];
>interface fxp0.0;
>}
>then reject;
> }
Nice, thanks.
> In our policies we explicitly allow prefixes we want in BGP and deny
This is exactly what I'm looking for, thanks. Although I suspect I need another
one which says static routes with a next hop on fxp0.0 should also be ignored?
I really wish I hadn't wasted 2 days of nonsense with your main tech support
line who couldn't understand the considerations at all. Is t
I haven't tested this but I think:
term term1 {
from {
protocol [ direct static ];
interface fxp0.0;
}
then reject;
}
in your export policy would be a "generic" way to prevent any routes
from the fxp interface from being injected into BGP.
In our policies we explic
It's working as designed.
Junos leaves the BGP advertisements in the hands of the operator. What you've
done is created an export policy that just happens to match fxp0; this isn't
Junos' fault.
If you want to advertise direct interfaces, but exclude fxp0, you could do
something like this that
Well, at least you have a work around, and an indication that this is working
as designed, so perhaps this can save you time with TAC.
I suggest you work with your sales/support team to have an ER filed to alter
the default behavior regarding fxp0 direct routes.
Though, I would add that by defa
Reply to Harry and Doug both since you mostly asked the same question.
On Sep 27, 2012, at 12:13 PM, Harry Reynolds wrote:
> It might help if you posted your BGP export policy. IIRC, there is a
> no-readvertise flag available for a static but not aware of any inherent
> blocking of the advertise
So I guess the million dollar question is what does your BGP export policy
look like?
Reply-all with:
- show protocols bgp
- show policy-options policy-statement
On 9/27/12 10:49 AM, "Jo Rhett" wrote:
>I don't know when Juniper broke this, but I was chasing down a different
>problem earlier
I see that there is a new "best-site" feature in Junos 12.2 for improving
the convergence time in VPLS multi-homed environments:
http://www.juniper.net/techpubs/en_US/junos12.2/topics/example/vpls-multihoming-convergence-example.html
The site-preference election method for determining the prima
Sorry to hear of the frustrations with support.
It might help if you posted your BGP export policy. IIRC, there is a
no-readvertise flag available for a static but not aware of any inherent
blocking of the advertisement of an fxpo address via BGP, more so if your
export permits it.
Here, I ad
I don't know when Juniper broke this, but I was chasing down a different
problem earlier this week and discovered that our Juniper MX80s are advertising
the fxp0 interface's network in BGP announcements. My testing seems to indicate
that it still won't accept packets on other interfaces for this
Hey all,
I've been poking around for a while now but haven't been able to find
anything, which does pretty much suggest this isn't possible.
So, I've got 2 J6350s in full flow-mode guise on 11.4, but not a cluster.
I am trying to use VRRP for some HA though.
Because they're both "on" the same ne
Hi,
I have ran into an issue with the following on a J2350 (JUNOS Software
Release [9.2R1.10] (Export edition) Enhanced Services)
Presently the client has the following address range 192.168.4.0/24 which
as can be seen below to be at the
next-hop address of 212.111.105.238 which is directly conne
18 matches
Mail list logo
