From kristian@juniks.net Wed Apr 5 13:26:35 2006 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 5 Apr 2006 14:26:35 +0200 Subject: [Xorp-hackers] BGP peers output Message-ID: <20060405122635.GC17077@juniks.net> Long time ago I submitted a patch for a nicer output of the show bgp peers commands. Atanu had thoughts about recoding the bgp show tool so the patches were never commited. Now I looked them over and thought that the output could be improved further... Cisco output: Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 85.195.4.148 4 39525 2096 86561 1027248 0 0 14:07:57 0 217.10.127.18 4 35706 100426 1423 1027248 0 0 22:18:57 182206 Cisco has MsgRcvd and MsgSent, which I've really doesn't understand the purpose of. Foundrys approach is much better with receied/filtered/sent/tosend prefixes. I think version can be ommited today, anyone using anything else than v4? Foundry output: Neighbor Address AS# State Time Rt:Accepted Filtered Sent ToSend 1.3.3.7 3246 CONN 23h15m50s 0 0 0 30 85.195.63.7 35706 ESTAB 2d11h44m 182145 0 181463 0 85.195.63.14 35706 ESTAB 19d 3h18m 640 0 181463 0 213.50.153.237 3246 ESTAB 22d 8h20m 182115 0 30 0 217.10.127.2 31642 ESTAB 22d 8h20m 2 0 4 0 217.10.127.10 39525 ESTAB 19d16h47m 1 0 1 0 217.10.127.14 39525 CONN 6d16h 6m 0 0 0 182208 217.10.127.17 39525 ESTAB 22h19m43s 2 0 182208 0 I would like to combine the best of this. What do we need to see? Peer IP address Peer remote AS State of the session How long it has been in this state Number of flaps is nice Number of received prefixes number of filtered prefixes number of sent prefixes number of prefixes to send (really great when writing route-maps) I had something like this in mind.. XORP output - Next Generation: me@mybox> show bgp peers F:Flaps PA:Accepted prefixes PF: Filtered prefixes PS:Sent prefixes TS:Prefixes to send Peer ASN F Time PA PF PS TS 53.123.53.25 34853 0 0w,1d,03:45:23 Active, attempt in 67 secs. 87.13.214.1 4834 0 0w,4d,06:23:57 Administratively down 123.123.123.123 12345 0 1w,5d,12:23:54 183521 0 0 0 217.10.127.17 39525 0 00:12:43 182145 0 23 0 We never explicitly tell the user that a session is established, but if you have received prefixes from a neighbor I think you can safely presume it is in a established state. What do you think of this output? Should we sort by IP address or AS number? Perhaps descriptions for BGP neighbors should be included? Now I'm just talking about the short output. The detailed output should ofcourse contain just about every information we have about the session. I will try and propose something for detailed output as well. What do you all think? Regards, Kristian From mhorn@vyatta.com Wed Apr 5 16:50:09 2006 From: mhorn@vyatta.com (Mike Horn) Date: Wed, 5 Apr 2006 08:50:09 -0700 (PDT) Subject: [Xorp-hackers] BGP peers output Message-ID: <9021343.14471144252209063.JavaMail.root@mail.vyatta.com> Hi Kristian, I agree that the "show bgp peers" command could use a few improvements. I like what you have done, I also think that the Juniper "show bgp summary" command also provides some useful combined BGP path information. Below are a few suggestions on the proposed formatting. me@mybox> show bgp peers Total Paths Active Paths Damped Paths Paths with Penalties 220568 183521 12 4 F:Flaps PA:Accepted prefixes PF: Filtered prefixes PS:Sent prefixes TS:Prefixes to send Peer ASN F Time PA PF PS TS 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 15 217.10.127.17 39525 0 00:12:43 182145 0 23 0 I know real estate is tight, but a few of the columns might be too narrow. For instance the Flaps column is max 3 char if you want to have a space before Time which may not be enough (long lived sessions, flapping link, etc). Also, the PF and PS columns are limited to 5 char if you want spacing between them, this is probably typically enough, but if for instance your upstream sends you the full route table and you are filtering for a limited number of prefixes you could you a six char set of PF or if you are sending full table you will need 6 char. I updated the spacing and put some larger values in to demonstrate some suggested spacing updates. I prefer sorting by ASN, but I'm sure opinions on this will vary. I think the description field should be in the 'detail' output but not in the 'summary'. Finally, I think we should have an option to specify the peer IP or ASN and get a subset of peers in the 'summary' format. Thanks for working on this! -mike ----- Original Message ----- From: Kristian Larsson To: xorp-hackers@xorp.org Sent: Wednesday, April 5, 2006 6:26:35 AM GMT-0700 Subject: [Xorp-hackers] BGP peers output Long time ago I submitted a patch for a nicer output of the show bgp peers commands. Atanu had thoughts about recoding the bgp show tool so the patches were never commited. Now I looked them over and thought that the output could be improved further... Cisco output: Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 85.195.4.148 4 39525 2096 86561 1027248 0 0 14:07:57 0 217.10.127.18 4 35706 100426 1423 1027248 0 0 22:18:57 182206 Cisco has MsgRcvd and MsgSent, which I've really doesn't understand the purpose of. Foundrys approach is much better with receied/filtered/sent/tosend prefixes. I think version can be ommited today, anyone using anything else than v4? Foundry output: Neighbor Address AS# State Time Rt:Accepted Filtered Sent ToSend 1.3.3.7 3246 CONN 23h15m50s 0 0 0 30 85.195.63.7 35706 ESTAB 2d11h44m 182145 0 181463 0 85.195.63.14 35706 ESTAB 19d 3h18m 640 0 181463 0 213.50.153.237 3246 ESTAB 22d 8h20m 182115 0 30 0 217.10.127.2 31642 ESTAB 22d 8h20m 2 0 4 0 217.10.127.10 39525 ESTAB 19d16h47m 1 0 1 0 217.10.127.14 39525 CONN 6d16h 6m 0 0 0 182208 217.10.127.17 39525 ESTAB 22h19m43s 2 0 182208 0 I would like to combine the best of this. What do we need to see? Peer IP address Peer remote AS State of the session How long it has been in this state Number of flaps is nice Number of received prefixes number of filtered prefixes number of sent prefixes number of prefixes to send (really great when writing route-maps) I had something like this in mind.. XORP output - Next Generation: me@mybox> show bgp peers F:Flaps PA:Accepted prefixes PF: Filtered prefixes PS:Sent prefixes TS:Prefixes to send Peer ASN F Time PA PF PS TS 53.123.53.25 34853 0 0w,1d,03:45:23 Active, attempt in 67 secs. 87.13.214.1 4834 0 0w,4d,06:23:57 Administratively down 123.123.123.123 12345 0 1w,5d,12:23:54 183521 0 0 0 217.10.127.17 39525 0 00:12:43 182145 0 23 0 We never explicitly tell the user that a session is established, but if you have received prefixes from a neighbor I think you can safely presume it is in a established state. What do you think of this output? Should we sort by IP address or AS number? Perhaps descriptions for BGP neighbors should be included? Now I'm just talking about the short output. The detailed output should ofcourse contain just about every information we have about the session. I will try and propose something for detailed output as well. What do you all think? Regards, Kristian _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From mhorn@vyatta.com Wed Apr 5 18:08:52 2006 From: mhorn@vyatta.com (Mike Horn) Date: Wed, 5 Apr 2006 10:08:52 -0700 (PDT) Subject: Fwd: [Xorp-hackers] BGP peers output Message-ID: <14050385.14771144256932957.JavaMail.root@mail.vyatta.com> Hi all, I'm cross posting this thread since I think the Vyatta community might have some additional thoughts about the formatting of "show bgp" commands. Please take a look at the proposed command outputs and provide your feedback. Thanks! -mike ----- Forwarded Message ----- From: Mike Horn To: Kristian Larsson Cc: xorp-hackers@xorp.org Sent: Wednesday, April 5, 2006 9:50:09 AM GMT-0700 Subject: Re: [Xorp-hackers] BGP peers output Hi Kristian, I agree that the "show bgp peers" command could use a few improvements. I like what you have done, I also think that the Juniper "show bgp summary" command also provides some useful combined BGP path information. Below are a few suggestions on the proposed formatting. me@mybox> show bgp peers Total Paths Active Paths Damped Paths Paths with Penalties 220568 183521 12 4 F:Flaps PA:Accepted prefixes PF: Filtered prefixes PS:Sent prefixes TS:Prefixes to send Peer ASN F Time PA PF PS TS 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 15 217.10.127.17 39525 0 00:12:43 182145 0 23 0 I know real estate is tight, but a few of the columns might be too narrow. For instance the Flaps column is max 3 char if you want to have a space before Time which may not be enough (long lived sessions, flapping link, etc). Also, the PF and PS columns are limited to 5 char if you want spacing between them, this is probably typically enough, but if for instance your upstream sends you the full route table and you are filtering for a limited number of prefixes you could you a six char set of PF or if you are sending full table you will need 6 char. I updated the spacing and put some larger values in to demonstrate some suggested spacing updates. I prefer sorting by ASN, but I'm sure opinions on this will vary. I think the description field should be in the 'detail' output but not in the 'summary'. Finally, I think we should have an option to specify the peer IP or ASN and get a subset of peers in the 'summary' format. Thanks for working on this! -mike ----- Original Message ----- From: Kristian Larsson To: xorp-hackers@xorp.org Sent: Wednesday, April 5, 2006 6:26:35 AM GMT-0700 Subject: [Xorp-hackers] BGP peers output Long time ago I submitted a patch for a nicer output of the show bgp peers commands. Atanu had thoughts about recoding the bgp show tool so the patches were never commited. Now I looked them over and thought that the output could be improved further... Cisco output: Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 85.195.4.148 4 39525 2096 86561 1027248 0 0 14:07:57 0 217.10.127.18 4 35706 100426 1423 1027248 0 0 22:18:57 182206 Cisco has MsgRcvd and MsgSent, which I've really doesn't understand the purpose of. Foundrys approach is much better with receied/filtered/sent/tosend prefixes. I think version can be ommited today, anyone using anything else than v4? Foundry output: Neighbor Address AS# State Time Rt:Accepted Filtered Sent ToSend 1.3.3.7 3246 CONN 23h15m50s 0 0 0 30 85.195.63.7 35706 ESTAB 2d11h44m 182145 0 181463 0 85.195.63.14 35706 ESTAB 19d 3h18m 640 0 181463 0 213.50.153.237 3246 ESTAB 22d 8h20m 182115 0 30 0 217.10.127.2 31642 ESTAB 22d 8h20m 2 0 4 0 217.10.127.10 39525 ESTAB 19d16h47m 1 0 1 0 217.10.127.14 39525 CONN 6d16h 6m 0 0 0 182208 217.10.127.17 39525 ESTAB 22h19m43s 2 0 182208 0 I would like to combine the best of this. What do we need to see? Peer IP address Peer remote AS State of the session How long it has been in this state Number of flaps is nice Number of received prefixes number of filtered prefixes number of sent prefixes number of prefixes to send (really great when writing route-maps) I had something like this in mind.. XORP output - Next Generation: me@mybox> show bgp peers F:Flaps PA:Accepted prefixes PF: Filtered prefixes PS:Sent prefixes TS:Prefixes to send Peer ASN F Time PA PF PS TS 53.123.53.25 34853 0 0w,1d,03:45:23 Active, attempt in 67 secs. 87.13.214.1 4834 0 0w,4d,06:23:57 Administratively down 123.123.123.123 12345 0 1w,5d,12:23:54 183521 0 0 0 217.10.127.17 39525 0 00:12:43 182145 0 23 0 We never explicitly tell the user that a session is established, but if you have received prefixes from a neighbor I think you can safely presume it is in a established state. What do you think of this output? Should we sort by IP address or AS number? Perhaps descriptions for BGP neighbors should be included? Now I'm just talking about the short output. The detailed output should ofcourse contain just about every information we have about the session. I will try and propose something for detailed output as well. What do you all think? Regards, Kristian _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian@juniks.net Wed Apr 5 18:11:11 2006 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 5 Apr 2006 19:11:11 +0200 Subject: [Xorp-hackers] BGP peers output In-Reply-To: <9021343.14471144252209063.JavaMail.root@mail.vyatta.com> References: <9021343.14471144252209063.JavaMail.root@mail.vyatta.com> Message-ID: <20060405171111.GE17077@juniks.net> Sorry for cross posting. This was originally sent to the xorp hackers list, but as Mike mentioned to me, there could be quite a few users on the vyatta list with valuable input so here goes.... On Wed, Apr 05, 2006 at 08:50:09AM -0700, Mike Horn wrote: > Hi Kristian, > > I agree that the "show bgp peers" command could use a few improvements. I like what you have done, I also think that the Juniper "show bgp summary" command also provides some useful combined BGP path information. Below are a few suggestions on the proposed formatting. > > me@mybox> show bgp peers > > Total Paths Active Paths Damped Paths Paths with Penalties > 220568 183521 12 4 > > F:Flaps PA:Accepted prefixes PF: Filtered prefixes PS:Sent prefixes > TS:Prefixes to send > > Peer ASN F Time PA PF PS TS > 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) > 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down > 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 15 > 217.10.127.17 39525 0 00:12:43 182145 0 23 0 > > > I know real estate is tight, but a few of the columns might be too narrow. For instance the Flaps column is max 3 char if you want to have a space before Time which may not be enough (long lived sessions, flapping link, etc). Perhaps we should just have days? 100w,5d = 705 day 705d is shorter. I think the big question is if we should maintain the width of not more than 80 chars. If you're on an old terminal over serial or something you're probably limited to 80 chars but at least on my workstation I often use wider xterms, especially since I don't wan 'show bgp routes' output to be wrapped (long AS paths..). > > Also, the PF and PS columns are limited to 5 char if you want spacing between them, this is probably typically enough, but if for instance your upstream sends you the full route table and you are filtering for a limited number of prefixes you could you a six char set of PF or if you are sending full table you will need 6 char. You're right. All fields should take 6 chars. It'll be awhile before we reach over 1 million routes... > I updated the spacing and put some larger values in to demonstrate some suggested spacing updates. > > I prefer sorting by ASN, but I'm sure opinions on this will vary. I think the description field should be in the 'detail' output but not in the 'summary'. I must say I also prefer sorting by ASN, perhaps the ASN column should be first? So primary sorting is ASN and secondary is IP address, so that if you have several peerings with the same AS they are sorted by IP. > > Finally, I think we should have an option to specify the peer IP or ASN and get a subset of peers in the 'summary' format. Indeed. > Thanks for working on this! :-) For the record there's a xorp bug open on this - #217. Kristian. > > ----- Original Message ----- > From: Kristian Larsson > To: xorp-hackers@xorp.org > Sent: Wednesday, April 5, 2006 6:26:35 AM GMT-0700 > Subject: [Xorp-hackers] BGP peers output > > Long time ago I submitted a patch for a nicer > output of the show bgp peers commands. > Atanu had thoughts about recoding the bgp show > tool so the patches were never commited. Now I > looked them over and thought that the output could > be improved further... > > Cisco output: > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd > 85.195.4.148 4 39525 2096 86561 1027248 0 0 14:07:57 0 > 217.10.127.18 4 35706 100426 1423 1027248 0 0 22:18:57 182206 > > Cisco has MsgRcvd and MsgSent, which I've really doesn't understand the purpose > of. Foundrys approach is much better with receied/filtered/sent/tosend prefixes. > I think version can be ommited today, anyone using anything else than v4? > > Foundry output: > Neighbor Address AS# State Time Rt:Accepted Filtered Sent ToSend > 1.3.3.7 3246 CONN 23h15m50s 0 0 0 30 > 85.195.63.7 35706 ESTAB 2d11h44m 182145 0 181463 0 > 85.195.63.14 35706 ESTAB 19d 3h18m 640 0 181463 0 > 213.50.153.237 3246 ESTAB 22d 8h20m 182115 0 30 0 > 217.10.127.2 31642 ESTAB 22d 8h20m 2 0 4 0 > 217.10.127.10 39525 ESTAB 19d16h47m 1 0 1 0 > 217.10.127.14 39525 CONN 6d16h 6m 0 0 0 182208 > 217.10.127.17 39525 ESTAB 22h19m43s 2 0 182208 0 > > > I would like to combine the best of this. > What do we need to see? > > Peer IP address > Peer remote AS > State of the session > How long it has been in this state > Number of flaps is nice > Number of received prefixes > number of filtered prefixes > number of sent prefixes > number of prefixes to send (really great when writing route-maps) > > I had something like this in mind.. > XORP output - Next Generation: > me@mybox> show bgp peers > F:Flaps PA:Accepted prefixes PF: Filtered prefixes PS:Sent prefixes > TS:Prefixes to send > > Peer ASN F Time PA PF PS TS > 53.123.53.25 34853 0 0w,1d,03:45:23 Active, attempt in 67 secs. > 87.13.214.1 4834 0 0w,4d,06:23:57 Administratively down > 123.123.123.123 12345 0 1w,5d,12:23:54 183521 0 0 0 > 217.10.127.17 39525 0 00:12:43 182145 0 23 0 > > We never explicitly tell the user that a session is established, but if you > have received prefixes from a neighbor I think you can safely presume it is > in a established state. What do you think of this output? > Should we sort by IP address or AS number? Perhaps descriptions for BGP > neighbors should be included? > > Now I'm just talking about the short output. The detailed output should > ofcourse contain just about every information we have about the session. > I will try and propose something for detailed output as well. > > What do you all think? > > Regards, > Kristian > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From robert@vyatta.com Wed Apr 5 19:55:18 2006 From: robert@vyatta.com (Robert Bays) Date: Wed, 05 Apr 2006 11:55:18 -0700 Subject: Fwd: [Xorp-hackers] BGP peers output In-Reply-To: <14050385.14771144256932957.JavaMail.root@mail.vyatta.com> References: <14050385.14771144256932957.JavaMail.root@mail.vyatta.com> Message-ID: <44341296.6040304@vyatta.com> Mike, Kristian, What is the definition of the 'to send' field in this example? cheers, robert. Mike Horn wrote: > Hi all, > > I'm cross posting this thread since I think the Vyatta community might have some additional thoughts about the formatting of "show bgp" commands. Please take a look at the proposed command outputs and provide your feedback. Thanks! > > -mike > > ----- Forwarded Message ----- > From: Mike Horn > To: Kristian Larsson > Cc: xorp-hackers@xorp.org > Sent: Wednesday, April 5, 2006 9:50:09 AM GMT-0700 > Subject: Re: [Xorp-hackers] BGP peers output > > Hi Kristian, > > I agree that the "show bgp peers" command could use a few improvements. I like what you have done, I also think that the Juniper "show bgp summary" command also provides some useful combined BGP path information. Below are a few suggestions on the proposed formatting. > > me@mybox> show bgp peers > > Total Paths Active Paths Damped Paths Paths with Penalties > 220568 183521 12 4 > > F:Flaps PA:Accepted prefixes PF: Filtered prefixes PS:Sent prefixes > TS:Prefixes to send > > Peer ASN F Time PA PF PS TS > 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) > 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down > 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 15 > 217.10.127.17 39525 0 00:12:43 182145 0 23 0 > > > I know real estate is tight, but a few of the columns might be too narrow. For instance the Flaps column is max 3 char if you want to have a space before Time which may not be enough (long lived sessions, flapping link, etc). > > Also, the PF and PS columns are limited to 5 char if you want spacing between them, this is probably typically enough, but if for instance your upstream sends you the full route table and you are filtering for a limited number of prefixes you could you a six char set of PF or if you are sending full table you will need 6 char. > > I updated the spacing and put some larger values in to demonstrate some suggested spacing updates. > > I prefer sorting by ASN, but I'm sure opinions on this will vary. I think the description field should be in the 'detail' output but not in the 'summary'. > > Finally, I think we should have an option to specify the peer IP or ASN and get a subset of peers in the 'summary' format. > > Thanks for working on this! > > -mike > > ----- Original Message ----- > From: Kristian Larsson > To: xorp-hackers@xorp.org > Sent: Wednesday, April 5, 2006 6:26:35 AM GMT-0700 > Subject: [Xorp-hackers] BGP peers output > > Long time ago I submitted a patch for a nicer > output of the show bgp peers commands. > Atanu had thoughts about recoding the bgp show > tool so the patches were never commited. Now I > looked them over and thought that the output could > be improved further... > > Cisco output: > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd > 85.195.4.148 4 39525 2096 86561 1027248 0 0 14:07:57 0 > 217.10.127.18 4 35706 100426 1423 1027248 0 0 22:18:57 182206 > > Cisco has MsgRcvd and MsgSent, which I've really doesn't understand the purpose > of. Foundrys approach is much better with receied/filtered/sent/tosend prefixes. > I think version can be ommited today, anyone using anything else than v4? > > Foundry output: > Neighbor Address AS# State Time Rt:Accepted Filtered Sent ToSend > 1.3.3.7 3246 CONN 23h15m50s 0 0 0 30 > 85.195.63.7 35706 ESTAB 2d11h44m 182145 0 181463 0 > 85.195.63.14 35706 ESTAB 19d 3h18m 640 0 181463 0 > 213.50.153.237 3246 ESTAB 22d 8h20m 182115 0 30 0 > 217.10.127.2 31642 ESTAB 22d 8h20m 2 0 4 0 > 217.10.127.10 39525 ESTAB 19d16h47m 1 0 1 0 > 217.10.127.14 39525 CONN 6d16h 6m 0 0 0 182208 > 217.10.127.17 39525 ESTAB 22h19m43s 2 0 182208 0 > > > I would like to combine the best of this. > What do we need to see? > > Peer IP address > Peer remote AS > State of the session > How long it has been in this state > Number of flaps is nice > Number of received prefixes > number of filtered prefixes > number of sent prefixes > number of prefixes to send (really great when writing route-maps) > > I had something like this in mind.. > XORP output - Next Generation: > me@mybox> show bgp peers > F:Flaps PA:Accepted prefixes PF: Filtered prefixes PS:Sent prefixes > TS:Prefixes to send > > Peer ASN F Time PA PF PS TS > 53.123.53.25 34853 0 0w,1d,03:45:23 Active, attempt in 67 secs. > 87.13.214.1 4834 0 0w,4d,06:23:57 Administratively down > 123.123.123.123 12345 0 1w,5d,12:23:54 183521 0 0 0 > 217.10.127.17 39525 0 00:12:43 182145 0 23 0 > > We never explicitly tell the user that a session is established, but if you > have received prefixes from a neighbor I think you can safely presume it is > in a established state. What do you think of this output? > Should we sort by IP address or AS number? Perhaps descriptions for BGP > neighbors should be included? > > Now I'm just talking about the short output. The detailed output should > ofcourse contain just about every information we have about the session. > I will try and propose something for detailed output as well. > > What do you all think? > > Regards, > Kristian > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From orante2003@yahoo.it Thu Apr 13 12:04:38 2006 From: orante2003@yahoo.it (ORANTE TUCCERI) Date: Thu, 13 Apr 2006 13:04:38 +0200 (CEST) Subject: [Xorp-hackers] re.info. Message-ID: <20060413110438.44554.qmail@web26808.mail.ukl.yahoo.com> --0-1511559428-1144926278=:29078 Content-Type: text/plain; charset=iso-8859-1 Which the timers of OSPF? they are configurables from customer? how? which the OSPF door (in order to create socket)? t. y. --------------------------------- Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive --0-1511559428-1144926278=:29078 Content-Type: text/html; charset=iso-8859-1 Which the timers of OSPF? they are configurables from customer? how?
which the OSPF door (in order to create socket)?
t. y.

