29 Peering Points
Just thinking about all these Telecom peering points. Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points. So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more. Then consider the case when a /32 appears to be from Dunedin, and then the next second it appears to be from Wellington (because the Dunedin broadband user lost their session, and a new Wellington use just acquired their dynamic IP address). Then consider all the places these routes could be redistributed to within different ISPs, and potentially outside of their own AS. Then consider [non telecom] peering points that only accept a /24 or bigger. Not that anything is wrong with asymmetric routing, but doing it almost to the customer edge is going to make solving connectivity issues much more difficult (I can access this web site, but not that web site ...). I can see a lot of potential for route flapping, and for frequent routing updates to occur. I can also see the potential for short term route loops occurring. I see route stability issues arising in NZ's future, or have I missed something?
On 26/07/2007, at 12:40 PM, Philip D'Ath wrote:
Just thinking about all these Telecom peering points.
Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points.
Firstly, you mean "assign", not "allocate". Secondly, let's highlight, underline, and put in large type that you're assuming.
So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more.
Then consider the case when a /32 appears to be from Dunedin, and then the next second it appears to be from Wellington (because the Dunedin broadband user lost their session, and a new Wellington use just acquired their dynamic IP address). Then consider all the places these routes could be redistributed to within different ISPs, and potentially outside of their own AS. Then consider [non telecom] peering points that only accept a /24 or bigger. Not that anything is wrong with asymmetric routing, but doing it almost to the customer edge is going to make solving connectivity issues much more difficult (I can access this web site, but not that web site ...). I can see a lot of potential for route flapping, and for frequent routing updates to occur. I can also see the potential for short term route loops occurring.
That would be terrible, huh? It's a good thing they have a network engineering group with a higher than zero competence, so that their /own/ routers don't melt down, let alone routers in other networks that they peer with. -- Nathan Ward
Of course, as it stands, one other large-player ISP (who shall remain nameless) is currently giving us 3280 host routes routes, not to mention all the other prefixes smaller than a /24.... This is of course a far cry from 200k to 300k routes ;) -Michael Fincham On Thu, 2007-07-26 at 12:47 +1200, Nathan Ward wrote:
On 26/07/2007, at 12:40 PM, Philip D'Ath wrote:
Just thinking about all these Telecom peering points.
Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points.
Firstly, you mean "assign", not "allocate". Secondly, let's highlight, underline, and put in large type that you're assuming.
So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more.
Then consider the case when a /32 appears to be from Dunedin, and then the next second it appears to be from Wellington (because the Dunedin broadband user lost their session, and a new Wellington use just acquired their dynamic IP address). Then consider all the places these routes could be redistributed to within different ISPs, and potentially outside of their own AS. Then consider [non telecom] peering points that only accept a /24 or bigger. Not that anything is wrong with asymmetric routing, but doing it almost to the customer edge is going to make solving connectivity issues much more difficult (I can access this web site, but not that web site ...). I can see a lot of potential for route flapping, and for frequent routing updates to occur. I can also see the potential for short term route loops occurring.
That would be terrible, huh?
It's a good thing they have a network engineering group with a higher than zero competence, so that their /own/ routers don't melt down, let alone routers in other networks that they peer with.
-- Nathan Ward
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- -Michael Fincham
Unleash Technology Solutions
Do they advertise supernets to cover those host routes, and longer- than-24-bit prefixes? On 26/07/2007, at 12:58 PM, Michael Fincham wrote:
Of course, as it stands, one other large-player ISP (who shall remain nameless) is currently giving us 3280 host routes routes, not to mention all the other prefixes smaller than a /24....
This is of course a far cry from 200k to 300k routes ;)
-Michael Fincham
On Thu, 2007-07-26 at 12:47 +1200, Nathan Ward wrote:
On 26/07/2007, at 12:40 PM, Philip D'Ath wrote:
Just thinking about all these Telecom peering points.
Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points.
Firstly, you mean "assign", not "allocate". Secondly, let's highlight, underline, and put in large type that you're assuming.
So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more.
Then consider the case when a /32 appears to be from Dunedin, and then the next second it appears to be from Wellington (because the Dunedin broadband user lost their session, and a new Wellington use just acquired their dynamic IP address). Then consider all the places these routes could be redistributed to within different ISPs, and potentially outside of their own AS. Then consider [non telecom] peering points that only accept a /24 or bigger. Not that anything is wrong with asymmetric routing, but doing it almost to the customer edge is going to make solving connectivity issues much more difficult (I can access this web site, but not that web site ...). I can see a lot of potential for route flapping, and for frequent routing updates to occur. I can also see the potential for short term route loops occurring.
That would be terrible, huh?
It's a good thing they have a network engineering group with a higher than zero competence, so that their /own/ routers don't melt down, let alone routers in other networks that they peer with.
-- Nathan Ward
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- -Michael Fincham
Unleash Technology Solutions _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
!DSPAM:22,46a7f0cb262211167819257!
Who is this other? As the other main player only gives 1407 domestic. -- Bill Walker Senior Network Engineer Snap Internet Limited ------------------------------------------------------------------------------------------------ Tel: 03 348 8747 / 0800 500638 Email: bill.walker(a)team.snap.net.nz Web: www.snap.net.nz ------------------------------------------------------------------------------------------------ -----Original Message----- From: Nathan Ward [mailto:nznog(a)daork.net] Sent: Thursday, 26 July 2007 1:01 p.m. To: nznog Subject: Re: [nznog] 29 Peering Points Do they advertise supernets to cover those host routes, and longer- than-24-bit prefixes? On 26/07/2007, at 12:58 PM, Michael Fincham wrote:
Of course, as it stands, one other large-player ISP (who shall remain nameless) is currently giving us 3280 host routes routes, not to mention all the other prefixes smaller than a /24....
This is of course a far cry from 200k to 300k routes ;)
-Michael Fincham
On Thu, 2007-07-26 at 12:47 +1200, Nathan Ward wrote:
On 26/07/2007, at 12:40 PM, Philip D'Ath wrote:
Just thinking about all these Telecom peering points.
Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points.
Firstly, you mean "assign", not "allocate". Secondly, let's highlight, underline, and put in large type that you're assuming.
So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more.
Then consider the case when a /32 appears to be from Dunedin, and then the next second it appears to be from Wellington (because the Dunedin broadband user lost their session, and a new Wellington use just acquired their dynamic IP address). Then consider all the places these routes could be redistributed to within different ISPs, and potentially outside of their own AS. Then consider [non telecom] peering points that only accept a /24 or bigger. Not that anything is wrong with asymmetric routing, but doing it almost to the customer edge is going to make solving connectivity issues much more difficult (I can access this web site, but not that web site ...). I can see a lot of potential for route flapping, and for frequent routing updates to occur. I can also see the potential for short term route loops occurring.
That would be terrible, huh?
It's a good thing they have a network engineering group with a higher than zero competence, so that their /own/ routers don't melt down, let alone routers in other networks that they peer with.
-- Nathan Ward
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- -Michael Fincham
Unleash Technology Solutions _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
!DSPAM:22,46a7f0cb262211167819257!
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
And we're probably even connected to the same router as you. Weird huh? Erin Salmon Managing Director Unleash Technology Solutions Phone: +64 3 365 1273 Mobile: +64 275 877 913 -----Original Message----- From: Bill Walker [mailto:Bill.Walker(a)staff.snap.net.nz] Sent: Thursday, 26 July 2007 12:59 p.m. To: nznog Subject: Re: [nznog] 29 Peering Points Who is this other? As the other main player only gives 1407 domestic. -- Bill Walker Senior Network Engineer Snap Internet Limited ---------------------------------------------------------------------------- -------------------- Tel: 03 348 8747 / 0800 500638 Email: bill.walker(a)team.snap.net.nz Web: www.snap.net.nz ---------------------------------------------------------------------------- -------------------- -----Original Message----- From: Nathan Ward [mailto:nznog(a)daork.net] Sent: Thursday, 26 July 2007 1:01 p.m. To: nznog Subject: Re: [nznog] 29 Peering Points Do they advertise supernets to cover those host routes, and longer- than-24-bit prefixes? On 26/07/2007, at 12:58 PM, Michael Fincham wrote:
Of course, as it stands, one other large-player ISP (who shall remain nameless) is currently giving us 3280 host routes routes, not to mention all the other prefixes smaller than a /24....
This is of course a far cry from 200k to 300k routes ;)
-Michael Fincham
On Thu, 2007-07-26 at 12:47 +1200, Nathan Ward wrote:
On 26/07/2007, at 12:40 PM, Philip D'Ath wrote:
Just thinking about all these Telecom peering points.
Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points.
Firstly, you mean "assign", not "allocate". Secondly, let's highlight, underline, and put in large type that you're assuming.
So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more.
Then consider the case when a /32 appears to be from Dunedin, and then the next second it appears to be from Wellington (because the Dunedin broadband user lost their session, and a new Wellington use just acquired their dynamic IP address). Then consider all the places these routes could be redistributed to within different ISPs, and potentially outside of their own AS. Then consider [non telecom] peering points that only accept a /24 or bigger. Not that anything is wrong with asymmetric routing, but doing it almost to the customer edge is going to make solving connectivity issues much more difficult (I can access this web site, but not that web site ...). I can see a lot of potential for route flapping, and for frequent routing updates to occur. I can also see the potential for short term route loops occurring.
That would be terrible, huh?
It's a good thing they have a network engineering group with a higher than zero competence, so that their /own/ routers don't melt down, let alone routers in other networks that they peer with.
-- Nathan Ward
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- -Michael Fincham
Unleash Technology Solutions _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
!DSPAM:22,46a7f0cb262211167819257!
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 25/07/2007 2:55 p.m. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 25/07/2007 2:55 p.m.
As you go through FX, no we don't ;-) -- Bill Walker Senior Network Engineer Snap Internet Limited ------------------------------------------------------------------------------------------------ Tel: 03 348 8747 / 0800 500638 Email: bill.walker(a)team.snap.net.nz Web: www.snap.net.nz ------------------------------------------------------------------------------------------------ -----Original Message----- From: Erin Salmon - Unleash [mailto:erin(a)unleash.co.nz] Sent: Thursday, 26 July 2007 1:04 p.m. To: Bill Walker; nznog Subject: RE: [nznog] 29 Peering Points And we're probably even connected to the same router as you. Weird huh? Erin Salmon Managing Director Unleash Technology Solutions Phone: +64 3 365 1273 Mobile: +64 275 877 913 -----Original Message----- From: Bill Walker [mailto:Bill.Walker(a)staff.snap.net.nz] Sent: Thursday, 26 July 2007 12:59 p.m. To: nznog Subject: Re: [nznog] 29 Peering Points Who is this other? As the other main player only gives 1407 domestic. -- Bill Walker Senior Network Engineer Snap Internet Limited ---------------------------------------------------------------------------- -------------------- Tel: 03 348 8747 / 0800 500638 Email: bill.walker(a)team.snap.net.nz Web: www.snap.net.nz ---------------------------------------------------------------------------- -------------------- -----Original Message----- From: Nathan Ward [mailto:nznog(a)daork.net] Sent: Thursday, 26 July 2007 1:01 p.m. To: nznog Subject: Re: [nznog] 29 Peering Points Do they advertise supernets to cover those host routes, and longer- than-24-bit prefixes? On 26/07/2007, at 12:58 PM, Michael Fincham wrote:
Of course, as it stands, one other large-player ISP (who shall remain nameless) is currently giving us 3280 host routes routes, not to mention all the other prefixes smaller than a /24....
This is of course a far cry from 200k to 300k routes ;)
-Michael Fincham
On Thu, 2007-07-26 at 12:47 +1200, Nathan Ward wrote:
On 26/07/2007, at 12:40 PM, Philip D'Ath wrote:
Just thinking about all these Telecom peering points.
Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points.
Firstly, you mean "assign", not "allocate". Secondly, let's highlight, underline, and put in large type that you're assuming.
So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more.
Then consider the case when a /32 appears to be from Dunedin, and then the next second it appears to be from Wellington (because the Dunedin broadband user lost their session, and a new Wellington use just acquired their dynamic IP address). Then consider all the places these routes could be redistributed to within different ISPs, and potentially outside of their own AS. Then consider [non telecom] peering points that only accept a /24 or bigger. Not that anything is wrong with asymmetric routing, but doing it almost to the customer edge is going to make solving connectivity issues much more difficult (I can access this web site, but not that web site ...). I can see a lot of potential for route flapping, and for frequent routing updates to occur. I can also see the potential for short term route loops occurring.
That would be terrible, huh?
It's a good thing they have a network engineering group with a higher than zero competence, so that their /own/ routers don't melt down, let alone routers in other networks that they peer with.
-- Nathan Ward
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- -Michael Fincham
Unleash Technology Solutions _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
!DSPAM:22,46a7f0cb262211167819257!
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 25/07/2007 2:55 p.m. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 25/07/2007 2:55 p.m.
Suffice to say it's not FX who's giving us host routes. We do have another provider. 3000 host routes isn't enough to cause any problems, it's just lousy design. Erin Salmon Managing Director Unleash Technology Solutions Phone: +64 3 365 1273 Mobile: +64 275 877 913 -----Original Message----- From: Bill Walker [mailto:Bill.Walker(a)staff.snap.net.nz] Sent: Thursday, 26 July 2007 1:06 p.m. To: nznog Subject: Re: [nznog] 29 Peering Points As you go through FX, no we don't ;-) -- Bill Walker Senior Network Engineer Snap Internet Limited ---------------------------------------------------------------------------- -------------------- Tel: 03 348 8747 / 0800 500638 Email: bill.walker(a)team.snap.net.nz Web: www.snap.net.nz ---------------------------------------------------------------------------- -------------------- -----Original Message----- From: Erin Salmon - Unleash [mailto:erin(a)unleash.co.nz] Sent: Thursday, 26 July 2007 1:04 p.m. To: Bill Walker; nznog Subject: RE: [nznog] 29 Peering Points And we're probably even connected to the same router as you. Weird huh? Erin Salmon Managing Director Unleash Technology Solutions Phone: +64 3 365 1273 Mobile: +64 275 877 913 -----Original Message----- From: Bill Walker [mailto:Bill.Walker(a)staff.snap.net.nz] Sent: Thursday, 26 July 2007 12:59 p.m. To: nznog Subject: Re: [nznog] 29 Peering Points Who is this other? As the other main player only gives 1407 domestic. -- Bill Walker Senior Network Engineer Snap Internet Limited ---------------------------------------------------------------------------- -------------------- Tel: 03 348 8747 / 0800 500638 Email: bill.walker(a)team.snap.net.nz Web: www.snap.net.nz ---------------------------------------------------------------------------- -------------------- -----Original Message----- From: Nathan Ward [mailto:nznog(a)daork.net] Sent: Thursday, 26 July 2007 1:01 p.m. To: nznog Subject: Re: [nznog] 29 Peering Points Do they advertise supernets to cover those host routes, and longer- than-24-bit prefixes? On 26/07/2007, at 12:58 PM, Michael Fincham wrote:
Of course, as it stands, one other large-player ISP (who shall remain nameless) is currently giving us 3280 host routes routes, not to mention all the other prefixes smaller than a /24....
This is of course a far cry from 200k to 300k routes ;)
-Michael Fincham
On Thu, 2007-07-26 at 12:47 +1200, Nathan Ward wrote:
On 26/07/2007, at 12:40 PM, Philip D'Ath wrote:
Just thinking about all these Telecom peering points.
Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points.
Firstly, you mean "assign", not "allocate". Secondly, let's highlight, underline, and put in large type that you're assuming.
So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more.
Then consider the case when a /32 appears to be from Dunedin, and then the next second it appears to be from Wellington (because the Dunedin broadband user lost their session, and a new Wellington use just acquired their dynamic IP address). Then consider all the places these routes could be redistributed to within different ISPs, and potentially outside of their own AS. Then consider [non telecom] peering points that only accept a /24 or bigger. Not that anything is wrong with asymmetric routing, but doing it almost to the customer edge is going to make solving connectivity issues much more difficult (I can access this web site, but not that web site ...). I can see a lot of potential for route flapping, and for frequent routing updates to occur. I can also see the potential for short term route loops occurring.
That would be terrible, huh?
It's a good thing they have a network engineering group with a higher than zero competence, so that their /own/ routers don't melt down, let alone routers in other networks that they peer with.
-- Nathan Ward
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- -Michael Fincham
Unleash Technology Solutions _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
!DSPAM:22,46a7f0cb262211167819257!
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 25/07/2007 2:55 p.m. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 25/07/2007 2:55 p.m. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 25/07/2007 2:55 p.m. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 25/07/2007 2:55 p.m.
In some cases at least (picking a couple of routes at random...) they do seem to be giving us a less-specific route as well. Yes, we get quite a few longer-than-24-bit prefixes :) -Michael On Thu, 2007-07-26 at 13:00 +1200, Nathan Ward wrote:
Do they advertise supernets to cover those host routes, and longer- than-24-bit prefixes?
On 26/07/2007, at 12:58 PM, Michael Fincham wrote:
Of course, as it stands, one other large-player ISP (who shall remain nameless) is currently giving us 3280 host routes routes, not to mention all the other prefixes smaller than a /24....
This is of course a far cry from 200k to 300k routes ;)
-Michael Fincham
On Thu, 2007-07-26 at 12:47 +1200, Nathan Ward wrote:
On 26/07/2007, at 12:40 PM, Philip D'Ath wrote:
Just thinking about all these Telecom peering points.
Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points.
Firstly, you mean "assign", not "allocate". Secondly, let's highlight, underline, and put in large type that you're assuming.
So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more.
Then consider the case when a /32 appears to be from Dunedin, and then the next second it appears to be from Wellington (because the Dunedin broadband user lost their session, and a new Wellington use just acquired their dynamic IP address). Then consider all the places these routes could be redistributed to within different ISPs, and potentially outside of their own AS. Then consider [non telecom] peering points that only accept a /24 or bigger. Not that anything is wrong with asymmetric routing, but doing it almost to the customer edge is going to make solving connectivity issues much more difficult (I can access this web site, but not that web site ...). I can see a lot of potential for route flapping, and for frequent routing updates to occur. I can also see the potential for short term route loops occurring.
That would be terrible, huh?
It's a good thing they have a network engineering group with a higher than zero competence, so that their /own/ routers don't melt down, let alone routers in other networks that they peer with.
-- Nathan Ward
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- -Michael Fincham
Unleash Technology Solutions _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
!DSPAM:22,46a7f0cb262211167819257!
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- -Michael Fincham
Unleash Technology Solutions
So are you going to name-and-shame this "other ISP" or can we stop
this thread right here?
On 26/07/07, Michael Fincham
In some cases at least (picking a couple of routes at random...) they do seem to be giving us a less-specific route as well. Yes, we get quite a few longer-than-24-bit prefixes :)
-Michael
On Thu, 2007-07-26 at 13:00 +1200, Nathan Ward wrote:
Do they advertise supernets to cover those host routes, and longer- than-24-bit prefixes?
On 26/07/2007, at 12:58 PM, Michael Fincham wrote:
Of course, as it stands, one other large-player ISP (who shall remain nameless) is currently giving us 3280 host routes routes, not to mention all the other prefixes smaller than a /24....
This is of course a far cry from 200k to 300k routes ;)
-Michael Fincham
On Thu, 2007-07-26 at 12:47 +1200, Nathan Ward wrote:
On 26/07/2007, at 12:40 PM, Philip D'Ath wrote:
Just thinking about all these Telecom peering points.
Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points.
Firstly, you mean "assign", not "allocate". Secondly, let's highlight, underline, and put in large type that you're assuming.
So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more.
Then consider the case when a /32 appears to be from Dunedin, and then the next second it appears to be from Wellington (because the Dunedin broadband user lost their session, and a new Wellington use just acquired their dynamic IP address). Then consider all the places these routes could be redistributed to within different ISPs, and potentially outside of their own AS. Then consider [non telecom] peering points that only accept a /24 or bigger. Not that anything is wrong with asymmetric routing, but doing it almost to the customer edge is going to make solving connectivity issues much more difficult (I can access this web site, but not that web site ...). I can see a lot of potential for route flapping, and for frequent routing updates to occur. I can also see the potential for short term route loops occurring.
That would be terrible, huh?
It's a good thing they have a network engineering group with a higher than zero competence, so that their /own/ routers don't melt down, let alone routers in other networks that they peer with.
-- Nathan Ward
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- -Michael Fincham
Unleash Technology Solutions _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
!DSPAM:22,46a7f0cb262211167819257!
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- -Michael Fincham
Unleash Technology Solutions _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- patpatnz(a)gmail.com
On 26 Jul 2007, at 01:58, Michael Fincham wrote:
Of course, as it stands, one other large-player ISP (who shall remain nameless) is currently giving us 3280 host routes routes, not to mention all the other prefixes smaller than a /24....
There's nothing wrong with routes longer than a /24 at all. You can filter them if you want, but I filter on boundaries much longer than a /24 because I have enough ram and cpu grunt in my edge kit ;-) cheers -a
On Thu, 2007-07-26 at 12:40 +1200, Philip D'Ath wrote:
Just thinking about all these Telecom peering points.
Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points.
Not quite right. The points architecturally are driven by BRAS location. BRAS have their own summarisible range assigned. It's that range which will be announced. End customers are allocated out of those pools.
So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more.
Nope. It won't be /32's. http://www.telecom.co.nz/binarys/ngn_consultation_june_2007.pdf jamie
On 26/07/2007, at 12:52 PM, jamie baddeley wrote:
Just thinking about all these Telecom peering points.
Assuming that Telecom allocate IP addresses as they are requested by incoming broadband connections, as opposed to by geographic peering point, then there will be no way to summarise addresses at these peering points. Not quite right. The points architecturally are driven by BRAS location. BRAS have their own summarisible range assigned. It's
On Thu, 2007-07-26 at 12:40 +1200, Philip D'Ath wrote: that range which will be announced. End customers are allocated out of those pools.
Yes this is correct. All the BRAS use summarized ranges, most prefixes within the areas are /24 or greater but there may be some statics and some split prefixes across BRAS as the need exists. Be advised that there may be greater than /24 prefix lengths. --truman
So this will imply that those ISP which do peer at these points will have to listen to a good 100k odd /32 announcements (at the larger peering points). I could easily see the routing table having to contain 200k to 300k additional /32 routes if you want to allow least cost routing to work its best. If there are redundant paths then this could increase a lot more.
Nope. It won't be /32's. http://www.telecom.co.nz/binarys/ ngn_consultation_june_2007.pdf jamie _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On Wed, July 25, 2007 17:40, Philip D'Ath wrote:
Just thinking about all these Telecom peering points.
in the spirit of randy bush, "i encourage my competitors to run their network like this" i guess when you have more money than sense, kind-of know how to build telephone networks, have a voice interconnection contract template, and miss the good 'ol days of your monopoly, this sort of idea would seem like a godsend... <sarcasm> i wonder how long before they'll offer local ip portability (so you don't have to change your static ip when you move from one 'local area' to another) </sarcasm> /joshua -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams -
participants (11)
-
Andy Davidson
-
Bill Walker
-
David Robb
-
Erin Salmon - Unleash
-
jamie baddeley
-
joshua sahala
-
Michael Fincham
-
Nathan Ward
-
Patrick Jordan-Smith
-
Philip D'Ath
-
Truman Boyes