I'm looking after a bgpd setup which announces an IPv6 /32 and an IPv4
/21.

Due to a need for some heavy traffic clients to have their traffic
arrive via just one transit I'd like to turn that /21 into a /22 and
two /23s and only advertise one of the /23s via the "heavy traffic"
transit.

I'm on some medication that makes me dopier than usual but I can't even
see a vague hint in man bgpd.conf. Is it possible?


*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

[ message continues ]

Here's an example that might work.  You can twist it around depending on how localpref is setup with your providers to make it work better.  If you happen to also be using "network inet static" (redistribute static routes via BGP) and you happen to be statically routing these same subnets beyond your router, you will run into this bug: http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=6406

# policy:
# community 2:100 announced to all ebgp peers
# community 2:99 announced to 12.1.1.1 only
# community 2:98 announced to 44.4.4.5 only
network 2709:fe00::0/32 set community 2:100 
network 35.0.0.0/21 set community 2:100 
network 35.0.0.0/23 set community 2:98
network 35.0.2.0/23 set community 2:99
network 35.0.4.0/22 set community 2:99

neighbor 12.1.1.1 {
	remote-as 7018
	local-address 12.1.1.2
	announce all
}

neighbor 44.4.4.5 {
	remote-as 9910
	local-address 44.4.4.6
	announce all
}

deny to 12.1.1.1
allow to 12.1.1.1 community 2:100 
allow to 12.1.1.1 community 2:98
deny to 44.4.4.5
allow to 44.4.4.5 community 2:100
allow to 44.4.4.5 community 2:99


If you only have one bgp-speaking router, using communities isn't as helpful, you might want to remove that layer of abstraction:

network 2709:fe00::0/32
network 35.0.0.0/21
network 35.0.0.0/23
network 35.0.2.0/23
network 35.0.4.0/22

neighbor 12.1.1.1 {
        remote-as 7018 
        local-address 12.1.1.2 
        announce all
}

neighbor 44.4.4.5 {
        remote-as 9910 
        local-address 44.4.4.6 
        announce all
}

deny to 12.1.1.1
allow to 12.1.1.1 prefix { 35.0.0.0/21 35.0.0.0/23 }
deny to 44.4.4.5

Heh... Time to get off the medication

Chris

[ message continues ]

Are you sure that problem still exists in 4.8 or -current? Because the way
networks are handled changed completely. There is no longer a special
static/connected global rule. Now explicit rules have a higher precedence
then the dynamic "network inet ..." ones.


[ message continues ]

That sounds good.  I missed that stuff, I didn't think it was much different from 4.7 to current when I submitted the PR.  I'll retest.

Thanks,

Chris

[ message continues ]