Re: More route flaps & inconsistent origins
Hi, again, here is a new route flap report. The villains from the top of the previous report have apparently fixed their problem, but a few ASes again manage to get the dubious position at the top of the list with more than 20.000 route flaps in the 24 hours from Oct 12 03:05 GMT to Oct 13 03:05 GMT. Again I would like to draw to your attention the fact that some destinations are apparently being originated by more than one AS. These show up in the report with more then one origin. I was under the impression that thsi is an illegal or highly undesireable configuration; I would still like to hear some comments on this issue. The top 20 were: Origin(s) flaps retr unrch dests AS AS Description 1717 26152 9317 9459 594 1717 RENATER 174:2149 21315 3503 3838 1019 2149 PSINET-2 174:2149 21315 3503 3838 1019 174 NYSERNET-AS 1270 7441 3020 3026 242 1270 EUnet/DE 701 6187 1863 1970 872 701 AlterNet 517 4397 1485 1514 117 517 XLINK-UKA 1237 3689 1172 1176 103 1237 EUNSOL-AS 1899 2854 1230 1274 115 1899 Fnet, EUnet-France 86 2845 592 740 452 86 SURANET-AS 378 2789 387 630 127 378 ILAN 1836 2541 1251 1249 62 1836 EUnet/CH Autonomous System 2551 2519 395 421 196 2551 NETCOM-AS 279 2331 743 1186 490 279 SURANET-AS-2 1290 1922 674 698 81 1290 EUnet GB 3354 1907 307 400 216 3354 THENET-AS-1 2915 1576 202 252 101 2915 SPIN-NET 174 1554 428 470 124 174 NYSERNET-AS 1250 1544 353 521 343 1250 SINGAPORE-AS 137 1410 163 182 169 137 GARR 2715 1385 377 383 18 2715 REDERIO-AS Legend: "Origin(s)" are the AS or ASes seen as "origin" of routing updates (essentially the last element in the logged path). "flaps" is the sum of "retr" and the number of times the route was updated (e.g. new path) "retr" is the number of times a route was withdrawn (retracted) "unrch" is the number of withdrawals which caused loss of connectivity for a destination "dests" is the number of destinations involved in route flaps "AS description" was what the RIPE database told me last time I looked up the AS descriptions or AS names. Excluded from this picture are any routes involving as-sets (there are a number of routing flaps involving them as well, I'll hopefully get some time to analyzing them separately sometime later...). Attached below you will find a more detailed report showing the number of times each individual path was announced for each of the entries on the "top 20" list, I can also easily (on request) produce a "per-network" report for any given AS. Regards, - Havard ------------------------------ Origin(s) flaps retr unrch dests AS AS Description 1717 26152 9317 9459 594 1717 RENATER Count Path 11275 2603 1755 1717 6795 2603 3224 2043 1128 1755 1717 234 2603 3224 2043 1128 1133 1800 1755 1717 Origin(s) flaps retr unrch dests AS AS Description 174:2149 21315 3503 3838 1019 2149 PSINET-2 Count Path 4724 2603 1805 1800 690 2149 446 2603 1755 1800 690 2149 572 2603 1805 1800 1133 690 2149 110 2603 1805 1800 1239 1240 690 2149 77 2603 1805 1800 701 690 2149 7 2603 1755 1800 1239 1240 690 2149 10 2603 1755 1800 1133 690 2149 9 2603 1755 1800 701 690 2149 2 2603 1805 1800 1133 1674 690 2149 8 2603 1805 1800 1239 690 2149 1 2603 1755 1800 1133 1674 690 2149 Origin(s) flaps retr unrch dests AS AS Description 174:2149 21315 3503 3838 1019 174 NYSERNET-AS Count Path 9673 2603 1805 1800 174 1598 2603 1755 1800 174 609 2603 1805 1800 690 174 70 2603 1805 1800 1239 1280 174 114 2603 3224 2043 1128 1133 1800 174 66 2603 1755 1800 690 174 55 2603 1755 1800 1133 690 174 92 2603 1805 1800 1133 690 174 11 2603 1805 1800 690 701 174 18 2603 1755 1800 1239 1280 174 23 2603 1805 1800 701 690 174 1 2603 1755 1800 701 690 174 Origin(s) flaps retr unrch dests AS AS Description 1270 7441 3020 3026 242 1270 EUnet/DE Count Path 4421 2603 3224 2043 1128 286 1270 Origin(s) flaps retr unrch dests AS AS Description 701 6187 1863 1970 872 701 AlterNet Count Path 2789 2603 1805 1800 701 160 2603 1805 1800 1239 1280 701 441 2603 1755 1800 701 71 2603 1755 1800 1239 1280 701 546 2603 1805 1800 690 701 45 2603 1805 1800 1133 690 701 56 2603 3224 2043 1128 1133 1800 701 273 2603 3224 2043 1128 1133 701 36 2603 1755 1800 690 701 Origin(s) flaps retr unrch dests AS AS Description 517 4397 1485 1514 117 517 XLINK-UKA Count Path 945 2603 3224 2043 1128 1755 1273 517 1483 2603 1755 1273 517 286 2603 1755 1800 690 1324 517 20 2603 1805 1800 701 690 1324 517 46 2603 3224 2043 1128 1133 1800 1755 1273 517 91 2603 1805 1800 690 1324 517 25 2603 1805 1800 1133 690 1324 517 16 2603 1755 1800 1133 690 1324 517 Origin(s) flaps retr unrch dests AS AS Description 1237 3689 1172 1176 103 1237 EUNSOL-AS Count Path 874 2603 1805 1800 1237 1236 2603 3224 2043 786 1129 1237 407 2603 1755 1800 1237 Origin(s) flaps retr unrch dests AS AS Description 1899 2854 1230 1274 115 1899 Fnet, EUnet-France Count Path 1624 2603 3224 2043 1128 286 1899 Origin(s) flaps retr unrch dests AS AS Description 86 2845 592 740 452 86 SURANET-AS Count Path 1402 2603 1805 1800 86 215 2603 1805 1800 690 279 3561 86 30 2603 1805 1800 1133 690 279 3561 86 71 2603 1755 1800 690 279 3561 86 55 2603 1805 1800 1239 1280 1957 690 279 3561 86 3 2603 1805 1800 701 690 279 3561 86 14 2603 1755 1800 1239 1280 1957 690 279 3561 86 10 2603 1755 1800 1133 690 279 3561 86 1 2603 1805 1800 1133 1674 690 279 3561 86 54 2603 1805 1800 690 279 86 308 2603 1805 1800 690 86 51 2603 1755 1800 86 23 2603 1805 1800 1239 1280 1957 690 86 5 2603 1755 1800 1239 1280 1957 690 86 3 2603 1805 1800 701 690 86 6 2603 1805 1800 1133 690 86 4 2603 1805 1800 1239 1280 1957 690 279 86 3 2603 1755 1800 1239 1280 1957 690 279 86 4 2603 1755 1800 690 86 3 2603 1755 1800 1133 690 86 Origin(s) flaps retr unrch dests AS AS Description 378 2789 387 630 127 378 ILAN Count Path 1280 2603 1755 378 686 2603 1755 1800 174 378 327 2603 1805 1800 174 378 19 2603 1755 1800 690 174 378 44 2603 3224 2043 1128 1755 378 22 2603 3224 2043 1128 1133 1800 174 378 6 2603 1805 1800 690 174 378 6 2603 3224 2043 1128 1133 1800 1755 378 7 2603 1755 1800 701 690 174 378 3 2603 1805 1800 701 690 174 378 1 2603 1755 1800 1133 1674 690 174 378 1 2603 1805 1800 1133 1674 690 174 378 Origin(s) flaps retr unrch dests AS AS Description 1836 2541 1251 1249 62 1836 EUnet/CH Autonomous System Count Path 1290 2603 3224 2043 1128 286 1836 Origin(s) flaps retr unrch dests AS AS Description 2551 2519 395 421 196 2551 NETCOM-AS Count Path 909 2603 1805 1800 2551 693 2603 1805 1800 690 1321 2551 119 2603 1755 1800 2551 138 2603 1755 1800 1239 1280 2551 145 2603 1805 1800 1239 1280 2551 20 2603 1805 1800 690 2551 48 2603 3224 2043 1128 1133 2551 10 2603 1805 1800 1133 690 1321 2551 15 2603 1755 1800 690 1321 2551 4 2603 1805 1800 1133 1674 690 2551 2 2603 1755 1800 1133 690 2551 8 2603 1805 1800 1133 690 2551 6 2603 1805 1800 701 690 1321 2551 1 2603 1805 1800 1133 1674 690 1321 2551 2 2603 1755 1800 690 2551 3 2603 3224 2043 1128 1133 1800 2551 1 2603 1755 1800 701 690 1321 2551 Origin(s) flaps retr unrch dests AS AS Description 279 2331 743 1186 490 279 SURANET-AS-2 Count Path 764 2603 1805 1800 86 279 82 2603 1805 1800 1239 1280 1957 690 86 279 371 2603 1755 1800 86 279 116 2603 1805 1800 1133 690 279 80 2603 1805 1800 1239 690 279 52 2603 1805 1800 690 86 3561 279 46 2603 1805 1800 690 86 279 45 2603 1805 1800 690 279 2 2603 1805 1800 1239 1280 1957 690 279 10 2603 1805 1800 1133 690 86 279 3 2603 1755 1800 1239 1280 1957 690 86 279 4 2603 1755 1800 690 279 10 2603 1755 1800 690 86 279 3 2603 1755 1800 1133 690 279 2 2603 1805 1800 701 690 279 Origin(s) flaps retr unrch dests AS AS Description 1290 1922 674 698 81 1290 EUnet GB Count Path 1248 2603 3224 2043 1128 286 1290 Origin(s) flaps retr unrch dests AS AS Description 3354 1907 307 400 216 3354 THENET-AS-1 Count Path 436 2603 1755 1800 1239 3354 886 2603 1805 1800 1239 3354 238 2603 1805 1800 690 3354 14 2603 1805 1800 1133 690 3354 16 2603 3224 2043 1128 1133 1239 3354 2 2603 1805 1800 1239 1240 690 3354 7 2603 3224 2043 1128 1133 1800 1239 3354 1 2603 1755 1800 690 3354 1 2603 1805 1800 1239 1240 690 114 3354 2 2603 1805 1800 690 114 3354 Origin(s) flaps retr unrch dests AS AS Description 2915 1576 202 252 101 2915 SPIN-NET Count Path 335 2603 1805 1800 690 2149 174 2713 2915 840 2603 1805 1800 174 2713 2915 199 2603 1755 1800 174 2713 2915 Origin(s) flaps retr unrch dests AS AS Description 174 1554 428 470 124 174 NYSERNET-AS Count Path 775 2603 1805 1800 174 301 2603 1755 1800 174 24 2603 1805 1800 1239 1280 174 35 2603 3224 2043 1128 1133 1800 174 23 2603 1805 1800 1133 690 174 23 2603 1755 1800 1133 690 174 8 2603 1755 1800 1239 1280 174 1 2603 1805 1800 690 174 2 2603 3224 2043 1128 1133 3561 174 Origin(s) flaps retr unrch dests AS AS Description 1250 1544 353 521 343 1250 SINGAPORE-AS Count Path 912 2603 1805 1800 690 97 1250 14 2603 1755 1800 690 97 1250 1 2603 1755 1800 1239 1240 690 97 1250 240 2603 1805 1800 1239 1280 97 1250 6 2603 1755 1800 1133 690 97 1250 9 2603 1805 1800 1133 690 97 1250 8 2603 1755 1800 1239 1280 97 1250 1 2603 1805 1800 1239 1240 690 97 1250 Origin(s) flaps retr unrch dests AS AS Description 137 1410 163 182 169 137 GARR Count Path 423 2603 3224 2043 137 226 2603 1755 1128 2043 137 82 2603 1755 1800 86 293 3425 2038 513 2043 137 383 2603 1755 513 2038 137 61 2603 1805 1800 86 293 3425 2038 137 46 2603 3224 2043 1128 513 2038 137 13 2603 1755 1128 2043 513 2038 137 3 2603 1755 1800 293 3425 2038 513 1128 2043 137 2 2603 1805 1800 701 690 293 3425 2038 137 2 2603 1755 1800 701 690 293 3425 2038 137 2 2603 1755 1800 86 293 3425 2038 137 2 2603 3224 2043 513 2038 137 2 2603 1755 1800 86 293 3425 2038 513 1128 2043 137 Origin(s) flaps retr unrch dests AS AS Description 2715 1385 377 383 18 2715 REDERIO-AS Count Path 619 2603 1805 1800 690 1740 2715 175 2603 1755 1800 690 1740 2715 14 2603 1755 1800 701 690 1740 2715 121 2603 1805 1800 701 690 1740 2715 77 2603 1805 1800 1133 690 1740 2715 11 2603 1755 1800 1133 690 1740 2715 4 2603 1805 1800 1133 1674 690 1740 2715
To: bgpd@merit.edu, routing-wg@ripe.net Subject: Re: More route flaps & inconsistent origins Date: Thu, 13 Oct 1994 22:58:15 +0100 From: Havard Eidnes <Havard.Eidnes@runit.sintef.no>
Hi,
again, here is a new route flap report. The villains from the top of the previous report have apparently fixed their problem, but a few ASes again manage to get the dubious position at the top of the list with more than 20.000 route flaps in the 24 hours from Oct 12 03:05 GMT to Oct 13 03:05 GMT.
Again I would like to draw to your attention the fact that some destinations are apparently being originated by more than one AS. These show up in the report with more then one origin. I was under the impression that thsi is an illegal or highly undesireable configuration; I would still like to hear some comments on this issue.
This is not illegal by the BGP RFC, but it is basicly frowned upon by operators and the BGPd community. This usually occurs when people are back-leaking redistributing IGP's into different BGP ASs. By the way, an interesting statistic here is not so much the originating AS (yes, that is interesting, but...) but rather determining transit ASs that are causing the flaps. For instance, say AS 109 is transited by AS 200, and AS 200 flaps a lot. AS 109 will show up as flapping and the flaps aren't debited against 200, so you don't discover the real problem. Paul * AS's used in this are only for example purposes, no slam against barrnet intended. :-)
To: bgpd@merit.edu, routing-wg@ripe.net Subject: Re: More route flaps & inconsistent origins Date: Thu, 13 Oct 1994 22:58:15 +0100 From: Havard Eidnes <Havard.Eidnes@runit.sintef.no>
Hi,
again, here is a new route flap report. The villains from the top of the previous report have apparently fixed their problem, but a few ASes again manage to get the dubious position at the top of the list with more than 20.000 route flaps in the 24 hours from Oct 12 03:05 GMT to Oct 13 03:05 GMT.
Again I would like to draw to your attention the fact that some destinations are apparently being originated by more than one AS. These show up in the report with more then one origin. I was under the impression that thsi is an illegal or highly undesireable configuration; I would still like to hear some comments on this issue.
This is not illegal by the BGP RFC, but it is basicly frowned upon by operators and the BGPd community. This usually occurs when people are back-leaking redistributing IGP's into different BGP ASs.
If you were homed to the NSFNET in two different places, you needed unique AS's at each peering point. So you had to dump your nets into two different AS's. I realize this recently changed, but why deal with it now, when it will soon go away. mf
By the way, an interesting statistic here is not so much the originating AS (yes, that is interesting, but...) but rather determining transit ASs that are causing the flaps.
For instance, say AS 109 is transited by AS 200, and AS 200 flaps a lot. AS 109 will show up as flapping and the flaps aren't debited against 200, so you don't discover the real problem.
Paul
* AS's used in this are only for example purposes, no slam against barrnet intended. :-)
To: Paul Traina <pst@cisco.com> Cc: Havard Eidnes <Havard.Eidnes@runit.sintef.no>, bgpd@merit.edu, routing-wg@ripe.net Subject: Re: More route flaps & inconsistent origins Date: Thu, 13 Oct 1994 18:29:56 -0400 From: "Mark S. Fedor" <fedor@msf.psi.net>
To: bgpd@merit.edu, routing-wg@ripe.net Subject: Re: More route flaps & inconsistent origins Date: Thu, 13 Oct 1994 22:58:15 +0100 From: Havard Eidnes <Havard.Eidnes@runit.sintef.no>
Hi,
again, here is a new route flap report. The villains from the top of the previous report have apparently fixed their problem, but a few ASes again manage to get the dubious position at the top of the list with more than 20.000 route flaps in the 24 hours from Oct 12 03:05 GMT to Oct 13 03:05 GMT.
Again I would like to draw to your attention the fact that some destinations are apparently being originated by more than one AS. These show up in the report with more then one origin. I was under the impression that thsi is an illegal or highly undesireable configuration; I would still like to hear some comments on this issue.
This is not illegal by the BGP RFC, but it is basicly frowned upon by operators and the BGPd community. This usually occurs when people are back-leaking redistributing IGP's into different BGP ASs.
If you were homed to the NSFNET in two different places, you needed unique AS's at each peering point. So you had to dump your nets into two different AS's. I realize this recently changed, but why deal with it now, when it will soon go away.
That hasn't been true for years... anyway, everyone knows that PSI=174:2149 so it's no big deal.
mf
By the way, an interesting statistic here is not so much the originating AS (yes, that is interesting, but...) but rather determining transit ASs that are causing the flaps.
For instance, say AS 109 is transited by AS 200, and AS 200 flaps a lot. AS 109 will show up as flapping and the flaps aren't debited against 200, so you don't discover the real problem.
Paul
* AS's used in this are only for example purposes, no slam against barrnet intended. :-)
To: bgpd@merit.edu, routing-wg@ripe.net Subject: Re: More route flaps & inconsistent origins Date: Thu, 13 Oct 1994 22:58:15 +0100 From: Havard Eidnes <Havard.Eidnes@runit.sintef.no>
Hi,
again, here is a new route flap report. The villains from the top of the previous report have apparently fixed their problem, but a few ASes again manage to get the dubious position at the top of the list with more than 20.000 route flaps in the 24 hours from Oct 12 03:05 GMT to Oct 13 03:05 GMT.
Again I would like to draw to your attention the fact that some destinations are apparently being originated by more than one AS. These show up in the report with more then one origin. I was under the impression that thsi is an illegal or highly undesireable configuration; I would still like to hear some comments on this issue.
This is not illegal by the BGP RFC, but it is basicly frowned upon by operators and the BGPd community. This usually occurs when people are back-leaking redistributing IGP's into different BGP ASs.
If you were homed to the NSFNET in two different places, you needed unique AS's at each peering point. So you had to dump your nets into two different AS's. I realize this recently changed, but why deal with it now, when it will soon go away.
mf
It has been a while since ANS/NSF needed multiple ASes on different peering points, however, I don't think ANS/NSF peering, or lack thereof, is the real issue, as you also alluded to. The important point is that the there are many incorrect home ASes tagged onto route announcements.
From an operational point of view, imho, it is helpful to be in a state where the home AS/network-prefix information is correct and consistent, both in the route annoucements and in the registration. There are cases where playing games w/route preferences based on home AS is required, and if they are not reliable, what good are they? I'd much rather deal w/AS path decisions than network prefixes. Make sense?
By the way, does anyone have a feel for how "good" the home AS registration information is/will be? -- Becca
By the way, an interesting statistic here is not so much the originating AS (yes, that is interesting, but...) but rather determining transit ASs that are causing the flaps.
For instance, say AS 109 is transited by AS 200, and AS 200 flaps a lot. AS 109 will show up as flapping and the flaps aren't debited against 200, so you don't discover the real problem.
Paul
* AS's used in this are only for example purposes, no slam against barrnet intended. :-)
Rebecca Lee Bostwick <bostwick@es.net> writes:
From an operational point of view, imho, it is helpful to be in a state where the home AS/network-prefix information is correct and consistent, both in the route annoucements and in the registration. There are cases where playing games w/route preferences based on home AS is required, and if they are not reliable, what good are they?
That is exactly why the original (classic :-) RIPE routing registry insisted on "one route one (home) AS". It is with great trepidation that we abandoned this in ripe-181 to allow multiple proxy aggregation that some felt should be describable.
I'd much rather deal w/AS path decisions than network prefixes. Make sense?
Yes, it does! Dealing with prefixes will not scale. It is impractical in many situations already. I would rather deal with originating (home) AS only rather than opening the box of pan(ndor)aths at this point. It is my experience that there are not many people who can engineer consistent routing based on AS paths in the face of changing topology. ripe-181 gives some simple examples of the problems in the discussion of the "as-exclude" attribute. There is certainly a need for planning and/or simulation tools which support the designer in handling topologies too complex to keep in (one) mind. Anyone working on such things?
By the way, does anyone have a feel for how "good" the home AS registration information is/will be?
Have a look at ftp://ftp.ripe.net/ripe/as Nosing around a little will give you the answer for the RIPE RR. To sum up today's results: We have 12289 routes registered with an originating AS and the following 36 conflicts: 131.154.0.0 in AS137 (database) and anounced by AS2038 (BGP) 134.93.0.0 in AS2857 (database) and anounced by AS517 (BGP) 134.214.0.0 in AS2060 (database) and anounced by AS789 (BGP) 140.78.0.0 in AS1205 (database) and anounced by AS1853 (BGP) 141.192.0.0 in AS790 (database) and anounced by AS1342 (BGP) 144.168.0.0 in AS1290 (database) and anounced by AS2551 (BGP) 152.66.0.0 in AS2012 (database) and anounced by AS2547 (BGP) 157.193.0.0 in AS2111 (database) and anounced by AS2611 (BGP) 159.93.0.0 in AS2875 (database) and anounced by AS2118 (BGP) 192.54.104.0 in AS517 (database) and anounced by AS1324 (BGP) 192.58.67.0 in AS719 (database) and anounced by AS544 (BGP) 192.65.185.0 in AS513 (database) and anounced by AS1133 (BGP) 192.71.39.0 in AS1257 (database) and anounced by AS2116 (BGP) 192.76.243.0 in AS760 (database) and anounced by AS1853 (BGP) 192.83.19.0 in AS1759 (database) and anounced by AS544 (BGP) 192.88.23.0 in AS1205 (database) and anounced by AS1853 (BGP) 192.88.24.0 in AS1205 (database) and anounced by AS1853 (BGP) 192.107.125.0 in AS1205 (database) and anounced by AS1853 (BGP) 192.108.114.0 in AS2546 (database) and anounced by AS1241 (BGP) 192.109.57.0 in AS517 (database) and anounced by AS1270 (BGP) 192.121.154.0 in AS1755 (database) and anounced by AS2603 (BGP) 192.129.55.0 in AS517 (database) and anounced by AS2871 (BGP) 192.152.54.0 in AS760 (database) and anounced by AS1901 (BGP) 193.6.23.0 in AS2012 (database) and anounced by AS2547 (BGP) 193.10.80.0 in AS1653 (database) and anounced by AS1805 (BGP) 193.63.58.0 in AS786 (database) and anounced by AS2699 (BGP) 193.101.134.0 in AS1270 (database) and anounced by AS701 (BGP) 193.119.73.0 in AS1290 (database) and anounced by AS786 (BGP) 193.172.27.0 in AS2043 (database) and anounced by AS786 (BGP) 193.184.88.0 in AS719 (database) and anounced by AS1741 (BGP) 193.185.26.0 in AS719 (database) and anounced by AS1741 (BGP) 193.186.165.0 in AS2131 (database) and anounced by AS1853 (BGP) 193.186.167.0 in AS2131 (database) and anounced by AS1853 (BGP) 193.186.169.0 in AS2131 (database) and anounced by AS1853 (BGP) 193.186.170.0 in AS2131 (database) and anounced by AS1853 (BGP) 193.186.171.0 in AS2131 (database) and anounced by AS1853 (BGP) which represents 0.29 percent of the routes registered. Further there are 141 prefixes registered as having no connectivity but we see routes for them. We see 10 prefixes we know are originated in Europe but not registered. Together all these incosistencies represent 1.52 percent of the data registered. We do not have the staff resources yet to do a better job at cleaning these up. I consider it not too bad though! Daniel
There is certainly a need for planning and/or simulation tools which support the designer in handling topologies too complex to keep in (one) mind. Anyone working on such things?
I have been led to believe that the RA has this as an item on its adgenda. -- --bill
bmanning@ISI.EDU writes:
There is certainly a need for planning and/or simulation tools which support the designer in handling topologies too complex to keep in (one) mind. Anyone working on such things?
I have been led to believe that the RA has this as an item on its adgenda.
Still the question remains: Anyone working on such things? Sorry to be flippant (just this one time :-). Seriously: I would like to know about any developments in this area. We should prevent wheel re-invention. Daniel
In message <9410132230.AA21917@msf.psi.net>, "Mark S. Fedor" writes:
Again I would like to draw to your attention the fact that some destinations are apparently being originated by more than one AS. These show up in the report with more then one origin. I was under the impression that thsi is an illegal or highly undesireable configuration; I would still like to hear some comments on this issue.
This is not illegal by the BGP RFC, but it is basicly frowned upon by operators and the BGPd community. This usually occurs when people are back-leaking redistributing IGP's into different BGP ASs.
If you were homed to the NSFNET in two different places, you needed unique AS's at each peering point. So you had to dump your nets into two different AS's. I realize this recently changed, but why deal with it now, when it will soon go away.
mf
Mark, This has not been the case for about 1/2 year now. You can border in two places with the same AS number. Even when it was the case, you should still provide the same home AS, just different border AS somewhere in the path. Other providers manage to do this. Curtis
participants (7)
-
bmanning＠ISI.EDU -
Curtis Villamizar -
Daniel Karrenberg -
Havard Eidnes -
Mark S. Fedor -
Paul Traina -
Rebecca Lee Bostwick