Re: openbgpd; strip private ASNs from bgp updates
Hello, I agree, changing the AS-PATH is not preferred in an ideal world. My case is one where we have a large WAN, with 100+ routers. Designing and traffic engineering that with a single AS is non-trivial so we rely on private ASNs to leverage the excellent eBGP vs iBGP differences to our advantage. That said, we now also do BGP peering with our providers so the need to strip private ASNs is needed, lest we re-engineer our entire WAN. But I do agree, if I really need the feature I am welcome to implement it myself or find another edge router that can accomplish this. On Sun, Mar 31, 2019 at 1:09 PM Claudio Jeker wrote: > > On Fri, Mar 29, 2019 at 08:36:26AM +0100, open...@kene.nu wrote: > > I forgot to add to my previous email. One thing that could be useful > > in this case is to mimic the Cisco option "neighbor x.x.x.x > > remove-private-as" which removes any private ASes from the path on any > > updates to a peer. Just throwing it out there, cant be a very > > difficult option to implement I guess? > > I think changing the AS PATH is a bad thing, removing elements from your > AS path has a major impact on the route selection and opens doors for > routing loops. In general I will only add features like 'as-override' when > there is a clear reason why it is needed. > So my question is, why do you need to use private AS numbers in your > internal network? > > > On Thu, Mar 28, 2019 at 2:55 PM wrote: > > > > > > That will indeed help. Will check it out. > > > > > > How I have solved it now is by having network statements on the edge > > > (/24s). To make the internal routing work I announce more specific > > > prefixes from the internal router, so externally I announce a /24 > > > (from edge to peering partners) but internally I announce two /25s > > > (from internal to edge). That way internet knows how to find my /24 > > > and edge knows how to find its way internally due to /25 being more > > > specific compared to /24. > > > > > > On Wed, Mar 27, 2019 at 9:33 PM Sebastian Benoit > > > wrote: > > > > > > > > open...@kene.nu(open...@kene.nu) on 2019.03.27 12:25:33 +0100: > > > > > Hello, > > > > > > > > > > That would unforunately affect all the prefixes announced to the edge > > > > > router from the internal router. I need it to be only prefixes > > > > > announced to my peering partners. > > > > > > > > > > /Oscar > > > > > > > > > > On Tue, Mar 26, 2019 at 3:50 PM Denis Fondras > > > > > wrote: > > > > > > > > > > > > On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote: > > > > > > > Hello, > > > > > > > > > > > > > > Is there a way to make openbgpd strip private ASNs from updates it > > > > > > > sends to certain neighbors? > > > > > > > I am using openbgpd on my edge routers and distribute routes > > > > > > > generated > > > > > > > internally to the rest of the world. However, the internal > > > > > > > routers use > > > > > > > private ASNs and this is obviously frowned upon by my peering > > > > > > > partners. > > > > > > > > > > > > > > I can of course have network statements on my edge routers but > > > > > > > that > > > > > > > assumes the prefixes will always be reachable via said edge > > > > > > > router, > > > > > > > something I can never be certain of. I would rather the updates > > > > > > > rely > > > > > > > on the prefix actually being announced from the source. > > > > > > > > > > > > > > > > > > > Perhaps with transparent-as ? > > > > > > > > In current (snapshots) there is "as-override": > > > > > > > > as-override (yes|no) > > > > If set to yes, all occurrences of the neighbor AS in the AS > > > > path will be replaced with the local AS before running the > > > > filters. The Adj-RIB-In still holds the unmodified AS > > > > path. > > > > The default value is no. > > > > > > > > this is a neighbor option and used on the session to a peer that uses a > > > > private AS. > > > > > > > > You dont say much about your network structure, but if your edge router > > > > has > > > > a normal As number, and your internal ebgp peers have private As > > > > numbers, > > > > this option will help. > > > > > > > > /Benno > > > > > > > > -- > :wq Claudio
Re: openbgpd; strip private ASNs from bgp updates
On 2019-03-31, Remi Locherer wrote: > On Sun, Mar 31, 2019 at 01:09:06PM +0200, Claudio Jeker wrote: >> On Fri, Mar 29, 2019 at 08:36:26AM +0100, open...@kene.nu wrote: >> > I forgot to add to my previous email. One thing that could be useful >> > in this case is to mimic the Cisco option "neighbor x.x.x.x >> > remove-private-as" which removes any private ASes from the path on any >> > updates to a peer. Just throwing it out there, cant be a very >> > difficult option to implement I guess? >> >> I think changing the AS PATH is a bad thing, removing elements from your >> AS path has a major impact on the route selection and opens doors for >> routing loops. In general I will only add features like 'as-override' when >> there is a clear reason why it is needed. >> So my question is, why do you need to use private AS numbers in your >> internal network? > > It's common to use private AS numbers in data center networks for Clos > topologies (one AS number per leaf switch and one for all spine switches > because of ECMP). > > Private AS numbers are also used for large DMVPN deployments. Also if you have a downstream with two connections to your network, that isn't eligible to get a public ASN (e.g. doesn't have a second upstream provider).
Re: openbgpd; strip private ASNs from bgp updates
On Sun, Mar 31, 2019 at 01:09:06PM +0200, Claudio Jeker wrote: > On Fri, Mar 29, 2019 at 08:36:26AM +0100, open...@kene.nu wrote: > > I forgot to add to my previous email. One thing that could be useful > > in this case is to mimic the Cisco option "neighbor x.x.x.x > > remove-private-as" which removes any private ASes from the path on any > > updates to a peer. Just throwing it out there, cant be a very > > difficult option to implement I guess? > > I think changing the AS PATH is a bad thing, removing elements from your > AS path has a major impact on the route selection and opens doors for > routing loops. In general I will only add features like 'as-override' when > there is a clear reason why it is needed. > So my question is, why do you need to use private AS numbers in your > internal network? It's common to use private AS numbers in data center networks for Clos topologies (one AS number per leaf switch and one for all spine switches because of ECMP). Private AS numbers are also used for large DMVPN deployments. Many BGP implementations have this feature: Junos (remove-private), NetIron (remove-private-as), IOS (remove-private-as) > > > On Thu, Mar 28, 2019 at 2:55 PM wrote: > > > > > > That will indeed help. Will check it out. > > > > > > How I have solved it now is by having network statements on the edge > > > (/24s). To make the internal routing work I announce more specific > > > prefixes from the internal router, so externally I announce a /24 > > > (from edge to peering partners) but internally I announce two /25s > > > (from internal to edge). That way internet knows how to find my /24 > > > and edge knows how to find its way internally due to /25 being more > > > specific compared to /24. > > > > > > On Wed, Mar 27, 2019 at 9:33 PM Sebastian Benoit > > > wrote: > > > > > > > > open...@kene.nu(open...@kene.nu) on 2019.03.27 12:25:33 +0100: > > > > > Hello, > > > > > > > > > > That would unforunately affect all the prefixes announced to the edge > > > > > router from the internal router. I need it to be only prefixes > > > > > announced to my peering partners. > > > > > > > > > > /Oscar > > > > > > > > > > On Tue, Mar 26, 2019 at 3:50 PM Denis Fondras > > > > > wrote: > > > > > > > > > > > > On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote: > > > > > > > Hello, > > > > > > > > > > > > > > Is there a way to make openbgpd strip private ASNs from updates it > > > > > > > sends to certain neighbors? > > > > > > > I am using openbgpd on my edge routers and distribute routes > > > > > > > generated > > > > > > > internally to the rest of the world. However, the internal > > > > > > > routers use > > > > > > > private ASNs and this is obviously frowned upon by my peering > > > > > > > partners. > > > > > > > > > > > > > > I can of course have network statements on my edge routers but > > > > > > > that > > > > > > > assumes the prefixes will always be reachable via said edge > > > > > > > router, > > > > > > > something I can never be certain of. I would rather the updates > > > > > > > rely > > > > > > > on the prefix actually being announced from the source. > > > > > > > > > > > > > > > > > > > Perhaps with transparent-as ? > > > > > > > > In current (snapshots) there is "as-override": > > > > > > > > as-override (yes|no) > > > > If set to yes, all occurrences of the neighbor AS in the AS > > > > path will be replaced with the local AS before running the > > > > filters. The Adj-RIB-In still holds the unmodified AS > > > > path. > > > > The default value is no. > > > > > > > > this is a neighbor option and used on the session to a peer that uses a > > > > private AS. > > > > > > > > You dont say much about your network structure, but if your edge router > > > > has > > > > a normal As number, and your internal ebgp peers have private As > > > > numbers, > > > > this option will help. > > > > > > > > /Benno > > > > > > > > -- > :wq Claudio >
Re: openbgpd; strip private ASNs from bgp updates
On Fri, Mar 29, 2019 at 08:36:26AM +0100, open...@kene.nu wrote: > I forgot to add to my previous email. One thing that could be useful > in this case is to mimic the Cisco option "neighbor x.x.x.x > remove-private-as" which removes any private ASes from the path on any > updates to a peer. Just throwing it out there, cant be a very > difficult option to implement I guess? I think changing the AS PATH is a bad thing, removing elements from your AS path has a major impact on the route selection and opens doors for routing loops. In general I will only add features like 'as-override' when there is a clear reason why it is needed. So my question is, why do you need to use private AS numbers in your internal network? > On Thu, Mar 28, 2019 at 2:55 PM wrote: > > > > That will indeed help. Will check it out. > > > > How I have solved it now is by having network statements on the edge > > (/24s). To make the internal routing work I announce more specific > > prefixes from the internal router, so externally I announce a /24 > > (from edge to peering partners) but internally I announce two /25s > > (from internal to edge). That way internet knows how to find my /24 > > and edge knows how to find its way internally due to /25 being more > > specific compared to /24. > > > > On Wed, Mar 27, 2019 at 9:33 PM Sebastian Benoit > > wrote: > > > > > > open...@kene.nu(open...@kene.nu) on 2019.03.27 12:25:33 +0100: > > > > Hello, > > > > > > > > That would unforunately affect all the prefixes announced to the edge > > > > router from the internal router. I need it to be only prefixes > > > > announced to my peering partners. > > > > > > > > /Oscar > > > > > > > > On Tue, Mar 26, 2019 at 3:50 PM Denis Fondras > > > > wrote: > > > > > > > > > > On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote: > > > > > > Hello, > > > > > > > > > > > > Is there a way to make openbgpd strip private ASNs from updates it > > > > > > sends to certain neighbors? > > > > > > I am using openbgpd on my edge routers and distribute routes > > > > > > generated > > > > > > internally to the rest of the world. However, the internal routers > > > > > > use > > > > > > private ASNs and this is obviously frowned upon by my peering > > > > > > partners. > > > > > > > > > > > > I can of course have network statements on my edge routers but that > > > > > > assumes the prefixes will always be reachable via said edge router, > > > > > > something I can never be certain of. I would rather the updates rely > > > > > > on the prefix actually being announced from the source. > > > > > > > > > > > > > > > > Perhaps with transparent-as ? > > > > > > In current (snapshots) there is "as-override": > > > > > > as-override (yes|no) > > > If set to yes, all occurrences of the neighbor AS in the AS > > > path will be replaced with the local AS before running the > > > filters. The Adj-RIB-In still holds the unmodified AS path. > > > The default value is no. > > > > > > this is a neighbor option and used on the session to a peer that uses a > > > private AS. > > > > > > You dont say much about your network structure, but if your edge router > > > has > > > a normal As number, and your internal ebgp peers have private As numbers, > > > this option will help. > > > > > > /Benno > > > > -- :wq Claudio
Re: openbgpd; strip private ASNs from bgp updates
On 2019-03-29, Sebastian Benoit wrote: > open...@kene.nu(open...@kene.nu) on 2019.03.29 08:36:26 +0100: >> I forgot to add to my previous email. One thing that could be useful >> in this case is to mimic the Cisco option "neighbor x.x.x.x >> remove-private-as" which removes any private ASes from the path on any >> updates to a peer. Just throwing it out there, cant be a very >> difficult option to implement I guess? > > If as-override does what you need, i'm not to keen on adding more knobs. > > That said, i'm happy to look at your diff ;) It's not really equivalent, the private-as peer may be on a different router than the upstream and you want to carry the paths internally with the private asn, just strip them at your outbound edge. The cisco/etc option is slightly different to what's stated, it is "remove private asn if there are *only* private asn in the path".
Re: openbgpd; strip private ASNs from bgp updates
open...@kene.nu(open...@kene.nu) on 2019.03.29 08:36:26 +0100: > I forgot to add to my previous email. One thing that could be useful > in this case is to mimic the Cisco option "neighbor x.x.x.x > remove-private-as" which removes any private ASes from the path on any > updates to a peer. Just throwing it out there, cant be a very > difficult option to implement I guess? If as-override does what you need, i'm not to keen on adding more knobs. That said, i'm happy to look at your diff ;)
Re: openbgpd; strip private ASNs from bgp updates
I forgot to add to my previous email. One thing that could be useful in this case is to mimic the Cisco option "neighbor x.x.x.x remove-private-as" which removes any private ASes from the path on any updates to a peer. Just throwing it out there, cant be a very difficult option to implement I guess? On Thu, Mar 28, 2019 at 2:55 PM wrote: > > That will indeed help. Will check it out. > > How I have solved it now is by having network statements on the edge > (/24s). To make the internal routing work I announce more specific > prefixes from the internal router, so externally I announce a /24 > (from edge to peering partners) but internally I announce two /25s > (from internal to edge). That way internet knows how to find my /24 > and edge knows how to find its way internally due to /25 being more > specific compared to /24. > > On Wed, Mar 27, 2019 at 9:33 PM Sebastian Benoit wrote: > > > > open...@kene.nu(open...@kene.nu) on 2019.03.27 12:25:33 +0100: > > > Hello, > > > > > > That would unforunately affect all the prefixes announced to the edge > > > router from the internal router. I need it to be only prefixes > > > announced to my peering partners. > > > > > > /Oscar > > > > > > On Tue, Mar 26, 2019 at 3:50 PM Denis Fondras wrote: > > > > > > > > On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote: > > > > > Hello, > > > > > > > > > > Is there a way to make openbgpd strip private ASNs from updates it > > > > > sends to certain neighbors? > > > > > I am using openbgpd on my edge routers and distribute routes generated > > > > > internally to the rest of the world. However, the internal routers use > > > > > private ASNs and this is obviously frowned upon by my peering > > > > > partners. > > > > > > > > > > I can of course have network statements on my edge routers but that > > > > > assumes the prefixes will always be reachable via said edge router, > > > > > something I can never be certain of. I would rather the updates rely > > > > > on the prefix actually being announced from the source. > > > > > > > > > > > > > Perhaps with transparent-as ? > > > > In current (snapshots) there is "as-override": > > > > as-override (yes|no) > > If set to yes, all occurrences of the neighbor AS in the AS > > path will be replaced with the local AS before running the > > filters. The Adj-RIB-In still holds the unmodified AS path. > > The default value is no. > > > > this is a neighbor option and used on the session to a peer that uses a > > private AS. > > > > You dont say much about your network structure, but if your edge router has > > a normal As number, and your internal ebgp peers have private As numbers, > > this option will help. > > > > /Benno > >
Re: openbgpd; strip private ASNs from bgp updates
That will indeed help. Will check it out. How I have solved it now is by having network statements on the edge (/24s). To make the internal routing work I announce more specific prefixes from the internal router, so externally I announce a /24 (from edge to peering partners) but internally I announce two /25s (from internal to edge). That way internet knows how to find my /24 and edge knows how to find its way internally due to /25 being more specific compared to /24. On Wed, Mar 27, 2019 at 9:33 PM Sebastian Benoit wrote: > > open...@kene.nu(open...@kene.nu) on 2019.03.27 12:25:33 +0100: > > Hello, > > > > That would unforunately affect all the prefixes announced to the edge > > router from the internal router. I need it to be only prefixes > > announced to my peering partners. > > > > /Oscar > > > > On Tue, Mar 26, 2019 at 3:50 PM Denis Fondras wrote: > > > > > > On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote: > > > > Hello, > > > > > > > > Is there a way to make openbgpd strip private ASNs from updates it > > > > sends to certain neighbors? > > > > I am using openbgpd on my edge routers and distribute routes generated > > > > internally to the rest of the world. However, the internal routers use > > > > private ASNs and this is obviously frowned upon by my peering > > > > partners. > > > > > > > > I can of course have network statements on my edge routers but that > > > > assumes the prefixes will always be reachable via said edge router, > > > > something I can never be certain of. I would rather the updates rely > > > > on the prefix actually being announced from the source. > > > > > > > > > > Perhaps with transparent-as ? > > In current (snapshots) there is "as-override": > > as-override (yes|no) > If set to yes, all occurrences of the neighbor AS in the AS > path will be replaced with the local AS before running the > filters. The Adj-RIB-In still holds the unmodified AS path. > The default value is no. > > this is a neighbor option and used on the session to a peer that uses a > private AS. > > You dont say much about your network structure, but if your edge router has > a normal As number, and your internal ebgp peers have private As numbers, > this option will help. > > /Benno >
Re: openbgpd; strip private ASNs from bgp updates
open...@kene.nu(open...@kene.nu) on 2019.03.27 12:25:33 +0100: > Hello, > > That would unforunately affect all the prefixes announced to the edge > router from the internal router. I need it to be only prefixes > announced to my peering partners. > > /Oscar > > On Tue, Mar 26, 2019 at 3:50 PM Denis Fondras wrote: > > > > On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote: > > > Hello, > > > > > > Is there a way to make openbgpd strip private ASNs from updates it > > > sends to certain neighbors? > > > I am using openbgpd on my edge routers and distribute routes generated > > > internally to the rest of the world. However, the internal routers use > > > private ASNs and this is obviously frowned upon by my peering > > > partners. > > > > > > I can of course have network statements on my edge routers but that > > > assumes the prefixes will always be reachable via said edge router, > > > something I can never be certain of. I would rather the updates rely > > > on the prefix actually being announced from the source. > > > > > > > Perhaps with transparent-as ? In current (snapshots) there is "as-override": as-override (yes|no) If set to yes, all occurrences of the neighbor AS in the AS path will be replaced with the local AS before running the filters. The Adj-RIB-In still holds the unmodified AS path. The default value is no. this is a neighbor option and used on the session to a peer that uses a private AS. You dont say much about your network structure, but if your edge router has a normal As number, and your internal ebgp peers have private As numbers, this option will help. /Benno
Re: openbgpd; strip private ASNs from bgp updates
Hello, That would unforunately affect all the prefixes announced to the edge router from the internal router. I need it to be only prefixes announced to my peering partners. /Oscar On Tue, Mar 26, 2019 at 3:50 PM Denis Fondras wrote: > > On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote: > > Hello, > > > > Is there a way to make openbgpd strip private ASNs from updates it > > sends to certain neighbors? > > I am using openbgpd on my edge routers and distribute routes generated > > internally to the rest of the world. However, the internal routers use > > private ASNs and this is obviously frowned upon by my peering > > partners. > > > > I can of course have network statements on my edge routers but that > > assumes the prefixes will always be reachable via said edge router, > > something I can never be certain of. I would rather the updates rely > > on the prefix actually being announced from the source. > > > > Perhaps with transparent-as ? >
Re: openbgpd; strip private ASNs from bgp updates
On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote: > Hello, > > Is there a way to make openbgpd strip private ASNs from updates it > sends to certain neighbors? > I am using openbgpd on my edge routers and distribute routes generated > internally to the rest of the world. However, the internal routers use > private ASNs and this is obviously frowned upon by my peering > partners. > > I can of course have network statements on my edge routers but that > assumes the prefixes will always be reachable via said edge router, > something I can never be certain of. I would rather the updates rely > on the prefix actually being announced from the source. > Perhaps with transparent-as ?
