Announce less specific prefix in routeserver environment for upstream purpose
Dear Bird Users, I have the following setup: Peer1 - AS65001 Peer2 - AS65002 RS - AS65123 GW - AS65123 All are connected via a layer 2 infrastructure and share next hop addresses out of a /22. This /22 is part of a /20. RS works as a routeserver with "rs client" in the protocol definition of Peer1, Peer2. My goal is, to announce the /20 over GW to the routeservers GW hasn't the "rs client" option set but "gateway direct". To solve the iBGP and empty AS path of GW, I want to prepend AS65123 for all GW incoming prefixes, so that the as path isn't empty. Do you expect this as a working design to announce the /20 from GW via RS to the peers? Rgds, Stefan
On Fri, Dec 16, 2011 at 02:14:48PM +0100, Stefan Jakob wrote:
Dear Bird Users,
I have the following setup:
Peer1 - AS65001 Peer2 - AS65002
RS - AS65123 GW - AS65123
All are connected via a layer 2 infrastructure and share next hop addresses out of a /22. This /22 is part of a /20.
RS works as a routeserver with "rs client" in the protocol definition of Peer1, Peer2.
My goal is, to announce the /20 over GW to the routeservers GW hasn't the "rs client" option set but "gateway direct".
To solve the iBGP and empty AS path of GW, I want to prepend AS65123 for all GW incoming prefixes, so that the as path isn't empty.
Do you expect this as a working design to announce the /20 from GW via RS to the peers?
This is a bit tricky. I see a possible problem - received route on RS would be probably rejected as loopy (received AS PATH contains local ASN) I see a simpler idea - just use a different 'local as' (perhaps some private ASN) on the BGP config on RS directed to GW (i.e. just on that one connection). In that case the session would be handled as eBGP, like all other sessions. Because the session would be also configured with 'rs client' on RS, the configured (private) ASN would not appear anywhere, it does not matter. BTW, why not just announce that /20 directly on RS? I think that should work too (this is probably not documented, but locally originated routes receives ASN to their path even when propagated through the session with 'rs client' enabled. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
on 16.12.2011 19:49 Ondrej Zajicek wrote:
On Fri, Dec 16, 2011 at 02:14:48PM +0100, Stefan Jakob wrote:
Dear Bird Users,
I have the following setup:
Peer1 - AS65001 Peer2 - AS65002
RS - AS65123 GW - AS65123
All are connected via a layer 2 infrastructure and share next hop addresses out of a /22. This /22 is part of a /20.
RS works as a routeserver with "rs client" in the protocol definition of Peer1, Peer2.
My goal is, to announce the /20 over GW to the routeservers GW hasn't the "rs client" option set but "gateway direct".
To solve the iBGP and empty AS path of GW, I want to prepend AS65123 for all GW incoming prefixes, so that the as path isn't empty.
Do you expect this as a working design to announce the /20 from GW via RS to the peers?
This is a bit tricky. I see a possible problem - received route on RS would be probably rejected as loopy (received AS PATH contains local ASN)
Well, RS would prepend AS65123 towards Peer1 and Peer2, not GW toward RS. This is intended iBGP behaviour, isn't it.
I see a simpler idea - just use a different 'local as' (perhaps some private ASN) on the BGP config on RS directed to GW (i.e. just on that one connection). In that case the session would be handled as eBGP, like all other sessions. Because the session would be also configured with 'rs client' on RS, the configured (private) ASN would not appear anywhere, it does not matter.
Well, is that really simpler?
BTW, why not just announce that /20 directly on RS? I think that should work too (this is probably not documented, but locally originated routes receives ASN to their path even when propagated through the session with 'rs client' enabled.
That also would need additional config as yyou would have to set next-hop to GW (actually the whole truth is that there are two GW) Wouldn't the original proposal (% the update I gave) reflect standard behaviour? Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 5593407 2 mobile: +49 152 53717690 fax: +49 6224 5593407 9
On Fri, Dec 16, 2011 at 11:39:38PM +0100, Arnold Nipper wrote:
This is a bit tricky. I see a possible problem - received route on RS would be probably rejected as loopy (received AS PATH contains local ASN)
Well, RS would prepend AS65123 towards Peer1 and Peer2, not GW toward RS. This is intended iBGP behaviour, isn't it.
In that case it is probably OK.
I see a simpler idea - just use a different 'local as' (perhaps some private ASN) on the BGP config on RS directed to GW (i.e. just on that one connection). In that case the session would be handled as eBGP, like all other sessions. Because the session would be also configured with 'rs client' on RS, the configured (private) ASN would not appear anywhere, it does not matter.
Well, is that really simpler?
It depends. This variant does not need any special handling in filters.
BTW, why not just announce that /20 directly on RS? I think that should work too (this is probably not documented, but locally originated routes receives ASN to their path even when propagated through the session with 'rs client' enabled.
That also would need additional config as yyou would have to set next-hop to GW (actually the whole truth is that there are two GW)
Wouldn't the original proposal (% the update I gave) reflect standard behaviour?
With the update it probably is. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
on 17.12.2011 10:04 Ondrej Zajicek wrote:
On Fri, Dec 16, 2011 at 11:39:38PM +0100, Arnold Nipper wrote:
I see a simpler idea - just use a different 'local as' (perhaps some private ASN) on the BGP config on RS directed to GW (i.e. just on that one connection). In that case the session would be handled as eBGP, like all other sessions. Because the session would be also configured with 'rs client' on RS, the configured (private) ASN would not appear anywhere, it does not matter.
Well, is that really simpler?
It depends. This variant does not need any special handling in filters.
Right ... but you have to take care for this in the peer section anyway. *And* you have to treat the RS on the GW differently as well. I guess it much depends on your philosophy. The best solution perhaps would be to use a different ASN for the GW. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 5593407 2 mobile: +49 152 53717690 fax: +49 6224 5593407 9
participants (3)
-
Arnold Nipper -
Ondrej Zajicek -
Stefan Jakob