Discussion:
announcing BGP prefixes from the same AS at different sites?
Thomas Johnson
2014-08-29 21:52:05 UTC
Permalink
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
2014-08-29 23:36:41 UTC
Permalink
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
Post by Thomas Johnson
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
***@fastly.com
Raphael Mazelier
2014-09-01 16:54:26 UTC
Permalink
Post by Tom Daly
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
Thomas Johnson
2014-09-10 13:38:36 UTC
Permalink
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!
Post by Tom Daly
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
Raphael Mazelier
2014-09-10 16:45:28 UTC
Permalink
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,
Post by Thomas Johnson
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!
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
Loading...