Bgp – Junos: Policy-Statment and AS-Prepends

bgpjuniper-junos

I am trying to create a policy-statement to prepend the local AS number 5 times (assuming it is AS1234) before advertising local routes up to a new upstream transit provider (no inbound traffic is desired via this upstream). MED and communities are not available here (and out of the scope of this question). The policy I originally wrote looked like this;

  policy-statement PS-AS-Prepend-x5 {
     from {
         route-filter 0.0.0.0/0 orlonger;
     }
     to protocol bgp;
      then {
          as-path-prepend "1234 1234 1234 1234 1234";
          accept;
      }
  }

  protocols {
      bgp {
        group new-upstream {
        type external;
        export [ PS-AS-Prepend-x5 ];
      }
  }

The upstream has a looking glass on which I can see that when performing something akin to "show ip bgp prefix/mask" they are only seeing one AS in the path to this route (and all routes advertised). I changed the policy-statement as follows;

  policy-statement PS-AS-Prepend-x5 {
     to protocol bgp;
      then {
          as-path-prepend "1234 1234 1234 1234 1234";
          accept;
      }
  }

After resetting the BGP session the same behaviour as before was still occuring, no prepends. My question is two fold;

Do you need a "from" clause in a policy-statement? I used 0/0 in the original statement as only local prefixes are being advertised so rather than writing them all out I used 0/0 to match them all. I have been search on-line documentation but haven't found anything definitive. This is why removed the "from" clause to try and match all prefixes that way. I also tried to protocol bgp but this too failed.
I now suspect the syntax of the policy-statment is not the problem so my second question is Can you pre-pend your own AS on advertisements in JUNOS to eBGP peers?

UPDATE

me@r1# run show route advertising-protocol bgp 11.22.33.44 detail 

inet.0: 471821 destinations, 512598 routes (471815 active, 0 holddown, 12 hidden)
* 123.0.0.0/8 (3 entries, 1 announced)
 BGP group new-upstream type Externa
     Nexthop: Self
     AS path: [1234] I
     Communities: 1234:1234

Best Answer

Do you need a "from" clause in a policy-statement?

No. You don't. Without a "from" class everything will match.

Can you pre-pend your own AS on advertisements in JUNOS to eBGP peers?

Yes, of course you can, that's the typical way in which AS prepending is being done.

So the real question is: why doesn't this work? One thing which I'm not sure about is the to protocol bgp statement, I've never used that in policies for prepending. The best thing to do is verify if you're actually prepending by checking what you're advertising: show route advertising-protocol bgp aaa.bbb.ccc.ddd detail, where aaa.bbb.ccc.ddd is the peer IP.

Related Solutions

Routing – BGP remote-triggered blackhole (RTBH) filter for Juniper

There is no reason to limit customer to blackhole only /32, allow them to blackhole anything from them.

Something like this:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

Remember to set 'accept-remote-nexthop' under BGP settings, so that the next-hop can be changed to something else than link address.

I also strongly support that providers start to support different blackhole communities than just 'full blackhole'. Especially if you operate in more than one country usually attack is from transit and often customer actually mostly wants to access domestic peerings, so it's useful to implement several levels of blackhhole:

Full
Outside local country (local IXP, whole own AS + customers seen)
Outside local area (if applicable, like for me it could be 'Nordics')
Include/Exclude specific peering router in blackhole

I'm happy to give example how to implement something like this with JNPR DCU/SCU, provided your peering routers are JNPR, but it's possible with just communities, just bit more awkward.

If you absolutely want to limit your customer's options you can add this:

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

This way it should be logical AND. But I really don't see the value in creating complexity to reduce expressiveness of configuration.

JunOS: View route-filter import policy matches

test policy PS-Filter-Prefix-Size 0.0.0.0/0

This should display routes passing the policy

There isn't direct way to ask the opposite, but you could create policy which calls 'PS-Filter-Prefix-Size' and then rejects and accepts rest.
Testing this policy would yield opposite results, showing routes not passing 'PS-Filter-Prefix-Size'.

As far as I understand your 'PS-Filter-Prefix-Size' does nothing, as there is no action, so existing 'default-action' is honored.
You should have 'then accept' or 'then reject', and preferably after that explicit catch-all rule.

In your situation I'd do something like this

term bogus_size {
    from {
        family inet;
        route-filter 0.0.0.0/0 prefix-length-range /25-/32;
        route-filter 0.0.0.0/0 prefix-length-range /1-/7;
    }
    then reject;
}
term accept {
    then accept;
}

Best Answer

Related Solutions

Routing – BGP remote-triggered blackhole (RTBH) filter for Juniper

JunOS: View route-filter import policy matches

Related Topic