On 2008-09-24, tico <[EMAIL PROTECTED]> wrote:
> Reading the FILTERS section of bgpd.conf lead me to believe that
> simply adding "allow from any inet6 prefixlen 12 - 48" would allow
> the IPv6 prefixes that my neighbor was announcing to me be added
> from the RIB into the FIB, however this was not the case. After
> trying to specify each rule as explicitly pertaining to "inet" or
> "inet6" I found that bgpd would only match the announced IPv6
> prefixes to my "allow" line when I qualified each "deny" line with
> a prefixlen, regardless of the CIDR mask appended to the address.
> Specifically, the "deny from any prefix 0.0.0.0/0" line in the
> sample config would always match *all* IPv6 prefixes (but not
> clobber any of my IPv4 prefixes, which were merged into the FIB
> just fine), even if I inserted the "inet" parameter into the rule.
>
> I ended up with the following minimum FILTER config, which works
> just fine:
Can you make it easier for us and show the config which you expected
to work, which doesn't work? Thanks.
Very well. I started with the following from the unmodified sample
bgpd.conf from 4.3:
------------
# filter out prefixes longer than 24 or shorter than 8 bits
deny from any
allow from any inet prefixlen 8 - 24
# do not accept a default route
deny from any prefix 0.0.0.0/0
# filter bogus networks
deny from any prefix 10.0.0.0/8 prefixlen >= 8
deny from any prefix 172.16.0.0/12 prefixlen >= 12
deny from any prefix 192.168.0.0/16 prefixlen >= 16
deny from any prefix 169.254.0.0/16 prefixlen >= 16
deny from any prefix 192.0.2.0/24 prefixlen >= 24
deny from any prefix 224.0.0.0/4 prefixlen >= 4
deny from any prefix 240.0.0.0/4 prefixlen >= 4
------------
And I added the "allow from any inet6 prefixlen 12 - 48" line so that
the filter looked like:
------------
# filter out prefixes longer than 24 or shorter than 8 bits
deny from any
allow from any inet prefixlen 8 - 24
# allow most IPv6 prefixes
allow from any inet6 prefixlen 12 - 48
# do not accept a default route
deny from any prefix 0.0.0.0/0
# filter bogus networks
deny from any prefix 10.0.0.0/8 prefixlen >= 8
deny from any prefix 172.16.0.0/12 prefixlen >= 12
deny from any prefix 192.168.0.0/16 prefixlen >= 16
deny from any prefix 169.254.0.0/16 prefixlen >= 16
deny from any prefix 192.0.2.0/24 prefixlen >= 24
deny from any prefix 224.0.0.0/4 prefixlen >= 4
deny from any prefix 240.0.0.0/4 prefixlen >= 4
----------------
However, that still didn't allow any IPv6 prefixes to be added to the FIB.
Then I thought that possibly bgpd might not be distinguishing between
IPv4 and IPv6 prefixes and that the CIDR mask might be matching a wide
swath of IPv6 prefixes, and so just for grins I took the advice of the
following section of the FILTERS portion of bgpd.conf(5):
---------
(inet|inet6)
This rule applies only to routes matching the stated
address fam-
ily. The address family needs to be set only in rules that use
prefixlen without specifying a prefix beforehand.
---------
So I specified either "inet" or "inet6" for _every_ single filter rule,
ending up with the following (note that this ACL _would_ actually allow
a neighbor to announce an IPv6 default route to me, but not an IPv4
default route):
--------
# filter out prefixes longer than 24 or shorter than 8 bits
deny from any
allow from any inet prefixlen 8 - 24
allow from any inet6 prefixlen 12 - 48
# do not accept a default route
deny from any inet prefix 0.0.0.0/0
# filter bogus networks
deny from any inet prefix 10.0.0.0/8 prefixlen >= 8
deny from any inet prefix 172.16.0.0/12 prefixlen >= 12
deny from any inet prefix 192.168.0.0/16 prefixlen >= 16
deny from any inet prefix 169.254.0.0/16 prefixlen >= 16
deny from any inet prefix 192.0.2.0/24 prefixlen >= 24
deny from any inet prefix 224.0.0.0/4 prefixlen >= 4
deny from any inet prefix 240.0.0.0/4 prefixlen >= 4
---------
But this still didn't allow any IPv6 prefixes into the FIB. So, as a
last resort, even though I'd specified the "don't accept a default
route" rule to _only_ apply to IPv4, I changed that line to include a
"prefixlen = 0" so that my filter section read as follows:
---------
# filter out prefixes longer than 24 or shorter than 8 bits
deny from any
allow from any inet prefixlen 8 - 24
allow from any inet6 prefixlen 8 - 128
# do not accept a default route
deny from any inet prefix 0.0.0.0/0 prefixlen = 0
# filter bogus networks
deny from any inet prefix 10.0.0.0/8 prefixlen >= 8
deny from any inet prefix 172.16.0.0/12 prefixlen >= 12
deny from any inet prefix 192.168.0.0/16 prefixlen >= 16
deny from any inet prefix 169.254.0.0/16 prefixlen >= 16
deny from any inet prefix 192.0.2.0/24 prefixlen >= 24
deny from any inet prefix 224.0.0.0/4 prefixlen >= 4
deny from any inet prefix 240.0.0.0/4 prefixlen >= 4
---------
And this worked.
So the problems I see are the following:
1) the "(inet|inet6)" parameter either doesn't work, doesn't work
consistently, or at the very least doesn't work as described in the man
page for bgpd.conf(5) IMHO.
2) the parser for the filter section in bgpd.conf doesn't detect an IPv4
prefix versus an IPv6 prefix. (Why else would 0.0.0.0/0 match
_anything_ in IPv6 land?)
3) it doesn't appear (though I haven't tested this theory much) that
bgpd will default the prefixlen to equal the CIDR mask.
> If this (having to always specify a prefixlen even if a CIDR mask
> is present) is the desired behavior
I think that's expected, the network/cidr identifies the part of
address space involved, prefixlen identifies the length of the
prefix.
I've mentioned that above, as problem (3).
In other words, I think I should be able to write a rule like "deny from
any prefix 0.0.0.0/0" and not have to specify "deny from any prefix
0.0.0.0/0 prefixlen = 0" which works just fine when running _only_ IPv4.
I'm fairly sure that I can write "deny from any prefix 169.254.0.0/16"
and have that work without problems. Now obviously if someone sent me a
more specific prefix within that block (169.254.0.0/20 for example) then
that wouldn't necessarily match that line of my filter, but I can live
with having to specify "prefixlen >= 16" to match that scenario.
Say you want to filter on RIR minimums, you might want to use
lines like this,
deny ... prefix xx.0.0.0/8 prefixlen >= 24 deny ... prefix yy.0.0.0/8
prefixlen >= 21 deny ... prefix zz.0.0.0/8 prefixlen >= 16
I agree -- that makes perfect sense, and in my experience that's worked
as described in the IPv4-only networks that I've worked on.
Anyhow, just for completeness' sake, here's a complete bgpd.conf for
this instant in time:
---------------
HE_edge0="64.62.180.89"
HE_edge0v6="2001:470:1:53:0000:0000:0000:1"
AS 30708
router-id 208.86.95.250
log updates
network 208.86.92.0/22
network 2607:F618:0000:0000:0000:0000:0000:0000/32
group "peering Hurricane" {
remote-as 6939
neighbor $HE_edge0 {
descr "Hurricane_rtr0_v4"
announce IPv4 unicast
announce IPv6 none
announce self
tcp md5sig password XXXXX
}
neighbor $HE_edge0v6 {
descr "Hurricane_rtr0_v6"
#announce capabilities no
announce IPv6 unicast
announce IPv4 none
announce self
#local-address 2001:470:1:53::2
tcp md5sig password XXXXX
}
}
deny from any
allow from any inet prefixlen 8 - 24
allow from any inet6 prefixlen 12 - 48
deny from any inet prefix 0.0.0.0/0 prefixlen = 0
deny from any inet prefix 10.0.0.0/8 prefixlen >= 8
deny from any inet prefix 172.16.0.0/12 prefixlen >= 12
deny from any inet prefix 192.168.0.0/16 prefixlen >= 16
deny from any inet prefix 169.254.0.0/16 prefixlen >= 16
deny from any inet prefix 192.0.2.0/24 prefixlen >= 24
deny from any inet prefix 224.0.0.0/4 prefixlen >= 4
deny from any inet prefix 240.0.0.0/4 prefixlen >= 4
---------------
Cheers!
-Tico
