Junos OS

Hi all,

Cisco route maps have a branching command (continue <n>)  where n is another stanza in the route map.  One use case for this is performing a common operation after a switch:

psuedocode:

case v:

    a: set community 1, goto common

    b: set community 2, goto common

    c: set community 3, goto common

goto end

common:

    add community 10

end:

Does JunOS have a way of doing this other than copying the common actions into each switch?

Thanks.

------------------------------
SCOTT AITKEN
------------------------------

Hey Scott,

I don't think you can quite do it in that way, the processing order is either "next term" or "next policy".

You can reference another policy within a policy (Juniper call it a subroutine), but that only allows you to match against things.

However, what is the exact logic behind the code you pasted?

Do you set communities a, b, and c if there's some common attribute matched, or, do you set each one based on some specific attributes matched?

You can always create a term at the bottom of a policy set that says to add community 10

Hi all,

Cisco route maps have a branching command (continue <n>)  where n is another stanza in the route map.  One use case for this is performing a common operation after a switch:

psuedocode:

case v:

    a: set community 1, goto common

    b: set community 2, goto common

    c: set community 3, goto common

goto end

common:

    add community 10

end:

Does JunOS have a way of doing this other than copying the common actions into each switch?

Thanks.

Thanks Andrey,

you understood the pseudocode correctly.  Cisco's ability for route-maps to skip to arbitrary stanzas is quite powerful and I'm mildly surprised that JunOS does not have an equivalent capability.  next-policy is ok in the penultimate policy but there's no way to "jump over" the next policy.

Many thanks for confirming my understanding.

Scott

Hey Scott,

I don't think you can quite do it in that way, the processing order is either "next term" or "next policy".

You can reference another policy within a policy (Juniper call it a subroutine), but that only allows you to match against things.

However, what is the exact logic behind the code you pasted?

Do you set communities a, b, and c if there's some common attribute matched, or, do you set each one based on some specific attributes matched?

You can always create a term at the bottom of a policy set that says to add community 10

Hi all,

Cisco route maps have a branching command (continue <n>)  where n is another stanza in the route map.  One use case for this is performing a common operation after a switch:

psuedocode:

case v:

    a: set community 1, goto common

    b: set community 2, goto common

    c: set community 3, goto common

goto end

common:

    add community 10

end:

Does JunOS have a way of doing this other than copying the common actions into each switch?

Thanks.

Hey Scott,

I don't think you can quite do it in that way, the processing order is either "next term" or "next policy".

You can reference another policy within a policy (Juniper call it a subroutine), but that only allows you to match against things.

However, what is the exact logic behind the code you pasted?

Do you set communities a, b, and c if there's some common attribute matched, or, do you set each one based on some specific attributes matched?

You can always create a term at the bottom of a policy set that says to add community 10

------------------------------
ANDREY LEO

Original Message:
Sent: 03-26-2024 04:02
From: SCOTT AITKEN
Subject: Branching in JunOS policies

Hi all,

Cisco route maps have a branching command (continue <n>)  where n is another stanza in the route map.  One use case for this is performing a common operation after a switch:

psuedocode:

case v:

    a: set community 1, goto common

    b: set community 2, goto common

    c: set community 3, goto common

goto end

common:

    add community 10

end:

Does JunOS have a way of doing this other than copying the common actions into each switch?

Thanks.

------------------------------
SCOTT AITKEN
------------------------------

Hi Andrey,

when you write that «You can reference another policy within a policy (Juniper call it a subroutine), but that only allows you to match against things.»:

Actually you can well use a subroutine to SET stuff within the subpolicy (localpref, community, and so on). We use this to set always the same localprefs for VRF export routes by example, depending of their source protocol:

