Poll firewall counters on Juniper routers via SNMP

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.

Could someone please tell me the community string indexing for switches other than Cisco?

Edit:

This is how to poll Q-BRIDGE-MIB for mac-addresses from the only non-Cisco I have, a DLink DGS-3200. I'm not using [community@vlan] for non-Cisco switches. You're correct that this indexing only applies to Ciscos. I expect any non-Cisco switch, which supports Q-BRIDGE-MIB to work the same way.

Polling sysDescr to document the switch under test

[mpenning@tsunami ~]$ # Demo from a DLink DGS-3200 switch
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public -OXsq 172.16.1.2 sysdescr
sysDescr.0 "DGS-3200-10 Gigabit Ethernet Switch"
[mpenning@tsunami ~]$

Walking dot1qVlanStaticName: List Vlans and their text names

[mpenning@tsunami ~]$
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public 172.16.1.2 .1.3.6.1.2.1.17.7.1.4.3.1.1
BRIDGE-MIB::dot1dBridge.7.1.4.3.1.1.1 = STRING: "default"
[mpenning@tsunami ~]$

dot1qFdbDynamicCount: Number of mac addresses known

[mpenning@tsunami ~]$ 
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public  172.16.1.2 .1.3.6.1.2.1.17.7.1.2.1.1.2
BRIDGE-MIB::dot1dBridge.7.1.2.1.1.2.1 = Counter32: 17
[mpenning@tsunami ~]$

dot1qVlanCurrentEgressPorts: bitmap of ports in the vlan

[mpenning@tsunami ~]$ 
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public 172.16.1.2 .1.3.6.1.2.1.17.7.1.4.2.1.4
BRIDGE-MIB::dot1dBridge.7.1.4.2.1.4.2562.1 = Hex-STRING: FF C0 00 00
[mpenning@tsunami ~]$

dot1qTpFdbPort: All MAC Addresses learned

The mac-addresses show up as a string of six decimal digits in the indexes to dot1qTpFdbPort. Note that I have a downstream switch connected to this switch on port 1/5...

[mpenning@tsunami ~]$ 
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public 172.16.1.2 .1.3.6.1.2.1.17.7.1.2.2.1.2
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.13.101.22.202.65 = INTEGER: 5
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.13.189.7.134.128 = INTEGER: 5
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.13.189.7.134.129 = INTEGER: 5
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.29.161.205.83.70 = INTEGER: 9
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.48.27.188.167.215 = INTEGER: 2
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.192.183.110.158.29 = INTEGER: 3

... more entries here
[mpenning@tsunami ~]$

dot1dBasePortIfIndex: Map values from dot1qTpFdbPort to an ifIndex

[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public -OXsq 172.16.1.26 .1.3.6.1.2.1.17.1.4.1.2
dot1dBasePortIfIndex[1] 1
dot1dBasePortIfIndex[2] 2
dot1dBasePortIfIndex[3] 3
dot1dBasePortIfIndex[4] 4
dot1dBasePortIfIndex[5] 5
dot1dBasePortIfIndex[6] 6
dot1dBasePortIfIndex[7] 7
dot1dBasePortIfIndex[8] 8
dot1dBasePortIfIndex[9] 9
dot1dBasePortIfIndex[10] 10

ifName: Map values from ifIndex to an ifName

[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public -OXsq 172.16.1.26 ifName
ifName[1] 1/1
ifName[2] 1/2
ifName[3] 1/3
ifName[4] 1/4
ifName[5] 1/5
ifName[6] 1/6
ifName[7] 1/7
ifName[8] 1/8
ifName[9] 1/9
ifName[10] 1/10
ifName[5121] System
[mpenning@tsunami ~]$

ORIGINAL:

There is a mistake in your OID, you're using 1.3.6.2.3.1.17.4.3.1.1; however, dot1dTpFdbAddress is 1.3.6.1.2.1.17.4.3.1.1.

The difference is changing some octets, below...

OID Incorrect: 1.3.6.2.3.1.17.4.3.1.1   <--- Not this
OID Corrected: 1.3.6.1.2.1.17.4.3.1.1   <--- Use this
                     ^ ^
                     | |