Routing

I have a strange one here:

we are running MX960 with  9.3R1.7 code loaded

I have an eBGP session against a customer with a route-filter to limit what I will accept from them:

 term Accepted_prefixes {
    from {
        route-filter 81.xx.yyy.0/23 orlonger;
    }
    then {
        local-preference 200;
        accept;
    }
}
then reject;

this should only accept a limited range of prefixes and reject everything else:

I then apply this as an import policy on their BGP session.

when I do :

>show route receive-protocol bgp xxx.xxx.xxx.xxx all

inet.0: 295321 destinations, 295337 routes (295319 active, 0 holddown, 2 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 81.xx.yyy.0/23          xxx.xxx.xxx.xxx        0                  AAAAA I
  81.xx.yyy.0/24          xxx.xxx.xxx.xxx        0                  AAAAA I
  81.xx.yyz.0/24          xxx.xxx.xxx.xxx        0                  AAAAA I

I am recieving a /23 and two /24s which are subsets of the /23

I seems that only the /23 is being put into the routing table and thus only being annouced upstream.

>show route protocol bgp 81.xx.yyy extensive

 81.xx.yyy.0/23 (1 entry, 1 announced)
TSI:
KRT in-kernel 81.xx.yyy.0/23 -> {xxx.xxx.xxx.xxx}
Page 0 idx 0 Type 1 val 15ac1c00
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 598
                Next-hop reference count: 5
                Source: xxx.xxx.xxx.xxx
                Next hop: xxx.xxx.xxx.xxx via ge-0/1/5.9, selected
                State: <Active Ext>
                Local AS: BBBBB Peer AS: AAAAA
                Age: 11w2d 2:36:22      Metric: 0
                Task: BGP_AAAAAAAA
                Announcement bits (3): 0-KRT 4-BGP RT Background 5-Resolve tree 1
                AS path: AAAAA I
                Accepted
                Localpref: 100
                Router ID: 81.xx.yyy.2

 I then look at the two missing /24's

 >run show route protocol bgp 81.xx.yyy hidden extensive  

inet.0: 295343 destinations, 295359 routes (295341 active, 0 holddown, 2 hidden)
81.xx.yyy.0/24 (1 entry, 0 announced)
         BGP                 /-101
                Next hop type: Router, Next hop index: 598
                Next-hop reference count: 5
                Source: xxx.xxx.xxx.xxx
                Next hop: xxx.xxx.xxx.xxx via ge-0/1/5.9, selected
                State: <Hidden Ext>
                Local AS: BBBBB Peer AS: AAAAA
                Age: 11w2d 2:40:04      Metric: 0
                Task: BGP_AAAA

                AS path: AAAAA I
                Localpref: 100
                Router ID: xxx.xxx.xxx.xxx

 we have tried soft-inbounds against the Cisco peer to force the Cisco tosend Updates but nothing seems to happen.

any ideas? is this normal behaviour? as it doesnt seem to be applying the local preference value correctly either

If the policy was applied after establishing the session and route exchange, the soft in reset on your MX should have don the trick. Is that what you did, soft in reset?

Did you also apply a next hop self policy along side the local pref policy with route-filter? That could explain the strange route selection, at least if the protocol next-hop differs between the /23 and /24.

For kicks try (unless nexthop self ruyins your BGP design, which it normally shouldnt since it is a good practive to use nexthop self on eBGP connections):

 term Accepted_prefixes {
    from {
        route-filter 81.xx.yyy.0/23 orlonger;
    }
    then {
        local-preference 200;

        next-hop self;
        accept;
    }
}
then reject;

 Have you also tried explicit route-filters to see if that changes anything?

Like:

term Accepted_prefixes {
    from {
        route-filter 81.xx.yyy.0/23 exact;

        route-filter 81.xx.yyx.0/24 exact;

        route-filter 81.xx.yyz.0/24 exact;

    }
    then {
        local-preference 200;

        next-hop self;
        accept;
    }
}
then reject;

well the customers Cisco box did a wobbly when they activated debugging and the session reset.

and strange enough when it came back everything is working as required.

With no changes on the MX? Fantastic 🙂 JUNOS - IOS, 1 - 0 🙂

But still consider the nexthop self thingie for your eBGP sessions. It will have its advantages like you dont need to annoucne the link network between you and your peer in your IGP and if you ever get multiple exit you can let iBGP descide best out of your network etc.

We use the next-hop self, but only on iBGP sessions so that we dont need to advertise the DMZ network in our IGP.

eBGP sessions are nearly always with the interface IP address.

I thought this was best practise?

You use an export policy to iBGP peers? Hmm actually that was what I mean, sorry fo rmessing it up. Import policy to eBGP would not preserve teh orignal next hop when the routers announces the route to other eBGP peers, which might mess up things.