Difference between revisions of "OpenBGPD configuration notes"
From falz.net
(Created page with "Category:Tech Notes below on experimentation with OpenBGPD == Peers == * Neighbor with password that will work with Cisco, Juniper, etc. Also setting attributes using met...") |
|||
Line 1: | Line 1: | ||
− | [[Category: | + | [[Category:Unix]] |
+ | [[Category:Network]] | ||
+ | |||
Notes below on experimentation with OpenBGPD | Notes below on experimentation with OpenBGPD | ||
Revision as of 10:18, 9 July 2014
Notes below on experimentation with OpenBGPD
Contents
[hide]Peers
- Neighbor with password that will work with Cisco, Juniper, etc. Also setting attributes using methodology here. Even though this is an EBGP peer we're still going to announce all instead of announce self because self will only announce originating prefixes. All will allow you to pass your customer or peer prefxies as well.
AS 65000 router-id 4.1.1.2 neighbor 4.1.1.1 { remote-as 65001 announce all descr "ebgp1" local-address 4.1.1.2 tcp md5sig password secret set med 10 set localpref 80 set community 65000:180 }
Filters
Specific examples for OpenBGPD's filter syntax seem hard to come by, here's some documentation from my experimentation based on the bgpd.conf man page.
- Apply community, med, localpref to a prefix
match from any prefix 4.0.0.0/8 set med 10 match from any prefix 4.0.0.0/8 set localpref 120 match from any prefix 4.0.0.0/8 set community 65000:220
- Same as above but with macros matching multiple prefix
PREFIXES_TEST = "{ 4.0.0.0/8, 12.0.0.0/8, 66.1.2.0/24 }" match from any prefix $PREFIXES_TEST set med 10 match from any prefix $PREFIXES_TEST set localpref 120 match from any prefix $PREFIXES_TEST set community 65000:220
- Same again but condensed
PREFIXES_TEST = "{ 4.0.0.0/8, 12.0.0.0/8, 66.1.2.0/24 }" match from any prefix $PREFIXES_TEST set { med 10, localpref 120, community 65000:220 }
- Previous examples are for exact matches. Below will match anything in 4.0.0.0/8 (/9 is what's actually currently being advertised)
PREFIXES_TEST = "{ 4.0.0.0/8, 12.0.0.0/8 }" match from any prefix $PREFIXES_TEST prefixlen >= 8 set { med 10, localpref 120, community 65000:220 }
- And with AS numbers (AS must be uppercase!). This will match anywhere in the AS PATH.
AS_TEST = "{ 3356, 7018 }" match from any AS $AS_TEST set { med 99, localpref 199, community 65000:299 }
- You can specify where the AS number is in the path as well, but not from a macro. Valid keywords that you can mix and match:
- peer-as: leftmost AS number
- source-as: rightmost AS number
- transit-as: all but the rightmost AS number
match from any AS { source-as 3356, 7018 } set { med 99, localpref 199, community 65000:299 }
- Only send prefixes to neighbor 10.170.7.203 with communities matching 65000:220
deny to 10.170.7.203 allow to 10.170.7.203 community 65000:220
- Same as above but with a macro for community:
COMMUNITY_TEST = "65000:220" deny to 10.170.7.203 allow to 10.170.7.203 community $COMMUNITY_TEST
- Same again but to a group named IBGP that contains 10.170.7.203
COMMUNITY_TEST = "65000:220" deny to group IBGP allow to group IBGP community $COMMUNITY_TEST
- Apply attributes from a neighbor
COMMUNITY_TRANSIT = "65000:180" match from group GROUP-EBGP set community $COMMUNITY_TRANSIT match from group GROUP-EBGP set med 10 match from group GROUP-EBGP set localpref 80
Originating networks
- Use the network statement in the global config of bgpd.conf:
network 200.0.0.0/24
- Set an attribute:
network 200.0.0.0/24 set localpref 140
- Set multiple attributes:
network 200.0.0.0/24 set { localpref 140 med 10 community 65000:666 }
- Or set multiple attributes and communities:
network 200.0.0.0/24 set { localpref 140 med 10 community 65000:666 community 65000:777 }
IPv6
- Configuration is the same.
- Use the inet6 keyword for your show commands.
- The default config is ipv6 equivalents of the ipv4 filters. If you don't add any filters the deny from any will do just that- deny all ipv6. These seem to be sane default filters including an adaptation of these relaxed filters:
# filter out ipv6 prefixes longer than 48 bits allow from any inet6 prefixlen <= 48 # filter out ipv6 default route deny from any inet6 prefix ::/0 prefixlen = 0 # bogons deny from any inet6 prefix 3ffe::/16 prefixlen <= 128 deny from any inet6 prefix 2001:db8::/32 prefixlen <= 128 deny from any inet6 prefix 2001::/32 prefixlen <= 128 deny from any inet6 prefix 2002::/16 prefixlen <= 128 deny from any inet6 prefix 0000::/8 prefixlen <= 128 deny from any inet6 prefix fe00::/9 prefixlen <= 128 deny from any inet6 prefix ff00::/8 prefixlen <= 128 deny from any inet6 prefix 0::/0 prefixlen <= 128 allow from any inet6 prefix 2000::/3 prefixlen <= 48 allow from any inet6 prefix 2001::/32 allow from any inet6 prefix 2002::/16
Performance
Approximate BGP convergence times. Full feeds in these tests comes from a lowly 7200VXR NPE-400. OpenBSD 4.8 i386 running as VMs each with 1 CPU, 512MB ram on a Dell 1950 with dual Xeons and no CPU limit per VM, no VMWare tools installed. OpenBSD runnnig BGP between loopback interfaces reachable via OSPF.
Scenario 1
Tests are with full feeds (~350k prefixes), no filters on OpenBGPD. C1 is OpenBSD Client. Diagram:
[NPE-400] --- [OpenBSD C1]
- No filters, RIB only: ~12 seconds
- Full feed, no filters, RIB+FIB: ~17 seconds
Scenario 2
RR = Route Reflector, C is RR Client. Tests are when manually shuting down the BGP peer between NPE and RR 1. RR1 is feeding C1 by matching 5 communities each with their own allow rule totaling full feeds:
[NPE-400] --- [OpenBSD RR1] --- [OpenBSD C1]
- 5 rules matching 5 communities: ~30 seconds
Scenario 3
RR1/RR2 = Route Reflectors, C1/2/3 are clients. Tests are when manually shuting down both BGP feeds peer between NPE and RR's. Same filters as above
+--- [OpenBSD RR1] --- [OpenBSD C1] | \ / [NPE-400] --| x [OpenBSD C2] | / \ +--- [OpenBSD RR2] --- [OpenBSD C3]
- Full convergence through to all clients ~1 minute
System Resources
CPU
Memory
Memory usage is stellar, this is with a full ipv4 and ipv6 view:
rr1# bgpctl show ip bgp memory RDE memory statistics 348715 IPv4 unicast network entries using 13.3M of memory 4426 IPv6 unicast network entries using 242K of memory 706282 rib entries using 43.1M of memory 706339 prefix entries using 43.1M of memory 124463 BGP path attribute entries using 14.2M of memory 56191 BGP AS-PATH attribute entries using 2.7M of memory, and holding 124463 references 7445 BGP attributes entries using 291K of memory and holding 89707 references 7444 BGP attributes using 104K of memory RIB using 117M of memory
Gotchas
- DO NOT accidentally start a 2nd instance of bgpd or ospfd. Doing so will happily launch without warning and destroy your sessions from the first instance.
- Most bgpd.conf settings take when you issue bgpctl reload. Some things such as tcp md5 passwords are not. If you add or remove a tcp md5sig password from a neighbor you must:
bgpctl reload bgpctl neighbor <name> clear
- Changing the announce setting on a neighbor such as from announce self to announce all will not take affect with a bgpctl reload / neighbor refresh. You must also clear as above.
- If you are making changes to networks you're originating, editing the 'network' statement in the conf and ussuing bgpctl reload will not suffice without this patch. You must set attributes with bgpctl network syntax as follows:
bgpctl network add 200.0.0.0/24 localpref 140
- Be sure to not set attributes as follows. Doing so will set ONLY that attribute and reset the others. If you were to issue these statements you'd end up with just community 65000:777 set, med 0, localpref 100.
bgpctl network add 200.0.0.0/24 localpref 140 bgpctl network add 200.0.0.0/24 med 10 bgpctl network add 200.0.0.0/24 community 65000:666 bgpctl network add 200.0.0.0/24 community 65000:777
- Instead you want something like this:
bgpctl network add 200.0.0.0/24 localpref 140 med 10 community 65000:666 community 65000:777