policy-statement vpn-MyVRF-export {    term default-direct-static-rip-bgp {        from {            protocol [ static aggregate direct bgp rip ripng ];            policy [ Sub-static-to-bgp Sub-direct-to-bgp Sub-rip-to-bgp Sub-bgp-accept ];        }        then {            community add vpn-MyVRF-target;            community add All-RouteSource-local;            accept;        }........}

... with subroutines like this (in which the «accept» doesn't really accept the route, since it's within a subroutine, but just sets the result of the boolean value at «true»):

policy-statement Sub-rip-to-bgp {    term backup {        from {            protocol [ rip ripng ];            preference 254;        }        then {            local-preference 30950;            accept;        }    }    term protocol {        from protocol [ rip ripng ];        then {            local-preference 31000;            accept;        }    }}

Hey Scott,

I don't think you can quite do it in that way, the processing order is either "next term" or "next policy".

You can reference another policy within a policy (Juniper call it a subroutine), but that only allows you to match against things.

However, what is the exact logic behind the code you pasted?

Do you set communities a, b, and c if there's some common attribute matched, or, do you set each one based on some specific attributes matched?

You can always create a term at the bottom of a policy set that says to add community 10

------------------------------
ANDREY LEO

Original Message:
Sent: 03-26-2024 04:02
From: SCOTT AITKEN
Subject: Branching in JunOS policies

Hi all,

Cisco route maps have a branching command (continue <n>)  where n is another stanza in the route map.  One use case for this is performing a common operation after a switch:

psuedocode:

case v:

    a: set community 1, goto common

    b: set community 2, goto common

    c: set community 3, goto common

goto end

common:

    add community 10

end:

Does JunOS have a way of doing this other than copying the common actions into each switch?

Thanks.

------------------------------
SCOTT AITKEN
------------------------------

Ah I didn't know that, so you're saying the "then" clause from the subroutine

        }        then {            local-preference 30950;            accept;        }    }

will actually set the local-preference value, WHILST a route is being evaluated by the master policy (vpn-MyVRF-export)?

So say the route was 10.14.11.0/24 learnt via RIP with a preference of 254,

It will end up with a local-preference of 30950 and have communities "vpn-MyVRF-target" and "All-RouteSource-local" added to it?

Or, does it only use the sub routine to match the route, ignoring the values in the accept clause, meaning it will only add the communities leaving the LP untouched?

------------------------------
ANDREY LEO

Original Message:
Sent: 03-28-2024 08:50
From: Olivier Benghozi
Subject: Branching in JunOS policies

Hi Andrey,

when you write that «You can reference another policy within a policy (Juniper call it a subroutine), but that only allows you to match against things.»:

Actually you can well use a subroutine to SET stuff within the subpolicy (localpref, community, and so on). We use this to set always the same localprefs for VRF export routes by example, depending of their source protocol:

policy-statement vpn-MyVRF-export {    term default-direct-static-rip-bgp {        from {            protocol [ static aggregate direct bgp rip ripng ];            policy [ Sub-static-to-bgp Sub-direct-to-bgp Sub-rip-to-bgp Sub-bgp-accept ];        }        then {            community add vpn-MyVRF-target;            community add All-RouteSource-local;            accept;        }........}

... with subroutines like this (in which the «accept» doesn't really accept the route, since it's within a subroutine, but just sets the result of the boolean value at «true»):

policy-statement Sub-rip-to-bgp {    term backup {        from {            protocol [ rip ripng ];            preference 254;        }        then {            local-preference 30950;            accept;        }    }    term protocol {        from protocol [ rip ripng ];        then {            local-preference 31000;            accept;        }    }}

------------------------------
Olivier Benghozi

Original Message:
Sent: 03-27-2024 06:32
From: ANDREY LEO
Subject: Branching in JunOS policies

Hey Scott,

I don't think you can quite do it in that way, the processing order is either "next term" or "next policy".

You can reference another policy within a policy (Juniper call it a subroutine), but that only allows you to match against things.

However, what is the exact logic behind the code you pasted?

Do you set communities a, b, and c if there's some common attribute matched, or, do you set each one based on some specific attributes matched?

You can always create a term at the bottom of a policy set that says to add community 10

------------------------------
ANDREY LEO

Original Message:
Sent: 03-26-2024 04:02
From: SCOTT AITKEN
Subject: Branching in JunOS policies

Hi all,

Cisco route maps have a branching command (continue <n>)  where n is another stanza in the route map.  One use case for this is performing a common operation after a switch:

psuedocode:

case v:

    a: set community 1, goto common

    b: set community 2, goto common

    c: set community 3, goto common

goto end

common:

    add community 10

end:

Does JunOS have a way of doing this other than copying the common actions into each switch?

Thanks.

------------------------------
SCOTT AITKEN
------------------------------

About the «then» clause in the subroutine:

• for non-terminating actions (setting localpref, community, tag, preference...): they are only effective if the final result of the term of the main/calling policy really accepts the route
• the terminating action in the subroutine (accept, reject) doesn't stop the evaluation in the main policy, it's just that this «from policy blah» line comes back to the main term/policy with:
  •  a «FALSE, doesn't match» for a reject
  • a «TRUE, does match» for an accept. In this case it's necessary and actually isn't terminating at all.

So if the subroutine sets attribute A, does come back with a TRUE («accept»), and the main policy finally accepts the route («accept», or by default for BGP) and its «then» clause sets attribute B, you will have both attributes A and B for the accepted routes.

------------------------------
Olivier Benghozi

Original Message:
Sent: 03-28-2024 14:04
From: ANDREY LEO
Subject: Branching in JunOS policies

Ah I didn't know that, so you're saying the "then" clause from the subroutine

        }        then {            local-preference 30950;            accept;        }    }

