Problems with specific routing policies for each exchange point
I ran in to a little problem yesterday with my peering sessions wih the various route servers around the country. The problem was that I was not receiving routes from particular ASNs anymore. With a little help from Jake at Merit we were able to pinpoint the problem in my rs-in configuration. It seems that I was importing two different AS macros that each referenced the other (AS-GENUITY and AS-NAPNET). This created a loop in the macro parser on the route server which in turn nullified my routing policy. I was wondering if anyone else had come across this little phenomenon. Mark Tripod Senior Backbone Engineer Exodus Communications
### On Thu, 30 Oct 1997 18:02:02 -0800, mark@exodus.net (Mark Tripod) wrote ### to <nanog@Merit.Net> concerning "Problems with specific routing policies ### for each exchange point": MT> I ran in to a little problem yesterday with my peering sessions wih the MT> various route servers around the country. The problem was that I was not MT> receiving routes from particular ASNs anymore. With a little help from Jake MT> at Merit we were able to pinpoint the problem in my rs-in configuration. It MT> seems that I was importing two different AS macros that each referenced the MT> other (AS-GENUITY and AS-NAPNET). This created a loop in the macro parser MT> on the route server which in turn nullified my routing policy. I would reccommend anyone referencing any of those two macros in their rs-in or rs-out to discontinue doing so at least until which time I can throw in a bugfix to handle looping expansions. Currently the expansion routine in the preprocessor will reach a depth limit and then spit out an error which gets interpretted by the main routine as a bogus expansion. This will nullify that import. -- /*===================[ Jake Khuon <khuon@Merit.Net> ]======================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | VOX: (313) 763-4907 FAX: (313) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/
From: "Jake Khuon" <khuon@Merit.Net> Date: Thu, 30 Oct 1997 23:45:25 -0500 Sender: owner-nanog@merit.edu
### On Thu, 30 Oct 1997 18:02:02 -0800, mark@exodus.net (Mark Tripod) wrote ### to <nanog@Merit.Net> concerning "Problems with specific routing policies ### for each exchange point":
MT> I ran in to a little problem yesterday with my peering sessions wih the MT> various route servers around the country. The problem was that I was not MT> receiving routes from particular ASNs anymore. With a little help from Jake MT> at Merit we were able to pinpoint the problem in my rs-in configuration. It MT> seems that I was importing two different AS macros that each referenced the MT> other (AS-GENUITY and AS-NAPNET). This created a loop in the macro parser MT> on the route server which in turn nullified my routing policy.
I would reccommend anyone referencing any of those two macros in their rs-in or rs-out to discontinue doing so at least until which time I can throw in a bugfix to handle looping expansions. Currently the expansion routine in the preprocessor will reach a depth limit and then spit out an error which gets interpretted by the main routine as a bogus expansion. This will nullify that import.
I must admit that I do not see the reason for using AS macros in rs-in and rs-out statements. As far as I know these statements merely control which AS peers will receive your routes from the route server and vice-versa. Since these are direct peers with the route server, I can't see the need to put anything other than specific AS numbers into the rs-in and rs-out lines. Am I missing something obvious? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
I must admit that I do not see the reason for using AS macros in rs-in and rs-out statements. As far as I know these statements merely control which AS peers will receive your routes from the route server and vice-versa. Since these are direct peers with the route server, I can't see the need to put anything other than specific AS numbers into the rs-in and rs-out lines.
One can use the same AS-macro in the inet-rtr.rs(in|out): as in a policy in aut-num.as-(in|out):. randy
Date: Fri, 31 Oct 97 08:25 PST From: Randy Bush <randy@psg.com>
One can use the same AS-macro in the inet-rtr.rs(in|out): as in a policy in aut-num.as-(in|out):.
I was not questioning the function, only the requirement. It seems that if the problem exist between NAPNET and GENUITY, it might exist elsewhere and changing to the specific ASes would be a simple fix. Are there cases where an AS macro would be really beneficial in the inet-rtr.rs-(in|out) statements? Frankly, it's paranoia that causes me to only put specific ASes in the statements. While I'm willing to let an ISP tell me what ASes they are carrying, I want to know exactly with whom I'm exchanging routes. I always thought of Randy as the conservative type, but maybe not as much as I. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
Randy, It's my understanding that you want us to disconnect your route server peering sessions. We will have this done by noon tomorrow. Please let us know if there is anything else we can do for you. *teehee* tons of love, abha ;) On Fri, 31 Oct 1997, Randy Bush wrote:
I always thought of Randy as the conservative type, but maybe not as much as I.
I am. Wouldn't tough a route server with a 10 meter nlri. Solves the problem entirely.
randy
__________________________________________________________________________ -------------------------------------------------------------------------- abha ahuja ahuja@merit.edu Merit Network, Inc. 313.764.0294
It's my understanding that you want us to disconnect your route server peering sessions.
We are utterly indifferent. We give our routes to the RSs so Craig can get data for statistical purposes. We ask the RSs give our routes to no one and we do not accept routes from the RSs. So disconnect any time you wish. No problem. randy
On Fri, 31 Oct 1997, Randy Bush wrote:
It's my understanding that you want us to disconnect your route server peering sessions.
We are utterly indifferent. We give our routes to the RSs so Craig can get data for statistical purposes. We ask the RSs give our routes to no one and we do not accept routes from the RSs.
and we appreciate your peering... :)
So disconnect any time you wish. No problem.
and i was only kidding... -abha ;) __________________________________________________________________________ -------------------------------------------------------------------------- abha ahuja ahuja@merit.edu Merit Network, Inc. 313.764.0294
On Fri, Oct 31, 1997 at 05:38:35PM -0500, Abha Ahuja wrote:
On Fri, 31 Oct 1997, Randy Bush wrote:
It's my understanding that you want us to disconnect your route server peering sessions.
We are utterly indifferent. We give our routes to the RSs so Craig can get data for statistical purposes. We ask the RSs give our routes to no one and we do not accept routes from the RSs.
and we appreciate your peering... :)
So disconnect any time you wish. No problem.
and i was only kidding...
Randy left his sense of humor in his other pants. And left those at the dry cleaners. Where they were lost in the fire. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
Flexibility. The "Other guy" can add/rm ASes without having to involve your policy.
From: "Jake Khuon" <khuon@Merit.Net> Date: Thu, 30 Oct 1997 23:45:25 -0500 Sender: owner-nanog@merit.edu
### On Thu, 30 Oct 1997 18:02:02 -0800, mark@exodus.net (Mark Tripod) wrote ### to <nanog@Merit.Net> concerning "Problems with specific routing policies ### for each exchange point":
MT> I ran in to a little problem yesterday with my peering sessions wih the MT> various route servers around the country. The problem was that I was not MT> receiving routes from particular ASNs anymore. With a little help from Jake MT> at Merit we were able to pinpoint the problem in my rs-in configuration. It MT> seems that I was importing two different AS macros that each referenced the MT> other (AS-GENUITY and AS-NAPNET). This created a loop in the macro parser MT> on the route server which in turn nullified my routing policy.
I would reccommend anyone referencing any of those two macros in their rs-in or rs-out to discontinue doing so at least until which time I can throw in a bugfix to handle looping expansions. Currently the expansion routine in the preprocessor will reach a depth limit and then spit out an error which gets interpretted by the main routine as a bogus expansion. This will nullify that import.
I must admit that I do not see the reason for using AS macros in rs-in and rs-out statements. As far as I know these statements merely control which AS peers will receive your routes from the route server and vice-versa. Since these are direct peers with the route server, I can't see the need to put anything other than specific AS numbers into the rs-in and rs-out lines.
Am I missing something obvious? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
From: Robert Bowman <rob@elite.exodus.net> Date: Fri, 31 Oct 1997 08:27:34 -0800 (PST)
Flexibility. The "Other guy" can add/rm ASes without having to involve your policy.
I'm not questioning the use of them in the as-(in|out) statements. We use them heavily there and would be in a real mess without them. But I don't see the need in the inet-rtr.rs-(in-out) statements. I do see that they would make maintenance of the rs-(in|our) a bit easier by simply copying them from the as-(in-out). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
### On Fri, 31 Oct 97 08:10:58 -0800, "Kevin Oberman" <oberman@es.net> wrote ### to khuon@Merit.Net (Jake Khuon) concerning "Re: Problems with specific ### routing policies for each exchange point ": KO> I must admit that I do not see the reason for using AS macros in rs-in KO> and rs-out statements. As far as I know these statements merely KO> control which AS peers will receive your routes from the route server KO> and vice-versa. Since these are direct peers with the route server, I KO> can't see the need to put anything other than specific AS numbers into KO> the rs-in and rs-out lines. KO> KO> Am I missing something obvious? One particular instance where an as-macro could be useful within rs-in/out is in the case where one wants to support an MLPA. -- /*===================[ Jake Khuon <khuon@Merit.Net> ]======================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | VOX: (313) 763-4907 FAX: (313) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/
This problem was addressed in the design of RAWhoisd. I will tell Jake how to use it. "Jake Khuon" on Thu, 30 Oct 1997 23:45:25 -0500 said:
### On Thu, 30 Oct 1997 18:02:02 -0800, mark@exodus.net (Mark Tripod) wrote ### to <nanog@Merit.Net> concerning "Problems with specific routing policies ### for each exchange point":
MT> I ran in to a little problem yesterday with my peering sessions wih the MT> various route servers around the country. The problem was that I was not MT> receiving routes from particular ASNs anymore. With a little help from Ja ke MT> at Merit we were able to pinpoint the problem in my rs-in configuration. It MT> seems that I was importing two different AS macros that each referenced t he MT> other (AS-GENUITY and AS-NAPNET). This created a loop in the macro parser MT> on the route server which in turn nullified my routing policy.
I would reccommend anyone referencing any of those two macros in their rs-in or rs-out to discontinue doing so at least until which time I can throw in a bugfix to handle looping expansions. Currently the expansion routine in the preprocessor will reach a depth limit and then spit out an error which gets interpretted by the main routine as a bogus expansion. This will nullify that import.
-- /*===================[ Jake Khuon <khuon@Merit.Net> ]======================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | VOX: (313) 763-4907 FAX: (313) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/
Some more people asked. Here is how: % whois -h radb.ra.net '!iAS-GENUITY,1' AS3847 AS31 AS125 AS127 AS226 AS1220 AS2150 AS2529 AS2873 AS2900 AS3259 AS3344 AS3557 AS3588 AS5378 AS5380 AS5412 AS5413 AS5459 AS5482 AS5485 AS5503 AS5519 AS5593 AS5594 AS5597 AS5600 AS5611 AS5646 AS6201 AS6259 AS6320 AS6427 AS6717 AS6675 AS6760 AS6765 AS6886 AS6973 AS8001 AS8130 AS8161 AS8170 AS8407 AS38 AS103 AS160 AS693 AS1746 AS2907 AS3365 AS3393 AS3669 AS3789 AS4247 AS4358 AS4527 AS5700 AS6136 AS6214 AS6217 AS6349 AS6365 AS6379 AS6392 AS6496 AS6555 AS6576 AS6618 AS6716 AS7062 AS7189 AS7263 AS7820 AS10268 AS10377 AS6402 AS5072 AS7206 AS6200 AS2381 AS3128 AS3129 AS7050 AS3136 AS3148 AS59 Cengiz Alaettinoglu on Fri, 31 Oct 97 09:09:16 PST said:
This problem was addressed in the design of RAWhoisd. I will tell Jake how to
use it.
"Jake Khuon" on Thu, 30 Oct 1997 23:45:25 -0500 said:
### On Thu, 30 Oct 1997 18:02:02 -0800, mark@exodus.net (Mark Tripod) wrote ### to <nanog@Merit.Net> concerning "Problems with specific routing policie s ### for each exchange point":
MT> I ran in to a little problem yesterday with my peering sessions wih the MT> various route servers around the country. The problem was that I was no t MT> receiving routes from particular ASNs anymore. With a little help from Ja ke MT> at Merit we were able to pinpoint the problem in my rs-in configuration . It MT> seems that I was importing two different AS macros that each referenced t he MT> other (AS-GENUITY and AS-NAPNET). This created a loop in the macro pars er MT> on the route server which in turn nullified my routing policy.
I would reccommend anyone referencing any of those two macros in their rs-i n or rs-out to discontinue doing so at least until which time I can throw in a bugfix to handle looping expansions. Currently the expansion routine in th e preprocessor will reach a depth limit and then spit out an error which gets interpretted by the main routine as a bogus expansion. This will nullify that import.
-- /*===================[ Jake Khuon <khuon@Merit.Net> ]======================
+
| Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | VOX: (313) 763-4907 FAX: (313) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]== */
In message <19971031020322.AAA5387@pokey.eng.pbi.net>, Mark Tripod writes:
I ran in to a little problem yesterday with my peering sessions wih the various route servers around the country. The problem was that I was not receiving routes from particular ASNs anymore. With a little help from Jake at Merit we were able to pinpoint the problem in my rs-in configuration. It seems that I was importing two different AS macros that each referenced the other (AS-GENUITY and AS-NAPNET). This created a loop in the macro parser on the route server which in turn nullified my routing policy.
I was wondering if anyone else had come across this little phenomenon.
Mark Tripod Senior Backbone Engineer Exodus Communications
We use different code that has loop suppression. It remembers each as-macro it has visited in an expansion and won't reenter one it has already been to. We've seen this quite a few times in the past. Curtis ps- catching up on nanog noise
participants (9)
-
Abha Ahuja -
Cengiz Alaettinoglu -
Curtis Villamizar -
Jake Khuon -
Jay R. Ashworth -
Kevin Oberman -
mark＠exodus.net -
Randy Bush -
Robert Bowman