Routing BGP Protocol-Theory RFC – How is BGP AS_SET Used?

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:

1. Full
2. Outside local country (local IXP, whole own AS + customers seen)
3. Outside local area (if applicable, like for me it could be 'Nordics')
4. 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.

Opaque LSA's are used to extend the capabilities of OSPF, and to allow for transmission of arbitrary data that OSPF does not necessarily need to care about. For example, if you were writing an application and you decided you wanted to use OSPF to transport the application's data but you did not want OSPF to use this data for its own purposes, ie route calculations.

There are three types of Opaque LSA's (in context of the subtype of the Opaque LSA, similar to other LSA types), which determine the scope of flooding of those LSA's:

• Type 9 - link-local scope
• Type 10 - area-local scope
• Type 11 - AS scope

The Opaque LSA has 32 bits allocated for the Opaque Type (8 bits) and the Opaque ID (24 bits). There are (AFAIK) currently four Opaque types that have been allocated by the IANA:

1. Traffic Engineering LSA - used for MPLS-TE
2. Sycamore Optical Topology Descriptions - likely proprietary. I wasn't able to find much info on this, other than the fact that John Moy works for Sycamore.
3. Grace LSA - used for OSPF graceful restart
4. Router Information LSA - Intended (but not yet implemented AFAIK) to supplement the options field to allow for communication of optional capabilities between neighbors. Currently the options field is only 8 bits and there is only a single bit that can be used that just determines if a neighbor supports Opaque LSA's. This RI LSA would provide TLV values to signal support of up to 32 different capabilities between neighbors without needing to add more bits to the options field in the LSA.

In regards to practical application of the Opaque LSA, likely the most common implementation you'll see of this in the wild is in MPLS traffic engineering. In OSPF extensions for MPLS traffic engineering, Opaque LSA's are used to communicate traffic engineering interface parameters (such as maximum bandwidth, maximum reservable bandwidth, unreserved bandwidth, etc) throughout an area in order to populate the traffic engineering databases of the routers within the area.

As for "how to use it" - you shouldn't have to, unless you're writing code that you would need to use it. In terms of practical application on a routing platform, on platforms I have experience with, there's not a specific knob you need to turn that "enables" Opaque LSAs. These should be implicitly enabled if you implement something that has dependencies on them, such as MPLS.