Le mar. 6 nov. 2018 à 14:56, Gregory Edigarov <[email protected]> a écrit :
>
> Hello, just noticed that.
>
> in pf.conf:
>
> table bgp-spamd-block persists
>
>
> in bgpd.conf
>
> spamdAS="65066"
> AS 65077
> fib-update no # Mandatory, to not update the local routing table
> #log updates
>
> group "spamd-bgp" {
> remote-as $spamdAS
> multihop 64
> export none # Do not send Route Server any information
>
> # us.bgp-spamd.net
> neighbor 64.142.121.62
>
> # eu.bgp-spamd.net
> neighbor 217.31.80.170
>
> # IPv6 eu.bgp-spamd.net
> # neighbor 2a00:15a8:0:100:0:d91f:50aa:1
> }
>
> match from group spamd-bgp community $spamdAS:666 set pftable
> "bgp-spamd-block"
>
> bgpd is running
>
> some time later:
>
> lbld12# bgpctl sh
> Neighbor AS MsgRcvd MsgSent OutQ Up/Down
> State/PrfRcvd
> 217.31.80.170 65066 78 20 0 00:08:53 38256
> 64.142.121.62 65066 76 20 0 00:08:53 38256
>
> i.e. it receives the prefixes ok, but:
>
> lbld12# pfctl -Tsh -t bgp-spamd-block | wc -l
> 0
what does 'bgpctl show nexthop' gives? On this kind of setup you might
need 'nexthop qualify via default' for nexthops to be validated and
prefixes to be accepted in pf tables.
