Route Server BGP communities (& OS upgrades) - 5/22/2016
Thanks to Chih Chen's help at the U of Wisc, I have testing done for phase1 of the BGP communities exporting that have been requested. (Phase2 would be doing prepends, but I'll have to lab up that functionality as I saw the export function grow 10 times or so before I stopped). Most of the delay was waiting for others to test with me. I plan on implementing this MICE site wide on Sunday, 5/22/2016, starting at around 10:00PM - 11:59PM. All the testing looked good to us during testing, the functions behaved as expected. This function is an expansion of what was tested before. ipHouse has had this export function on it since the end of winter. It is written to properly handle 32-bit ASNs (I believe, that part was provided by the BIRD WIKI author). And of course IPv4 and IPv6 make no difference. The communities supported by this setup will include 0:peerAS -- Don't export route prefix to this peer. 53679:peerAS -- Always export route prefix to this peer. 0:53679 -- Don't export route prefix to all MICE peers. The steps of actually implementing this would be non-eventful, but I know some will want to drop for it. ALSO, we really should upgrade the OS that is running the route servers too. So I'll be doing OS updates and other upgrades that will upgrade BIRD as well in the same window. BIRD moves from 1.4.5 -> 1.5.0. The release notes say it mostly is OSPF changes, I expect no problems in this update, BIRD has been very stable, and the OS has been stable in production use here. Thanks. -- Doug McIntyre <merlyn@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades
On 05/18/2016 11:11 AM, Doug McIntyre wrote:
Thanks to Chih Chen's help at the U of Wisc, I have testing done for phase1 of the BGP communities exporting that have been requested. (Phase2 would be doing prepends, but I'll have to lab up that functionality as I saw the export function grow 10 times or so before I stopped). Most of the delay was waiting for others to test with me.
I plan on implementing this MICE site wide on Sunday, 5/22/2016, starting at around 10:00PM - 11:59PM.
All the testing looked good to us during testing, the functions behaved as expected. This function is an expansion of what was tested before. ipHouse has had this export function on it since the end of winter.
It is written to properly handle 32-bit ASNs (I believe, that part was provided by the BIRD WIKI author). And of course IPv4 and IPv6 make no difference.
The communities supported by this setup will include
0:peerAS -- Don't export route prefix to this peer. 53679:peerAS -- Always export route prefix to this peer. 0:53679 -- Don't export route prefix to all MICE peers.
The steps of actually implementing this would be non-eventful, but I know some will want to drop for it.
ALSO, we really should upgrade the OS that is running the route servers too. So I'll be doing OS updates and other upgrades that will upgrade BIRD as well in the same window. BIRD moves from 1.4.5 -> 1.5.0. The release notes say it mostly is OSPF changes, I expect no problems in this update, BIRD has been very stable, and the OS has been stable in production use here.
Great work folks, glad to see this coming in to production. Is it possible to see examples of the config? Or at least verify that these communities are stripped out on the route server after the action is taken? Cheers, -- Chris Wopat Network Engineer, WiscNet wopat@wiscnet.net 608-210-3965
On Wed, May 18, 2016 at 11:30:25AM -0500, Chris Wopat wrote:
Is it possible to see examples of the config? Or at least verify that these communities are stripped out on the route server after the action is taken?
Here's what I'm doing now function bgp_out_comm(int peeras) { if ! (source = RTS_BGP ) then return false; if peeras > 65535 then { if (ro,0,peeras) ~ bgp_ext_community then return false; if (ro,MICEAS,peeras) ~ bgp_ext_community then return true; if ((ro,0,MICEAS) ~ bgp_ext_community) then return false; } else { if ((0,peeras) ~ bgp_community) || ((ro,0,peeras) ~ bgp_ext_community) then return false; if ((MICEAS,peeras) ~ bgp_community) || ((ro,MICEAS,peeras) ~ bgp_ext_community) then return true; if ((0, MICEAS) ~ bgp_community) || ((ro,0,MICEAS) ~ bgp_ext_community) then return false; } return true; } The route server would need to keep the community state, this is the export function per peer back out. So I guess I'm not understanding the last part of the request. Would you want the export function to clear any communities it had at the end? (Something that is NOT done right now). -- Doug McIntyre <merlyn@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades
On 05/18/2016 11:53 AM, Doug McIntyre wrote:
Would you want the export function to clear any communities it had at the end? (Something that is NOT done right now).
Yes, I would consider it standard practice to clear action communities after the action was taken so they don't propagate/leak beyond AS 53679. IX members may wish to filter them on import as well [1]. Both is probably the most sane outcome. [1] - ras's BGP community presentation is always good to review - https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf -- Chris Wopat Network Engineer, WiscNet wopat@wiscnet.net 608-210-3965
The route servers are performing the action of not advertising. It shouldn't be on all IX participants to perform action on these communities or they wouldn't work as intended. If an IX participant wants to control traffic directly with another peer, they would work with that participant to use their possibly pre existing action communities. -- Chris Wopat Network Engineer, WiscNet wopat@wiscnet.net 608-210-3965 ________________________________ From: Steve Howard <showard@PAULBUNYAN.NET> Sent: May 18, 2016 12:23 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Route Server BGP communities (& OS upgrades) - 5/22/2016 On 05/18/2016 12:03 PM, Chris Wopat wrote: On 05/18/2016 11:53 AM, Doug McIntyre wrote: Would you want the export function to clear any communities it had at the end? (Something that is NOT done right now). Yes, I would consider it standard practice to clear action communities after the action was taken so they don't propagate/leak beyond AS 53679. IX members may wish to filter them on import as well [1]. Both is probably the most sane outcome. [1] - ras's BGP community presentation is always good to review - https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf Perhaps I don't understand the specific question? But, I would prefer that the communities not be stripped. If they are stripped, how would we pass action communities onto other MICE members that require action on their networks? Perhaps just strip out the 53679:* communities would be a better choice? ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
It seems pretty obvious to me that the route servers shouldn't clear ALL communities. Whether they need to clear 53679:* is another question. -- Richard
Chris is referring to deleting the communities that the route server is using to take action (i.e.: it should be transparent in that regard and not leak communities). The original example I had sent on how to do this in Bird has this as part of it as well, and would be considered standard and best practice. These shouldn’t be leaked back and forth between participants. see: https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_based... function bgp_out(int peeras) { if !bgp_out_comm(peeras) then return false; # Remove IXP related communities bgp_community.delete([(0,*)]); bgp_community.delete([(myas,*)]); bgp_ext_community.delete([(ro,0,*)]); bgp_ext_community.delete([(ro,myas,*)]); return true; } -- Andrew Hoyos hoyosa@gmail.com
On May 18, 2016, at 1:00 PM, Steve Howard <showard@paulbunyan.net> wrote:
Like I said. Perhaps I don't understand the question...
I understand the statement "If an IX participant wants to control traffic directly with another peer, they would work with that participant to use their possibly pre existing action communities." But, how will that work if all communities are cleared by the route servers? Or are you saying only strip the communities that the route server uses to take action?
On 05/18/2016 12:49 PM, Chris Wopat wrote:
The route servers are performing the action of not advertising. It shouldn't be on all IX participants to perform action on these communities or they wouldn't work as intended.
If an IX participant wants to control traffic directly with another peer, they would work with that participant to use their possibly pre existing action communities.
-- Chris Wopat Network Engineer, WiscNet wopat@wiscnet.net 608-210-3965
From: Steve Howard <showard@PAULBUNYAN.NET> Sent: May 18, 2016 12:23 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Route Server BGP communities (& OS upgrades) - 5/22/2016
On 05/18/2016 12:03 PM, Chris Wopat wrote:
On 05/18/2016 11:53 AM, Doug McIntyre wrote:
Would you want the export function to clear any communities it had at the end? (Something that is NOT done right now).
Yes, I would consider it standard practice to clear action communities after the action was taken so they don't propagate/leak beyond AS 53679.
IX members may wish to filter them on import as well [1]. Both is probably the most sane outcome.
[1] - ras's BGP community presentation is always good to review - https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf
Perhaps I don't understand the specific question? But, I would prefer that the communities not be stripped. If they are stripped, how would we pass action communities onto other MICE members that require action on their networks? Perhaps just strip out the 53679:* communities would be a better choice?
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
The idea is to ONLY clear these specific action communities, leaving all other communities alone. -- Chris Wopat Network Engineer, WiscNet wopat@wiscnet.net 608-210-3965
Doug & Chih, Thanks for your efforts on this. Mike H, can you post to MICE-ANNOUNCE? And maybe we can convince Richard to throw up a section on the micemn.net technical page that lists the communities? :) Thanks guys. ~Matthew On Wed, May 18, 2016 at 11:11 AM, Doug McIntyre <merlyn@iphouse.net> wrote:
Thanks to Chih Chen's help at the U of Wisc, I have testing done for phase1 of the BGP communities exporting that have been requested. (Phase2 would be doing prepends, but I'll have to lab up that functionality as I saw the export function grow 10 times or so before I stopped). Most of the delay was waiting for others to test with me.
I plan on implementing this MICE site wide on Sunday, 5/22/2016, starting at around 10:00PM - 11:59PM.
All the testing looked good to us during testing, the functions behaved as expected. This function is an expansion of what was tested before. ipHouse has had this export function on it since the end of winter.
It is written to properly handle 32-bit ASNs (I believe, that part was provided by the BIRD WIKI author). And of course IPv4 and IPv6 make no difference.
The communities supported by this setup will include
0:peerAS -- Don't export route prefix to this peer. 53679:peerAS -- Always export route prefix to this peer. 0:53679 -- Don't export route prefix to all MICE peers.
The steps of actually implementing this would be non-eventful, but I know some will want to drop for it.
ALSO, we really should upgrade the OS that is running the route servers too. So I'll be doing OS updates and other upgrades that will upgrade BIRD as well in the same window. BIRD moves from 1.4.5 -> 1.5.0. The release notes say it mostly is OSPF changes, I expect no problems in this update, BIRD has been very stable, and the OS has been stable in production use here.
Thanks.
-- Doug McIntyre <merlyn@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades
On May 18, 2016, at 11:34, Matthew Beckwell <matthewb@AITECH.NET> wrote:
maybe we can convince Richard to throw up a section on the micemn.net technical page that lists the communities? :)
Yes, will do. I have a few updates pending from the new members in the last couple days. I should have this all done in a few hours. -- Richard
I've pushed the changes. I did reword the descriptions, and added some explanatory prose, with examples. Feedback and/or patches are always welcome. http://micemn.net/technical.html I wonder if I should break out the port configuration stuff and the communities into separate pages. I'm not sure which is worse: a longer page or another level of pages/links. -- Richard
On Wed, May 18, 2016 at 11:11:38AM -0500, Doug McIntyre wrote:
I plan on implementing this MICE site wide on Sunday, 5/22/2016, starting at around 10:00PM - 11:59PM.
This maintenance is complete. *) Community phase1 support with MICE community stripping at the end *) OS patches & software updates. Fully up to date now. Everything looks good to me, number of routes roughly the same start to finish, traffic load is swinging down, but it does this time of night as well. -- Doug McIntyre <merlyn@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades
On May 22, 2016, at 11:40 PM, Doug McIntyre <merlyn@iphouse.net> wrote:
This maintenance is complete.
*) Community phase1 support with MICE community stripping at the end *) OS patches & software updates. Fully up to date now.
Thanks Doug! This will be super helpful for the community (pun intended)! -- Andrew Hoyos hoyosa@gmail.com
participants (7)
-
Andrew Hoyos -
Chris Wopat -
Doug McIntyre -
Matthew Beckwell -
Mike Horwath -
Richard Laager -
Steve Howard