will actually set the local-preference value, WHILST a route is being evaluated by the master policy (vpn-MyVRF-export)?

So say the route was 10.14.11.0/24 learnt via RIP with a preference of 254,

It will end up with a local-preference of 30950 and have communities "vpn-MyVRF-target" and "All-RouteSource-local" added to it?

Or, does it only use the sub routine to match the route, ignoring the values in the accept clause, meaning it will only add the communities leaving the LP untouched?

------------------------------
ANDREY LEO

Original Message:
Sent: 03-28-2024 08:50
From: Olivier Benghozi
Subject: Branching in JunOS policies

Hi Andrey,

when you write that «You can reference another policy within a policy (Juniper call it a subroutine), but that only allows you to match against things.»:

Actually you can well use a subroutine to SET stuff within the subpolicy (localpref, community, and so on). We use this to set always the same localprefs for VRF export routes by example, depending of their source protocol:

policy-statement vpn-MyVRF-export {    term default-direct-static-rip-bgp {        from {            protocol [ static aggregate direct bgp rip ripng ];            policy [ Sub-static-to-bgp Sub-direct-to-bgp Sub-rip-to-bgp Sub-bgp-accept ];        }        then {            community add vpn-MyVRF-target;            community add All-RouteSource-local;            accept;        }........}

... with subroutines like this (in which the «accept» doesn't really accept the route, since it's within a subroutine, but just sets the result of the boolean value at «true»):

policy-statement Sub-rip-to-bgp {    term backup {        from {            protocol [ rip ripng ];            preference 254;        }        then {            local-preference 30950;            accept;        }    }    term protocol {        from protocol [ rip ripng ];        then {            local-preference 31000;            accept;        }    }}

------------------------------
Olivier Benghozi

Original Message:
Sent: 03-27-2024 06:32
From: ANDREY LEO
Subject: Branching in JunOS policies

Hey Scott,

I don't think you can quite do it in that way, the processing order is either "next term" or "next policy".

You can reference another policy within a policy (Juniper call it a subroutine), but that only allows you to match against things.

However, what is the exact logic behind the code you pasted?

Do you set communities a, b, and c if there's some common attribute matched, or, do you set each one based on some specific attributes matched?

You can always create a term at the bottom of a policy set that says to add community 10

------------------------------
ANDREY LEO

Original Message:
Sent: 03-26-2024 04:02
From: SCOTT AITKEN
Subject: Branching in JunOS policies

Hi all,

Cisco route maps have a branching command (continue <n>)  where n is another stanza in the route map.  One use case for this is performing a common operation after a switch:

psuedocode:

case v:

    a: set community 1, goto common

    b: set community 2, goto common

    c: set community 3, goto common

goto end

common:

    add community 10

end:

Does JunOS have a way of doing this other than copying the common actions into each switch?

Thanks.

------------------------------
SCOTT AITKEN
------------------------------

Gotcha, that makes sub routines even more useful!

Would definitely require some careful hierarchical and logic policy structuring architecture to get the most use out of it though.

Thanks for the info!

About the «then» clause in the subroutine:

• for non-terminating actions (setting localpref, community, tag, preference...): they are only effective if the final result of the term of the main/calling policy really accepts the route
• the terminating action in the subroutine (accept, reject) doesn't stop the evaluation in the main policy, it's just that this «from policy blah» line comes back to the main term/policy with:
  •  a «FALSE, doesn't match» for a reject
  • a «TRUE, does match» for an accept. In this case it's necessary and actually isn't terminating at all.

So if the subroutine sets attribute A, does come back with a TRUE («accept»), and the main policy finally accepts the route («accept», or by default for BGP) and its «then» clause sets attribute B, you will have both attributes A and B for the accepted routes.

------------------------------
Olivier Benghozi

Original Message:
Sent: 03-28-2024 14:04
From: ANDREY LEO
Subject: Branching in JunOS policies

Ah I didn't know that, so you're saying the "then" clause from the subroutine

        }        then {            local-preference 30950;            accept;        }    }

