[j-nsp] Adjusting OSPF metric based on VRRP state?

[Jonathan Looney]

Howard,

That's a creative solution; however, it isn't what the "apply-groups"
command does.

The "apply-groups" command adds any configuration from the group that is
relevant to the particular section of the hierarchy where it is applied.
Your group only contains things in [edit protocols ospf], but your
apply-groups statement is under [edit interfaces]. Therefore, none of the
configuration from the group will be applied to the [edit interfaces]
hierarchy.

On the other hand, if you used the configuration below, then the OSPF
configuration from the group would be applied in [edit protocols]:
protocols {
    ospf {
        apply-groups ospf-weight;
    }
}

However, in this case, the configuration would always be applied,
regardless of the VRRP status.

In general, to adjust a piece of configuration one place based on an event
occurring somewhere else, you might try using event scripts. (There are, of
course, exceptions where Juniper has programmed an option to automate the
adjustment. However, I'm not aware of something like this for VRRP.)

In this particular case, the "cleanest" thing to do might be to cluster the
devices. If they are acting as firewalls, clustering probably gives the
best failover options. Without clustering, even if you get the OSPF metric
change to work, all the sessions will lose state during the failover.

Hope this helps.

-Jon

On Fri, Sep 28, 2012 at 5:12 PM, Howard Hart <hch at ooma.com> wrote:

> Hi Mike,
>
>   I'm definitely winging this since I don't use OSPF much, but would you
> be able to use a combination of VRRP interface tracking and groups to do
> this? i.e. -
>
>    ge-1/3/0 {
>         }
>         unit 0 {
>             family inet {
>                 address 192.168.1.2/24 {
>                     vrrp-group 1 {
>                         virtual-address 192.168.1.1;
>                         priority 100;
>                         track {
>                             interface ge-0/0/0.0 {
>                                 priority-cost 15;
>                                 apply-groups ospf-weight;
>                             }
>                         }
>                     }
>                }
>            }
>    }
>
> groups {
>     ospf-weight {
>            protocols {
>                   ospf {
>                      change-your-ospf-weighting-**thing
>                   }
>            }
>     }
> }
>
> Howard Hart
> Ooma
>
>
> On 09/27/2012 11:15 PM, Per Granath wrote:
>
>> 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 network segment they both announce
>>> that prefix into OSPF, and that's causing me a problem.
>>> If a TCP session arrives via J1 and J2 is the VRRP master, J2 will
>>> drop/reject
>>> the SYN-ACK as it didn't deal with the SYN.
>>>
>>> Now I know I could set "flow tcp-session no-syn-check" to effectively
>>> ignore
>>> the problem, or given suitable amounts of interest/time/effort we could
>>> probably cluster the 2 devices (different Colo providers in the same
>>> building),
>>> or even use some creativity with static routes (urgh) to bypass OSPF
>>> entirely,
>>> but I'm hoping there is some magic OSPF/VRRP knob I haven't been able to
>>> find yet that will alter the OSPF metric for a logical interface based
>>> on the
>>> VRRP state.
>>>
>>
>> ______________________________**_________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>>
>
> ______________________________**_________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>