RE: [lir-wg] AS Number Policy
[snip]
Yes. I had recently a lengthy "discussion" with RIPE hostmasters about a multihomed AS of a customer. Primary upstream with us, secondary upstream with AS702. Using 702:80 community to lower localpref within 702, making the backup link real backup. As 702 announces best path (which is via their peering to us to the customer), RIPE was unable to see the 702 backup announcement anywhere. Explanation of BGP basics by myself were not understood or ignored. Or both. They also did not contact AS702 for simple confirmation of what I've told them. Took three or four emails to get that finally sorted out. Whom do I bill those 30-45 minutes to (rhetoric question)? ;->
This is another good example why AS number is originated but invisible to the global routing table.
End of the story was that they finally said "We have found AS21197 in the import policy of AS702 and going to close this ticket now." :-]]]
IF they really want to enforce ASN assignment policy, they should REALLY have to have a clue about BGP. Looking at some random looking glasses or RIS data and not understanding it is NOT enough for a policy-enforcing agency. And someone should explain them the difference between a looking glass and a traceroute server.
Let's say... Halabi as compulsary lecture for hostmasters who have to evaluate ASN assignment policy compliance. :-)
Regards, Daniel
It is almost impossible for RIPE NCC to look into all upstream ISP's routing table and verify that an AS is being used properly. If RIPE NCC can't find a way to reduce the false alarm of AS verification, the enforcement will become more likely an harassment. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net
On Wed, Jul 10, 2002 at 10:38:58AM -0400, Lu, Ping wrote:
It is almost impossible for RIPE NCC to look into all upstream ISP's routing table and verify that an AS is being used properly.
ACK. And in this specific example, the looking glass would perhaps even have to have a direct info feed from the specific aggregation router to see the path.
If RIPE NCC can't find a way to reduce the false alarm of AS verification, the enforcement will become more likely an harassment.
StrongACK. Especially, when the first email already contains a bold statement like "this AS is not multihomed, so...". Best regards, Daniel
--On Wednesday, July 10, 2002 10:38:58 -0400 "Lu, Ping" <PLu@cw.net> wrote:
Yes. I had recently a lengthy "discussion" with RIPE hostmasters about a multihomed AS of a customer. Primary upstream with us, secondary upstream with AS702. Using 702:80 community to lower localpref within 702, making the backup link real backup. As 702 announces best path (which is via their peering to us to the customer), RIPE was unable to see the 702 backup announcement anywhere. Explanation of BGP basics by myself were not understood or ignored. Or both. They also did not contact AS702 for simple confirmation of what I've told them. Took three or four emails to get that finally sorted out. Whom do I bill those 30-45 minutes to (rhetoric question)? ;->
This is another good example why AS number is originated but invisible to the global routing table.
I don't read it as beeing invisible - just seen throug one path. - kurtis -
participants (3)
-
Daniel Roesen
-
Kurt Erik Lindqvist
-
Lu, Ping