<orante2003@yahoo.it>

Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive --0-1511559428-1144926278=:29078-- From jfletcher@vyatta.com Fri Apr 14 00:36:55 2006 From: jfletcher@vyatta.com (Justin Fletcher) Date: Thu, 13 Apr 2006 16:36:55 -0700 (PDT) Subject: [Xorp-hackers] Patch posted for bug 263 Message-ID: <689070.18181144971415702.JavaMail.root@mail.vyatta.com> I've just attached a proposed fix to bug 263: RIP - configuration help formatting. It updates the help strings to: create protocols rip interface eth0 vif eth0 address 172.16.0.50 ? Possible completions: <[Enter]> Execute this command accept-default-route Accept default route accept-non-rip-requests Answer RIP requests made from non-RIP processes advertise-default-route Advertise default route on address authentication Authentication method disable Disable RIP on address horizon Horizon type applied to routes announced on address interpacket-delay-msecs Minimum delay between outbound RIP packets metric Cost metric added to routes received on address passive Set address as receive only route-deletion-secs Route deletion interval after advertised as unreachable route-expiry-secs Route expiration interval in the absence of updates table-announce-max-secs Upper bound of route table announcements table-announce-min-secs Lower bound of route table announcements table-request-secs RIP request interval when no known neighbors triggered-update-max-secs Upper bound of triggered update announcements triggered-update-min-secs Lower bound of triggered update announcements { Enter text on multiple lines Justin Fletcher Vyatta From jfletcher@vyatta.com Fri Apr 14 01:58:09 2006 From: jfletcher@vyatta.com (Justin Fletcher) Date: Thu, 13 Apr 2006 17:58:09 -0700 (PDT) Subject: [Xorp-hackers] Decreased RIPv2 request rate Message-ID: <18354872.18271144976289842.JavaMail.root@mail.vyatta.com> I've just provided a patch for an issue we've seen where RIPv2 requests were sent out each second. It's a simple template change for the default interval, and is attached to bug 613. Justin Fletcher Vyatta From hasso@linux.ee Fri Apr 14 17:57:00 2006 From: hasso@linux.ee (Hasso Tepper) Date: Fri, 14 Apr 2006 19:57:00 +0300 Subject: [Xorp-hackers] Patch posted for bug 263 In-Reply-To: <689070.18181144971415702.JavaMail.root@mail.vyatta.com> References: <689070.18181144971415702.JavaMail.root@mail.vyatta.com> Message-ID: <200604141957.00595.hasso@linux.ee> Justin Fletcher wrote: > I've just attached a proposed fix to bug 263: RIP - configuration help > formatting. It updates the help strings to: Note, that this probably will break again ;). 1) Pavlin already committed my patch from Xorp bugzilla #530 which will make command name part 5 symbols wider than it is in Vyatta at the moment. 2) We discussed some issues regarding cli commands via mail with Pavlin and already agreed to remove unit suffixes from commands (secs and msecs). This info belongs to help string. I'm also in progress to summarise my thoughts regarding these issues and hopefully can post them into hackers list later today or tomorrow. Hopefully we'll have kind of style guide to avoid this kind of issues in future. regards, -- Hasso Tepper From pavlin@icir.org Sat Apr 15 04:43:44 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 14 Apr 2006 20:43:44 -0700 Subject: [Xorp-hackers] Patch posted for bug 263 In-Reply-To: Message from Hasso Tepper of "Fri, 14 Apr 2006 19:57:00 +0300." <200604141957.00595.hasso@linux.ee> Message-ID: <200604150343.k3F3hiQj088896@possum.icir.org> > Justin Fletcher wrote: > > I've just attached a proposed fix to bug 263: RIP - configuration help > > formatting. It updates the help strings to: > > Note, that this probably will break again ;). > > 1) Pavlin already committed my patch from Xorp bugzilla #530 which will > make command name part 5 symbols wider than it is in Vyatta at the > moment. > 2) We discussed some issues regarding cli commands via mail with Pavlin > and already agreed to remove unit suffixes from commands (secs and > msecs). This info belongs to help string. > > I'm also in progress to summarise my thoughts regarding these issues and > hopefully can post them into hackers list later today or tomorrow. > Hopefully we'll have kind of style guide to avoid this kind of issues in > future. On one hand, I'd like to apply the cleanup of the help strings from Justin. On the other hand, if we are to perform this kind of cleanup (including the secs/msecs renaming, etc) we should do it across all template files, otherwise we will have to keep fixing same issues again and again. It will be great if we have a style guide for configuration options, help strings, etc, so I think first we should have the style guide written and committed to CVS, and then cleanup all templates. Pavlin From hasso@linux.ee Sat Apr 15 11:16:39 2006 From: hasso@linux.ee (Hasso Tepper) Date: Sat, 15 Apr 2006 13:16:39 +0300 Subject: [Xorp-hackers] Cli style guide draft Message-ID: <200604151316.40126.hasso@linux.ee> --Boundary-00=_IgMQEQvQ0zFQ0Fy Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline As I promised, here are my ideas about cli style guide. Feel free to comment, make additions etc. ************** * Configuration commands (node names) SHOULD be less than 20 symbols long. The length of configuration command + short help MUST NOT exceed 76 symbols. This is to ensure that the output of possible completions would fit into 80 symbols wide terminal. In most of cases it's wrapping that makes the output look really bad. So, keep the length of node names and short help minimum. Node names are especially important. If it can be shortened below 20 symbols without loosing the point, it should be done. If it can't be done, OK, but these cases should be kept minimum. For example: restore-original-config-on-shutdown -> restore-system-conf enable-ip-router-alert-option-check -> router-alert-check * No units in node names (sec, msec), this info should be in short help. For example: interpacket-delay-msecs Minimum delay between outbound RIPng packets. vs. interpacket-delay Minimum delay between outbound RIPng packets (msec) * Avoid "Set ...", "Edit ..." etc in short help strings. Short help string should just describe shortly variables/commands. And note that it can be logically wrong as well - variables and commands aren't always set, but sometimes deleted as well. For example: horizon Set the horizon type applied to routes announced on address. vs. horizon Horizon type applied to announced routes * Short help strings begin with capital letter and don't have dot in the end. Just to make the look consistent. * Keep parameters user have to configure minimum. For example timers with jitter can be described as "some-timer-min" and "some-timer-max" (as it is in rip(ng)). If user wants to change timer, he/she has to configure two parameters. But mostly it's just average value which user wants to change. So, prefer "some-timer" and "some-jitter" with good default to jitter, better in percents than in absolute value. * Commands should describe what they do, not for what they can be used. For example there is command in rip(ng): accept-non-rip-requests Answer RIP requests made from non-RIP processes It's not clear at all what it does. Better use following command and help and describe for what it can be used in documentation: source-port-check Answer RIPng requests made only from RIPng port ************** I played with these ideas in RIPng configuration and picture (to make sure that mail clients don't mess result with wrapping) with result is attached. regards, -- Hasso Tepper --Boundary-00=_IgMQEQvQ0zFQ0Fy Content-Type: image/png; name="xorp-ripng.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xorp-ripng.png" iVBORw0KGgoAAAANSUhEUgAAAtQAAAEvCAIAAADq8sHgAAAAAXNSR0IDN8dNUwAACXRpQ0NQaWNj AAB42u2ZZ1AUaRrH3+6eHBiYGYYMQxyCRAkDSM5JJAdRgRkyjDAkBUzI4gqsICKSFEFEARdcXYKs oiKKAVFQwIDuIIuAsi6uIioqN+gHr+qu7tN9ubp5Prz9q38/VW+Hp6p/VQ2A7HgiJykVNgAgiZfG 93WxZwaHhDKxowAFKIAMYAAiOKnJXn7O/kBYK73gX+rdKIBWjvd0//35/1hEbhKPCwCEE3I8NyqV I+Q0Icdyk7gr+fgKZ6YlCzPYUch0vvAChRy8wpHfOHGFY77xzq89/r4OQi4DAEeK+cqEoysc+ZWp p1aYE8tPAkC2S9iv9m3fryWuuXITzDheWhSfF5GoBf7b9U97iaWuPPDI9LjENN043v/oPivz8o3e WH2dA4hR8T3bLHwH7FcAICXfM7XDAFB2A9DR8z2LPA5AZwkA0k856fyMbxlqZUEDgnAS6UAGKAJV oAl0gREwA5bAFjgBd+AN/EEI2Ag4IBYkAT7IBDlgF8gHhaAEHARVoBY0gCbQCs6ATnAeXAbXwC1w F4yAx0AApsBLMA/egSUIgrAQGaJBMpASpA7pQEYQG7KGnCBPyBcKgcKhGIgHpUM50G6oECqFqqA6 qAn6BToHXYZuQEPQQ2gCmoX+hj7CCEyC6bACrAHrw2zYDvaA/eENcAycAmfBefA+uAKuh0/BHfBl +BY8Agvgl/ACAhAiwkCUEV2EjTgg3kgoEo3wke1IAVKO1COtSDfSj9xDBMgc8gGFQdFQTJQuyhLl igpAcVApqO2oIlQV6iSqA9WHuoeaQM2jvqDJaHm0DtoC7YYORsegM9H56HJ0I7odfRU9gp5Cv8Ng MAwMC2OGccWEYOIx2ZgizGFMG+YSZggziVnAYrEyWB2sFdYbG4FNw+ZjK7GnsBexw9gp7HscEaeE M8I540JxPFwurhzXjOvBDeOmcUt4cbw63gLvjefit+KL8Q34bvwd/BR+iSBBYBGsCP6EeMIuQgWh lXCVME54QyQSVYjmRB9iHHEnsYJ4mnidOEH8QKKStEkOpDBSOmkf6QTpEukh6Q2ZTNYg25JDyWnk feQm8hXyU/J7MZqYnpibGFdsh1i1WIfYsNgrCp6iTrGjbKRkUcopZyl3KHPieHENcQfxCPHt4tXi 58THxBckaBKGEt4SSRJFEs0SNyRmqFiqBtWJyqXmUY9Rr1AnaQhNleZA49B20xpoV2lTdAydRXej x9ML6T/TB+nzklRJY8lAyS2S1ZIXJAUMhKHBcGMkMooZZxijjI9SClJ2UlFSe6VapYalFqXlpG2l o6QLpNukR6Q/yjBlnGQSZPbLdMo8kUXJasv6yGbKHpG9KjsnR5ezlOPIFcidkXskD8try/vKZ8sf kx+QX1BQVHBRSFaoVLiiMKfIULRVjFcsU+xRnFWiKVkrxSmVKV1UesGUZNoxE5kVzD7mvLK8sqty unKd8qDykgpLJUAlV6VN5YkqQZWtGq1aptqrOq+mpOallqPWovZIHa/OVo9VP6Ter76owdII0tij 0akxw5JmubGyWC2scU2ypo1mima95n0tjBZbK0HrsNZdbVjbRDtWu1r7jg6sY6oTp3NYZ2gVepX5 Kt6q+lVjuiRdO90M3RbdCT2Gnqderl6n3it9Nf1Q/f36/fpfDEwMEg0aDB4bUg3dDXMNuw3/NtI2 4hhVG91fTV7tvHrH6q7Vr411jKOMjxg/MKGZeJnsMek1+WxqZso3bTWdNVMzCzerMRtj09nr2EXs 6+Zoc3vzHebnzT9YmFqkWZyx+MtS1zLBstlyZg1rTdSahjWTVipWEVZ1VgJrpnW49VFrgY2yTYRN vc0zW1Vbrm2j7bSdll283Sm7V/YG9nz7dvtFBwuHbQ6XHBFHF8cCx0EnqlOAU5XTU2cV5xjnFud5 FxOXbJdLrmhXD9f9rmNuCm4ctya3eXcz923ufR4kDz+PKo9nntqefM9uL9jL3euA1/ha9bW8tZ3e wNvN+4D3k3WsdSnrfvPB+KzzqfZ57mvom+Pb70fz2+TX7PfO396/2P9xgGZAekBvICUwLLApcDHI Mag0SBCsH7wt+FaIbEhcSFcoNjQwtDF0Yb3T+oPrp8JMwvLDRjewNmzZcGOj7MbEjRc2UTZFbDob jg4PCm8O/xThHVEfsRDpFlkTOc9x4BzivOTacsu4s1FWUaVR09FW0aXRMzFWMQdiZmNtYstj5+Ic 4qriXse7xtfGLyZ4J5xIWE4MSmxLwiWFJ53jUXkJvL7Nipu3bB5K1knOTxakWKQcTJnne/AbU6HU DaldaXThh3kgXTP9h/SJDOuM6oz3mYGZZ7dIbOFtGdiqvXXv1uks56zj2ahsTnZvjnLOrpyJbXbb 6rZD2yO39+5Q3ZG3Y2qny86Tuwi7EnbdzjXILc19uztod3eeQt7OvMkfXH5oyRfL5+eP7bHcU/sj 6se4Hwf3rt5bufdLAbfgZqFBYXnhpyJO0c2fDH+q+Gl5X/S+wWLT4iMlmBJeyeh+m/0nSyVKs0on D3gd6ChjlhWUvT246eCNcuPy2kOEQ+mHBBWeFV2VapUllZ+qYqtGqu2r22rka/bWLB7mHh4+Ynuk tVahtrD249G4ow/qXOo66jXqy49hjmUce94Q2NB/nH28qVG2sbDx8wneCcFJ35N9TWZNTc3yzcUt cEt6y+ypsFN3f3b8uatVt7WujdFWeBqcTj/94pfwX0bPeJzpPcs+2/qr+q817bT2gg6oY2vHfGds p6ArpGvonPu53m7L7vbf9H47cV75fPUFyQvFPYSevJ7li1kXFy4lX5q7HHN5sndT7+MrwVfu9/n0 DV71uHr9mvO1K/12/RevW10/f8Pixrmb7Judt0xvdQyYDLTfNrndPmg62HHH7E7XXfO73UNrhnqG bYYv33O8d+2+2/1bI2tHhkYDRh+MhY0JHnAfzDxMfPj6Ucajpcc7x9HjBU/En5Q/lX9a/7vW720C U8GFCceJgWd+zx5PciZf/pH6x6epvOfk5+XTStNNM0Yz52edZ+++WP9i6mXyy6W5/D8l/qx5pfnq 179s/xqYD56fes1/vfx30RuZNyfeGr/tXVi38PRd0rulxYL3Mu9PfmB/6P8Y9HF6KfMT9lPFZ63P 3V88vowvJy0vi1xA5AIiFxC5gMgFRC4gcgGRC4hcQOQCIhcQuYDIBUQuIHKB/2MX+PrvRljIynJs DAD/bAA8bwNQWQWARjQAlLB/AEpyAwzt5FOhAAAAHHpUWHRhdXRob3IAAHja80gsLs5XCEktKEgt AgActQSPxnz/2QAAIABJREFUeNrtnVuS5LgNRdUdub7+q1XWX6/Q9pSdkdYDAkEQBKhzPiamKzNF EAQpvu/29fW1AQAAAETxGxcAAAAAnQ8AAACg8wEAAADgwevzH3///v3z508Gs/5tyec/k1gFdXlH VEws/SQ3PW6TmBHvfy+bZWvdMyWXV4AP47OsTD3Pu8nsulkPbH1O3Mv3c8PpLtUkPY88hp2alNC2 zH6ba2F+hyxZKJ8PzFkEp1bJpgZnyj25hFkWnvnApsyrlJueE/nyZdkFAKBrNPnv/1++X/vALC9W ZNl4yX2fT9OF2Rj3j/R98/ev3o4+nRiUf9Wa5Z+/f05+KMvY1/hbCw0PlOP41FFmz9ss7ImopkLR 1GrZ+N2jbn2oicOfrymNNJhhKBTZGzuylbKcZaE9dHkZfP5Fv6JRKMv6olTa4N5UukSUYLzNjFMb hFW540e2nkdoZ2W37LJzjWYeTJio6flIOcW3+9rpr+S0DFneTMsu8oyWwfjbJJQzq5osyI4yG99q oe2jzr9oHKJ88lX25Y8M5tnMMIeN7A29S11K2RDzV1lWFoqXGcJzXMo9Psv6Uv5MWvjI3M4PjSjB eNtr9HS5RFhDkT/y6jj68ntEx0c57hmR/+x9PTHp5DuqZPNmGe+erv6BvsEW6cARaV0NyN5jiZ6G bI3o2k046WewXHxY19XHj/qN9K2JMa3Qn3+4+r67DaNXbV79nYDj4t/bYuEjfUU91lhD+XV20k// blh2sQWf+z6s0U1YoRMNPSFaNMsBw6DPFkCoIJHRW3eDguzD/FmObG2CX1KGLFeJw4D9Ii+zKfKK 1671sWXp+BDZDN93g5DW57p7QCHpj5+N88bC9IRofPcoz0Sde+s2NHqTlOm76ZjYbsx9hw19++rn M7xeUjEt9pL8NodUhl5eZMkFHy1zf1p/WjlLs9Oq/Gd9fxqsN4sNW8Oi1zfLtgWUzMPcmCzbXhZD 265x55bdrbLt+Ujbc33pTTluuT/9aNPNaLl8pDzuZZtYk9O66jWPNqPJG7ti6jHDNgS/TavVQvP0 6W5jV8yk63EL+ggfGszQpzjOUe5NinscGrzUNPnhVV6Zs6wvZeVHLk2le0TZorc/y60TBPqgiuhP o2oLCWcI8KHwK8oCAKrDJWMAAAAQygsXAGRmxMIQAMBkWHYBAACASFh2AQAAgFD+b9nluJFt9ATv 6b5ueZ9tRW3uocbnkU0HAABQsdN2uXpZTnlDd34nfxdk6E8AAABywrILAAAAhGLXdnEUMr7VfRin jb71CdZ/CtC8P7Ldh90pPS/cWXR8oFK9XXgsqzwAAGBnt+yy4+qdtA1WOb9Vf/bSRu/M1+n/jDC+ 9fJp2fge1ewYaU0AAHjQzIfLiLZfrbi0elb+WYEe1XjmPAAAwLnzYXuTRaoVN00AFCKD8dxnBQAA NTofW6xascuAPiF5JL/DygsAAJ6Jw2mXEWrFE6cBVpWe93oyez4AAKAT7cxHpMr5JiqP+2qjd64Z nSYxwvgrMeswbwAAALiBtkuVaQkAAIA14JIxAAAAoPMBAAAAdD5ACZskAAAAZF4BaRjuGo8kuXkA AAB0Pu7f5ZpTIacbM6e8+48qKnJewL3P95DO3204PVw3h+oG8CB8T7ucvlH0f+xJJdJ4GOTtZYwh lqqHBAAMxXPPx5IDl+PVFwAAANCD27KLY89D0HxX6ssff/Xz/4IA/W3/gwnhyBGwcMu75tq6qwAQ ntYUUZrh+1Ww3V5Ad7tGqQxFm6N2fW7NR7eev83yxnYrgKfhsuzSKvi+/e+W7jfHj4QnKOe0P/+y e6ZhVpz5D/cexlUAHMtOU8r6j+TkWr/WGvOtSdjM6HRU0//IPbCrLN/WegBg5mMIwlhnxDCIoVU2 5AB4D5rNBZewxF1Msj1kljeU6bK+CUDnw9K+ZFiY0Dderaay7DLlpXXq9shXVIbXYQnBHfoNADCh 85Gk/zEodXoes95np0EVWRZJyl3YAZOnpOiLAIAez9MuUyZOA/Tr6XlMfJ/1BJXthzHHbuPtCaub SdwOAJlx3vPRNP9xbG4My8OdIvL0POb2ME4DYOf2z6ASSln/0TFK3SPq9IFKb+zOktjMsDlKk8Tp l4/ubbWQPR8Aj+LX19fX9/d32DuG69UBAACeju8NpwAAAAAyqNoCAAAAnQ8AAACg8wEAAABA52MI TVvur24Ht6X7zBum18gyYRPv8KIZbzVbc409QD0W23DaXxtt+h2jL2NYtZX5ydf03BE2tfqXI3xY sU2j8wF1YeYDZraq/TeJAQBAOXwuGTOId28d2uinN3PcSplrjJdviVbevGQQdteY15qvKj2Pd6ZO le4Jm8iweT/89FcGC2UzXG4FPJrRavxnBDY56ioGNCEqixYd78FTxltTeY0rFIB7Riy7GFTO9R/J ouStA2hB1/tWylyZll7YfXvSssuI2CBs+sNm5yuD52890PS1pnz1GC98+TYhZVr6v+xyIaRlM8Pg KICMMx+GYUrTR5098dP6c/oc5fz/1U3YsFLYNJm3UthkjudbH4YZn0Tg0GxGhooDdD78R7GpHmiu P1dmnEqQMFZYLGzczagYNkPfPYYsyz5M8uIs1wIMVcgCGNX5GCGonVPKfJY3HjKfQdg8LWxWfbEZ 8iXsIJleK+l/wAj8T7vIjWb/sbH+heHqY3HuAiFs6oYNfXGh9/lmlj8pHQjDYeZDkMZ2EUDfdcbl IUKrlLnNeJcHXp3vOF3MNki0lx44EjbZwkbv+eNJjVMzImf4NWl5pS6ndVVeZm9cBbZLHG4su8A4 al0yRsccCBt4QogStLA2XDIGAAAAobxwAQDAXFjvgMexmLYLAAAAJIdlFwAAAFi68zFxF9UsAW7E 1vv9Q9gQNk+g1fMI3kJhgpddRleJhFUOsfVb826NIWwIm6FmFH1V0/mAurDsAjObzp9ddUptFAAA WIMh2i4aJejT+6RvFdUFMWileLesZL15qEsvKbY+rufxtuEqAAibumFjlrm/slBZXk0Wuj9QuNFO EzZysB3vcFNGTpPnvbwBcMmIZRdBa7tTG327FoO++q38qdkMZRIria0PChLCZu2w6ZG5b3Jpzz1d jg80y9wbiltOy2aGobwAps18KDleGn011rl9zlAjbU3V6Q8XE1ufwjJhY8vyAmHztHiOzK9yGmyE /TRTML/zMXH/1zjFiu1OG90xXxXF1gmb1rBxz1fFsBn6xlrjbFfO8uIaNEjX+TCrgb9HsccnTBw6 fBrjbgZi67LnCRvCpsqUQ5iFsibi3ApL/wPM+J92yXP6K8MFEoitlzOPsKkVNssfu/15x7+ZlRF2 eIAvv76+vr6/vx3jUj62IJ9WuAr0ps35rfu0Rx9b0BzHkLNmc++t8alOu2zX51YIm9JhI3hef0pO mMjxOo7he9pFE9j9ESWk1XPoxlBeAM2g7QIAkBaOmcCScMkYAAAAhPLCBQAAaeGYCdD5AACACf0P nACLwbILAAAAhDJk5uNUesCl8y6fWZh7fANai1Ie2xUNm+NmQOWxhYcMduXDFNRcgKcwVNtlypPZ Cl6x8zG01CLDxkW/Y3vktbbUXIDnwLILpECpZgIAAAvgr+2iuQvodKCjv9vHcNkw28WLjo8JG/1t UaeXcTXlS07L5iib4LtN2N395jcAGEX/sougBn71na1xnlmjE+2VFgR3L8YV5ZSw+XtAmferX+m1 0ZVRLWvZuyyHCRZqPtpMwu62jwCg8MzHbkhhq9joOMMaYSOLzRosTCLRPrRxGHGbRRKXAkBE58Pc DE0RJYdyXY0qYaNfBFmA0fVLU8pCbHBPFwCdj8v6v5NE8m3aaGtW6n9UCZvR/Y8kYusjPO8yn/Fp GHLwAKnwP+1iXnhWfpM5jFWHzoadkvnDZugpHrPY+uii9P1oaLoAMAWHmY/j8EvYKaaZCJUfqNn5 r08LkrylrobOi4XNVVpePRvNA93zJbja9pHNeJZdACox4pIxAJgyx8AQHwBKwCVjAAAAEAqqtgBV YTUBAOh8AMCE/gdOAIBysOwCAAAA1Tofg/a4XV1NDWswaLMkYTO0yAT39nuegguucQAzcdd2AZjY +aChr5s18yUukNxplBccYdkFAAAAQnHbcKqR/N4O4t3bnWq25trmz2cKaWW4iBpsQ6VCYXNUUj0a f/ynnJbtSIshX+aacuX5TS1z35qQHABzHXUbvY4B4O5eTf1qypetvDjGtT4uyy5Kye/dX65Us+V3 hvA0oZ3ijvaE3YsrHfkFwub0m8LTzJXI0J+T07rNctMt5nqZ+6YtIxr3znJUU5Y7A2CEe6/qly1f tvLi9jxmPrSYu6U9/dkmaSg6zgkxq5EtGTZJ0ppVU4aK4JRw1NCwbHJvwtaSBpzOR5bwQpQSnhM2 nSP4isZjYRLjh9aXK+O5PY/OR976RizCc8LGYHawzH3dMWseRz1wSkA/sUSbvx71TrsQhVArbIZu ULDZkFB93pyur8Eleh4GI/PkS2MJOzyewNiZD/Ps2ZXy+M8/T5/JTN0yLBA2O+340z8e0z09nmCz UBasFw5WaM5c7NwrfKSXuW/dlCC718tRvtF7mtatkfoHernXPV+t5UVj/gj6T7sAQOcQMHKol3Da AwCeBpeMAcx/6wMAPApUbQGC4KY7AID/wrILAAAARMKyCwAAgJHpy6lF13OdtV1Wmkmee6ZXmbqg qVHOvUeFCEO+EsZhtqLksPoyLcDxraOUYhF+RaGUs0d5bCodc5ddMnfZemzrz1fTEyr2fJ8j35Ct KOcGdqEymptZ230YXn+hWa5VIypWTJZdIEWF4SQIAJRrwZLMN+SURpJ5eZXB2wXHsrnSpBZ+a1BU H6FJLYTa7ZRm6yy6cA5ihFB4hvrzni08lp0houRf7apokxr48VcLFKVBDv7KyfIKmqHqyaXs66jb CmtwlJCWso2aeBuv3kLlwlD+Ztn3QjO53bBlec0r1xyXXU5n8+R7nQ03TwuKz4Y7pJWyzq0y7q2d UEH/2mvWVK9/HTntcfxvZ0Qpy1Spcn4bLRWL0qbebquw5o8MWRuh+d4vcy80I/KvlFneoW+WT3/V ZGFnsCVplnsWoeQHahqQzo8ytOSTZz7k0W3YM70uxj6WqMuTT4Pj9MkV59A6Jz/mRtTTpkMH+dBx Fi3PbPaUB+rD5j0T7FWJZmV5VrM8N/Zsaa0x85H0krEmlQffByobU8MDzRFTWlEdahWle1rc5p6z E1+6Ovg2y2GLGnJaT6sOr7R1aeiATD+quOpiJ+8dFxIKf9Sxz/xFGTnw5cRvof6H+/28eZpl+cz/ 0OrwmdbTqkOi0y5hx1Plrx17pj+xHin5HTb6ZOi5zERC/IHe44L6GsuFGQ5h2dId6v+f8n2zTLPc 47FWh3uVzukukHJ9F+fTLq1LcY7S2JtalPxW2fyqu/ou4NtfnearyXKlhUop86sHpn1b2CLq9len f7ndw9+6mp6/KJU1RRnYn07bOTBSNt1d893mKE1ENYVNfLPc6t7SzfK4ZZfb1sYWURunXZYfYjI0 B4oSQBhtE5Mb16tb4ZIxGhGgKAHASIbr1Sv67UXoPLCqIOxOUQL0BBvxBr0ss+wCAAAAJWDZBQAA AOh83NFzwgpSFeLpNc8UbvWa4n6x2ENCYmh5Ua0gF3OXXagPUFfgu/TFo6t2PmhSEnqGQoEjLLsA AABAKA6nXWwKwhqFbln++LjXms3Yqw7U+tWlfZWsb3XYl6wpSkcpJenND7w1z0s2Xele949ub/vW iMibfWjI8s7CU/McfQiL0L/sYlMQvvrC++9NWslb5dl7Ohly6W/t6tL62OhRsm4NsMVqikYOXv/R 1q0vL+TFnOUr947TRm/6ywgf9mfZLAHfWc2hFnmXXfq7unSW6zK67FZSss5WU9yV5Oa6fbp7dxds 2FQ8WiUCntYgQDzDLxlz6bESeRA/Bgq+VSl/TQkTySvRJ05ybGe0D6dEFBea0fmgxwoLDvTNaUVq bSfs89kE0FdtHCJncd7qdJ2qh4V8GFn1YAqJll0YV0GqYJsill2lptgO0wbPFiRpATKYkacxRI4O fvj19fX1/f3tPiTSbMbefeFqv7Qcl2yQXqAf4LW9X9+ceW25bz3tUrqmCErx/R9t4kmNpoGv12mX Ee7tDLamg0s2H/Zn+TQtTrvAHrRdAAAAIBIuGQMAAAA6HwAAAEDnAwAAAIDOBwAAANTjVdHooy4G FC3EN46lWfFKgOPZwibZlxFuXMDhEw2jjapbGSEITrtAhtet48l+QQalUOejkJ5RT6JDDR7tjdLX UcQYz40dcAXLLpCC44XKAACwKg7LLu97fz9fJFc934TC05B/WLYT75a1woWLmGx3ggla9qeRdmth jAOVtbL1Ci9NkfWLrRtiY7sWkbc1DnIACMYLOfK9VsvW9grGuztKqFbwdPqXXQQBdKHhSCI8DUm6 F/rYMK/X2C4R18iL775jsPDvAaXHrn4lmOG+4NWTlkvqV2n1tzZXAaAxPqCN0nteaby7o+SYBGY+ enHpyXYqcR9vbqZ/vSTBxTpavnz3q9a4ddevL1EoSpM+B+LmxmFo1vofPsg8Q/spz3ZszDfDiM6H YbgpiCaP0FOmxw0lXrFeiyALM1FXr7Nc5JZtJWVNpfwQ0PkY2EwIMtzC4qJNT3lV4Wl4WhdnaHud YUvKoCYlf+Ogb/RK9JWb4o1GGD757dUitH7NXXcbqg9nI9um5DE29OzPj6vfXH2nyQAXa22bcpIU cWml+ON2EN8I/Ik09nyA/8zH1Vjq+PfdKuxpP105OXnam74a2XDaJXmT91kig8prF36+AT+08yTH fH/PxmXngb4FuCpr/eympkk5zaZv43Bl/FV5Ra413z7w1PhPF+3c1W+hbVcTLIvLaRfcCFCxzydU Yeo1AIyDS8YAAAAglBcuAHgUmvlz5sYBYCxouwAAAEAkLLsAAACEgrAfyy6qwqs4Be11siOsVhQS kSewlwns0gtMa6+OtYao4I1sjgqzJ/Wlhc9ZdonsA+bpb1a5WmArJSJPYC+T69LxQ/ArvZHNUc+s sztYdgEAAIjrDQRfqpuz//FydKV834780efskCDDvZk0qfvFu08vRb7SEBd+axPvNohcP7ZKO4rI E9jLBLac1nZ9352cr9Zb6vUhas7yLths+TI80D3LQkjLdVlW8LB5o7UFcJmi6GwcCuCy7KJUHt9M +tfypeydEtK2aatb2fRWuWqbD1uTyNZXyC8iT2CvEdiyew2q9LeO0oST2RtKP9vylSrLTcEvp2Uz wyV6Nd80F4rt4YvMfLh0uEZMDSk75rYfjuhgnj6zRw08OSVE5IsGdqqH5wns01Rs6Ub+StOIeeUr iaPco9dshvKHSXQBC70dXqMjIEwn2iY9EFxU7uLdC+w4KyQiXyiw4+exlgzs/PWr+mmdiuOlLVyL Z8mdxa+w0orv2yaslubO7KkauFle/Gn9jxEi8gT2EwI7/3u9tGC9weYRddnF+P5aKTxwyc18WU67 9Dcu8Qrg2dIq3TueLiJPYC8f2O5K8Xnqjq9gfWZHmeuyb3Z6nnbq23FHx9POjb1G1wqlhPStNPan yrPmgZtOQlpZkK1jC0Gu2tbx16iB7/7pq8M+qzOaU0SewK4V2IJSfGTYDE1Lv4PqNthaHTUiy1el bHbU1ZSJeb1+VpOyjVz9CSXPJWNcmANhocUlPwDU5eXfd5mdwyVjAAAAoYRdr57WA2i7wCPqObex AVCXIRHP0XYBAACADLDsAgDwUNh5ALN4PbbKNd1/6jizl+TsyXQzju1R/ulTwibPyakRTk6SqbAc IewOM0m77DK0szz67gTuZzTY5mItYfOEcaogi8MgO2dBUy6wg2UXAIAn9jwQdoeJvByD2Ka1ffyn Tbxb3++Wb262aU+0Gi/rRG8e4t0GM47XYc3SbiZsHh42+l91BoDcfPWH6NYucy/83CuwbZ5fU9gd ZuGy7OKiPC7Xgaavyd8RVM63AULPtlx0Kll3miH8j8EMIWY+aTKMsHlU2OjzYgiA2/AzPFCTUFMA I+wOzHzcjD9mcRrZgpZ3oUK68q0+y5nzVUjSdo2wKc0g0QBfX10J5m3jhd2TRBEzHxDX+QiLPEF5 3PeBI35V+u0yKMsxO+Hdja8bNhlGBZ3V3BAwejNsyy6RUT1ObP2Bwu6wVOej1huXrv30LAf0Pwib QmFzum2iVgBczXyUC+zlhd1hFjVOu+RRQ6472E0+ahmxqEHYrGGG2YZZxgtixXmqIcLuMJdfX19f 39/fXpXtNgqvJvFORwnjji2cnpJoSuvWjFbjDZvnmzLen5bvhnZzWoTNE8JGLmU5LwYf2qZnWr2h PO3SZGFPrTx97LjApvMB/wfaLgAAD5lGmmISm0XgCJeMAQA8FITdgc4HAAAA0PkAAAAmAADofAAA yLCVASA5L1zQ2fSgcu7VcD9kXBhZXs8MUZTiAQqQ9rQLo4q1vTHojgGuECVEUYoHyA/LLgCwVFcM pXiA/Lwca3vPxUSR2ujbJP3rpouSjglNVzmfOHh9ctjIZhhi4zZfV8aXDlGU4gFy4bLsYlB8nqiN vuXQv24aMCVUOXeJmU+asvOcsLk1zBwbp+41R2mSEEUpHuApMx9JxgRmffkM+tdm40tjVihNYvwy sukPHNyjCwiwSOcjrIrKWtu2YVmY/nWSRi3VWC3myICvsHtw2LCL1iXGcC/A4p2PckOWMP3r0j4s 3f+oGzYj9OUfGKIoxQOkosZpl6Gt7RT9654nL/nuGXFqYL2w2dq3VqxXYQ2BhFI8QDZewQ3B52hD Vs3+/MLVr7aWXR2nvzpNVDDy2AzpL1Da5aipQTz1hsaM078k38NP2AhmnFrVFBuDAiBziOojKsBR APAf0l4ytvzojZVmwgZKlwJlDWCGS8Z4LQGsBkrxAMlB2yW0QWy9vgkAAGBBWHYBAACASFh2AQAA gFBYdsmO+1m+bIcDKx5WPG7faZJiOf0VPDwgBS2ehI+lpkAvLLvEVLkMjxr0wH5jym3FbRJMafoL NeXhJvmmrlQLoqY8IbCzwbILzB9ioksOAPAofJZdDJrUsja6QV58M+lfKwXQr4w/WijLi9t8uPvU 3RtT5pmFe7o6C+UqqFqLMt4bmiwrL3R3qUTHQrkqPlsLINQUW13+NNucZX2tbK3Lcikra4q5tnY2 sLJ7q9eUDK+Ax9G/7OIiV338p0aVfuuW4RY0xG8V1YUpzdZxvE3lvN/zx4dHNiJTstxalELYfKLM 4NWv9FluEpfvrESfTxDM6KmVetfpI0pIvSfLrWY0Bbb+L00V9urLPbGhcW+hmpLkFcDMhw9etzV7 fU0WrA8TQJfNEP4+wp8Txy6+vj1+0zA0NPjhdD6gJ6ERZeF+K/ksk8ICdfQKYFhGDLfaD81y5poS 9goA585HgAKCbbYzMkSUIh0B8wfKX2WoNgbjzcGmT6u1iaxyWmeoiLxQ9XxVdeJrStGWvemVH9NC ri3CR0dkzsyHsNZO8SfM8txVWyFsxgXbuJyOblVHXIwbOTxwKa9OD5/uB6JJia/v5WoKjMPhtEv1 k2k5BeRGj03//MPEPR+DnHncPhbWqo7L8p8PFq5cTZsJBlmVvDpU30mQs6agIVp15sNFrlrZKR6h f33VX+6Z+72SFzfka6g3bMuxqRqvXZY/z+7O0ka/XW73yvLoCrsL46sK2xOHpzWlM8un+xua8jWo VtrCRjYprH6NqDtJakqGV8ATefglY/RJoVyIRgYtFYQma+2agj9nwSVjAAD0NgBCQdsFIDXBa0aQ PAAofWrKIqDtAgAAAJGw7AIAAGAkZl1swdW3uTMftY56upha7nRrmDNzuuWBIQqQvDrkqZXs/p7f +XhCq9ckq0E7la3zQYgCLi2U5RKep/NhhmUXSFFveWsCQLkWLHJPa/z1iUN5uRTA7n9atZtPtcF2 Hj/VRhc+2rolpDdRa9vgDSHLNjVwmxx8Z1qOFe9dfMdrSX3NIETlIZRG871Tefz4T9sDN6vmuy3L t2HQ5F5b2HjFhjIODc2Xzb2lW1GXANB/tCajl11u9cqbJKRtut6bt7x45/xYp251vxz8bRK3Hva6 ePv433FmEKKakBDkxQ3K47I3+h+orDs9MveOd8zbwsYrNvRVw9x8GdxbtBUVvtkZva0Pf/TMh2aA myGrjnf3nkbArGyepjvCwt1EheNEok1I1teMxUJ0hA0TpcyHFlA5UeJa4F6z/OfaEx+vlcrYJptu E3aPdJohX2YL5bTCdLEnmrFGiHqZkZAkSo0T0+qPDXbRRo4BhtZlOh/OVetqjVBePly1gxlm4a3y uPuUw3axfhxvxnNC1KwvX7o6ZKhE5rAx5EveT1M6APJPwAj70rh0dWzno/OtIPx84vvGXD8LacbK Wb7SjK1oBiFa68WTpBIZzNhtJggLG/0Db7dWFPV82CDEfSe+0Edcqe/y8i2Gps6dRkJ698B+EXl5 fLDp5MXN3riVkL5VA3fsOzcpj+/ifvTCxwgzCNH+wHax8DbXnT70rUStYSO4d2JsNIVNa/M1qI0q 0YoOKpSN0y5JBnCtW4IBCFF4ctgQhxOLtW4qkXDJGAAAgJGYKYr1JkJ+fX19fX9/J+9LPvomFqgw 3CFEIVvYEIeQmoTLLgAAALAwLLsAAAAYYc+HkbkzHw/UK8+f5RgLNXeWI95NCwUPbBwK1UpUbed3 PtAr5x3g2/mg6pJHXPrkLFe5gQaH2GDZBVLUW96aAFCuBQu+OBVhufNXCHrlWwUxaGVap5fr2W6A luvS538HmUGIykMopb68fGO3nK/jP20P3BRy8IZKdJXl2zBocq8tbLxiQxmHhubL5t7SrahLAGwP PyU3etnlmXrlmcWgW5O4yr7LJUjH/44zgxDVhIQgcy98pLdQU5SdouRNEX4bUf1jTaU3ZBv6Y0Nf Ncx0L13MAAAKWUlEQVTNl8G9RVtR4Zud0dv68EfPfGgGuBmy6qhVOEKw3jdfIywckUHDNe2DzFgs REfY4O6lfvm0lUp/ASNxr+PDl5/5eK1UxmF65cFhYcgXFwo9PES9zEhIfv280Wn1xwa7aCPHAEPr Mp0P/9Hwacnl1ytn0POE3JUO0eqK6smrueBec9gY8iXvpykdAPnbGUGNlmHh2M4HeuVJbAZCdI1B cF1h991mgrCw0T/wdmtFUc+HDUIGCd+Pe/JqnQ/0yjXeSCUGLW8WubIw+D3qaAYh2h/YLhbe5rrT h76VqDVsBPdOjI2msGltvga1USVa0UGFsnHaJckADr1yIESBsHFJC0YXa91UIuGSMQAAACMxUxTr TYT8+vr6+v7+Tt6XRK8cCFEgbLzSAphPwmUXAAAAWBiWXQAAAEJhp0iimY+Jbqolm360vKLxC2yI 6/e81/3oNNnVq8OTC/SBbS9auFU7Hyg+V39tb+zGL9vfmvvAJvUiWDWYq7e9dD42ll0gSb3lhQEA D2n3gq9bzdm6vtxdaVPNlq/7bVV8Pn3m7StQr95uM0PQbpYvs/Pdtd4pPO1Yhd5XTh1d7WtGpxy8 l7y4MuabHnhbK20hKgShV9XreaDhJvLOxuHUUVeNQ0+w9bSi+rTMLYChPaTttU1RdJZyAfqXXVxU s+XFM40oc+c0vkG93WCGQRp7XE5lkV55csJLZ/z43xFm2NTbN4XWdqu8+G3M2/6iybWLDrt71dPn RVkrfX1oMMMWbC6taOtHTdLztvaQtlcZ851F2frwRWY+bke306eGzPryYertu2un+ycVzFnWT1Q4 Tgk2Pc1mhtngyGuY3U1a8mqHJJkSzHC3MEmJT9RmK9T2zvVAoSr/ymmW7y6e4PJw1242eMOcZTkt 355HEjPCtLYXfmdP34ga3KSUgCxPaXu9hiLC2soavHIGkE3xuXqP9XRAH6l/fZuW+8zHdrHFIdIM bn7M5sMRMW+wsLr0/PJD55Xa3u1i48vCbdTw0y6ta7qtT3jasduJZ7TelSF4+7SLGQlfG45r5GvE /NUDvfYWFKp61Y1c8iipV0KnDZfXw0+fnLPv8nJ35a7/eLVpWS88rVR8NksSm9Xbfc3YLlYTZG/0 SM/fCk9//nNn2ND1lxFmKOOwP2zMUuZheuWtFh4d7h7zTY7SHP1w8eFtQxTp+c4HbuOl50+LkrbX PTaGNg6hDL1kjMsbgOEgAMCURilz08clYwAAAKHETFFkngih8wEAAACx5NF2AQAAgCfAzAcAAEAo 7PkoqWo7IukHyjrP9cbtYbP8hdJvYbksJ28lRlQHoO11DzZUbat2Ph54lr1w99ba+eBV+gSDWx+o +T6dj+WDuXrbS+djY9kFktRbXhgA8JB2L1glZ1lhORcxaPkW23G63tvzZJ2Vgtp6b3TWis//DjKj U+VcLuXT6+GvyksT800PvK2VthAVgtCr6vU80BCHnY3DqaOuGoeeYOtpRfVpaVqApizfxjBtb0+I 2j7KTv+yi4sYtLx41q+nbJibWlXWuUlHW+8NW9gc/zvCDJsouVBetr9oYt5RDt4QbAa1+s6AbJVf 0ASAow8NZtiCzaUVbf2oqSmwtYe0vcqY7yzK1ocvMvNxO7qdPjVk1pevK+tsznK8N1ozGyyXNW4k YY75JALrs8ivH+luYZISD14sKNr2zvVAoSr/ymmW7y6e4PLIIOuMUuvE8nrgO3v6RtTgJmWxwH5g lse1vV5DEWFtZQ1eOQPIJmRcvceaQdb5gQNZOmrZfDgi5g0WVq96yw+dF2t7ha0nS7ZRw0+7tK7p tj7hacduORWyjN8c18jXcOnVA303G61d9R54DUG5tvd0vdXr4adPztl3ebm7ctd/VEqZ7ySSZSVr Xz3lx8o6n37ZVye6vwp5maGMw/6waZVN73mgV9unF3YfFPNNjtIc/XDx4W1DFOn5zgeeZvn0L75F SdvrHhtDG4dQhl4yxjAdGA4CAExplDI3fVwyBgAAEErMFEXmiRA6HwAAABBLHm0XAAAAeALOR21b NxwBAAAAnY+ungd9Dmjtp35C/JQostZiMhwHcB/GyA+ce7YL4Ik4LrtwpgBioqX0LQLVq4nyNg6c DwACbDgFAACAUDyXXQwiYQCnw9MwQW3NKLlHlf40dfNdTKdpterLC4rqt9dL9zhKL5tu80ZPvBks XFPlHCAMr2WXU31wADlg3sixNE5Qu/VVp0xL+U2bAU368pq+gkbY/TaJVhkEjfG2v7SWpsHCfpVz AGY+AOYQKUoeOQC90qkK9mHpAFjJQmY+AAZ2Pt4Ty9Q0mIW7oLY5LZYgM5TyFDNqy20AlOt80POA R42k5bTCZj4o5YRmCNroAPADp12AcbBzWu+Xza0O6qq7AfSOIiABngl7PiBRM60cILoLajumdapB f6tKrzTAd+h/q6i+M17WEL/Kl/ArzVmS3a/M3hDMMGijL6tyDhCGr7bL6eEFAABmCABg1MwHfXwA AACQYc8HAAAAhMKeDwCYALOkAKkQVkJH1FY6HwAAACBpPrvzOyANWxfs6u5tgJ6IikwuSa4f6P/R A8FBmZKfFuDD+CwrU88fOWkVmPO67vO0S9qrAxO6T5ByWLg+VLeQjuz0ZjRnETSp2EzJlHtyCbNM 58P9gU09RZtsk8/MBwAAaJpp4cISsgwJiywbL7mb0y8h3SM8rembK2XTbaLkwq92kx8u2uitxt9a aHigHMdXMvc2z9ssdJcyN3tj8xOR18eh/tZ2mxmGQpG9sSNbKctZFtpDl5fB6R1ut6kUyrK+KJU2 uDeVLhElGG8zQ9h7ofyowKX+u2UXvUJ3p7r07UfKKT6NbLqXKLny4fpJrU7jb5MwyMHrp+9cjG+1 sFPK3FGi/SrL8l8EiXalenvrcNOgZW8IG9kbrbetuwvWm+NQWSheZmx+U99Jsqwv5c+khY/M7fzQ iBKMt71GT5dLhDUU+SNzzPQU9C2/bX1qc8fc8PymnBueP7F7eLygOnM/VTZvlvHu6eof6BtseVTx HJ/5bhM7dymuEV27CSf9DJaLD+u6+lQHINVLKqYV+vMPV98vd3a94aitQUK6R+bg/dtjjTWUX2cn /fTvhmUXW/C578Ma3YQVqgZeShxPuLXCUPXeM+SOR/hyxvzo2mRoZNIeIIhvKoO1eErvnE3X+Thd rbwqrc8v96hLHx8im+H7bhDS+lx3D1hau3p+pDcWJrkAurAXpPQ0QHD0JinTd9Mxsd0I7nnYSnn0 fIbXSyqmxV6S3+aQytDLSyinPvGZo9Xbc5Zmp1X5z/r+NFhvFhu2hkWvb5ZtCyhpCcuy7WUxtO0a d27Z3Srbno/yMx+nWtunH226GS2Xj5THvWwTa3JaV73m0WY0ecNXet4wBL9Nq9VC8/Spu0S7pk1p EpH3DZvNpBQ/ImzCmhT3ODR4qWnyw6u8MmdZX8rKj1yaSveIskVvf5ZbJwhydZE/T7sAJJkhwIfC rygLAAhroLhkDAAAAFYAYTmA1IxYGAIAOBI6q8qyCwAAAETyLyE7x2hhkvDbAAAAAElFTkSuQmCC --Boundary-00=_IgMQEQvQ0zFQ0Fy-- From kohler@cs.ucla.edu Sat Apr 15 15:03:49 2006 From: kohler@cs.ucla.edu (Eddie Kohler) Date: Sat, 15 Apr 2006 07:03:49 -0700 Subject: [Xorp-hackers] Cli style guide draft In-Reply-To: <200604151316.40126.hasso@linux.ee> References: <200604151316.40126.hasso@linux.ee> Message-ID: <4440FD45.4030201@cs.ucla.edu> Hasso, I think this is a very strong proposal! One comment in terms of usability. While I agree that getting rid of units from node names, it becomes problematic when different nodes with the same nominal unit (like time) have different scales (msec vs. sec). That kind of thing is extremely easy to forget, and will really bite people. I'm thinking of interpacket-delay ... (msec) request-interval ... (sec) triggered-timer-max ... (sec) triggered-timer-min ... (sec) .... If interpacket-delay is the only one in msec, maybe it SHOULD take -msec in the node name to make that explicit. But there is a better answer, which is to introduce types for time in seconds and time in milliseconds and allow people to actually enter unit suffixes, as in "set ... interpacket-delay 100msec". FWIW, Click time units are now entered this way; it was a really good change. Eddie Hasso Tepper wrote: > As I promised, here are my ideas about cli style guide. Feel free to > comment, make additions etc. > > ************** > > * Configuration commands (node names) SHOULD be less than 20 symbols > long. The length of configuration command + short help MUST NOT exceed > 76 symbols. > > This is to ensure that the output of possible completions would fit into > 80 symbols wide terminal. In most of cases it's wrapping that makes the > output look really bad. > > So, keep the length of node names and short help minimum. Node names are > especially important. If it can be shortened below 20 symbols without > loosing the point, it should be done. If it can't be done, OK, but these > cases should be kept minimum. For example: > > restore-original-config-on-shutdown -> restore-system-conf > enable-ip-router-alert-option-check -> router-alert-check > > * No units in node names (sec, msec), this info should be in short help. > For example: > > interpacket-delay-msecs Minimum delay between outbound RIPng packets. > vs. > interpacket-delay Minimum delay between outbound RIPng packets (msec) > > * Avoid "Set ...", "Edit ..." etc in short help strings. > > Short help string should just describe shortly variables/commands. And > note that it can be logically wrong as well - variables and commands > aren't always set, but sometimes deleted as well. For example: > > horizon Set the horizon type applied to routes announced on address. > vs. > horizon Horizon type applied to announced routes > > * Short help strings begin with capital letter and don't have dot in the > end. > > Just to make the look consistent. > > * Keep parameters user have to configure minimum. > > For example timers with jitter can be described as "some-timer-min" > and "some-timer-max" (as it is in rip(ng)). If user wants to change > timer, he/she has to configure two parameters. But mostly it's just > average value which user wants to change. So, prefer "some-timer" > and "some-jitter" with good default to jitter, better in percents than > in absolute value. > > * Commands should describe what they do, not for what they can be used. > > For example there is command in rip(ng): > > accept-non-rip-requests Answer RIP requests made from non-RIP processes > > It's not clear at all what it does. Better use following command and > help and describe for what it can be used in documentation: > > source-port-check Answer RIPng requests made only from RIPng port > > > ************** > > I played with these ideas in RIPng configuration and picture (to make sure > that mail clients don't mess result with wrapping) with result is > attached. > > > regards, > > > > ------------------------------------------------------------------------ > From hasso@linux.ee Sat Apr 15 18:53:40 2006 From: hasso@linux.ee (Hasso Tepper) Date: Sat, 15 Apr 2006 20:53:40 +0300 Subject: [Xorp-hackers] LXR? Message-ID: <200604152053.40424.hasso@linux.ee> While hunting through code today with questions "where it's declared?", "where is implementation?" and "where is it used?" I realised that something like lxr (http://lxr.sf.net - old page has more general info) would be really nice to have. -- Hasso Tepper From hasso@linux.ee Sat Apr 15 19:26:13 2006 From: hasso@linux.ee (Hasso Tepper) Date: Sat, 15 Apr 2006 21:26:13 +0300 Subject: [Xorp-hackers] Cli style guide draft In-Reply-To: <4440FD45.4030201@cs.ucla.edu> References: <200604151316.40126.hasso@linux.ee> <4440FD45.4030201@cs.ucla.edu> Message-ID: <200604152126.13805.hasso@linux.ee> Eddie Kohler wrote: > Hasso, > > I think this is a very strong proposal! > > One comment in terms of usability. While I agree that getting rid of > units from node names, it becomes problematic when different nodes with > the same nominal unit (like time) have different scales (msec vs. sec). > That kind of thing is extremely easy to forget, and will really bite > people. I'm thinking of > > interpacket-delay ... (msec) > request-interval ... (sec) > triggered-timer-max ... (sec) > triggered-timer-min ... (sec) > .... > > If interpacket-delay is the only one in msec, maybe it SHOULD take > -msec in the node name to make that explicit. I thought about that. At first I think that making exceptions is bad style - if to use it in command strings, then everywhere. But I don't see need for that. As general rule if user is going to change timers, he/she has to have exact knowledge what's he/she is doing and therefore has to know units as well. Mostly commands speak for theirselves - you wouldn't expect interpacket-delay specified in seconds? ;) We also discussed with coworkers it and agreed that it's unnecessary - info in help is enough. There are some cli's which are using msec rarely if they are moving timers from seconds to milliseconds - ie. there is old command "some-timer" and the new one "some-timer-msec". But most implementations just adjust value in such cases during upgrade (that's why it's good idea to have version info in the configuration file ;). > But there is a better answer, which is to introduce types for time in > seconds and time in milliseconds and allow people to actually enter > unit suffixes, as in "set ... interpacket-delay 100msec". FWIW, Click > time units are now entered this way; it was a really good change. I don't think that it's good idea either. If, then only representation should have it - it would be really annoying to type sec/msec. And it introduces complexity in cli. And it would make value string in cli (at least for now) and it would make sanity checking much harder etc. -- Hasso Tepper From kohler@cs.ucla.edu Sat Apr 15 19:32:50 2006 From: kohler@cs.ucla.edu (Eddie Kohler) Date: Sat, 15 Apr 2006 11:32:50 -0700 Subject: [Xorp-hackers] Cli style guide draft In-Reply-To: <200604152126.13805.hasso@linux.ee> References: <200604151316.40126.hasso@linux.ee> <4440FD45.4030201@cs.ucla.edu> <200604152126.13805.hasso@linux.ee> Message-ID: <44413C52.1030602@cs.ucla.edu> > I thought about that. At first I think that making exceptions is bad > style - if to use it in command strings, then everywhere. But I don't see > need for that. As general rule if user is going to change timers, he/she > has to have exact knowledge what's he/she is doing and therefore has to > know units as well. Mostly commands speak for theirselves - you wouldn't > expect interpacket-delay specified in seconds? ;) Not a great argument; I might expect it to be specified in MICROseconds. > There are some cli's which are using msec rarely if they are moving timers > from seconds to milliseconds - ie. there is old command "some-timer" and > the new one "some-timer-msec". This is a really strong argument for explicit units. > But most implementations just adjust value > in such cases during upgrade (that's why it's good idea to have version > info in the configuration file ;). There is no way to version peoples' brains. >> But there is a better answer, which is to introduce types for time in >> seconds and time in milliseconds and allow people to actually enter >> unit suffixes, as in "set ... interpacket-delay 100msec". FWIW, Click >> time units are now entered this way; it was a really good change. > > I don't think that it's good idea either. If, then only representation > should have it - it would be really annoying to type sec/msec. And it > introduces complexity in cli. And it would make value string in cli (at > least for now) and it would make sanity checking much harder etc. It is not really annoying to type "s" or "ms" (which are also reasonable abbreviations); and as in Click a straight integer could default to "s", leaving "ms" for the uncommon case. Also "much harder" is an exaggeration. But I'm done here. If the values are left as straight integers, without even the possibility of units, then I advocate leaving non-seconds time units as "-msec". Eddie From hasso@linux.ee Sat Apr 15 19:55:06 2006 From: hasso@linux.ee (Hasso Tepper) Date: Sat, 15 Apr 2006 21:55:06 +0300 Subject: [Xorp-hackers] Cli style guide draft In-Reply-To: <44413C52.1030602@cs.ucla.edu> References: <200604151316.40126.hasso@linux.ee> <200604152126.13805.hasso@linux.ee> <44413C52.1030602@cs.ucla.edu> Message-ID: <200604152155.06490.hasso@linux.ee> Eddie Kohler wrote: > > There are some cli's which are using msec rarely if they are moving > > timers from seconds to milliseconds - ie. there is old command > > "some-timer" and the new one "some-timer-msec". > > This is a really strong argument for explicit units. Nope. I said in _rare_ cases. It's only in case if older software version had command with arguments in seconds and the new one introduces the new command with arguments in milliseconds. And I have seen it done only in case there is overlap in ranges of old and new command. So, it's not done to gave to you info about units, it's done because software can say to you "You are dooooomed!" during upgrade ;). > It is not really annoying to type "s" or "ms" (which are also > reasonable abbreviations); and as in Click a straight integer could > default to "s", leaving "ms" for the uncommon case. It depends on context. In RIP seconds are common case, in link state protocol milliseconds are common. And I don't think that comparing click and xorp is fair here. Xorp is meant to be configured through cli and for cli users info about units is all there. It's quite hard to avoid short help in cli ;). -- Hasso Tepper From bms@spc.org Sat Apr 15 22:32:23 2006 From: bms@spc.org (Bruce M Simpson) Date: Sat, 15 Apr 2006 22:32:23 +0100 Subject: [Xorp-hackers] LXR? In-Reply-To: <200604152053.40424.hasso@linux.ee> References: <200604152053.40424.hasso@linux.ee> Message-ID: <20060415213223.GB28496@spc.org> On Sat, Apr 15, 2006 at 08:53:40PM +0300, Hasso Tepper wrote: > While hunting through code today with questions "where it's > declared?", "where is implementation?" and "where is it used?" I realised > that something like lxr (http://lxr.sf.net - old page has more general > info) would be really nice to have. I use cscope, in the vim-integrated form. But I agree that a cross reference on the web is a nice tool to have. Regards, BMS From mike@vyatta.com Mon Apr 17 19:42:44 2006 From: mike@vyatta.com (Michael Larson) Date: Mon, 17 Apr 2006 11:42:44 -0700 Subject: [Xorp-hackers] patch for bug 596: Single node operational commands do not recognize optiona... Message-ID: <4443E1A4.6080601@vyatta.com> Hey all, I've attached a patch for this bug. It's small enough that I'll just include it in the body of the email: [mike@zeus rtrmgr]$ diff cli.cc cli.cc_new -Naur --- cli.cc 2006-04-16 19:32:57.000000000 +0000 +++ cli.cc_new 2006-04-16 19:32:40.000000000 +0000 @@ -658,6 +658,9 @@ command_vector_name.push_back(ccm.command_name()); com1->set_global_name(command_vector_name); com1->set_can_pipe(ccm.can_pipe()); + + com1->set_default_nomore_mode(ccm.default_nomore_mode()); + com1->set_type_match_cb(ccm.type_match_cb()); // Set the callback to generate the node's children com1->set_dynamic_children_callback( Thanks! Mike Larson Vyatta From pavlin@icir.org Mon Apr 17 22:21:07 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 17 Apr 2006 14:21:07 -0700 Subject: [Xorp-hackers] Cli style guide draft In-Reply-To: Message from Eddie Kohler of "Sat, 15 Apr 2006 07:03:49 PDT." <4440FD45.4030201@cs.ucla.edu> Message-ID: <200604172121.k3HLL7Hw026042@possum.icir.org> > Hasso, > > I think this is a very strong proposal! Ditto. > One comment in terms of usability. While I agree that getting rid of units > from node names, it becomes problematic when different nodes with the same > nominal unit (like time) have different scales (msec vs. sec). That kind of > thing is extremely easy to forget, and will really bite people. I'm thinking of > > interpacket-delay ... (msec) > request-interval ... (sec) > triggered-timer-max ... (sec) > triggered-timer-min ... (sec) > .... > > If interpacket-delay is the only one in msec, maybe it SHOULD take -msec in > the node name to make that explicit. > > But there is a better answer, which is to introduce types for time in seconds > and time in milliseconds and allow people to actually enter unit suffixes, as > in "set ... interpacket-delay 100msec". FWIW, Click time units are now > entered this way; it was a really good change. On one hand I think this is a very good idea, given that we use time values in many places. Implementation-wise, for example we already support mac/macaddr type in the rtrmgr templates and the XRLs, so it won't be terrible difficult to add support for timeval type (or whatever name we choose). We could easily support more than one ways of representing the time. E.g.: * 1 (= 1 second) * 1.234567 (= 1s 234ms 567us) * 1s, 1sec ( = 1 second) * 1ms, 1msec ( = 1 millisecond) * 1us (= 1 microsecond) On the other hand, majority of the time values we use for protocol configuration purpose are in seconds, and (off the top of my head) I cannot think of an example (within the set of protocols we support so far) where we want to represent time value that has seconds and ms/us component, so the above flexible format might be an overkill. Stylistically-wise, I'd prefer that we introduce the new timeval type, because it is cleaner and self-explanatory (e.g., I don't need xorpsh access with the help strings to figure-out the time units). Pragmatically-wise, we might be the only routing "vendor" that support/use such time format so I won't be surprised if this creates some confusion to the users. Any other opinions/preferences on the subject? Pavlin From pavlin@icir.org Mon Apr 17 22:25:22 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 17 Apr 2006 14:25:22 -0700 Subject: [Xorp-hackers] Cli style guide draft In-Reply-To: Message from Hasso Tepper of "Sat, 15 Apr 2006 13:16:39 +0300." <200604151316.40126.hasso@linux.ee> Message-ID: <200604172125.k3HLPMK0026087@possum.icir.org> > As I promised, here are my ideas about cli style guide. Feel free to > comment, make additions etc. Hasso, If you don't mind, I'd like to add the text to CVS as a new file: xorp/devnotes/cli-style.txt Any adjustments to the text (e.g., the sec/msec discussion, etc) will be reflected in the CVS version. Thanks, Pavlin > > ************** > > * Configuration commands (node names) SHOULD be less than 20 symbols > long. The length of configuration command + short help MUST NOT exceed > 76 symbols. > > This is to ensure that the output of possible completions would fit into > 80 symbols wide terminal. In most of cases it's wrapping that makes the > output look really bad. > > So, keep the length of node names and short help minimum. Node names are > especially important. If it can be shortened below 20 symbols without > loosing the point, it should be done. If it can't be done, OK, but these > cases should be kept minimum. For example: > > restore-original-config-on-shutdown -> restore-system-conf > enable-ip-router-alert-option-check -> router-alert-check > > * No units in node names (sec, msec), this info should be in short help. > For example: > > interpacket-delay-msecs Minimum delay between outbound RIPng packets. > vs. > interpacket-delay Minimum delay between outbound RIPng packets (msec) > > * Avoid "Set ...", "Edit ..." etc in short help strings. > > Short help string should just describe shortly variables/commands. And > note that it can be logically wrong as well - variables and commands > aren't always set, but sometimes deleted as well. For example: > > horizon Set the horizon type applied to routes announced on address. > vs. > horizon Horizon type applied to announced routes > > * Short help strings begin with capital letter and don't have dot in the > end. > > Just to make the look consistent. > > * Keep parameters user have to configure minimum. > > For example timers with jitter can be described as "some-timer-min" > and "some-timer-max" (as it is in rip(ng)). If user wants to change > timer, he/she has to configure two parameters. But mostly it's just > average value which user wants to change. So, prefer "some-timer" > and "some-jitter" with good default to jitter, better in percents than > in absolute value. > > * Commands should describe what they do, not for what they can be used. > > For example there is command in rip(ng): > > accept-non-rip-requests Answer RIP requests made from non-RIP processes > > It's not clear at all what it does. Better use following command and > help and describe for what it can be used in documentation: > > source-port-check Answer RIPng requests made only from RIPng port > > > ************** > > I played with these ideas in RIPng configuration and picture (to make sure > that mail clients don't mess result with wrapping) with result is > attached. > > > regards, > > -- > Hasso Tepper > > --Boundary-00=_IgMQEQvQ0zFQ0Fy > Content-Type: image/png; > name="xorp-ripng.png" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; > filename="xorp-ripng.png" > > iVBORw0KGgoAAAANSUhEUgAAAtQAAAEvCAIAAADq8sHgAAAAAXNSR0IDN8dNUwAACXRpQ0NQaWNj > AAB42u2ZZ1AUaRrH3+6eHBiYGYYMQxyCRAkDSM5JJAdRgRkyjDAkBUzI4gqsICKSFEFEARdcXYKs > oiKKAVFQwIDuIIuAsi6uIioqN+gHr+qu7tN9ubp5Prz9q38/VW+Hp6p/VQ2A7HgiJykVNgAgiZfG > 93WxZwaHhDKxowAFKIAMYAAiOKnJXn7O/kBYK73gX+rdKIBWjvd0//35/1hEbhKPCwCEE3I8NyqV > I+Q0Icdyk7gr+fgKZ6YlCzPYUch0vvAChRy8wpHfOHGFY77xzq89/r4OQi4DAEeK+cqEoysc+ZWp > p1aYE8tPAkC2S9iv9m3fryWuuXITzDheWhSfF5GoBf7b9U97iaWuPPDI9LjENN043v/oPivz8o3e > WH2dA4hR8T3bLHwH7FcAICXfM7XDAFB2A9DR8z2LPA5AZwkA0k856fyMbxlqZUEDgnAS6UAGKAJV > oAl0gREwA5bAFjgBd+AN/EEI2Ag4IBYkAT7IBDlgF8gHhaAEHARVoBY0gCbQCs6ATnAeXAbXwC1w > F4yAx0AApsBLMA/egSUIgrAQGaJBMpASpA7pQEYQG7KGnCBPyBcKgcKhGIgHpUM50G6oECqFqqA6 > qAn6BToHXYZuQEPQQ2gCmoX+hj7CCEyC6bACrAHrw2zYDvaA/eENcAycAmfBefA+uAKuh0/BHfBl > +BY8Agvgl/ACAhAiwkCUEV2EjTgg3kgoEo3wke1IAVKO1COtSDfSj9xDBMgc8gGFQdFQTJQuyhLl > igpAcVApqO2oIlQV6iSqA9WHuoeaQM2jvqDJaHm0DtoC7YYORsegM9H56HJ0I7odfRU9gp5Cv8Ng > MAwMC2OGccWEYOIx2ZgizGFMG+YSZggziVnAYrEyWB2sFdYbG4FNw+ZjK7GnsBexw9gp7HscEaeE > M8I540JxPFwurhzXjOvBDeOmcUt4cbw63gLvjefit+KL8Q34bvwd/BR+iSBBYBGsCP6EeMIuQgWh > lXCVME54QyQSVYjmRB9iHHEnsYJ4mnidOEH8QKKStEkOpDBSOmkf6QTpEukh6Q2ZTNYg25JDyWnk > feQm8hXyU/J7MZqYnpibGFdsh1i1WIfYsNgrCp6iTrGjbKRkUcopZyl3KHPieHENcQfxCPHt4tXi > 58THxBckaBKGEt4SSRJFEs0SNyRmqFiqBtWJyqXmUY9Rr1AnaQhNleZA49B20xpoV2lTdAydRXej > x9ML6T/TB+nzklRJY8lAyS2S1ZIXJAUMhKHBcGMkMooZZxijjI9SClJ2UlFSe6VapYalFqXlpG2l > o6QLpNukR6Q/yjBlnGQSZPbLdMo8kUXJasv6yGbKHpG9KjsnR5ezlOPIFcidkXskD8try/vKZ8sf > kx+QX1BQVHBRSFaoVLiiMKfIULRVjFcsU+xRnFWiKVkrxSmVKV1UesGUZNoxE5kVzD7mvLK8sqty > unKd8qDykgpLJUAlV6VN5YkqQZWtGq1aptqrOq+mpOallqPWovZIHa/OVo9VP6Ter76owdII0tij > 0akxw5JmubGyWC2scU2ypo1mima95n0tjBZbK0HrsNZdbVjbRDtWu1r7jg6sY6oTp3NYZ2gVepX5 > Kt6q+lVjuiRdO90M3RbdCT2Gnqderl6n3it9Nf1Q/f36/fpfDEwMEg0aDB4bUg3dDXMNuw3/NtI2 > 4hhVG91fTV7tvHrH6q7Vr411jKOMjxg/MKGZeJnsMek1+WxqZso3bTWdNVMzCzerMRtj09nr2EXs > 6+Zoc3vzHebnzT9YmFqkWZyx+MtS1zLBstlyZg1rTdSahjWTVipWEVZ1VgJrpnW49VFrgY2yTYRN > vc0zW1Vbrm2j7bSdll283Sm7V/YG9nz7dvtFBwuHbQ6XHBFHF8cCx0EnqlOAU5XTU2cV5xjnFud5 > FxOXbJdLrmhXD9f9rmNuCm4ctya3eXcz923ufR4kDz+PKo9nntqefM9uL9jL3euA1/ha9bW8tZ3e > wNvN+4D3k3WsdSnrfvPB+KzzqfZ57mvom+Pb70fz2+TX7PfO396/2P9xgGZAekBvICUwLLApcDHI > Mag0SBCsH7wt+FaIbEhcSFcoNjQwtDF0Yb3T+oPrp8JMwvLDRjewNmzZcGOj7MbEjRc2UTZFbDob > jg4PCm8O/xThHVEfsRDpFlkTOc9x4BzivOTacsu4s1FWUaVR09FW0aXRMzFWMQdiZmNtYstj5+Ic > 4qriXse7xtfGLyZ4J5xIWE4MSmxLwiWFJ53jUXkJvL7Nipu3bB5K1knOTxakWKQcTJnne/AbU6HU > DaldaXThh3kgXTP9h/SJDOuM6oz3mYGZZ7dIbOFtGdiqvXXv1uks56zj2ahsTnZvjnLOrpyJbXbb > 6rZD2yO39+5Q3ZG3Y2qny86Tuwi7EnbdzjXILc19uztod3eeQt7OvMkfXH5oyRfL5+eP7bHcU/sj > 6se4Hwf3rt5bufdLAbfgZqFBYXnhpyJO0c2fDH+q+Gl5X/S+wWLT4iMlmBJeyeh+m/0nSyVKs0on > D3gd6ChjlhWUvT246eCNcuPy2kOEQ+mHBBWeFV2VapUllZ+qYqtGqu2r22rka/bWLB7mHh4+Ynuk > tVahtrD249G4ow/qXOo66jXqy49hjmUce94Q2NB/nH28qVG2sbDx8wneCcFJ35N9TWZNTc3yzcUt > cEt6y+ypsFN3f3b8uatVt7WujdFWeBqcTj/94pfwX0bPeJzpPcs+2/qr+q817bT2gg6oY2vHfGds > p6ArpGvonPu53m7L7vbf9H47cV75fPUFyQvFPYSevJ7li1kXFy4lX5q7HHN5sndT7+MrwVfu9/n0 > DV71uHr9mvO1K/12/RevW10/f8Pixrmb7Judt0xvdQyYDLTfNrndPmg62HHH7E7XXfO73UNrhnqG > bYYv33O8d+2+2/1bI2tHhkYDRh+MhY0JHnAfzDxMfPj6Ucajpcc7x9HjBU/En5Q/lX9a/7vW720C > U8GFCceJgWd+zx5PciZf/pH6x6epvOfk5+XTStNNM0Yz52edZ+++WP9i6mXyy6W5/D8l/qx5pfnq > 179s/xqYD56fes1/vfx30RuZNyfeGr/tXVi38PRd0rulxYL3Mu9PfmB/6P8Y9HF6KfMT9lPFZ63P > 3V88vowvJy0vi1xA5AIiFxC5gMgFRC4gcgGRC4hcQOQCIhcQuYDIBUQuIHKB/2MX+PrvRljIynJs > DAD/bAA8bwNQWQWARjQAlLB/AEpyAwzt5FOhAAAAHHpUWHRhdXRob3IAAHja80gsLs5XCEktKEgt > AgActQSPxnz/2QAAIABJREFUeNrtnVuS5LgNRdUdub7+q1XWX6/Q9pSdkdYDAkEQBKhzPiamKzNF > EAQpvu/29fW1AQAAAETxGxcAAAAAnQ8AAACg8wEAAADgwevzH3///v3z508Gs/5tyec/k1gFdXlH > VEws/SQ3PW6TmBHvfy+bZWvdMyWXV4AP47OsTD3Pu8nsulkPbH1O3Mv3c8PpLtUkPY88hp2alNC2 > zH6ba2F+hyxZKJ8PzFkEp1bJpgZnyj25hFkWnvnApsyrlJueE/nyZdkFAKBrNPnv/1++X/vALC9W > ZNl4yX2fT9OF2Rj3j/R98/ev3o4+nRiUf9Wa5Z+/f05+KMvY1/hbCw0PlOP41FFmz9ss7ImopkLR > 1GrZ+N2jbn2oicOfrymNNJhhKBTZGzuylbKcZaE9dHkZfP5Fv6JRKMv6olTa4N5UukSUYLzNjFMb > hFW540e2nkdoZ2W37LJzjWYeTJio6flIOcW3+9rpr+S0DFneTMsu8oyWwfjbJJQzq5osyI4yG99q > oe2jzr9oHKJ88lX25Y8M5tnMMIeN7A29S11K2RDzV1lWFoqXGcJzXMo9Psv6Uv5MWvjI3M4PjSjB > eNtr9HS5RFhDkT/y6jj68ntEx0c57hmR/+x9PTHp5DuqZPNmGe+erv6BvsEW6cARaV0NyN5jiZ6G > bI3o2k046WewXHxY19XHj/qN9K2JMa3Qn3+4+r67DaNXbV79nYDj4t/bYuEjfUU91lhD+XV20k// > blh2sQWf+z6s0U1YoRMNPSFaNMsBw6DPFkCoIJHRW3eDguzD/FmObG2CX1KGLFeJw4D9Ii+zKfKK > 1671sWXp+BDZDN93g5DW57p7QCHpj5+N88bC9IRofPcoz0Sde+s2NHqTlOm76ZjYbsx9hw19++rn > M7xeUjEt9pL8NodUhl5eZMkFHy1zf1p/WjlLs9Oq/Gd9fxqsN4sNW8Oi1zfLtgWUzMPcmCzbXhZD > 265x55bdrbLt+Ujbc33pTTluuT/9aNPNaLl8pDzuZZtYk9O66jWPNqPJG7ti6jHDNgS/TavVQvP0 > 6W5jV8yk63EL+ggfGszQpzjOUe5NinscGrzUNPnhVV6Zs6wvZeVHLk2le0TZorc/y60TBPqgiuhP > o2oLCWcI8KHwK8oCAKrDJWMAAAAQygsXAGRmxMIQAMBkWHYBAACASFh2AQAAgFD+b9nluJFt9ATv > 6b5ueZ9tRW3uocbnkU0HAABQsdN2uXpZTnlDd34nfxdk6E8AAABywrILAAAAhGLXdnEUMr7VfRin > jb71CdZ/CtC8P7Ldh90pPS/cWXR8oFK9XXgsqzwAAGBnt+yy4+qdtA1WOb9Vf/bSRu/M1+n/jDC+ > 9fJp2fge1ewYaU0AAHjQzIfLiLZfrbi0elb+WYEe1XjmPAAAwLnzYXuTRaoVN00AFCKD8dxnBQAA > NTofW6xascuAPiF5JL/DygsAAJ6Jw2mXEWrFE6cBVpWe93oyez4AAKAT7cxHpMr5JiqP+2qjd64Z > nSYxwvgrMeswbwAAALiBtkuVaQkAAIA14JIxAAAAoPMBAAAAdD5ACZskAAAAZF4BaRjuGo8kuXkA > AAB0Pu7f5ZpTIacbM6e8+48qKnJewL3P95DO3204PVw3h+oG8CB8T7ucvlH0f+xJJdJ4GOTtZYwh > lqqHBAAMxXPPx5IDl+PVFwAAANCD27KLY89D0HxX6ssff/Xz/4IA/W3/gwnhyBGwcMu75tq6qwAQ > ntYUUZrh+1Ww3V5Ad7tGqQxFm6N2fW7NR7eev83yxnYrgKfhsuzSKvi+/e+W7jfHj4QnKOe0P/+y > e6ZhVpz5D/cexlUAHMtOU8r6j+TkWr/WGvOtSdjM6HRU0//IPbCrLN/WegBg5mMIwlhnxDCIoVU2 > 5AB4D5rNBZewxF1Msj1kljeU6bK+CUDnw9K+ZFiY0Dderaay7DLlpXXq9shXVIbXYQnBHfoNADCh > 85Gk/zEodXoes95np0EVWRZJyl3YAZOnpOiLAIAez9MuUyZOA/Tr6XlMfJ/1BJXthzHHbuPtCaub > SdwOAJlx3vPRNP9xbG4My8OdIvL0POb2ME4DYOf2z6ASSln/0TFK3SPq9IFKb+zOktjMsDlKk8Tp > l4/ubbWQPR8Aj+LX19fX9/d32DuG69UBAACeju8NpwAAAAAyqNoCAAAAnQ8AAACg8wEAAABA52MI > TVvur24Ht6X7zBum18gyYRPv8KIZbzVbc409QD0W23DaXxtt+h2jL2NYtZX5ydf03BE2tfqXI3xY > sU2j8wF1YeYDZraq/TeJAQBAOXwuGTOId28d2uinN3PcSplrjJdviVbevGQQdteY15qvKj2Pd6ZO > le4Jm8iweT/89FcGC2UzXG4FPJrRavxnBDY56ioGNCEqixYd78FTxltTeY0rFIB7Riy7GFTO9R/J > ouStA2hB1/tWylyZll7YfXvSssuI2CBs+sNm5yuD52890PS1pnz1GC98+TYhZVr6v+xyIaRlM8Pg > KICMMx+GYUrTR5098dP6c/oc5fz/1U3YsFLYNJm3UthkjudbH4YZn0Tg0GxGhooDdD78R7GpHmiu > P1dmnEqQMFZYLGzczagYNkPfPYYsyz5M8uIs1wIMVcgCGNX5GCGonVPKfJY3HjKfQdg8LWxWfbEZ > 8iXsIJleK+l/wAj8T7vIjWb/sbH+heHqY3HuAiFs6oYNfXGh9/lmlj8pHQjDYeZDkMZ2EUDfdcbl > IUKrlLnNeJcHXp3vOF3MNki0lx44EjbZwkbv+eNJjVMzImf4NWl5pS6ndVVeZm9cBbZLHG4su8A4 > al0yRsccCBt4QogStLA2XDIGAAAAobxwAQDAXFjvgMexmLYLAAAAJIdlFwAAAFi68zFxF9UsAW7E > 1vv9Q9gQNk+g1fMI3kJhgpddRleJhFUOsfVb826NIWwIm6FmFH1V0/mAurDsAjObzp9ddUptFAAA > WIMh2i4aJejT+6RvFdUFMWileLesZL15qEsvKbY+rufxtuEqAAibumFjlrm/slBZXk0Wuj9QuNFO > EzZysB3vcFNGTpPnvbwBcMmIZRdBa7tTG327FoO++q38qdkMZRIria0PChLCZu2w6ZG5b3Jpzz1d > jg80y9wbiltOy2aGobwAps18KDleGn011rl9zlAjbU3V6Q8XE1ufwjJhY8vyAmHztHiOzK9yGmyE > /TRTML/zMXH/1zjFiu1OG90xXxXF1gmb1rBxz1fFsBn6xlrjbFfO8uIaNEjX+TCrgb9HsccnTBw6 > fBrjbgZi67LnCRvCpsqUQ5iFsibi3ApL/wPM+J92yXP6K8MFEoitlzOPsKkVNssfu/15x7+ZlRF2 > eIAvv76+vr6/vx3jUj62IJ9WuAr0ps35rfu0Rx9b0BzHkLNmc++t8alOu2zX51YIm9JhI3hef0pO > mMjxOo7he9pFE9j9ESWk1XPoxlBeAM2g7QIAkBaOmcCScMkYAAAAhPLCBQAAaeGYCdD5AACACf0P > nACLwbILAAAAhDJk5uNUesCl8y6fWZh7fANai1Ie2xUNm+NmQOWxhYcMduXDFNRcgKcwVNtlypPZ > Cl6x8zG01CLDxkW/Y3vktbbUXIDnwLILpECpZgIAAAvgr+2iuQvodKCjv9vHcNkw28WLjo8JG/1t > UaeXcTXlS07L5iib4LtN2N395jcAGEX/sougBn71na1xnlmjE+2VFgR3L8YV5ZSw+XtAmferX+m1 > 0ZVRLWvZuyyHCRZqPtpMwu62jwCg8MzHbkhhq9joOMMaYSOLzRosTCLRPrRxGHGbRRKXAkBE58Pc > DE0RJYdyXY0qYaNfBFmA0fVLU8pCbHBPFwCdj8v6v5NE8m3aaGtW6n9UCZvR/Y8kYusjPO8yn/Fp > GHLwAKnwP+1iXnhWfpM5jFWHzoadkvnDZugpHrPY+uii9P1oaLoAMAWHmY/j8EvYKaaZCJUfqNn5 > r08LkrylrobOi4XNVVpePRvNA93zJbja9pHNeJZdACox4pIxAJgyx8AQHwBKwCVjAAAAEAqqtgBV > YTUBAOh8AMCE/gdOAIBysOwCAAAA1Tofg/a4XV1NDWswaLMkYTO0yAT39nuegguucQAzcdd2AZjY > +aChr5s18yUukNxplBccYdkFAAAAQnHbcKqR/N4O4t3bnWq25trmz2cKaWW4iBpsQ6VCYXNUUj0a > f/ynnJbtSIshX+aacuX5TS1z35qQHABzHXUbvY4B4O5eTf1qypetvDjGtT4uyy5Kye/dX65Us+V3 > hvA0oZ3ijvaE3YsrHfkFwub0m8LTzJXI0J+T07rNctMt5nqZ+6YtIxr3znJUU5Y7A2CEe6/qly1f > tvLi9jxmPrSYu6U9/dkmaSg6zgkxq5EtGTZJ0ppVU4aK4JRw1NCwbHJvwtaSBpzOR5bwQpQSnhM2 > nSP4isZjYRLjh9aXK+O5PY/OR976RizCc8LGYHawzH3dMWseRz1wSkA/sUSbvx71TrsQhVArbIZu > ULDZkFB93pyur8Eleh4GI/PkS2MJOzyewNiZD/Ps2ZXy+M8/T5/JTN0yLBA2O+340z8e0z09nmCz > UBasFw5WaM5c7NwrfKSXuW/dlCC718tRvtF7mtatkfoHernXPV+t5UVj/gj6T7sAQOcQMHKol3Da > AwCeBpeMAcx/6wMAPApUbQGC4KY7AID/wrILAAAARMKyCwAAgJHpy6lF13OdtV1Wmkmee6ZXmbqg > qVHOvUeFCEO+EsZhtqLksPoyLcDxraOUYhF+RaGUs0d5bCodc5ddMnfZemzrz1fTEyr2fJ8j35Ct > KOcGdqEymptZ230YXn+hWa5VIypWTJZdIEWF4SQIAJRrwZLMN+SURpJ5eZXB2wXHsrnSpBZ+a1BU > H6FJLYTa7ZRm6yy6cA5ihFB4hvrzni08lp0houRf7apokxr48VcLFKVBDv7KyfIKmqHqyaXs66jb > CmtwlJCWso2aeBuv3kLlwlD+Ztn3QjO53bBlec0r1xyXXU5n8+R7nQ03TwuKz4Y7pJWyzq0y7q2d > UEH/2mvWVK9/HTntcfxvZ0Qpy1Spcn4bLRWL0qbebquw5o8MWRuh+d4vcy80I/KvlFneoW+WT3/V > ZGFnsCVplnsWoeQHahqQzo8ytOSTZz7k0W3YM70uxj6WqMuTT4Pj9MkV59A6Jz/mRtTTpkMH+dBx > Fi3PbPaUB+rD5j0T7FWJZmV5VrM8N/Zsaa0x85H0krEmlQffByobU8MDzRFTWlEdahWle1rc5p6z > E1+6Ovg2y2GLGnJaT6sOr7R1aeiATD+quOpiJ+8dFxIKf9Sxz/xFGTnw5cRvof6H+/28eZpl+cz/ > 0OrwmdbTqkOi0y5hx1Plrx17pj+xHin5HTb6ZOi5zERC/IHe44L6GsuFGQ5h2dId6v+f8n2zTLPc > 47FWh3uVzukukHJ9F+fTLq1LcY7S2JtalPxW2fyqu/ou4NtfnearyXKlhUop86sHpn1b2CLq9len > f7ndw9+6mp6/KJU1RRnYn07bOTBSNt1d893mKE1ENYVNfLPc6t7SzfK4ZZfb1sYWURunXZYfYjI0 > B4oSQBhtE5Mb16tb4ZIxGhGgKAHASIbr1Sv67UXoPLCqIOxOUQL0BBvxBr0ss+wCAAAAJWDZBQAA > AOh83NFzwgpSFeLpNc8UbvWa4n6x2ENCYmh5Ua0gF3OXXagPUFfgu/TFo6t2PmhSEnqGQoEjLLsA > AABAKA6nXWwKwhqFbln++LjXms3Yqw7U+tWlfZWsb3XYl6wpSkcpJenND7w1z0s2Xele949ub/vW > iMibfWjI8s7CU/McfQiL0L/sYlMQvvrC++9NWslb5dl7Ohly6W/t6tL62OhRsm4NsMVqikYOXv/R > 1q0vL+TFnOUr947TRm/6ywgf9mfZLAHfWc2hFnmXXfq7unSW6zK67FZSss5WU9yV5Oa6fbp7dxds > 2FQ8WiUCntYgQDzDLxlz6bESeRA/Bgq+VSl/TQkTySvRJ05ybGe0D6dEFBea0fmgxwoLDvTNaUVq > bSfs89kE0FdtHCJncd7qdJ2qh4V8GFn1YAqJll0YV0GqYJsill2lptgO0wbPFiRpATKYkacxRI4O > fvj19fX1/f3tPiTSbMbefeFqv7Qcl2yQXqAf4LW9X9+ceW25bz3tUrqmCErx/R9t4kmNpoGv12mX > Ee7tDLamg0s2H/Zn+TQtTrvAHrRdAAAAIBIuGQMAAAA6HwAAAEDnAwAAAIDOBwAAANTjVdHooy4G > FC3EN46lWfFKgOPZwibZlxFuXMDhEw2jjapbGSEITrtAhtet48l+QQalUOejkJ5RT6JDDR7tjdLX > UcQYz40dcAXLLpCC44XKAACwKg7LLu97fz9fJFc934TC05B/WLYT75a1woWLmGx3ggla9qeRdmth > jAOVtbL1Ci9NkfWLrRtiY7sWkbc1DnIACMYLOfK9VsvW9grGuztKqFbwdPqXXQQBdKHhSCI8DUm6 > F/rYMK/X2C4R18iL775jsPDvAaXHrn4lmOG+4NWTlkvqV2n1tzZXAaAxPqCN0nteaby7o+SYBGY+ > enHpyXYqcR9vbqZ/vSTBxTpavnz3q9a4ddevL1EoSpM+B+LmxmFo1vofPsg8Q/spz3ZszDfDiM6H > YbgpiCaP0FOmxw0lXrFeiyALM1FXr7Nc5JZtJWVNpfwQ0PkY2EwIMtzC4qJNT3lV4Wl4WhdnaHud > YUvKoCYlf+Ogb/RK9JWb4o1GGD757dUitH7NXXcbqg9nI9um5DE29OzPj6vfXH2nyQAXa22bcpIU > cWml+ON2EN8I/Ik09nyA/8zH1Vjq+PfdKuxpP105OXnam74a2XDaJXmT91kig8prF36+AT+08yTH > fH/PxmXngb4FuCpr/eympkk5zaZv43Bl/FV5Ra413z7w1PhPF+3c1W+hbVcTLIvLaRfcCFCxzydU > Yeo1AIyDS8YAAAAglBcuAHgUmvlz5sYBYCxouwAAAEAkLLsAAACEgrAfyy6qwqs4Be11siOsVhQS > kSewlwns0gtMa6+OtYao4I1sjgqzJ/Wlhc9ZdonsA+bpb1a5WmArJSJPYC+T69LxQ/ArvZHNUc+s > sztYdgEAAIjrDQRfqpuz//FydKV834780efskCDDvZk0qfvFu08vRb7SEBd+axPvNohcP7ZKO4rI > E9jLBLac1nZ9352cr9Zb6vUhas7yLths+TI80D3LQkjLdVlW8LB5o7UFcJmi6GwcCuCy7KJUHt9M > +tfypeydEtK2aatb2fRWuWqbD1uTyNZXyC8iT2CvEdiyew2q9LeO0oST2RtKP9vylSrLTcEvp2Uz > wyV6Nd80F4rt4YvMfLh0uEZMDSk75rYfjuhgnj6zRw08OSVE5IsGdqqH5wns01Rs6Ub+StOIeeUr > iaPco9dshvKHSXQBC70dXqMjIEwn2iY9EFxU7uLdC+w4KyQiXyiw4+exlgzs/PWr+mmdiuOlLVyL > Z8mdxa+w0orv2yaslubO7KkauFle/Gn9jxEi8gT2EwI7/3u9tGC9weYRddnF+P5aKTxwyc18WU67 > 9Dcu8Qrg2dIq3TueLiJPYC8f2O5K8Xnqjq9gfWZHmeuyb3Z6nnbq23FHx9POjb1G1wqlhPStNPan > yrPmgZtOQlpZkK1jC0Gu2tbx16iB7/7pq8M+qzOaU0SewK4V2IJSfGTYDE1Lv4PqNthaHTUiy1el > bHbU1ZSJeb1+VpOyjVz9CSXPJWNcmANhocUlPwDU5eXfd5mdwyVjAAAAoYRdr57WA2i7wCPqObex > AVCXIRHP0XYBAACADLDsAgDwUNh5ALN4PbbKNd1/6jizl+TsyXQzju1R/ulTwibPyakRTk6SqbAc > IewOM0m77DK0szz67gTuZzTY5mItYfOEcaogi8MgO2dBUy6wg2UXAIAn9jwQdoeJvByD2Ka1ffyn > Tbxb3++Wb262aU+0Gi/rRG8e4t0GM47XYc3SbiZsHh42+l91BoDcfPWH6NYucy/83CuwbZ5fU9gd > ZuGy7OKiPC7Xgaavyd8RVM63AULPtlx0Kll3miH8j8EMIWY+aTKMsHlU2OjzYgiA2/AzPFCTUFMA > I+wOzHzcjD9mcRrZgpZ3oUK68q0+y5nzVUjSdo2wKc0g0QBfX10J5m3jhd2TRBEzHxDX+QiLPEF5 > 3PeBI35V+u0yKMsxO+Hdja8bNhlGBZ3V3BAwejNsyy6RUT1ObP2Bwu6wVOej1huXrv30LAf0Pwib > QmFzum2iVgBczXyUC+zlhd1hFjVOu+RRQ6472E0+ahmxqEHYrGGG2YZZxgtixXmqIcLuMJdfX19f > 39/fXpXtNgqvJvFORwnjji2cnpJoSuvWjFbjDZvnmzLen5bvhnZzWoTNE8JGLmU5LwYf2qZnWr2h > PO3SZGFPrTx97LjApvMB/wfaLgAAD5lGmmISm0XgCJeMAQA8FITdgc4HAAAA0PkAAAAmAADofAAA > yLCVASA5L1zQ2fSgcu7VcD9kXBhZXs8MUZTiAQqQ9rQLo4q1vTHojgGuECVEUYoHyA/LLgCwVFcM > pXiA/Lwca3vPxUSR2ujbJP3rpouSjglNVzmfOHh9ctjIZhhi4zZfV8aXDlGU4gFy4bLsYlB8nqiN > vuXQv24aMCVUOXeJmU+asvOcsLk1zBwbp+41R2mSEEUpHuApMx9JxgRmffkM+tdm40tjVihNYvwy > sukPHNyjCwiwSOcjrIrKWtu2YVmY/nWSRi3VWC3myICvsHtw2LCL1iXGcC/A4p2PckOWMP3r0j4s > 3f+oGzYj9OUfGKIoxQOkosZpl6Gt7RT9654nL/nuGXFqYL2w2dq3VqxXYQ2BhFI8QDZewQ3B52hD > Vs3+/MLVr7aWXR2nvzpNVDDy2AzpL1Da5aipQTz1hsaM078k38NP2AhmnFrVFBuDAiBziOojKsBR > APAf0l4ytvzojZVmwgZKlwJlDWCGS8Z4LQGsBkrxAMlB2yW0QWy9vgkAAGBBWHYBAACASFh2AQAA > gFBYdsmO+1m+bIcDKx5WPG7faZJiOf0VPDwgBS2ehI+lpkAvLLvEVLkMjxr0wH5jym3FbRJMafoL > NeXhJvmmrlQLoqY8IbCzwbILzB9ioksOAPAofJZdDJrUsja6QV58M+lfKwXQr4w/WijLi9t8uPvU > 3RtT5pmFe7o6C+UqqFqLMt4bmiwrL3R3qUTHQrkqPlsLINQUW13+NNucZX2tbK3Lcikra4q5tnY2 > sLJ7q9eUDK+Ax9G/7OIiV338p0aVfuuW4RY0xG8V1YUpzdZxvE3lvN/zx4dHNiJTstxalELYfKLM > 4NWv9FluEpfvrESfTxDM6KmVetfpI0pIvSfLrWY0Bbb+L00V9urLPbGhcW+hmpLkFcDMhw9etzV7 > fU0WrA8TQJfNEP4+wp8Txy6+vj1+0zA0NPjhdD6gJ6ERZeF+K/ksk8ICdfQKYFhGDLfaD81y5poS > 9goA585HgAKCbbYzMkSUIh0B8wfKX2WoNgbjzcGmT6u1iaxyWmeoiLxQ9XxVdeJrStGWvemVH9NC > ri3CR0dkzsyHsNZO8SfM8txVWyFsxgXbuJyOblVHXIwbOTxwKa9OD5/uB6JJia/v5WoKjMPhtEv1 > k2k5BeRGj03//MPEPR+DnHncPhbWqo7L8p8PFq5cTZsJBlmVvDpU30mQs6agIVp15sNFrlrZKR6h > f33VX+6Z+72SFzfka6g3bMuxqRqvXZY/z+7O0ka/XW73yvLoCrsL46sK2xOHpzWlM8un+xua8jWo > VtrCRjYprH6NqDtJakqGV8ATefglY/RJoVyIRgYtFYQma+2agj9nwSVjAAD0NgBCQdsFIDXBa0aQ > PAAofWrKIqDtAgAAAJGw7AIAAGAkZl1swdW3uTMftY56upha7nRrmDNzuuWBIQqQvDrkqZXs/p7f > +XhCq9ckq0E7la3zQYgCLi2U5RKep/NhhmUXSFFveWsCQLkWLHJPa/z1iUN5uRTA7n9atZtPtcF2 > Hj/VRhc+2rolpDdRa9vgDSHLNjVwmxx8Z1qOFe9dfMdrSX3NIETlIZRG871Tefz4T9sDN6vmuy3L > t2HQ5F5b2HjFhjIODc2Xzb2lW1GXANB/tCajl11u9cqbJKRtut6bt7x45/xYp251vxz8bRK3Hva6 > ePv433FmEKKakBDkxQ3K47I3+h+orDs9MveOd8zbwsYrNvRVw9x8GdxbtBUVvtkZva0Pf/TMh2aA > myGrjnf3nkbArGyepjvCwt1EheNEok1I1teMxUJ0hA0TpcyHFlA5UeJa4F6z/OfaEx+vlcrYJptu > E3aPdJohX2YL5bTCdLEnmrFGiHqZkZAkSo0T0+qPDXbRRo4BhtZlOh/OVetqjVBePly1gxlm4a3y > uPuUw3axfhxvxnNC1KwvX7o6ZKhE5rAx5EveT1M6APJPwAj70rh0dWzno/OtIPx84vvGXD8LacbK > Wb7SjK1oBiFa68WTpBIZzNhtJggLG/0Db7dWFPV82CDEfSe+0Edcqe/y8i2Gps6dRkJ698B+EXl5 > fLDp5MXN3riVkL5VA3fsOzcpj+/ifvTCxwgzCNH+wHax8DbXnT70rUStYSO4d2JsNIVNa/M1qI0q > 0YoOKpSN0y5JBnCtW4IBCFF4ctgQhxOLtW4qkXDJGAAAgJGYKYr1JkJ+fX19fX9/J+9LPvomFqgw > 3CFEIVvYEIeQmoTLLgAAALAwLLsAAAAYYc+HkbkzHw/UK8+f5RgLNXeWI95NCwUPbBwK1UpUbed3 > PtAr5x3g2/mg6pJHXPrkLFe5gQaH2GDZBVLUW96aAFCuBQu+OBVhufNXCHrlWwUxaGVap5fr2W6A > luvS538HmUGIykMopb68fGO3nK/jP20P3BRy8IZKdJXl2zBocq8tbLxiQxmHhubL5t7SrahLAGwP > PyU3etnlmXrlmcWgW5O4yr7LJUjH/44zgxDVhIQgcy98pLdQU5SdouRNEX4bUf1jTaU3ZBv6Y0Nf > Ncx0L13MAAAKWUlEQVTNl8G9RVtR4Zud0dv68EfPfGgGuBmy6qhVOEKw3jdfIywckUHDNe2DzFgs > REfY4O6lfvm0lUp/ASNxr+PDl5/5eK1UxmF65cFhYcgXFwo9PES9zEhIfv280Wn1xwa7aCPHAEPr > Mp0P/9Hwacnl1ytn0POE3JUO0eqK6smrueBec9gY8iXvpykdAPnbGUGNlmHh2M4HeuVJbAZCdI1B > cF1h991mgrCw0T/wdmtFUc+HDUIGCd+Pe/JqnQ/0yjXeSCUGLW8WubIw+D3qaAYh2h/YLhbe5rrT > h76VqDVsBPdOjI2msGltvga1USVa0UGFsnHaJckADr1yIESBsHFJC0YXa91UIuGSMQAAACMxUxTr > TYT8+vr6+v7+Tt6XRK8cCFEgbLzSAphPwmUXAAAAWBiWXQAAAEJhp0iimY+Jbqolm360vKLxC2yI > 6/e81/3oNNnVq8OTC/SBbS9auFU7Hyg+V39tb+zGL9vfmvvAJvUiWDWYq7e9dD42ll0gSb3lhQEA > D2n3gq9bzdm6vtxdaVPNlq/7bVV8Pn3m7StQr95uM0PQbpYvs/Pdtd4pPO1Yhd5XTh1d7WtGpxy8 > l7y4MuabHnhbK20hKgShV9XreaDhJvLOxuHUUVeNQ0+w9bSi+rTMLYChPaTttU1RdJZyAfqXXVxU > s+XFM40oc+c0vkG93WCGQRp7XE5lkV55csJLZ/z43xFm2NTbN4XWdqu8+G3M2/6iybWLDrt71dPn > RVkrfX1oMMMWbC6taOtHTdLztvaQtlcZ851F2frwRWY+bke306eGzPryYertu2un+ycVzFnWT1Q4 > Tgk2Pc1mhtngyGuY3U1a8mqHJJkSzHC3MEmJT9RmK9T2zvVAoSr/ymmW7y6e4PJw1242eMOcZTkt > 355HEjPCtLYXfmdP34ga3KSUgCxPaXu9hiLC2soavHIGkE3xuXqP9XRAH6l/fZuW+8zHdrHFIdIM > bn7M5sMRMW+wsLr0/PJD55Xa3u1i48vCbdTw0y6ta7qtT3jasduJZ7TelSF4+7SLGQlfG45r5GvE > /NUDvfYWFKp61Y1c8iipV0KnDZfXw0+fnLPv8nJ35a7/eLVpWS88rVR8NksSm9Xbfc3YLlYTZG/0 > SM/fCk9//nNn2ND1lxFmKOOwP2zMUuZheuWtFh4d7h7zTY7SHP1w8eFtQxTp+c4HbuOl50+LkrbX > PTaGNg6hDL1kjMsbgOEgAMCURilz08clYwAAAKHETFFkngih8wEAAACx5NF2AQAAgCfAzAcAAEAo > 7PkoqWo7IukHyjrP9cbtYbP8hdJvYbksJ28lRlQHoO11DzZUbat2Ph54lr1w99ba+eBV+gSDWx+o > +T6dj+WDuXrbS+djY9kFktRbXhgA8JB2L1glZ1lhORcxaPkW23G63tvzZJ2Vgtp6b3TWis//DjKj > U+VcLuXT6+GvyksT800PvK2VthAVgtCr6vU80BCHnY3DqaOuGoeeYOtpRfVpaVqApizfxjBtb0+I > 2j7KTv+yi4sYtLx41q+nbJibWlXWuUlHW+8NW9gc/zvCDJsouVBetr9oYt5RDt4QbAa1+s6AbJVf > 0ASAow8NZtiCzaUVbf2oqSmwtYe0vcqY7yzK1ocvMvNxO7qdPjVk1pevK+tsznK8N1ozGyyXNW4k > YY75JALrs8ivH+luYZISD14sKNr2zvVAoSr/ymmW7y6e4PLIIOuMUuvE8nrgO3v6RtTgJmWxwH5g > lse1vV5DEWFtZQ1eOQPIJmRcvceaQdb5gQNZOmrZfDgi5g0WVq96yw+dF2t7ha0nS7ZRw0+7tK7p > tj7hacduORWyjN8c18jXcOnVA303G61d9R54DUG5tvd0vdXr4adPztl3ebm7ctd/VEqZ7ySSZSVr > Xz3lx8o6n37ZVye6vwp5maGMw/6waZVN73mgV9unF3YfFPNNjtIc/XDx4W1DFOn5zgeeZvn0L75F > SdvrHhtDG4dQhl4yxjAdGA4CAExplDI3fVwyBgAAEErMFEXmiRA6HwAAABBLHm0XAAAAeALOR21b > NxwBAAAAnY+ungd9Dmjtp35C/JQostZiMhwHcB/GyA+ce7YL4Ik4LrtwpgBioqX0LQLVq4nyNg6c > DwACbDgFAACAUDyXXQwiYQCnw9MwQW3NKLlHlf40dfNdTKdpterLC4rqt9dL9zhKL5tu80ZPvBks > XFPlHCAMr2WXU31wADlg3sixNE5Qu/VVp0xL+U2bAU368pq+gkbY/TaJVhkEjfG2v7SWpsHCfpVz > AGY+AOYQKUoeOQC90qkK9mHpAFjJQmY+AAZ2Pt4Ty9Q0mIW7oLY5LZYgM5TyFDNqy20AlOt80POA > R42k5bTCZj4o5YRmCNroAPADp12AcbBzWu+Xza0O6qq7AfSOIiABngl7PiBRM60cILoLajumdapB > f6tKrzTAd+h/q6i+M17WEL/Kl/ArzVmS3a/M3hDMMGijL6tyDhCGr7bL6eEFAABmCABg1MwHfXwA > AACQYc8HAAAAhMKeDwCYALOkAKkQVkJH1FY6HwAAACBpPrvzOyANWxfs6u5tgJ6IikwuSa4f6P/R > A8FBmZKfFuDD+CwrU88fOWkVmPO67vO0S9qrAxO6T5ByWLg+VLeQjuz0ZjRnETSp2EzJlHtyCbNM > 58P9gU09RZtsk8/MBwAAaJpp4cISsgwJiywbL7mb0y8h3SM8rembK2XTbaLkwq92kx8u2uitxt9a > aHigHMdXMvc2z9ssdJcyN3tj8xOR18eh/tZ2mxmGQpG9sSNbKctZFtpDl5fB6R1ut6kUyrK+KJU2 > uDeVLhElGG8zQ9h7ofyowKX+u2UXvUJ3p7r07UfKKT6NbLqXKLny4fpJrU7jb5MwyMHrp+9cjG+1 > sFPK3FGi/SrL8l8EiXalenvrcNOgZW8IG9kbrbetuwvWm+NQWSheZmx+U99Jsqwv5c+khY/M7fzQ > iBKMt71GT5dLhDUU+SNzzPQU9C2/bX1qc8fc8PymnBueP7F7eLygOnM/VTZvlvHu6eof6BtseVTx > HJ/5bhM7dymuEV27CSf9DJaLD+u6+lQHINVLKqYV+vMPV98vd3a94aitQUK6R+bg/dtjjTWUX2cn > /fTvhmUXW/C578Ma3YQVqgZeShxPuLXCUPXeM+SOR/hyxvzo2mRoZNIeIIhvKoO1eErvnE3X+Thd > rbwqrc8v96hLHx8im+H7bhDS+lx3D1hau3p+pDcWJrkAurAXpPQ0QHD0JinTd9Mxsd0I7nnYSnn0 > fIbXSyqmxV6S3+aQytDLSyinPvGZo9Xbc5Zmp1X5z/r+NFhvFhu2hkWvb5ZtCyhpCcuy7WUxtO0a > d27Z3Srbno/yMx+nWtunH226GS2Xj5THvWwTa3JaV73m0WY0ecNXet4wBL9Nq9VC8/Spu0S7pk1p > EpH3DZvNpBQ/ImzCmhT3ODR4qWnyw6u8MmdZX8rKj1yaSveIskVvf5ZbJwhydZE/T7sAJJkhwIfC > rygLAAhroLhkDAAAAFYAYTmA1IxYGAIAOBI6q8qyCwAAAETyLyE7x2hhkvDbAAAAAElFTkSuQmCC > > --Boundary-00=_IgMQEQvQ0zFQ0Fy-- > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From robert@vyatta.com Mon Apr 17 23:16:08 2006 From: robert@vyatta.com (Robert Bays) Date: Mon, 17 Apr 2006 15:16:08 -0700 Subject: [Xorp-hackers] Cli style guide draft In-Reply-To: <200604172121.k3HLL7Hw026042@possum.icir.org> References: <200604172121.k3HLL7Hw026042@possum.icir.org> Message-ID: <444413A8.8050609@vyatta.com> I would vote for Hasso's proposal of having timevals as u32, with no units in the keyword or value. The help should contain a reference to the correct scale. Just make sure there is a valid allowed range for the value and let the underlying module interpret it. Cheers, Robert. Pavlin Radoslavov wrote: >> Hasso, >> >> I think this is a very strong proposal! > > Ditto. > >> One comment in terms of usability. While I agree that getting rid of units >> from node names, it becomes problematic when different nodes with the same >> nominal unit (like time) have different scales (msec vs. sec). That kind of >> thing is extremely easy to forget, and will really bite people. I'm thinking of >> >> interpacket-delay ... (msec) >> request-interval ... (sec) >> triggered-timer-max ... (sec) >> triggered-timer-min ... (sec) >> .... >> >> If interpacket-delay is the only one in msec, maybe it SHOULD take -msec in >> the node name to make that explicit. >> >> But there is a better answer, which is to introduce types for time in seconds >> and time in milliseconds and allow people to actually enter unit suffixes, as >> in "set ... interpacket-delay 100msec". FWIW, Click time units are now >> entered this way; it was a really good change. > > On one hand I think this is a very good idea, given that we use time > values in many places. > Implementation-wise, for example we already support mac/macaddr type > in the rtrmgr templates and the XRLs, so it won't be terrible > difficult to add support for timeval type (or whatever name we > choose). We could easily support more than one ways of representing > the time. E.g.: > > * 1 (= 1 second) > * 1.234567 (= 1s 234ms 567us) > * 1s, 1sec ( = 1 second) > * 1ms, 1msec ( = 1 millisecond) > * 1us (= 1 microsecond) > > > On the other hand, majority of the time values we use for protocol > configuration purpose are in seconds, and (off the top of my head) I > cannot think of an example (within the set of protocols we support > so far) where we want to represent time value that has seconds and > ms/us component, so the above flexible format might be an overkill. > > > Stylistically-wise, I'd prefer that we introduce the new timeval > type, because it is cleaner and self-explanatory (e.g., I don't need > xorpsh access with the help strings to figure-out the time units). > > Pragmatically-wise, we might be the only routing "vendor" that > support/use such time format so I won't be surprised if this creates > some confusion to the users. > > Any other opinions/preferences on the subject? > > Pavlin > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Tue Apr 18 00:29:06 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 17 Apr 2006 16:29:06 -0700 Subject: [Xorp-hackers] patch for bug 596: Single node operational commands do not recognize optiona... In-Reply-To: Message from Michael Larson of "Mon, 17 Apr 2006 11:42:44 PDT." <4443E1A4.6080601@vyatta.com> Message-ID: <200604172329.k3HNT67A048306@possum.icir.org> > I've attached a patch for this bug. It's small enough that I'll just > include it in the body of the email: Fix applied to CVS: 1.129 +2 -1; commitid: af56444423f17ea6; xorp/rtrmgr/cli.cc Thanks, Pavlin > > [mike@zeus rtrmgr]$ diff cli.cc cli.cc_new -Naur > --- cli.cc 2006-04-16 19:32:57.000000000 +0000 > +++ cli.cc_new 2006-04-16 19:32:40.000000000 +0000 > @@ -658,6 +658,9 @@ > command_vector_name.push_back(ccm.command_name()); > com1->set_global_name(command_vector_name); > com1->set_can_pipe(ccm.can_pipe()); > + > + com1->set_default_nomore_mode(ccm.default_nomore_mode()); > + > com1->set_type_match_cb(ccm.type_match_cb()); > // Set the callback to generate the node's children > com1->set_dynamic_children_callback( > > Thanks! > > Mike Larson > Vyatta > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From hasso@linux.ee Tue Apr 18 04:38:09 2006 From: hasso@linux.ee (Hasso Tepper) Date: Tue, 18 Apr 2006 06:38:09 +0300 Subject: [Xorp-hackers] Cli style guide draft In-Reply-To: <200604172125.k3HLPMK0026087@possum.icir.org> References: <200604172125.k3HLPMK0026087@possum.icir.org> Message-ID: <200604180638.10534.hasso@linux.ee> Pavlin Radoslavov wrote: > If you don't mind, I'd like to add the text to CVS as a new file: > xorp/devnotes/cli-style.txt I don't mind at all. That's why I wrote this :). Feel free to correct grammar etc. -- Hasso Tepper From cshue@cs.indiana.edu Tue Apr 18 05:05:48 2006 From: cshue@cs.indiana.edu (Craig Shue) Date: Tue, 18 Apr 2006 00:05:48 -0400 Subject: [Xorp-hackers] Implementing reverse path filtering and packet marking Message-ID: <4444659C.5030506@cs.indiana.edu> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig15E66545E438C4EC92B4BFD1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings, I am interested in implementing a form of Reverse Path Filtering. This process is similar to ingress filtering that is performed by consulting the BGP FIB/RIB and accepting packets only from address ranges reachable through the interface (based on routing advertisements, static routes, etc.). Afterwards, I would like to experiment by adding a prefix-indexed table for this lookup and perform packet marking in the IP options field. I have been looking around in the FEA section and documentation. However, I am rather unclear about how/where the regular packet processing is actually happening. I am seeing raw packet handling functions, but they don't seem like they are for typical packets. Could anyone point me to some detailed documentation on this or explain it a bit? Also, if you have any pointers or general advice on how to proceed, it would be greatly appreciated. Thank you for your time, -- Craig --------------enig15E66545E438C4EC92B4BFD1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFERGWcWQ671T0s3GoRAhlFAJ9+wquq7souBS5nri5CIDRJhsjZ0gCglJvm Y6FnvLDfgnRv6jC58DMay3w= =H9iu -----END PGP SIGNATURE----- --------------enig15E66545E438C4EC92B4BFD1-- From kristian@juniks.net Tue Apr 18 06:15:42 2006 From: kristian@juniks.net (Kristian Larsson) Date: Tue, 18 Apr 2006 07:15:42 +0200 Subject: [Xorp-hackers] Implementing reverse path filtering and packet marking In-Reply-To: <4444659C.5030506@cs.indiana.edu> References: <4444659C.5030506@cs.indiana.edu> Message-ID: <20060418051542.GD19647@juniks.net> On Tue, Apr 18, 2006 at 12:05:48AM -0400, Craig Shue wrote: > Greetings, > > I am interested in implementing a form of Reverse Path Filtering. This > process is similar to ingress filtering that is performed by consulting > the BGP FIB/RIB and accepting packets only from address ranges reachable > through the interface (based on routing advertisements, static routes, > etc.). Afterwards, I would like to experiment by adding a prefix-indexed > table for this lookup and perform packet marking in the IP options field. > > I have been looking around in the FEA section and documentation. > However, I am rather unclear about how/where the regular packet > processing is actually happening. I am seeing raw packet handling > functions, but they don't seem like they are for typical packets. Could > anyone point me to some detailed documentation on this or explain it a bit? The code in the FEA section is only for traffic actually destined for XORP, that is routing protocol traffic and such. The actual forwarding of traffic is not handled by XORP, it is done inside the kernel. Thus it is the kernel that should support the RPF check. Linux already does this, please have a look at /proc/sys/net/ipv4/conf/*/rp_filter AFAIK, FreeBSD is lacking this functionality, just like many other OSes out there so indeed there is some work to do :) > > Also, if you have any pointers or general advice on how to proceed, it > would be greatly appreciated. > > Thank you for your time, Regards, Kristian From jfletcher@vyatta.com Tue Apr 18 19:18:20 2006 From: jfletcher@vyatta.com (Justin Fletcher) Date: Tue, 18 Apr 2006 11:18:20 -0700 (PDT) Subject: [Xorp-hackers] Patch for bug 312 BGP origin help submitted Message-ID: <2728097.121145384300573.JavaMail.root@mail.vyatta.com> I just submitted a patch for bug 312 on BGP origin help which will limit the range to origin attribute values 0-2 as defined in the BGP RFCs 1771 and 4271. Help is added in the form of Possible completions: [0..2] Origin attribute; specify 0 for IGP, 1 for EGP or 2 for incomplete The help text is longer than I like, but provides a simple resolution as to what the user should specify and why. It also starts with an upper-case letter and doesn't have a trailing "." to match the proposed CLI style guide :-) Justin Fletcher Vyatta From pavlin@icir.org Wed Apr 19 03:21:33 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 18 Apr 2006 19:21:33 -0700 Subject: [Xorp-hackers] Patch for bug 312 BGP origin help submitted In-Reply-To: Message from Justin Fletcher of "Tue, 18 Apr 2006 11:18:20 PDT." <2728097.121145384300573.JavaMail.root@mail.vyatta.com> Message-ID: <200604190221.k3J2LX2d012612@possum.icir.org> > I just submitted a patch for bug 312 on BGP origin help which will limit the range to origin attribute values 0-2 as defined in the BGP RFCs 1771 and 4271. Help is added in the form of > > Possible completions: > [0..2] Origin attribute; specify 0 for IGP, 1 for EGP or 2 for > incomplete > > The help text is longer than I like, but provides a simple > resolution as to what the user should specify and why. It also > starts with an upper-case letter and doesn't have a trailing "." > to match the proposed CLI style guide :-) The patch is applied to CVS with minor modifications: 1.90 +4 -1; commitid: f4e244459bde7ea6; xorp/etc/templates/bgp.tp Now the help string is slightly shorter so it truly conforms to the proposed CLI style guide :) [0..2] Origin attribute: 0 for IGP, 1 for EGP, 2 for incomplete Thanks, Pavlin From pavlin@icir.org Wed Apr 19 06:08:32 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 18 Apr 2006 22:08:32 -0700 Subject: [Xorp-hackers] LXR? In-Reply-To: Message from Bruce M Simpson of "Sat, 15 Apr 2006 22:32:23 BST." <20060415213223.GB28496@spc.org> Message-ID: <200604190508.k3J58Whj013822@possum.icir.org> > On Sat, Apr 15, 2006 at 08:53:40PM +0300, Hasso Tepper wrote: > > While hunting through code today with questions "where it's > > declared?", "where is implementation?" and "where is it used?" I realised > > that something like lxr (http://lxr.sf.net - old page has more general > > info) would be really nice to have. > > I use cscope, in the vim-integrated form. But I agree that a cross > reference on the web is a nice tool to have. I also agree that having something like LXR would be nice. Though, for security and pragmatic reasons we may have to postpone installing it until we refactor/upgrade some of the infrastructure (Web and CVS servers, etc). Pavlin From dave@vyatta.com Wed Apr 19 19:10:23 2006 From: dave@vyatta.com (Dave Roberts) Date: Wed, 19 Apr 2006 11:10:23 -0700 Subject: [Xorp-hackers] Patch for bug 312 BGP origin help submitted In-Reply-To: <2728097.121145384300573.JavaMail.root@mail.vyatta.com> References: <2728097.121145384300573.JavaMail.root@mail.vyatta.com> Message-ID: <44467D0F.4050208@vyatta.com> Perhaps go with "Origin attribute; 0 = IGP, 1 = EGP, 2 = incomplete" -- Dave Justin Fletcher wrote: > I just submitted a patch for bug 312 on BGP origin help which will limit the range to origin attribute values 0-2 as defined in the BGP RFCs 1771 and 4271. Help is added in the form of > > Possible completions: > [0..2] Origin attribute; specify 0 for IGP, 1 for EGP or 2 for > incomplete > > The help text is longer than I like, but provides a simple resolution as to what the user should specify and why. It also starts with an upper-case letter and doesn't have a trailing "." to match the proposed CLI style guide :-) > > Justin Fletcher > Vyatta > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From cshue@cs.indiana.edu Wed Apr 19 05:01:51 2006 From: cshue@cs.indiana.edu (Craig Shue) Date: Wed, 19 Apr 2006 00:01:51 -0400 Subject: [Xorp-hackers] Implementing reverse path filtering and packet marking In-Reply-To: <20060418051542.GD19647@juniks.net> References: <4444659C.5030506@cs.indiana.edu> <20060418051542.GD19647@juniks.net> Message-ID: <4445B62F.4010500@cs.indiana.edu> Kristian, > The code in the FEA section is only for traffic > actually destined for XORP, that is routing > protocol traffic and such. The actual forwarding > of traffic is not handled by XORP, it is done > inside the kernel. > Thus it is the kernel that should support the RPF > check. Linux already does this, please have a look > at /proc/sys/net/ipv4/conf/*/rp_filter This does make a lot more sense. I was suspecting that something like that was happening. Thank you for your help! -- Craig From pavlin@icir.org Thu Apr 20 09:22:44 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 20 Apr 2006 01:22:44 -0700 Subject: [Xorp-hackers] HEADS UP: "create" and "set" configuration commands are merged Message-ID: <200604200822.k3K8Miwr047396@possum.icir.org> Due to popular demand, the "create" and "set" configuration commands are merged, so now the new "set" command can be used for setting values and for creating new configuration nodes. (Strictly speaking, the new "set" command is actually the old "create" command which was already capable of setting values and creating new configuration nodes). For backward compatibility, the obsoleted "create" command is preserved as an alias for the new "set" command, though it may be removed in the future. This change is in XORP-current and will be in the forthcoming XORP-1.3 release. For details about the decision to merge those commands see the xorp-hackers email exchange with Subject: "BG 172": http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2006-March/thread.html and Bugzilla entry #172: http://www.xorp.org/bugzilla/show_bug.cgi?id=172 Please let me know if you find any issues because of this change. Pavlin From dave@vyatta.com Thu Apr 20 17:10:36 2006 From: dave@vyatta.com (Dave Roberts) Date: Thu, 20 Apr 2006 09:10:36 -0700 Subject: [Xorp-hackers] Re: [Xorp-users] HEADS UP: "create" and "set" configuration commands are merged In-Reply-To: <200604200822.k3K8Miwr047396@possum.icir.org> References: <200604200822.k3K8Miwr047396@possum.icir.org> Message-ID: <4447B27C.1030100@vyatta.com> And a great cheer went up in all the land, and there was feasting and revelry... ;-) -- Dave Pavlin Radoslavov wrote: > Due to popular demand, the "create" and "set" configuration > commands are merged, so now the new "set" command can be used for > setting values and for creating new configuration nodes. > > (Strictly speaking, the new "set" command is actually the old > "create" command which was already capable of setting values and > creating new configuration nodes). > > For backward compatibility, the obsoleted "create" command is > preserved as an alias for the new "set" command, though it may be > removed in the future. > > > This change is in XORP-current and will be in the forthcoming > XORP-1.3 release. > > For details about the decision to merge those commands see > the xorp-hackers email exchange with Subject: "BG 172": > http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2006-March/thread.html > > and Bugzilla entry #172: > http://www.xorp.org/bugzilla/show_bug.cgi?id=172 > > Please let me know if you find any issues because of this change. > > Pavlin > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From jfletcher@vyatta.com Thu Apr 20 18:19:20 2006 From: jfletcher@vyatta.com (Justin Fletcher) Date: Thu, 20 Apr 2006 10:19:20 -0700 (PDT) Subject: [Xorp-hackers] Patch for bug 312 BGP origin help submitted Message-ID: <9589483.61145553560293.JavaMail.root@mail.vyatta.com> > The patch is applied to CVS with minor modifications: > > 1.90 +4 -1; commitid: f4e244459bde7ea6; xorp/etc/templates/bgp.tp > > Now the help string is slightly shorter so it truly conforms to > the proposed CLI style guide :) > > [0..2] Origin attribute: 0 for IGP, 1 for EGP, 2 for incomplete > > > Thanks, > Pavlin I've updated my version of the patch so that we match, and better fit the style. Justin Fletcher Vyatta From jfletcher@vyatta.com Thu Apr 20 18:47:32 2006 From: jfletcher@vyatta.com (Justin Fletcher) Date: Thu, 20 Apr 2006 10:47:32 -0700 (PDT) Subject: [Xorp-hackers] Cli style guide draft Message-ID: <30139439.91145555252850.JavaMail.root@mail.vyatta.com> ------=_Part_0_22449018.1145555252846 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I've a few proposed additions; * Node names are all lower-case characters. * Existing commands are only changed after significant consideration. This will help preserve backwards compatibility of configuration files between releases. * Help for high level configuration commands begin with "Configure " Example: create protocols ? bgp Configure BGP options * Help for area options describe the available parameters. Example: create protocols bgp ? The changes are integrated into the attached version. Justin Fletcher Vyatta local-as Autonomous System (AS) number for this domain * Help for specific parameter configuration commands identify the value to be configured. Example: create protocols bgp local-as ? local-as Local AS number * Protocol acronyms are listed in upper case in short help strings. For example, use BGP instead of bgp. ------=_Part_0_22449018.1145555252846 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=cli-style.txt # # $XORP: xorp/devnotes/cli-style.txt,v 1.2 2006/04/19 05:59:32 pavlin Exp $ # Provisional XORP CLI coding style This is a *provisional* attempt to lay down some rules that we can adhere to when it comes to adding new CLI configuration statements or commands (or modifying existing ones). Note that each configuration node can have a "short" and a "long" help string. In the text below we use the terms "short help string" and "long help string" to differenciate between them. * Each configuration node should have a short help string. * A configuration node name SHOULD be less than 20 symbols long. The associated short help string SHOULD be less than 56 symbols long. The length of a configuration node name + its short help string MUST NOT exceed 76 symbols. This is to ensure that the output of possible completions would fit into 80 symbols wide terminal. In most of cases it's wrapping that makes the output look really bad. Both node names and short help strings should be concise. Node names are especially important. If it can be shortened below 20 symbols without loosing the point, it should be done. If it can't be done, OK, but these cases should be kept minimum. For example: restore-original-config-on-shutdown -> restore-system-conf enable-ip-router-alert-option-check -> router-alert-check * If a node name is composed of more than one word, use '-' to separate the words. For example: multicastcapable -> multicast-capable * Don't specify the units in the node names (e.g., sec or msec). This info should be in the short help string. For example: interpacket-delay-msecs Minimum delay between outbound RIPng packets. vs. interpacket-delay Minimum delay between outbound RIPng packets (msec) * Node names are all lower-case characters. * Existing commands are only changed after significant consideration. This will help preserve backwards compatibility of configuration files between releases. * Help for high level configuration commands begin with "Configure " Example: create protocols ? bgp Configure BGP options * Help for area options describe the available parameters. Example: create protocols bgp ? local-as Autonomous System (AS) number for this domain * Help for specific parameter configuration commands identify the value to be configured. Example: create protocols bgp local-as ? local-as Local AS number * Avoid "Set ...", "Edit ..." etc in the short help strings. A short help string should just describe the purpose of the particular variable or command. Using "Set" or "Edit" in the short help string can be logically wrong as well - variables and commands aren't always set, but sometimes deleted as well. For example: horizon Set the horizon type applied to routes announced on address. vs. horizon Horizon type applied to announced routes * Short help strings begin with capital letter and don't have a dot in the end. Just to make the look consistent. * Protocol acronyms are listed in upper case in short help strings. For example, use BGP instead of bgp. * Keep to minimum the number of parameters the user has to configure. For example, a timer with a jitter can be described as "some-timer-min" and "some-timer-max". If the user wants to change the timer value, he/she has to modify both parameters. Usually the user wants to modify only the average value of the timer. In this example, "some-timer" and "some-jitter" should be used instead, where "some-jitter" should have some reasonable default value (in percents rather than in absolute value). * Commands should describe what they do, not what they can be used for. For example, the purpose of the following command is not very clear: accept-non-rip-requests Answer RIP requests made from non-RIP processes It is better use following command and help string to describe it: source-port-check Answer RIP requests made only from RIP port Additional details about the command can be provided in the user documentation. ------=_Part_0_22449018.1145555252846-- From pavlin@icir.org Thu Apr 20 20:22:03 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 20 Apr 2006 12:22:03 -0700 Subject: [Xorp-hackers] Cli style guide draft In-Reply-To: Message from Justin Fletcher of "Thu, 20 Apr 2006 10:47:32 PDT." <30139439.91145555252850.JavaMail.root@mail.vyatta.com> Message-ID: <200604201922.k3KJM3U3053666@possum.icir.org> > I've a few proposed additions; > > * Node names are all lower-case characters. Agree. Also, I'd like to add the following: * Node names may include digits, but their usage should be limited, and should never be used as the first symbol. > * Existing commands are only changed after significant consideration. > > This will help preserve backwards compatibility of configuration files > between releases. This is not really a coding style, but more like a policy. Though, given there is no better place for it, maybe it should be added to the cli-style.txt document. > * Help for high level configuration commands begin with "Configure " > > Example: create protocols ? > > bgp Configure BGP options I prefer "BGP configuration" or "Configure BGP" or something similar, because "BGP options" may be ambiguous (i.e., it may have some protocol-specific meaning). FWIW, in JunOS the help strings at the protocol level are not consistent: some are "FOO options" while other are "FOO configuration" so we can choose the wording we like. > * Help for area options describe the available parameters. > > Example: create protocols bgp ? > > local-as Autonomous System (AS) number for this domain > > * Help for specific parameter configuration commands identify the value to be > configured. > > Example: create protocols bgp local-as ? > > local-as Local AS number Implementing something like the above two bullets would require associating two short help strings with each parameter, and I don't see the (significant) difference in the information they would provide. So I'd prefer there is a single short help string (as it is now). FYI, there is also a long help string that can be associated with each node, thought right now this string is not used (yet). > * Protocol acronyms are listed in upper case in short help strings. > > For example, use BGP instead of bgp. I would say that the protocol acronyms should follow the common convention: typically it is all upper (e.g., BGP), but sometimes it may include lower cases as well (e.g., VoIP). Pavlin From jfletcher@vyatta.com Thu Apr 20 21:02:19 2006 From: jfletcher@vyatta.com (Justin Fletcher) Date: Thu, 20 Apr 2006 13:02:19 -0700 (PDT) Subject: [Xorp-hackers] Cli style guide draft Message-ID: <30272224.241145563339749.JavaMail.root@mail.vyatta.com> > Agree. Also, I'd like to add the following: > > * Node names may include digits, but their usage should be limited, > and should never be used as the first symbol. Good addition. > > * Existing commands are only changed after significant > consideration. > > > > This will help preserve backwards compatibility of configuration > files > > between releases. > > This is not really a coding style, but more like a policy. > Though, given there is no better place for it, maybe it should be > added to the cli-style.txt document. True - but putting it here gives it a little visibility :-) > > * Help for high level configuration commands begin with "Configure > " > > > > Example: create protocols ? > > > > bgp Configure BGP options > > I prefer "BGP configuration" or "Configure BGP" or something > similar, because "BGP options" may be ambiguous (i.e., it may have > some protocol-specific meaning). > FWIW, in JunOS the help strings at the protocol level are > not consistent: some are "FOO options" while other are > "FOO configuration" so we can choose the wording we like. Yes, I've noticed the same about JunOS. Maybe they don't have a CLI style guide :-) I'm perfectly happy with "Configure BGP" or "Configure RIP" or "Configure RIP options" or something similar, as there is a consistent appearance to high-level commands for a major system area. It's likely you can't fully specify a help string where you just fill in , but this will give a start. > > * Help for area options describe the available parameters. > > > > Example: create protocols bgp ? > > > > local-as Autonomous System (AS) number for this domain > > > > * Help for specific parameter configuration commands identify the > value to be > > configured. > > > > Example: create protocols bgp local-as ? > > > > local-as Local AS number > > Implementing something like the above two bullets would require > associating two short help strings with each parameter, and I don't > see the (significant) difference in the information they would > provide. > So I'd prefer there is a single short help string (as it is now). > FYI, there is also a long help string that can be associated with > each node, thought right now this string is not used (yet). Whoops - I must not have been clear. Two help strings wasn't the intention - it's just a matter of making the help more and more precise as more parameters to the command are added, as in the examples for create protocols ? create protocols bgp ? create protocols bgp local-as Hmm - maybe that should simply say: * Help strings should become more precise as additional parameters are specified. > > * Protocol acronyms are listed in upper case in short help strings. > > > > For example, use BGP instead of bgp. > > I would say that the protocol acronyms should follow the common > convention: typically it is all upper (e.g., BGP), but sometimes it > may include lower cases as well (e.g., VoIP). Yup, yup. How about: * Protocol acronyms are listed using common conventions in short help strings, typically all upper case. Justin Fletcher Vyatta From pavlin@icir.org Fri Apr 21 01:03:41 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 20 Apr 2006 17:03:41 -0700 Subject: [Xorp-hackers] Cli style guide draft In-Reply-To: Message from Justin Fletcher of "Thu, 20 Apr 2006 13:02:19 PDT." <30272224.241145563339749.JavaMail.root@mail.vyatta.com> Message-ID: <200604210003.k3L03fx1057096@possum.icir.org> Now that we've reached an aggreement, I've added the new rules to the cli-style document. Also, now that we started adding policy rules for modifying the CLI commands, I added one more rule (originally suggested by Hasso some time ago in a Bugzilla comment): * If a command is changed (renamed, deleted or moved), the original command should be marked as "deprecated" (i.e., by using the "%deprecated" keyword in the rtrmgr template) and kept in the configuration tree for at least three major releases or 18 months (whichever comes later). For example, if a command is deprecated in Release-1.5, the deprecated state about that command can be removed in Release-1.8 (assuming there have been at least 18 months between those two releases). The particular details about this rule can be modified as appropriate. Pavlin From krn@krn.dk Sun Apr 23 15:26:23 2006 From: krn@krn.dk (Kristen Nielsen) Date: Sun, 23 Apr 2006 16:26:23 +0200 Subject: [Xorp-hackers] XORT-NAT: Proposal for NAT interface XIF and a config file syntaks In-Reply-To: <200603310214.k2V2E0pt046265@possum.icir.org> References: <200603310214.k2V2E0pt046265@possum.icir.org> Message-ID: <444B8E8F.3000103@krn.dk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Pavlin Thank you for commenting on my nat suggestion. I answer some of your questions below Kristen. Pavlin Radoslavov wrote: > [Note: a follow-up of an old email that was postponed for discussion > after the 1.2 release]. > > >>After a long time of considerations and working on specifying a >>configuratoin syntax and a XIF file for a NAT module, I am hereby >>sending this proposal to the list for comments. >> >>(Re my mail from oct 16 2005 with subject: NAT support for XORP) >> >> >>20060200-NAT-interface-descr.txt file contains the syntax and a few >>samples of use of the configuration format. >> >>The nat.xif file has kdoc documentation documenting the various >>functions and parameters. >> >>The idea is to provice a common interface for the NAT module, with a >>defined syntax, and then use either the native (FreeBSD natd/or the >>similar functionality in linux) daemon, or a click module, with a rule >>of thumb something like this: >> >>If the nat configuration is possible to implement with the native module >>this can be used, else the user must switch to the click nat module to >>achieve the wanted functionality. > > > The caveat with the above rule is that the user must have Click. > Currently, kernel-mode Click works only on Linux and some versions > of FreeBSD, and those systems already have native NAT support. > FYI, I believe user-mode Click works on a larger variety of systems > (I have been able to compile and use it as-is on Mac OS X), but > obviously you will get some performance penalty if you perform NAT > in user space Click. The upside of user-space Click NAT of course > would be that you don't have to modify your kernel and the > performance hit may be acceptable in most cases (you may want to do > some measurements here to prove this of course). OK - I later realized that the kernel module was (almost) silently left out when I compiled click on a FreeBSD Rel 6 machine. I have been working some time trying to port it to FreeBSD 6, as this gives me at reason to take a look at the FreeBSD networking system. For now I will have to leave it for some weeks. > > >>I have designed with the use of IP-realms (aka different ip domains) >>which I am aware of is not possible to use in the standard ip stack of >>Freebsd/Linux, but if one make configurations with non overlapping ip >>ranges it will actually be possible to implement theese in the existing >>kernel / ip stacks. The realm stuff is kept entirely in the nat config >>area of the config file. >> >>I would apreaciate comments on this, as I would like to continue >>planning and coding soon. >> >>I would also like to have ideas / comments about how to add more >>datatypes to the idl generator scripts. (for the port type, and an >>eventually ipv4-range type (which I here has made with 2 ipv4 ip-addresses.) > > > Can you clarify what you mean by "idl generator scripts". i mean the tgt-gen and clnt-gen in the xrl/scripts directory. > > If you need ipv4-range type support, there is rtrmgr template type > named "ipv4range" and "ipv6range" which has the syntax IPADDR..IPADDR. > E.g. see the policy section inside etc/templates/bgp.tp. I would also need some support for the "port" description language in the scripts (as far as I understand) Is this doable? > > Comments continuing below. > > >>Sincerely >>Mr. Kristen Nielsen >>University of Copenhagen >>Copenhagen >>Denmark >>kristen@diku.dk / krn@krn.dk >>phone +4540466221 (gmt -1) >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.2 (FreeBSD) >>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org >> >>iD8DBQFD+fVJe7tFxipD00wRApbiAJ9p3KmXx/FN7EUjdmMh7hi0szs4hgCgmTNb >>fzLck6xcwnqSfqA3uYgrphA= >>=wZHj >>-----END PGP SIGNATURE----- >> >>--------------040204020303010209060700 >>Content-Type: text/plain; >> name="20060220-NAT-interface-descr.txt" >>Content-Transfer-Encoding: 7bit >>Content-Disposition: inline; >> filename="20060220-NAT-interface-descr.txt" >> >>* Short description of the config file format for the xorp NAT module. >>* Examples of configurations with alike FreeBSD natd commandline. >>* Syntax of the port statement. >> >>protocols { >> nat { >> disable {disabled:bool} >> >> nat-realm { > > > Currently, the rtrmgr template syntax doesn't support multi-value > statements like the one above. You would have to break it into, say: > > nat-realm { > description: > > > >> interface vif { >> description >> default-vif-address: >> ip-address: >> tag: >> >> interface-alias { >> description: >> alias-address: /* alt to more interface-alias clauses */ >> tag: >> } >> } > > > The interface/vif statements need to be specified separately: > interface { > vif { > ... > } > ... > } > > > Also, note that we don't support a list of addresses, hence you may > want to specify all addresses with multi-value nodes like: > > interface { > vif { > address { > description: > tag: > } > } > ... > } > > > >> >> /* Address pool maps to the create/delete/get_nat_realm4 function) */ >> address-pool { >> description: >> ip-address: >> ip-range: - >> ipnet: >> tag: >> } >> } >> >> static-nat { >> map { >> description: >> source { >> realm: >> ip-address: >> ip-range: - >> ipnet: >> tag: >> port: >> } >> destination { >> realm: >> ip-address: >> ip-range: - >> ipnet: >> tag: >> port: >> } >> } >> } >> >> dynamic-nat { >> map { >> description: >> source { >> realm: >> ip-address: >> ip-range: - >> ipnet: >> tag: >> port: >> } >> destination { >> realm: >> ip-address: >> ip-range: - >> ipnet: >> tag: >> port: >> binding: >> >> } >> } >> >> ls-nat { >> map { >> description: >> source { >> realm: >> ip-address: >> ip-range: - >> ipnet: >> tag: >> port: >> } >> destination { >> realm: >> ip-address: >> ip-range: - >> ipnet: >> tag: >> port: >> } >> } >> } >> } >>} >> >> >>The "port:" parameter is used to set the ports in use for an actual translation. >>Syntax: >> >> ::= ports: >> ::= >> ::= [, ]... >> ::= | >> ::= tcp | udp >> ::= >>service-name ::= ... >>digits ::= ... >>digit ::= <0|1|2|3|4|5|6|7|8|9> >>letters ::= ... >>letter ::= >> >>Example: >> >>ports: tcp 22,33,44-55, udp 22,33,66-77, 88 > > > > The above syntax seems to me as tcp/udp centric and assumes the > particular protocol has the concept of a port. > This is not true for protocols like ICMP and GRE. > > OK See my comment later. > >>Sample configurations with similar FreeBSD natd mappings. >> >>The FreeBSD >> >>"natd -redirect_port tcp 172.17.16.15/telnet 6666" >> >>command with the global ip address equal to 80.10.10.10 is expressed in XORP NAT configuration files as: >> >>protocols { >> NAT { >> realm "global" { >> ip: 80.10.1010 >> } >> >> realm "local" { >> ip: 172.17.16.15 >> } >> static-map { >> source { ip-address: 80.10.10.10 >> ports: tcp 6666 >> } >> >> destination { >> ip-address: 172.17.16.15 >> ports: tcp telnet >> } >> } >> } >>} > > > > I would recommend to generalize the source and destination syntax by > separating the concept of protocol and port. Of course, for > protocols like tcp and udp you must have ports, so your syntax must > incorporate that too :) > I did this with NAT in my mind, but it seems naturally to come up with a more generic dexcription for this which can be used more generally in xorp. Do I understand you correct, that you would like a language that supports all possible protocols in the IP packet not only TCP, UDP. or do you also want the layer 2 protocols included in the language? I will look into this again and come up with a new suggestion. > > >>The configline: >>"natd -interface em0" >>Creation of a dynamic mapping from 172.17.16/24 to global address of em0 interface = ip 80.10.10.10 is expressed as: >> >>protocols { >> NAT{ >> realm "global" { >> ip: 80.10.10.10 >> tag "globalip" >> } >> >> realm "local" { >> ipnet: 172.17.16.0/24 >> tag: "localnet"} >> >> dynamic-map { >> source {tag: "localnet" >> } >> destination { >> tag: "globalip" >> } >> } >> } >>} >>Written by >>Kristen Nielsen >>Computer Science dept >>University of Copenhagen, Denmark >>kristen@diku.dk / KrN@KrN.dk >> >> >> >>--------------040204020303010209060700 >>Content-Type: text/plain; >> name="nat.xif" >>Content-Transfer-Encoding: 7bit >>Content-Disposition: inline; >> filename="nat.xif" >> >>/* xorp/xrl/interfaces/nat.xif file by KrN@KrN.DK 20060220 */ >>/* Suggestion to a nat interface for xorp. */ >> >> >>/* The following interfaces exists for the xorp nat module */ >> >> /** >> * Network address translation (NAT) interface. >> * The NAT module consists of the following configuration elements: >> * >> * set_nat_disable and get_nat_disable: >> * sets and returns the status of the nat module >> * >> * nat_realm: >> * Manages (creates/deletes/get) realms for use in nat mappings. >> * Before realms can be used in configurations, they must >> * be created. >> * >> * nat_realm_vif4: >> * Manages (creates/delete/lists) vif addresses for nat use >> * in nat mappings. >> * >> * nat_realm_alias4: >> * Manages (creates/deletes/lists) alias ipv4 addresses for vif >> * interfaces for use in nat mappings. >> * >> * nat_realm4: >> * Defines ip4 addresses, ip4 networks and ip4 address ranges >> * for use in nat mappings. Addresses are not directly connected >> * to any vif on the xorp router. Addresses are reachable >> * via the realm / vif interface stated. (This will probably be >> * changed to be the interface pointed out by the next-hop entry >> * in the rib.) >> * >> * nat_static_map4: >> * Defines static NAT table mappings >> * From the realm and ip definitions in the nat_realm_* group >> * Tcp and/or udp port definitions can be defined here. >> * >> * nat_dynamic_map4: >> * Defines dynamic NAT table mappings (triggers) >> * From the definitions in the nat_real_* group >> * Tcp and/or udp port definitions can be defined here. >> * >> * nat_lsnat_map4: >> * Defines Load Sharing NAT mappings >> * From the definitions in the nat_real_* group >> * Tcp and/or udp port definitions can be defined here. >> * >> */ >>interface nat/0.1 { >> >> /** >> * set nat disable (and enable) function >> * >> * @param disabled sets the status of the nat module true = disabled, >> * false = enabled >> * @param disabledstatus returns the status of the module, >> * true = disabled, false = enabled >> */ >> set_nat_disable ? disabled:bool -> disabledstatus:bool > > > What is the purpose of the returned disabledstatus? > If "set_nat_disable" returned success, then the status must be same > as the "disabled:bool" argument when the XRL was invoked. I believe that the returned success was a "the communication went through" kind of reply, and a no-success would indicate some kind of fatal fault. Did I misunderstand some of the docs? > BTW, stylistically, we prefer that longer names are separated > with, say, underscore: disabledstatus -> disabled_status :) > OK - no problem. (I guess this is a leftover from Danish :-) This is my last answer / comment in this mail. Kristen. > This is my last comment. Without going into details, the rest of the > XRLs seem reasonable. Though, if you change the NAT configuration > syntax quite likely you would have to change some of the XRLs as > well. > > Pavlin > > > >> /** >> * get nat status function >> * >> * @param disabledstatus returns the status of the module, (as the >> * set_nat_disable function) true = disabled, false = enabled >> */ >> get_nat_disable -> disabledstatus:bool >> >> >> /** >> * create_nat_realm - creates a nat realm. >> * >> * @param realm holds the name of the realm to be created. The name >> * must not exist when the call is made. >> * @param descr is the textual description of the realm. >> */ >> create_nat_realm ? realm:txt & descr:txt >> >> /** >> * delete_nat_realm - deletes a nat realm. >> * >> * @param realm holds the name of the realm to be deleted. The name >> * must exist when the call is made. >> */ >> delete_nat_realm ? realm:txt >> >> /** >> * get_nat_realm - lists nat realms. >> * >> * @param realm holds the name of the realm to be deleted. >> * If the parameter is NULL, all existing realms is returned. >> */ >> get_nat_realm ? realm:txt -> realms:list >> >> >> /** >> * create_nat_realm_vif4 - creates an entry for the base ipv4 address >> * of a virtual interface. >> * Any virtual interface can at most be a member of one realm. >> * Virtual interfaces must be in the same realm as the ip addresses >> * passing the vif interface. >> * >> * @param realm is an existing realm that the vif is mapped to. >> * @param ifname is the name of the physical interface where the >> * vif is defined. >> * @param vifname is the name of the virtual interface to be mapped. >> * @param tag is a textlabel that the mapping is labeled with. >> * @param description textual description of the mapping. >> */ >> create_nat_realm_vif4 ? realm:txt & ifname:txt & vifname:txt & \ >> tag:txt & description:txt >> >> /** >> * delete_nat_realm_vif4 - removes an entry for a base ipv4 (vif) >> * address of virtual interface from a nat realm. >> * The definitions matching all the supplied parameters is deleted. >> * Wild card parameters must be set to NULL. >> * >> * @param realm all vif4 definitions to this realm is deleted. >> * @param ifname all definitions with this ifname is deleted. >> * @param vifname all mappings to this vifname is deleted >> * @param tag all mappings with this tag is deleted. >> */ >> delete_nat_realm_vif4 ? realm:txt & ifname:txt & vifname:txt & \ >> tag:txt >> >> /** >> * update_nat_realm_vif4 - updates an existing vif mapping with its >> * new ipv4 address. >> * The vif4 mapping is updated when the vif get a new ipv4 address. >> */ >> update_nat_realm_vif4 ? ifname:txt & vifname:txt & ip:ipv4 >> >> /** >> * get_nat_realm_vif4 - lists nat_realm_vif4 definitions. >> * >> * get_nat_realm_vif4 returns a list of all nat_realm_vif4 >> * interfaces in the router matching the realm supplied. >> * @param realm specifies the realm to return interfaces for. >> * If NULL then all defined nat_realm_vif4 interfaces are returned. >> */ >> get_nat_realm_vif4 ? realm:txt -> nat_realm_vif4s:list >> >> >> /** >> * create_nat_realm_alias4 - creates a mapping to the nat_realm >> * definitions. Manipulates ipv4 address aliases of an interface >> * (vif) for in/out going nat gateways. Aliases are not the base >> * ipv4 address of the virtual interface, but ipv4 addresses in >> * the same subnet as the vif. (see nat_realm_vif) >> * >> * Any aliases, aliased to a vif must be in the same realm as the >> * vif itself. >> * >> * @param realm specifies the realm that the IP address belongs to. >> * @param ifname is the physical interfaces for this interface >> * @param vifname is the virtual interface name to add this alias to. >> * @param tag is a label for grouping definitions. >> * @param description is a textual description of this alias. >> * @param ipaddr is the ipv4 alias address added to the vif. >> */ >> create_nat_realm_alias4 ? realm:txt & ifname:txt & vifname:txt & \ >> tag:txt & description:txt & ipaddr:ipv4 >> >> >> /** >> * delete_realm_alias4 function >> * Deletes ipv4 realm_alias4 address from the virtuel interface (vif). >> * >> * The alias4 mappings matching the supplied parameters are deleted. >> * Parameters that are not defined (=not matched against) must be NULL. >> * >> * @param realm the alias4 mappings in the same realm is deleted. >> * @param ifname all alias4 mappings defined for this interface is >> * deleted. >> * @param vifname all alias4 mappings defined under this vif is >> * deleted. >> * @param tag all alias4 mappings with tag is deleted. >> * @param ipaddr the alias4 mapping with this ipv4 address is deleted. >> */ >> delete_nat_realm_alias4 ? realm:txt & ifname:txt & vifname:txt & \ >> tag:txt & ipaddr:ipv4 >> >> /** >> * get_nat_realm_alias4 returns a nat_realm_alias4 list with matching >> * alias4 elements. Wildcard parameters shuld be set to NULL. >> * >> * @param realm specifies the realm of the alias4 addresses to be >> * returned. >> * @param ifname specifies the physical interfaces to match. >> * @param vifname specifies the virtual interfaces to match. >> * @param tag specifies the tag of the definitions to match. >> * @param ipaddr specifies the ipv4 addr of the alias4 to match. >> * @param nat_realm_alias4s is the list of the matching aliases >> * defined. >> */ >> get_nat_realm_alias4 ? realm:txt & ifname:txt & vifname:txt & \ >> tag:txt & ipaddr:ipv4 \ >> -> nat_realm_alias4s:list >> >> /** >> * create_nat_realm - create definitions of ipv4 addresses/ipv4/ >> * networks/ipv4 ip ranges to the nat_realm list. >> * >> * The ipv4 addresses / ipv4 networks / ipv4 address ranges / tagged >> * list of definitions, are all ip-addresses not directly attached >> * to any physical/virtual interface on the xorp router. >> * >> * The function have the following way of interpreting the address >> * arguments: >> * All function calls must have theese parameters defined: >> * , where realm specifies the actural realm. >> * ifname and vifname the interfaces to route these addresses through. >> * (If the ifname and vifname is possible to acquire via the routing >> * info, these parameters might disappear during implementation) >> * >> * To specify a tag for the definition, supply the parameter. >> * >> * To specify an single ipv4 address supply ONLY the parameter. >> * >> * To specify an ipv4 network supply ONLY the parameter. >> * >> * To specify an ipv4 range supply ONLY the and parameters. >> * is the lowest ip address and ipto is the highest ip address >> * in the range. >> * >> * The 3 types of definitions above can not be mixed in a single call >> * to the function. Grouping is done with defining more of the 3 >> * first classes with the same tag. >> * >> * create_nat_realm4 create an ipv4 address/ipv4network/ipv4-range/tag >> * at the nat map list. >> * >> * @param realm specifies the realm to which the mapping belong. >> * @param tag maps the definition with this tag. >> * @param description a textual description of this alias. >> * @param ip is the ip address or the lowest bound of an ip range. >> * @param ipto is the highest bound of a range. >> * @param ipnet specifies an ipv4 network (ip address + subnetmask) >> */ >> create_nat_realm4 ? realm:txt & \ >> tag:txt & description:txt & \ >> ip:ipv4 & ipto:ipv4 & \ >> ipnet:ipv4net >> >> /** >> * delete_nat_realm4 deletes all nat_realm4 mappings, matching >> * all supplied parameters. Wild card parameters must be set to NULL. >> * (For further doc see add_nat_realm4) >> * >> * @param realm all nat_realm4 with this realm is deleted. >> * @param tag all nat_realm4 definitions with this tag is deleted. >> * @param ip the ipv4 address mapping is deleted. (see ipto param too) >> * @param ipto the range defined together with the ip parameter is >> * deleted. >> * @param ipnet the ipv4network defined is deleted. >> * >> * If more parameters are defined, only the definitions that match >> * ALL the supplied parameters is deleted. >> */ >> delete_nat_realm4 ? realm:txt & \ >> tag:txt & \ >> ip:ipv4 & ipto:ipv4 & \ >> ipnet:ipv4net >> >> /** >> * get_nat_realm4 function - returns the list of defined elements >> * that matches the supplied parameters. >> * (For further doc on the use see add_nat_realm4 the doc.) >> * Wildcard parameters must be set to NULL. >> * >> * @param realm returns the list of realm4 definitions for this realm. >> * @param tag returns the list of definitions tagged with this tag. >> * @param ip returns the list of definitions with this ipv4 address. >> * @param ipto returns the list of definitions with this ipv4 range. >> * @param ipnet returns the list of ipv4 networks defined. >> * @param nat_realm4s is a list of the matched definitions. >> */ >> get_nat_realm4 ? realm:txt & \ >> tag:txt & description:txt & \ >> ip:ipv4 & ipto:ipv4 & \ >> ipnet:ipv4net -> nat_realm4s:list >> >> /** >> * create_nat_static_map4 >> * >> * create_nat_static_map4 - defines static NAT table entries from the >> * ip definitions from the nat_realm* functions. >> * >> * The nat_static_map functions defines static nat mappings between >> * ip addresses at the source side realm and the ip addresses of >> * the destination side realm. >> * If the ip sizes of the ranges on either side of the mapping is not >> * equal, then the mappings must go from the source side realm >> * (aka local realm) to the destination side realm (aka global realm). >> * ip addresses that is used for TCP/UDP port mapping >> * (port overloading) must always be defined at the destination side. >> * >> * The nat_static_map function has more sub functions dependent of >> * the supplied parameters. The parameters can define either a single >> * ip address, a contiguous range of ip addresses or a sub net, or a >> * tagged set of definitions. The ip addresses and realm used in a map >> * statement must be defined in a nat_realm* clause. >> * The source and destination side of a mapping can take all 4 forms >> * from the following definitions. >> * >> * To specify a single ip address the ip parameter is used. The >> * ipto paramter must be NULL. >> * >> * To specify a contiguous range of IP addresses, the ip and ipto >> * parameters are used. The ipnet parameter must be NULL. >> * >> * To specify an ipnetwork, the ipnet parameters must be specified. >> * The ipnet takes a subnet-address and a submet-mask. The ip and ipto >> * parameters must be NULL. >> * >> * To use a tag from the nat_realm definitions, specify the tag at >> * the tag parameter. The ip, ipto and ipnet parameters must be NULL. >> * >> * @param srcrealm specifies the realm for the source side of the map. >> * >> * @param destrealm specifies the realm for the destination side >> * of the map. >> * >> * @param srcip is the ipv4 source ip address of a mapping. >> * >> * @param srcipto is the source ipv4 address that forms the upper >> * bound of an ip range. >> * >> * @param srcipnet is the ipv4 network which forms the source mapping. >> * bound of an ip range. >> * >> * @param srctag maps all nat_realm definitions with the same tag as >> * the source definition. >> * >> * @param srcport is the range of ports used to this mapping. >> * >> * @param destip is the ipv4 destination address of the mapping >> * >> * @param destipto is the ipv4 address that forms the upper bound of >> * the destination ip range. >> * >> * @param destipnet is the ipv4 network that is the destination ip >> * addresses for the mapping. >> * >> * @param desttag maps all nat_realm definitions with the same tag as >> * the destination definition. >> * >> * @param destport is a list of tcp and/or udp ports used at the >> * destination addresses. >> * >> */ >> create_nat_static_map4 ? description:txt & \ >> srcrealm:txt & \ >> srcip:ipv4 & srcipto:ipv4 & \ >> srcipnet:ipv4net & \ >> srctag:txt & \ >> srcport:ipv4ports & \ >> destrealm:txt & \ >> destip:ipv4 & destipto:ipv4 & \ >> destipnet:ipv4net & \ >> desttag:txt & \ >> destport:ipv4ports >> >> /** >> * delete_nat_static_map4 >> * >> * delete_nat_static_map4 - delete static nat table entries from the >> * ip definitions from the nat_static_map4 functions. >> * >> * The function deletes the nat_static_map4 entries that matches >> * all the supplied parameters. (for more information about the >> * interfaces see create_nat_static_map4 documentation) >> * >> * The selected ranges must be fully matching sets from the >> * create_nat_static_map4 definition. No internal ranges can be deleted. >> * >> * @param srcrealm specifies the source realm to be deleted. All >> * nat_static_map4 definitions with the same realm is selected. >> * >> * @param destrealm specifies the realm for the destination side >> * to be deleted. All nat_static_map4 definitions with the same realm >> * is selected. >> * >> * @param srcip is the ipv4 source ip address to be deleted. >> * >> * @param srcipto is together with the srcip parameter defines the >> * source ip range to be deleted. >> * >> * @param srcipnet is the ipv4 network source mapping to be deleted. >> * >> * @param srctag maps selects the source tags to be deleted. >> * >> * @param srcport is the range of tcp and/or udp ports to be deleted. >> * >> * @param destip is the ipv4 destination address to be deleted. >> * >> * @param destipto is together with the destip parameter defines >> * the destination ip range to be deleted. >> * >> * @param destipnet is the ipv4 network to be deleted. >> * >> * @param desttag maps defines the destination tags to be deleted. >> * >> * @param destport is a list of tcp and/or udp ports to be deleted. >> */ >> delete_nat_static_map4 ? srcrealm:txt & \ >> srcip:ipv4 & srcipto:ipv4 & \ >> srcipnet:ipv4net & \ >> srctag:txt & \ >> srcport:ipv4ports & \ >> destrealm:txt & \ >> destip:ipv4 & destipto:ipv4 & \ >> destipnet:ipv4net & \ >> desttag:txt & \ >> destport:ipv4ports >> >> /** >> * get_nat_static_map4 - lists nat_static_map4 entries. >> * >> * get_nat_static_map4 - lists static NAT table entries that matches >> * the supplied parameters. >> * >> * The function deletes the nat_static_map4 entries that is matches >> * all the supplied parameters. >> * (for more information about the interfaces see >> * create_nat_static_map4 documentation) >> * >> * @param srcrealm specifies the source realm to be listed. >> * >> * @param destrealm specifies the realm for the destination side >> * to be listed. >> * >> * @param srcip is the ipv4 source ip address to be listed. >> * >> * @param srcipto is together with the srcip parameter defines the >> * source ip range to be listed. >> * >> * @param srcipnet is the ipv4 network source to be listed. >> * >> * @param srctag maps selects the srctags to be listed. >> * >> * @param srcport is the range of tcp and/or udp ports to be delted. >> * >> * @param destip is the ipv4 destination address to be listed. >> * >> * @param destipto is together with the destip parameter defines >> * the destination ip range to be listed. >> * >> * @param destipnet is the ipv4 network to be listed. >> * >> * @param desttag maps defines the destination tags to be listed. >> * >> * @param nat_static_map4s contains the list of matched elements. >> * >> * @param destport is a list of tcp and/or udp ports to be matched. >> */ >> get_nat_static_map4 ? description:txt & \ >> srcrealm:txt & \ >> srcip:ipv4 & srcipto:ipv4 & \ >> srcipnet:ipv4net & \ >> srctag:txt & \ >> srcport:ipv4ports & \ >> destrealm:txt & \ >> destip:ipv4 & destipto:ipv4 & \ >> destipnet:ipv4net & \ >> destport:ipv4ports & \ >> desttag:txt -> nat_static_map4s:list >> >> >> /** >> * create_nat_dynamic map definitions. >> * >> * The nat_static_map functions defines static mappings between >> * IP addresses at the source side realm and the IP addresses of >> * the destination side realm. >> * If the IP sizes of the ranges on either side is not equal, >> * then the mappings must go from the source side realm >> * (aka local realm) and the destination side realm (aka global realm). >> * IP addresses that is used for TCP/UDP port mapping >> * (port overloading) must be defined on the destination side. >> * >> * @param srcrealm specify the network realm for the source part >> * of the mapping. >> * >> * @param srctag maps the nat_realm* definitions with this tag as >> * the source side of the mapping. The tagged definitions must belong >> * to the same realm as stated in srcrealm. If the special meaning >> * tag "all" is given then all the definitions in the nat_realm >> * with the same realm as stated in srcrealm is matched. >> * >> * Src or dest definitions defults to "all" which is all addresses >> * in the matching (src/dest) realm as defined in nat_realm_* group. >> * >> * @param srcip is the ipv4 source ip address of a mapping. >> * >> * @param srcipnet is the ipv4 network which forms the source mapping. >> * >> * @param scrip is the source ipv4 address that forms the lower bound >> * of an ip range. >> * >> * @param srcipto is the source ipv4 address that forms the upper >> * bound of an ip range. >> * >> * @param srcport is the range of tcp and/or udp ports to be used in >> * the mapping. >> * >> * @param destip is the ipv4 destination address of the mapping >> * >> * @param destipnet is the ipv4 network that is the destination ip >> * addresses for the mapping. >> * >> * @param destip is the ipv4 address that forms the lower bound of the >> * destination ip range. >> * >> * @param destipto is the ipv4 address that forms the upper bound of >> * the destination ip range. >> * >> * @param desttag maps the nat_realm* definitions with this tag as >> * the destination side of the mapping. The tagged definitions must >> * belong to the same realm as stated in srcrealm. If the special >> * meaning tag "all" is given then all the definitions in the nat_realm >> * with the same realm as stated in srcrealm is matched. >> * >> * @param destport is a list of tcp and/or udp ports to use for the >> * dynamic mapping. >> * >> * @param binding This argument can be "dynamic" (default) or "fixed" >> * Dynamic can be a new mapping each time the mapping is used for a >> * new connection (from src side). "fixed" is using the same source >> * and destination mapping each time the src ip/port is connecting. >> */ >> create_nat_dynamic_map4 ? description:txt & \ >> srcrealm:txt & \ >> srcip:ipv4 & srcipto:ipv4 & \ >> srcipnet:ipv4net & \ >> srctag:txt & \ >> srcport:ipv4ports & \ >> destrealm:txt & \ >> destip:ipv4 & destipto:ipv4 & \ >> destipnet:ipv4net & \ >> desttag:txt & \ >> destport:ipv4ports & \ >> binding:txt >> >> /** >> * delete_nat_dynamic_map4 >> * >> * The delete_nat_dynamic_map4 function deletes the elements from the >> * nat_dynamic_map4 table that matches the supplied parameters. >> * >> * @param srcrealm matches source realm parameter of mappings. >> * >> * @param srctag matches the source tag paramter of the mappings to >> * be deleted. >> * If the special meaning tag "all" is given then all the definitions >> * with this tag on the source side is matched. With the same realm >> * as stated in srcrealm is matched. >> * >> * @param srcip matches the ipv4 source ip, or the lower bound of an >> * ipv4 ip-range to be deleted. >> * >> * @param srcipto matches the source ipv4 address that forms the upper >> * bound of an ip range to be deleted. >> * >> * @param srcipnet matches the source ipv4 network to be deleted. >> * >> * @param srcport is the tcp and/or udp port range to be deleted. >> * >> * @param destip matches the ipv4 destination address of the mapping >> * or the ipv4 address that forms the lower bound of the destination >> * ip range. >> * >> * @param destipto matches the destination ipv4 address to be deleted. >> * >> * @param destipnet matches the destination ipv4 network. >> * >> * @param desttag maps the mappings with this tag as the destination >> * side of the mapping. The tagged definitions must belong to the >> * same realm as stated in srcrealm. If the special >> * meaning tag "all" is given then all the definitions in the >> * nat_dynamic_realm with the same source realm as stated in srcrealm >> * is matched. >> * >> * @param destport is a list of tcp and/or udp ports to be deleted. >> * >> * @param binding This argument can be "dynamic" (default) or "fixed" >> * Dynamic can be a new mapping each time the mapping is used for a >> * new connection (from src side). "fixed" is using the same source >> * and destination mapping each time the src ip/port is connecting. >> */ >> delete_nat_dynamic_map4 ? srcrealm:txt & \ >> srcip:ipv4 & srcipto:ipv4 & \ >> srcipnet:ipv4net & \ >> srctag:txt & \ >> srcport:ipv4ports & \ >> destrealm:txt & \ >> destip:ipv4 & destipto:ipv4 & \ >> destipnet:ipv4net & \ >> desttag:txt & \ >> destport:ipv4ports & \ >> binding:txt >> >> /** >> * get_nat_dynamic_map4 >> * >> * The get_nat_dynamic_map4 function returns the elements from the >> * nat_dynamic_map4 table that matches all the supplied parameters. >> * >> * @param srcrealm matches source realm parameter of the mappings. >> * >> * @param srctag matches the source tag parameter of the mappings. >> * If the special meaning tag "all" is given then all the definitions >> * with this tag on the source side is matched. With the same realm >> * as stated in srcrealm is matched. >> * >> * @param srcip matches the ipv4 source ip, or the lower bound of an >> * ipv4 ip-range. >> * >> * @param srcipto matches the source ipv4 address that forms the upper >> * bound of an ip range. >> * >> * @param srcipnet matches the source ipv4 network. >> * >> * @param srcport is the tcp and/or udp range to be returned. >> * >> * @param destip matches the ipv4 destination address of the mapping >> * or the ipv4 address that forms the lower bound of the destination >> * ip range. >> * >> * @param destipto matches the destination ipv4 address. >> * >> * @param destipnet matches the destination ipv4 network. >> * >> * @param desttag maps the mappings with this tag as the destination >> * side of the mapping. The tagged definitions must belong to the >> * same realm as stated in srcrealm. If the special >> * mening tag "all" is given then all the definitions in the >> * nat_dynamic_realm with the same source realm as stated in srcrealm >> * is matched. >> * >> * @param destport is a list of tcp and/or udp ports to be returned. >> * >> * @param binding This argument can be "dynamic" (default) or "fixed" >> * Dynamic can be a new mapping each time the mapping is used for a >> * new connection (from src side). "fixed" is using the same source >> * and destination mapping each time the src ip/port is connecting. >> */ >> get_nat_dynamic_map4 ? description:txt & \ >> srcrealm:txt & \ >> srcip:ipv4 & srcipto:ipv4 & \ >> srcipnet:ipv4net & \ >> srctag:txt & \ >> srcport:ipv4ports & \ >> destrealm:txt & \ >> destip:ipv4 & destipto:ipv4 & \ >> destipnet:ipv4net & \ >> desttag:txt & \ >> destport:ipv4ports & \ >> binding:txt -> nat_dynamic_map4s:list >> >> >> >> /** >> * lsnat_map functions - define Load Sharing NAT (LSNAT) functionality. >> * >> * lsnat_map defines hosts at the destination side which is to be >> * loadshared when accesses via a common global address and port, >> * defined at the source side. >> * >> * The lsnat_map function has a range of ways to define ipv4 addresses, >> * ipv4 networks and ipv4 ip address ranges. >> * The parameters can define either a single ip address, a contigous >> * range of IP addresses or a subnet, or a tag. >> * The source and destination side of a mapping can each take all >> * 4 forms. >> * >> * To specify an single ip address the ip parameter is used. The >> * ipto paramter must be NULL. >> * >> * To specify a contiguous range of IP addresses, the ip and ipto >> * parameters are used. The ipnet parameter must be NULL. >> * >> * To specify an ipnetwork, the ipnet parameters must be specified. >> * The ipnet takes a sub net-address and a sub net-mask. The ip and ipto >> * parameters must be NULL. >> * >> * To use a named tag from the nat_realm definitions, specify the tag >> * at the tag parameter. The ip, ipto and ipnet parameters must be >> * NULL. Tags with the special value "all" matches all defined >> * addresses in the same realm as the tag. >> * >> * @param srcrealm defines which realm the source addresses belongs >> * to. The common ip addresses to access the load shared services must >> * be load shared must be connected to the source side of the map. >> * >> * @param destrealm defines which realm the destination addresses >> * belongs to (host network realm). The ip addresses of the hosts >> * with the services to be load shared is on this realm. >> * >> * @param srcip is the ipv4 source ip address of a mapping. >> * >> * @param srcipto is the source ipv4 address that forms the upper >> * bound of an ip range. >> * >> * @param srcipnet is the ipv4 network which forms the source mapping. >> * bound of an ip range. >> * >> * @param srctag maps all nat_realm definitions with the same tag as >> * the source definition. The special tag value "all" matches all >> * definitions from the nat_realm with the same realm. >> * >> * @param srcport is the list of tcp and/or udp ports to created. >> * >> * @param destip is the ipv4 destination address of the mapping >> * >> * @param destipto is the ipv4 address that forms the upper bound of >> * the destination ip range. >> * >> * @param destipnet is the ipv4 network that is the destination ip >> * addresses for the mapping. >> * >> * @param desttag maps all nat_realm definitions with the same tag as >> * the destination definition. The special tag value "all" matches all >> * definitions from the nat_realm with the same realm. >> * >> * @param destport is the tcp and/or udp port to load share. >> * >> * @param lsalgorithm defines the load sharing algorithm, and takes >> * the values: round-robin, random, (more ?), ... >> * >> */ >> >> /** >> * create_lsnat_map4 function - >> * Creates a lsnat_map4 table entry to the nat mappings. >> */ >> create_lsnat_map4 ? description:txt & \ >> srcrealm:txt & \ >> srcip:ipv4 & srcipto:ipv4 & \ >> srcipnet:ipv4net & \ >> srctag:txt & \ >> srcport:ipv4ports & \ >> destrealm:txt & \ >> destip:ipv4 & destipto:ipv4 & \ >> destipnet:ipv4net & \ >> desttag:txt & \ >> destport:ipv4ports & \ >> lsalgorithm:txt >> >> /** >> * delete_lsnat_map4 function - >> * Deletes the lsnat_map4 tableentries from the nat mappings that >> * matches all the defined parameters. >> */ >> delete_lsnat_map4 ? srcrealm:txt & \ >> srcip:ipv4 & srcipto:ipv4 & \ >> srcipnet:ipv4net & \ >> srctag:txt & \ >> srcport:ipv4ports & \ >> destrealm:txt & \ >> destip:ipv4 & destipto:ipv4 & \ >> destipnet:ipv4net & \ >> desttag:txt & \ >> destport:ipv4ports & \ >> >> /** >> * get_lsnat_map4 function - >> * Lists lsnat_map4 table entries that matches all the defined the >> * parameters. >> */ >> get_lsnat_map4 ? description:txt & \ >> srcrealm:txt & \ >> srcip:ipv4 & srcipto:ipv4 & \ >> srcipnet:ipv4net & \ >> srctag:txt & \ >> srcport:ipv4ports & \ >> destrealm:txt & \ >> destip:ipv4 & destipto:ipv4 & \ >> destipnet:ipv4net & \ >> desttag:txt & \ >> destport:ipv4ports & \ >> lsalgorithm:txt -> lsnat_map4s:list >>} >> >> >> >>--------------040204020303010209060700-- >>_______________________________________________ >>Xorp-hackers mailing list >>Xorp-hackers@icir.org >>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFES46Ne7tFxipD00wRAsKFAJ990gnrrXk2bFrgIIPhLuYdY5CNiwCeOGaP LAsRagYNi5h9CCMdTQp3uDg= =4j9z -----END PGP SIGNATURE----- From pavlin@icir.org Sun Apr 23 20:51:42 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 23 Apr 2006 12:51:42 -0700 Subject: [Xorp-hackers] XORT-NAT: Proposal for NAT interface XIF and a config file syntaks In-Reply-To: Message from Kristen Nielsen of "Sun, 23 Apr 2006 16:26:23 +0200." <444B8E8F.3000103@krn.dk> Message-ID: <200604231951.k3NJpgXm008554@possum.icir.org> > >>I would also like to have ideas / comments about how to add more > >>datatypes to the idl generator scripts. (for the port type, and an > >>eventually ipv4-range type (which I here has made with 2 ipv4 ip-addresses.) > > > > > > Can you clarify what you mean by "idl generator scripts". > > i mean the tgt-gen and clnt-gen in the xrl/scripts directory. > > > > > If you need ipv4-range type support, there is rtrmgr template type > > named "ipv4range" and "ipv6range" which has the syntax IPADDR..IPADDR. > > E.g. see the policy section inside etc/templates/bgp.tp. > > I would also need some support for the "port" description language in > the scripts (as far as I understand) Is this doable? If the "port" type you need is just 16-bit wide integer, you could just reuse the existing i32 or u32 types (the 32-bit wide integers). Then, inside the rtrmgr template you can add "%allow-range" command to restrict the allowed values in the [0, 65535] interval. > > I would recommend to generalize the source and destination syntax by > > separating the concept of protocol and port. Of course, for > > protocols like tcp and udp you must have ports, so your syntax must > > incorporate that too :) > > > I did this with NAT in my mind, but it seems naturally to come up with a > more generic dexcription for this which can be used more generally in xorp. > > Do I understand you correct, that you would like a language that > supports all possible protocols in the IP packet not only TCP, UDP. > > or do you also want the layer 2 protocols included in the language? I had in mind the IP protocols. E.g., if you have a field to specify "tcp" or "udp", then this field should be generic to specify the IP protocol (including "tcp" and "udp"). Of course, then the TCP/UDP application port would be applicable only for the tcp/udp protocols. I'd recommend to have a look into existing NAT languages such as ipnat(5) from FreeBSD or the Juniper NAT configuration: http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-services/frameset.htm FYI, in general we have the tendency to use configuration statements that are similar to Juniper. Hence, you may want to start with the Juniper syntax and improve it where you find necessary. > >>interface nat/0.1 { > >> > >> /** > >> * set nat disable (and enable) function > >> * > >> * @param disabled sets the status of the nat module true = disabled, > >> * false = enabled > >> * @param disabledstatus returns the status of the module, > >> * true = disabled, false = enabled > >> */ > >> set_nat_disable ? disabled:bool -> disabledstatus:bool > > > > > > What is the purpose of the returned disabledstatus? > > If "set_nat_disable" returned success, then the status must be same > > as the "disabled:bool" argument when the XRL was invoked. > > I believe that the returned success was a "the communication went > through" kind of reply, and a no-success would indicate some kind of > fatal fault. > Did I misunderstand some of the docs? The XRL mechanism provides return status for every XRL invoked. E.g., XrlCmdError::OKAY() indicates success, XrlCmdError::COMMAND_FAILED() indicates failure in processing the command, etc. See libxipc/xrl_error.hh for list of all XRL error codes. Regards, Pavlin From jfletcher@vyatta.com Wed Apr 26 03:00:34 2006 From: jfletcher@vyatta.com (Justin Fletcher) Date: Tue, 25 Apr 2006 19:00:34 -0700 (PDT) Subject: [Xorp-hackers] Possible fix for XORP bug 603 Message-ID: <2834205.981146016834922.JavaMail.root@mail.vyatta.com> You may get an invalid <[Enter]> and | options in help, as in: DUT-2> show ospf4 ? Possible completions: <[Enter]> Execute this command <==***Should not be displayed*** database Show LSA database neighbor Show Neighbors | Pipe through this command <==***Should not be displayed*** As these command fail with "ERROR: no matching command" if the command is executed, I've come up with possible fix which only displays these options if the command is valid, using the same mechanism as that which generated the error message in the first place. In cli_client.cc, add the command validation: --- cli_client.cc.bak 2006-04-25 02:13:13.000000000 +0000 +++ cli_client.cc 2006-04-25 02:16:25.000000000 +0000 @@ -35,6 +35,10 @@ #include "cli_command_pipe.hh" #include "cli_private.hh" +#include "rtrmgr/op_commands.hh" + +extern OpCommandList* ocl; + #ifdef HOST_OS_WINDOWS #define isatty(x) (x).is_console() #endif @@ -1315,6 +1319,7 @@ word_end--; // XXX: exclude the '?' character bool can_execute = false, can_pipe = false; + bool cmd_valid = false; // Is command valid? list::iterator iter; for (iter = curr_cli_command->child_command_list().begin(); iter != curr_cli_command->child_command_list().end(); @@ -1326,13 +1331,25 @@ is_found = true; } if (is_found) { + + // Is command valid? + + // Build temporary command with '?' stripped off + + string command_name = line; + command_name.erase(word_end - 1, 2); + cout << "command_name: '" << command_name << "'" << endl; + if (ocl->op_command_valid(command_name)) { + cmd_valid = true; + } + cli_print("\nPossible completions:\n"); - if (can_execute) { + if (can_execute && cmd_valid) { cli_print(c_format(" %-15s %s\r\n", "<[Enter]>", "Execute this command")); } cli_print(command_help_string); - if (can_pipe) { + if (can_pipe && cmd_valid) { cli_print(c_format(" %-15s %s\r\n", "|", "Pipe through this command")); } and add the validator functions to op_commands: --- op_commands.hh.bak 2006-04-25 02:21:50.000000000 +0000 +++ op_commands.hh 2006-04-25 02:22:58.000000000 +0000 @@ -206,6 +206,7 @@ void set_slave_config_tree(SlaveConfigTree* sct) { _slave_config_tree = sct; } bool check_variable_name(const string& variable_name) const; OpCommand* find_op_command(const list& command_parts); + bool op_command_valid(const string& command_name); OpCommand* add_op_command(const OpCommand& op_command); bool command_match(const list& command_parts, bool exact_match) const; --- op_commands.cc.bak 2006-04-25 02:20:43.000000000 +0000 +++ op_commands.cc 2006-04-25 02:20:16.000000000 +0000 @@ -696,6 +696,17 @@ } bool +OpCommandList::op_command_valid(const string& command_name) +{ + list::const_iterator iter; + for (iter = _op_commands.begin(); iter != _op_commands.end(); ++iter) { + if ((*iter)->command_name() == command_name) + return true; + } + return false; +} + +bool OpCommandList::command_match(const list& command_parts, bool exact_match) const { Finally, there's a global variable to tie the two together: --- xorpsh_main.cc.bak 2006-04-25 02:25:47.000000000 +0000 +++ xorpsh_main.cc 2006-04-25 02:27:27.000000000 +0000 @@ -72,6 +72,7 @@ static void signal_handler(int signal_value); static void exit_handler(CliClient*); +OpCommandList *ocl; // Global command list static void announce_waiting() @@ -892,6 +893,7 @@ string xname = "xorpsh" + c_format("-%d-%s", getpid(), hostname); XorpShell xorpsh(eventloop, xname, xorp_binary_root_dir(), template_dir, xrl_targets_dir, verbose); + ocl = xorpsh.op_cmd_list(); xorpsh.run(commands); } catch (const InitError& e) { XLOG_ERROR("xorpsh exiting due to an init error: %s", e.why().c_str()); What I don't like about this is that it requires a global variable to access the command list from the help function. What I do like about this is that it works! Suggestions? Alternatives? Just do it? :-) Justin Fletcher Vyatta From pavlin@icir.org Thu Apr 27 06:30:07 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 26 Apr 2006 22:30:07 -0700 Subject: [Xorp-hackers] HEADS UP: Mailman upgrade this Saturday (April 29th) Message-ID: <200604270530.k3R5U7IH065668@possum.icir.org> All, This Saturday (April 29th) the ICSI administrators are going to upgrade the Mailman software on the server that manages all XORP mailing lists. Please don't send any emails during the update to any of the XORP MLs. Also, please postpone any subscription related changes (preferences, unsubscribe requests, etc) until the upgrade is completed. I will send another email after everything is back to normal. There is chance that right after the upgrade some of the Mailman configuration options may be reset. This may result in some unwanted spam. If this happens we should fix the problem promptly. In the mean time please have some patience. Thank you, Pavlin From pavlin@icir.org Thu Apr 27 21:25:08 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 27 Apr 2006 13:25:08 -0700 Subject: [Xorp-hackers] Possible fix for XORP bug 603 In-Reply-To: Message from Justin Fletcher of "Tue, 25 Apr 2006 19:00:34 PDT." <2834205.981146016834922.JavaMail.root@mail.vyatta.com> Message-ID: <200604272025.k3RKP8R8073082@possum.icir.org> > You may get an invalid <[Enter]> and | options in help, as in: > > DUT-2> show ospf4 ? > Possible completions: > <[Enter]> Execute this command <==***Should not be displayed*** > database Show LSA database > neighbor Show Neighbors > | Pipe through this command <==***Should not be displayed*** > > As these command fail with "ERROR: no matching command" if the > command is executed, I've come up with possible fix which only > displays these options if the command is valid, using the same > mechanism as that which generated the error message in the first > place. > > In cli_client.cc, add the command validation: > and add the validator functions to op_commands: > Finally, there's a global variable to tie the two together: > What I don't like about this is that it requires a global variable > to access the command list from the help function. What I do like > about this is that it works! > > Suggestions? Alternatives? Just do it? :-) Just don't do it please :) * Global variables are bad and should be avoid unless there is no other solution. * The patch introduces an "interesting" dependency: the libcli library becomes dependent on the xorpsh/rtrmgr code. * The real problem was somewhere else and the bogus command-line completion for the "show ospf4" command was a side effect of that problem. This problem is now fixed in CVS. See XORP Bugzilla entry #603 for details: http://www.xorp.org/bugzilla/show_bug.cgi?id=603 Pavlin From jfletcher@vyatta.com Fri Apr 28 02:00:02 2006 From: jfletcher@vyatta.com (Justin Fletcher) Date: Thu, 27 Apr 2006 18:00:02 -0700 (PDT) Subject: [Xorp-hackers] Possible fix for XORP bug 603 Message-ID: <6217484.871146186002138.JavaMail.root@mail.vyatta.com> > Just don't do it please :) > > * Global variables are bad and should be avoid unless there is no > other solution. > > * The patch introduces an "interesting" dependency: the libcli > library becomes dependent on the xorpsh/rtrmgr code. > > * The real problem was somewhere else and the bogus command-line > completion for the "show ospf4" command was a side effect of that > problem. This problem is now fixed in CVS. > See XORP Bugzilla entry #603 for details: > http://www.xorp.org/bugzilla/show_bug.cgi?id=603 The fix to ospfv2.cmds fixes the specific case, but unfortunately not the general case. Template entries of the form cmd opt1 opt2 { } where both opt1 and opt2 must be specified end up with "cmd opt1" being marked as valid in help, even though it's not executable. There are also issues with configuration templates; I'll need to come up with specific examples for both. Best, Justin Fletcher Vyatta From pavlin at icir.org Sat Apr 29 18:13:32 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 29 Apr 2006 18:13:32 -0700 Subject: [Xorp-hackers] HEADS UP: Mailman upgrade this Saturday (April 29th) In-Reply-To: Message from Pavlin Radoslavov of "Wed, 26 Apr 2006 22:30:07 PDT." <200604270530.k3R5U7IH065668@possum.icir.org> Message-ID: <200604300113.k3U1DW9L058475@possum.icir.org> > All, > > This Saturday (April 29th) the ICSI administrators are going to > upgrade the Mailman software on the server that manages all XORP > mailing lists. > > Please don't send any emails during the update to any of the XORP > MLs. Also, please postpone any subscription related changes > (preferences, unsubscribe requests, etc) until the upgrade is > completed. I will send another email after everything is back to > normal. > > There is chance that right after the upgrade some of the > Mailman configuration options may be reset. This may result in some > unwanted spam. If this happens we should fix the problem promptly. > In the mean time please have some patience. The upgrade is completed and everything should be back to normal. Please let me know if you find any Mailman-related problems. Thanks, Pavlin