Routing

Hi all

I'm trying to achieve an - I think - fairly simple basic goal.

2 uplink connections - one main, one backup. I'm advertising my own prefixes over both uplinks. All works fine, however I need to add a MED to the advertisements over the backup.

Now, thinking simple and logically, this would be the perfect setup:

term modify-to-backup {
    to neighbor 172.16.11.242;
    then {
        metric add 999;
    }
}
term accept-ownsubnets {
    from {
        route-filter 2.2.2.2/27 prefix-length-range /28-/28;
        route-filter 1.1.1.1/27 prefix-length-range /28-/28;
    }
    to neighbor [ 172.16.11.241 172.16.11.242 ];
    then accept;
}
then reject;

and then apply this policy to the group where both peers reside.

As you can assume, the backup uplink is 172.16.11.242.

This would scale perfectly and do exactly as I need...

This doesn't work. The prefixes advertised to 172.16.11.241 also get their MED changed. What's even stranger, I didn't even apply this policy to neighbor 172.16.11.242 yet!

So looking up the docs etc, I found this detail in the match conditions overview: http://www.juniper.net/documentation/en_US/junos12.1x45/topics/usage-guidelines/policy-configuring-match-conditions-in-routing-policy-terms.html

For BGP export policies, specifying the neighbor match condition has no effect and is ignored.

Both peers are on the same interface so using "to interface" - if even possible - is not an option.

I DON'T want to maintain a separate policy per neighbor, I just know that's just asking for troubles (the policy to backup would get overlooked - until our main connection goes down ^o)).

So, I hope you routing gurus could point me to a workaround for this problem - my requirement is (in this case) basicly to simply advertise everything the same to two uplinks, however, the advertisements to the backup link should have a raised MED.

Hope anyone can help me with this...

Thanks a lot!

Hi,

as you already pointed out, the "to neighbor" does not work in export policy. So, the only option is to have different policies for both neighbors. The nice thing in JUNOS is that you can evaluate multiple policies in a chain, so easist way to solve your problem would be splitting up the policy into two:

[edit policy-options]

policy-statement MED999 {

    then {

        metric add 999;

    }

}

policy-statement ADVERTISE {

    term accept-ownsubnets {

        from {

            route-filter 2.2.2.2/27 prefix-lenght-range /28-/28;

            route-filter 1.1.1.1/27 prefix-lenght-range /28-/28;

        }

        then accept;

    }

    then reject;

}

[edit protocols bgp group UPSTREAM]

neighbor 172.16.11.241 {

    export ADVERTISE;

}

neighbor 172.16.11.242 {

    export [ MED999 ADVERTISE ];

}

Cheers,

Carsten

Hi,

I was hoping to be able to avoid this and to keep using group-level policies to keep things nice & clean, but this was indeed the only other thing I could think of...

Thanks for your input!

Well, I actually tried that, but my connection got dropped (I got locked out myself so couldn't check deeper what happened :-)), but I concluded that "from neighbor" in an export means "route came in originally from neighbor x.x.x.x".

Don't know if that's completely accurate however but that seemed a logical explanation.

When someone gives me the magic solution to my other problem (http://forums.juniper.net/t5/Routing/BGP-export-clear-whole-AS-path/td-p/276759) I could test this theory easily while I'm implementing that!

Thanks for your input!

---

@ithFrederic wrote:

Well, I actually tried that, but my connection got dropped (I got locked out myself so couldn't check deeper what happened :-)), but I concluded that "from neighbor" in an export means "route came in originally from neighbor x.x.x.x".

 

Actually you are right... The only way to be neighbor specific is to go down in hierarchy.

The reason is how junos generates bgp updates: per peer-group processing of routes, where group has consistent export policy. Groups are split when export parameters differ.

 

HTH,

Krasi

 

 

That's very good to know... A good case of how knowing inner workings can help 🙂 That also explains a comment I once read about group policies being more efficient than neighbor-specific.

Tyvm for your valuable input!