announcing BGP prefixes from the same AS at different sites?
I am trying to sort out a chicken-and-egg problem is probably more of a network design question than bird-specific. I am using bird to announce prefixes from two geographically-separate locations (A and B). I am announcing different prefixes at each, but with the same AS. The problem I am having is how to get these locations to add each other's routes. At location A, I have a pair of bird routers (X and Y), each connected to a different provider. Both routers announce the prefixes for this site over eBGP. These routers have an iBGP session between them. At location B, there is a single router (Z), connected to one ISP. It announces its own prefixes upstream. Since both sites announce with the same AS, they don't import the other's prefixes. An iBGP full-mesh seems to be the _correct_ solution, but I am having trouble getting this implemented correctly. If I configure the inter-site iBGP sessions to connect between the addresses on the WAN interfaces, I get partial success. At site A, router X correctly adds routes for site B. Router Y establishes a connection to router Z (site B), but adds the B prefixes as unreachable. The difference is that the Y->Z BGP connection (A->B direction) is routed via router X (shorter AS path via X ISP). My configuration files for this setup are below. If I attempt to establish the inter-site iBGP between the loopbacks on the routers, I have no success, since the loopback addresses fall with the subnets I announce at each site. Is there some bit of configuration I am missing? Am I going about this the wrong way? Any thoughts are appreciated. # # router Y # site A # protocol bgp bgp_he { local as 12345; neighbor 1.1.2.69 as 6939; # Export exactly what prefixes we want advertised. No surprises. export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" then accept; reject; }; # Import filtered routes from upstream. import filter bgp_in_he; } protocol bgp ibgp_border { local 6.9.5.212 as 12345; neighbor 6.9.5.213 as 12345; multihop 2; import filter { accept; }; export filter { if source != RTS_BGP then { reject; } if proto = "ibgp_border" then { reject; } accept; }; } protocol bgp ibgp_1b { local 1.1.2.70 as 12345; neighbor 7.4.2.132 as 12345; multihop 10; import filter { accept; }; export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" then accept; reject; }; } protocol ospf { # *snip* } # # router X # site A # protocol bgp bgp_cogent { local as 12345; neighbor 3.8.1.105 as 174; # Export exactly what prefixes we want advertised. No surprises. export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" && net.len <= 24 then accept; reject; }; # Import filtered routes from upstream. import filter bgp_in_cogent; } protocol bgp ibgp_border { local 6.9.5.213 as 12345; neighbor 6.9.5.212 as 12345; multihop 2; # Send all routes learnt via BGP import filter { accept; }; export filter { if source != RTS_BGP then { reject; } if proto = "ibgp_border" then { reject; } accept; }; } protocol bgp ibgp_1b { local 3.8.1.106 as 12345; neighbor 7.4.2.132 as 12345; multihop 10; import filter { accept; }; export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" && net.len <= 24 then accept; reject; }; } protocol ospf { # *snip* } # # router Z # site B # template bgp ibgp_A { debug all; local 7.4.2.132 as 12345; multihop 10; import filter { accept; }; export filter { if proto = "static_bgp" then accept; if proto = "standby_bgp" then accept; if proto = "portable_bgp" then accept; reject; }; } protocol bgp ibgp_Y from ibgp_A { neighbor 1.1.2.70 as 12345; }; protocol bgp ibgp_X from ibgp_A { neighbor 3.8.1.106 as 12345; }; template bgp B { # Set our local AS. local as 12345; # Export exactly what prefixes we want advertised. No surprises. export filter { if proto = "static_bgp" then accept; if proto = "standby_bgp" then accept; if proto = "portable_bgp" && net.len <= 24 then accept; reject; }; # Import filtered routes from upstream. import filter bgp_in_B; } protocol bgp bgp_B from B { neighbor 7.4.2.130 as 1212; };
Hi, It sounds like you might want to try disabling aspath loop detection for eBGP. Checkout the bird option called "allow local as [number]" as documented at http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2. This will allow you to import prefixes with your own ASN in the aspath. However, one possible pitfall is that your upstream ISP's router might try to be smart - and not send prefixes with your aspath in them too. Older Foundry boxes do this and there is a per BGP peer knob you have to turn. Overall, this should let you run everything over eBGP and run two simple island networks. Cheers, Tom On Fri, Aug 29, 2014 at 5:52 PM, Thomas Johnson <tommyj27@gmail.com> wrote:
I am trying to sort out a chicken-and-egg problem is probably more of a network design question than bird-specific.
I am using bird to announce prefixes from two geographically-separate locations (A and B). I am announcing different prefixes at each, but with the same AS. The problem I am having is how to get these locations to add each other's routes.
At location A, I have a pair of bird routers (X and Y), each connected to a different provider. Both routers announce the prefixes for this site over eBGP. These routers have an iBGP session between them.
At location B, there is a single router (Z), connected to one ISP. It announces its own prefixes upstream.
Since both sites announce with the same AS, they don't import the other's prefixes. An iBGP full-mesh seems to be the _correct_ solution, but I am having trouble getting this implemented correctly.
If I configure the inter-site iBGP sessions to connect between the addresses on the WAN interfaces, I get partial success. At site A, router X correctly adds routes for site B. Router Y establishes a connection to router Z (site B), but adds the B prefixes as unreachable. The difference is that the Y->Z BGP connection (A->B direction) is routed via router X (shorter AS path via X ISP). My configuration files for this setup are below.
If I attempt to establish the inter-site iBGP between the loopbacks on the routers, I have no success, since the loopback addresses fall with the subnets I announce at each site.
Is there some bit of configuration I am missing? Am I going about this the wrong way? Any thoughts are appreciated.
# # router Y # site A #
protocol bgp bgp_he { local as 12345; neighbor 1.1.2.69 as 6939;
# Export exactly what prefixes we want advertised. No surprises. export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" then accept; reject; }; # Import filtered routes from upstream. import filter bgp_in_he; }
protocol bgp ibgp_border { local 6.9.5.212 as 12345; neighbor 6.9.5.213 as 12345; multihop 2; import filter { accept; }; export filter { if source != RTS_BGP then { reject; } if proto = "ibgp_border" then { reject; } accept; }; }
protocol bgp ibgp_1b { local 1.1.2.70 as 12345; neighbor 7.4.2.132 as 12345; multihop 10; import filter { accept; }; export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" then accept; reject; }; }
protocol ospf { # *snip* }
# # router X # site A #
protocol bgp bgp_cogent { local as 12345; neighbor 3.8.1.105 as 174;
# Export exactly what prefixes we want advertised. No surprises. export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" && net.len <= 24 then accept; reject; }; # Import filtered routes from upstream. import filter bgp_in_cogent; }
protocol bgp ibgp_border { local 6.9.5.213 as 12345; neighbor 6.9.5.212 as 12345; multihop 2;
# Send all routes learnt via BGP import filter { accept; }; export filter { if source != RTS_BGP then { reject; } if proto = "ibgp_border" then { reject; } accept; }; }
protocol bgp ibgp_1b { local 3.8.1.106 as 12345; neighbor 7.4.2.132 as 12345; multihop 10; import filter { accept; }; export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" && net.len <= 24 then accept; reject; }; }
protocol ospf { # *snip* }
# # router Z # site B #
template bgp ibgp_A { debug all; local 7.4.2.132 as 12345; multihop 10; import filter { accept; }; export filter { if proto = "static_bgp" then accept; if proto = "standby_bgp" then accept; if proto = "portable_bgp" then accept; reject; }; }
protocol bgp ibgp_Y from ibgp_A { neighbor 1.1.2.70 as 12345; }; protocol bgp ibgp_X from ibgp_A { neighbor 3.8.1.106 as 12345; };
template bgp B { # Set our local AS. local as 12345;
# Export exactly what prefixes we want advertised. No surprises. export filter { if proto = "static_bgp" then accept; if proto = "standby_bgp" then accept; if proto = "portable_bgp" && net.len <= 24 then accept; reject; }; # Import filtered routes from upstream. import filter bgp_in_B; }
protocol bgp bgp_B from B { neighbor 7.4.2.130 as 1212; };
-- Tom Daly - VP, Infrastructure tjd@fastly.com
Le 30/08/2014 01:36, Tom Daly a écrit :
Hi, It sounds like you might want to try disabling aspath loop detection for eBGP. Checkout the bird option called "allow local as [number]" as documented at http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2. This will allow you to import prefixes with your own ASN in the aspath.
However, one possible pitfall is that your upstream ISP's router might try to be smart - and not send prefixes with your aspath in them too. Older Foundry boxes do this and there is a per BGP peer knob you have to turn.
Overall, this should let you run everything over eBGP and run two simple island networks.
Cheers, Tom
Unfortunately proper ISPs make their job good and does not advertise your own route. I have a Pop in the same configuration of yours. Two solution : IBGP in a GRE tunnel, it's uggly, but It works. Or static route :) -- Raphael Mazelier AS39605
Thank you for the feedback. I was aware of disabling aspath loop detection, but have not yet explored it; based on my reading, it seemed like a hacky workaround. Are there any drawbacks to this approach, aside from the obvious possibility of creating loops? With regard to an IBGP mesh, it seems that if a BGP session in my mesh fails, routing of prefixes between the affected routers fails. Is this the expected behavior? Is this where I should be using an IGP to route around the failed IBGP? Thanks! On Mon, Sep 1, 2014 at 11:54 AM, Raphael Mazelier <raph@futomaki.net> wrote:
Le 30/08/2014 01:36, Tom Daly a écrit :
Hi, It sounds like you might want to try disabling aspath loop detection for eBGP. Checkout the bird option called "allow local as [number]" as documented at http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2. This will allow you to import prefixes with your own ASN in the aspath.
However, one possible pitfall is that your upstream ISP's router might try to be smart - and not send prefixes with your aspath in them too. Older Foundry boxes do this and there is a per BGP peer knob you have to turn.
Overall, this should let you run everything over eBGP and run two simple island networks.
Cheers, Tom
Unfortunately proper ISPs make their job good and does not advertise your own route. I have a Pop in the same configuration of yours. Two solution : IBGP in a GRE tunnel, it's uggly, but It works. Or static route :)
-- Raphael Mazelier AS39605
Back to basics : 1) Your IGP should be use to propagate loopback (and interco if needed) of your router. You may use multiple path between your router for redundancy. 2) Your IBGP should be a full mesh of your loopback core router using BGP (unless using RR). A IBGP session should not failed, if so you are loosing your route associated to the router. The redundancy is done by the IGP (if you have multiple path) I agreed that disabling as-path loop is an hacky workarroud, which may not work, and make thing unclear. Bad idea for me. So two options : - make some tunnel, and establish an IGP/IBGP session with it. - or use statics routes (with tracking optionnaly). Regards, Le 10/09/2014 15:38, Thomas Johnson a écrit :
Thank you for the feedback. I was aware of disabling aspath loop detection, but have not yet explored it; based on my reading, it seemed like a hacky workaround. Are there any drawbacks to this approach, aside from the obvious possibility of creating loops?
With regard to an IBGP mesh, it seems that if a BGP session in my mesh fails, routing of prefixes between the affected routers fails. Is this the expected behavior? Is this where I should be using an IGP to route around the failed IBGP?
Thanks!
On Mon, Sep 1, 2014 at 11:54 AM, Raphael Mazelier <raph@futomaki.net <mailto:raph@futomaki.net>> wrote:
Le 30/08/2014 01:36, Tom Daly a écrit :
Hi, It sounds like you might want to try disabling aspath loop detection for eBGP. Checkout the bird option called "allow local as [number]" as documented at http://bird.network.cz/?get___doc&f=bird-6.html#ss6.2 <http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2>. This will allow you to import prefixes with your own ASN in the aspath.
However, one possible pitfall is that your upstream ISP's router might try to be smart - and not send prefixes with your aspath in them too. Older Foundry boxes do this and there is a per BGP peer knob you have to turn.
Overall, this should let you run everything over eBGP and run two simple island networks.
Cheers, Tom
Unfortunately proper ISPs make their job good and does not advertise your own route. I have a Pop in the same configuration of yours. Two solution : IBGP in a GRE tunnel, it's uggly, but It works. Or static route :)
-- Raphael Mazelier AS39605
participants (3)
-
Raphael Mazelier -
Thomas Johnson -
Tom Daly