Despite a few days of troubleshooting, I'm at a loss for answers, and Google is currently mocking further research attempts. Any help is greatly appreciated. My goals & confusion: - The intent is to announce two /24 netblocks across both of two separate uplinks, w/ my ASN via BGP. - It's not clear if I need to maintain multiple routing tables, with a single "internal" autonomous system, and if so, how to facilitate that with bird's pipe function. - I believe I should be focusing on ensuring replies return via the originating interface - however at this point, another set of eyes would really help in hashing this out. From the perspective of my router: - BGP sessions are active w/ uplinks, and providers are not filtering announcements. - ingress TCP connections to router's "source address" IP are established with no problem, if my BGP/routing tables instruct replies via the same interface packets happen to originate via. - ingress TCP connections cannot be established, if my BGP/routing tables instruct replies via a different interface than what packets happen to originate via. - tcpdump shows packets ingress from 1st provider, and egress towards 2nd provider, only if routing table instructs to 2nd provider...although replies never arrive at destination. - outbound TCP connections originating from the router itself, can be established with no issue, to either provider. Source IP matches local address of outbound route. - All addresses are public; this router is not doing any NAT. Below IPs were changed to protect the innocent, guilty, and everyone in-between - all replacements were via sed -i s///g... Since I've had no luck finding a template detailing how to accomplish this, once this hashes out, I'll followup with a relevant & documented configuration template. My bird.conf: log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; # Avoid martians from planet RFC1918 function avoid_martians() prefix set martians; { martians = [ 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+, 10.0.0.0/8+, 224.0.0.0/4+, 240.0.0.0/4+, 0.0.0.0/32-, 0.0.0.0/0{31,32}, 0.0.0.0/0{0,7} ]; if net ~ martians then return false; return true; } protocol direct { } protocol kernel { learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 60; # Scan kernel routing table every 60 seconds import none; # Default is import all export all; # Default is export none } protocol device { scan time 60; # Scan interfaces every 60 seconds } protocol static { route 1.0.0.0/24 via "eth0"; route 2.0.0.0/24 via "eth0"; } filter bgp_out { if net ~ [2.0.0.0/24] then accept; if net ~ [1.0.0.0/24] then accept; reject; } protocol bgp INET1 { local as 11111; source address 3.0.0.118; neighbor 3.0.0.117 as 22222; import all; path metric 1; # Prefer routes with shorter paths (like Cisco does) default bgp_med 1; # MED value we use for comparison when none is defined default bgp_local_pref 100; # The same for local preference export filter bgp_out; } protocol bgp INET2 { local as 11111; source address 4.0.0.14; neighbor 4.0.0.13 as 33333; import all; path metric 1; # Prefer routes with shorter paths (like Cisco does) default bgp_med 1; # MED value we use for comparison when none is defined default bgp_local_pref 100; # The same for local preference export filter bgp_out; } As for any possible "alien" routes, the only thing I'm doing is adding the spamhaus DROP list, via this script: ip route flush table 10; ip rule del from all table 10 priority 10; curl http://www.spamhaus.org/drop/drop.lasso | sed 's/;/#/g' | sed 's/^[0-9]/ip\ route\ add\ blackhole\ &/g' | sed 's/ \#/ table 10 \#/' |sed '/^ip/!D' > spamhausDrop; ip rule add from all table 10 priority 10; sh spamhausDrop In summary, it sources http://www.spamhaus.org/drop/drop.lasso to generate a bunch of lines akin to: ip route add blackhole 95.64.98.0/23 table 10 # SBL90817 - Gregg Berkholtz Dependable IT consulting, hosting & support since 1995 www.tocici.com | 503-488-5461 | AS14613