will actually set the local-preference value, WHILST a route is being evaluated by the master policy (vpn-MyVRF-export)?

So say the route was 10.14.11.0/24 learnt via RIP with a preference of 254,

It will end up with a local-preference of 30950 and have communities "vpn-MyVRF-target" and "All-RouteSource-local" added to it?

Or, does it only use the sub routine to match the route, ignoring the values in the accept clause, meaning it will only add the communities leaving the LP untouched?

------------------------------
ANDREY LEO

Original Message:
Sent: 03-28-2024 08:50
From: Olivier Benghozi
Subject: Branching in JunOS policies

Hi Andrey,

when you write that «You can reference another policy within a policy (Juniper call it a subroutine), but that only allows you to match against things.»:

Actually you can well use a subroutine to SET stuff within the subpolicy (localpref, community, and so on). We use this to set always the same localprefs for VRF export routes by example, depending of their source protocol:

policy-statement vpn-MyVRF-export {    term default-direct-static-rip-bgp {        from {            protocol [ static aggregate direct bgp rip ripng ];            policy [ Sub-static-to-bgp Sub-direct-to-bgp Sub-rip-to-bgp Sub-bgp-accept ];        }        then {            community add vpn-MyVRF-target;            community add All-RouteSource-local;            accept;        }........}

... with subroutines like this (in which the «accept» doesn't really accept the route, since it's within a subroutine, but just sets the result of the boolean value at «true»):

policy-statement Sub-rip-to-bgp {    term backup {        from {            protocol [ rip ripng ];            preference 254;        }        then {            local-preference 30950;            accept;        }    }    term protocol {        from protocol [ rip ripng ];        then {            local-preference 31000;            accept;        }    }}

------------------------------
Olivier Benghozi

Original Message:
Sent: 03-27-2024 06:32
From: ANDREY LEO
Subject: Branching in JunOS policies

Hey Scott,

I don't think you can quite do it in that way, the processing order is either "next term" or "next policy".

You can reference another policy within a policy (Juniper call it a subroutine), but that only allows you to match against things.

However, what is the exact logic behind the code you pasted?

Do you set communities a, b, and c if there's some common attribute matched, or, do you set each one based on some specific attributes matched?

You can always create a term at the bottom of a policy set that says to add community 10

------------------------------
ANDREY LEO

Original Message:
Sent: 03-26-2024 04:02
From: SCOTT AITKEN
Subject: Branching in JunOS policies

Hi all,

Cisco route maps have a branching command (continue <n>)  where n is another stanza in the route map.  One use case for this is performing a common operation after a switch:

psuedocode:

case v:

    a: set community 1, goto common

    b: set community 2, goto common

    c: set community 3, goto common

goto end

common:

    add community 10

end:

Does JunOS have a way of doing this other than copying the common actions into each switch?

Thanks.

------------------------------
SCOTT AITKEN
------------------------------