How many legitimate cases when Origin AS in BGP announcement changed by another AS?
Hi I am looking for example routing policies when any AS receiving BGP advertisement changes Origin AS in BGP AS set attribute to remove the received AS number and puts its own AS number.[legitimate cases] 1. customer AS advertises the prefix however provider AS announce the aggregate(super prefix) shall put it's AS number in the BGP announcement.It may or may not suppress the customer BGP announcement based on multihoming.Well, we may say this is not a change in origin AS but new BGP announcement. 2.Can it happen in the case of private/public peering ? 3.ASes managed by same organization? 4.Are there cases it can be done for sub prefix or exact prefix announcement forwarding? Thank you. Akmal PhD Student MMLAB,SNU,Korea --- On Tue, 1/4/11, nanog-request@nanog.org <nanog-request@nanog.org> wrote: From: nanog-request@nanog.org <nanog-request@nanog.org> Subject: NANOG Digest, Vol 36, Issue 7 To: nanog@nanog.org Date: Tuesday, January 4, 2011, 12:00 PM Send NANOG mailing list submissions to nanog@nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request@nanog.org You can reach the person managing the list at nanog-owner@nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: Router only speaks IGP in BGP network (Tarig Ahmed) 2. Software For Telcos (jacob miller) 3. 2010 IPv4 (and IPv6) Address Use Report (Iljitsch van Beijnum) 4. RES: Software For Telcos (Takashi Tome) ---------------------------------------------------------------------- Message: 1 Date: Tue, 4 Jan 2011 09:00:27 +0300 From: Tarig Ahmed <tariq198487@hotmail.com> Subject: Re: Router only speaks IGP in BGP network To: Jeff Aitken <jaitken@aitken.com> Cc: nanog@nanog.org Message-ID: <BLU0-SMTP1103BD6461EF9DAA4EAFAD0BB080@phx.gbl> Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes On Jan 3, 2011, at 8:02 PM, Jeff Aitken <jaitken@aitken.com> wrote:
On Sat, Dec 25, 2010 at 08:52:42AM -0500, ML wrote:
If you're only redistributing 10 prefixes into OSPF? Problem?
I know I'm a little late to this thread, but figured I'd point out one reason why this can be very dangerous:
In IOS, you use a route-map to control redistribution between protocols. For example, if you want to redist just those BGP prefixes tagged with a specific community into OSPF, you will probably configure something that looks like this:
route-map bgp-to-ospf permit 10 match community $COMMUNITY ! route-map bgp-to-ospf deny 20 ! router ospf $PID redistribute bgp $ASN subnets route-map bgp-to-ospf
Now, consider the following failure scenarios:
1. Someone typo's a BGP config elsewhere in your network and attaches $COMMUNITY to a whole bunch more routes... say, all 350k being sent by your upstream provider. *oops*
2. An engineer thinks that there's something wrong with the redistribution and decides to temporarily disable it as part of the troubleshooting process. He types the following:
conf t router ospf $PID no redistribute bgp $ASN subnets route-map bgp-to-ospf
*boom*
He just dumped all BGP routes into OSPF, due to the way IOS parses the command: it removes the route-map but leaves the redistribution intact. To be fair, Cisco does provide you with tools to mitigate this risk (see the "redistribute maximum-prefix" command) but the point is that this is a fairly easy mistake to make.
At the end of the day, the reason that many folks advise against the redistribution of BGP into an IGP is that it sets the stage for a seemingly insignificant mistake to cause a not-so-insignificant outage.
--Jeff
This is an interesting point. But why cisco *no* command does not remove the redistribute , I think it should do. Thanks ------------------------------ Message: 2 Date: Mon, 3 Jan 2011 23:04:14 -0800 (PST) From: jacob miller <mmzinyi@yahoo.com> Subject: Software For Telcos To: nanog@nanog.org Message-ID: <360440.86064.qm@web39502.mail.mud.yahoo.com> Content-Type: text/plain; charset=us-ascii Hi, I have been wondering what type of Software do top telcos use. The tracking of Customer circuits to ensure that from marketing,sales,accounts and technical department everything to do with the circuits has to be tracked. Anyone with any help in regards to top software that can be used to run such a telco to ensure that world class service is obtained will be crucial. Regards, Jacob ------------------------------ Message: 3 Date: Tue, 4 Jan 2011 12:29:48 +0100 From: Iljitsch van Beijnum <iljitsch@muada.com> Subject: 2010 IPv4 (and IPv6) Address Use Report To: NANOG list <nanog@nanog.org> Message-ID: <49A2BD30-5F17-40FA-A862-FF8C7496DAE0@muada.com> Content-Type: text/plain; charset=us-ascii [ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. ] On the web: IPv4: http://www.bgpexpert.com/addrspace2010.php IPv6: http://www.bgpexpert.com/addrspace-ipv6-2010.php The IPv4 one is included below: 2010 IPv4 Address Use Report As of January 1, 2011, the number of unused IPv4 addresses is 495.66 million. Exactly a year earlier, the number of available addresses was 721.06 million. So we collectively used up 225.4 million addresses in 2010. 35 of the 256 the /8s that make up the IPv4 address space have the status "reserved". 0 and 127 have special meaning and can't be used for normal purposes. 224 - 239 are used for multicast and 240 - 255 are "reserved for future use". With only about two years worth of IPv4 addresses remaining on the shelves, it would seem that that future is here now, but unfortunately, pretty much all operating systems balk at using a "reserved" address. So unreserving those addresses means upgrading EVERY system connected to the Internet. If we're going to do that, we may as well skip those reserved IPv4 addresses and upgrade to IPv6. Last but not least, there's block 10, which is the largest of the three address blocks set aside for private use. The others, 172.16.0.0/12 and 192.168.0.0/16, don't show up as reserved, but are obviously not available for regular use. This makes the total number of usable IPv4 addresses is (256 - 35) * 2^24 - 2^20 - 2^16 = 3706.65 million addresses. The "IANA global pool" consists of 7 /8s (117.44 million) are still unused (unallocated): 39/8, 102/8, 103/8, 104/8, 106/8, 179/8 and 185/8. But there's also a lot of unused space hiding in the "allocated" and "legacy" categories. Each RIR publishes a list of address blocks further delegated to ISPs or end users every day on their FTP servers. If we add up all those blocks, this comes out to 3210.99 million addresses. So the total number of usable-but-unused IPv4 addresses is 3706.65 - 3210.99 = 495.66 million. Going back to the IANA global pool, these are the changes over the past year: Delegated Blocks +/- 2010 to/status AfriNIC 3 +1 APNIC 42 +8 ARIN 35 +4 LACNIC 8 +2 RIPE NCC 34 +4 LEGACY 92 UNALLOCATED 7 -19 There is an agreement between IANA and the RIRs that each RIR will get one of the last five /8s. APNIC has been getting two /8s every three months like clockwork in 2010. If this continues, they'll be getting numbers 7 and 6 later this month, and then the final distribution will look like this: Delegated Blocks +/- 2010 to/status AfriNIC 4 APNIC 45 ARIN 36 LACNIC 9 RIPE NCC 35 LEGACY 92 UNALLOCATED - At this point, it becomes very interesting what the status of the legacy space is, exactly. The legacy blocks are each "administered" by one of the RIRs, but does that mean that that RIR is free to further delegate that space to ISPs and end users? There are 146.92 million unused addresses in legacy space, including 16.65 million returned by Interop a few months ago. This is the used versus unused address space administered by each RIR: Legacy Allocated total unused total unused AfriNIC 33.55 24.85 50.33 27.06 APNIC 100.66 22.32 704.64 44.38 ARIN 654.31 60.55 587.20 56.21 LACNIC - - 134.22 37.39 RIPE NCC 67.11 5.77 570.43 67.38 IANA 671.09 16.65 - - AfriNIC used up 8.95 million addresses last year. So their current unused allocated space is good for another three years (if nothing changes) and their final /8 is worth another almost two years. If they get to use their legacy space, that buys them another 2.5 years. So unless IPv4 address use <em>really</em> takes off in Africa, AfriNIC will be handing out addresses for at least three or four years. APNIC is at the opposite end of the spectrum, using up no less than 126.22 million new IPv4 addresses last year. Even if they get to use the legacy space they administer on top of three of the last seven /8s and, it's hard to see how APNIC can avoid having to tell people "no" before the year is out. However, there is a caveat: in the 2010 APNIC records, there is 6.65 million addresses worth of space that isn't in the 2011 records. Part of this is address space returned to APNIC. In other cases, an address block delegated in a previous year expands or shrinks retroactively. Depending on what the underlying reason for these changes is, the actual rate at which APNIC and the other RIRs are giving out address space may be different from what it seems to be at first glance. ARIN, LACNIC, and the RIPE NCC used up 54.55, 17.29, and 75.45 million addresses, respectively, in 2010. However, ARIN saw 27.24 million addresses returned, including the 16.65 million from Interop, which is administered in the ARIN records even though the IANA list doesn't reflect this. For AfriNIC, LACNIC and the RIPE NCC the numbers of addresses that came back were 0.31, 0.22, and 22.62 million, respectively. With respect to running out of addresses, it's important to realize that the Pareto principle (the 80/20 rule) applies: out of the 7686 address blocks given out last year, only 392 (5 percent) were blocks larger than 100,000 addresses, but those were responsible for 82 percent of the address <em>space</em> given out. Even when the RIRs are no longer able to give out those large blocks, they may still be able to fulfill the requests for address blocks smaller than 10,000 addresses. Last year, 6425 such blocks were given out, totaling 14.03 million addresses. It really only takes a single address to be in the content business; it's the ISPs that need a continuous supply of new addresses to connect new customers. So the address shortages looming beyond the summer will hit ISPs and their broadband/mobile customers first and foremost, and the content industry to a much lesser degree. The top 15 IPv4 address holding countries: 2011-01-01 2010-01-01 Increase Country 1 - US 1519.53 M 1495.13 M 1.6% United States 2 - CN 277.64 M 232.45 M 19.4% China 3 - JP 186.82 M 177.15 M 5.5% Japan 4 - EU 151.80 M 149.48 M 1.6% Multi-country in Europe 5 (6) KR 103.50 M 77.77 M 33.1% Korea 6 (5) DE 91.61 M 86.51 M 5.9% Germany 7 (9) GB 82.25 M 74.18 M 10.9% United Kingdom 8 - CA 79.53 M 76.96 M 3.3% Canada 9 - FR 79.29 M 75.54 M 5.0% France 10 - AU 49.10 M 39.77 M 23.5% Australia 11 - BR 40.24 M 33.95 M 18.5% Brazil 12 - IT 37.14 M 33.50 M 10.9% Italy 13 - RU 34.66 M 28.47 M 21.7% Russia 14 - TW 31.93 M 27.10 M 17.8% Taiwan 15 (19) IN 28.70 M 19.42 M 47.8% India Because the US holds so much space, the increase of 25 million addresses seems small, but that's still more than 10% of the address space given out in 2010. China's growth is slowing down a little at 45 million addresses last year compared to 50 million in 2009. But other countries in Asia are picking up the slack and then some: Korea keeps using up large amounts of address space, and India is now also picking up the pace. The US now has 47.3% of the address space in use, down from 50.1% a year ago. The other countries in the top 15 collectively hold 39.7%, up from 38%. That leaves 13% for the rest of the world, up from 12%. Note that I slightly changed the way addresses are counted: previously, all the legacy blocks that didn't have an RIR listed were assumed to be used 100%. But with the return of most of the Interop block this is no longer the case: although ARIN isn't listed as administering the 45/8 block, they actually are and only have 45.0.0.0/15 listed as in use. ------------------------------ Message: 4 Date: Tue, 4 Jan 2011 09:34:53 -0200 From: "Takashi Tome" <takashi@cpqd.com.br> Subject: RES: Software For Telcos To: <nanog@nanog.org> Message-ID: <E723F40B750C0D47B43CDC67EFC3806E1CE4CE@MAILSRV4.aquarius.cpqd.com.br> Content-Type: text/plain; charset="iso-8859-1" Hi Jacob, Generally, top telcos use software made by top telco's software vendors... of course :-) Say in other words, top telco's equipment vendors have their own sw team or third-party suppliers. Equipment vendors are Alcatel, Lucent (ex-AT&T), Ericsson, Nokia, etc. You can see at those companies' web site to check. Which kind of software: - system and service management; - CRM; - switching, IMS, etc; - billing; and so on. Hope it works. Takashi Tome takashi@cpqd.com.br www.cpqd.com.br -----Mensagem original----- De: jacob miller [mailto:mmzinyi@yahoo.com] Enviada em: ter?a-feira, 4 de janeiro de 2011 05:04 Para: nanog@nanog.org Assunto: Software For Telcos Hi, I have been wondering what type of Software do top telcos use. The tracking of Customer circuits to ensure that from marketing,sales,accounts and technical department everything to do with the circuits has to be tracked. Anyone with any help in regards to top software that can be used to run such a telco to ensure that world class service is obtained will be crucial. Regards, Jacob ------------------------------ _______________________________________________ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 36, Issue 7 ************************************
Hi Last week I faced a case like this in an african NREN. This NREN provides Internet and Academic traffic to thier members, but there are some members leases a layer 3 VPN from local ISP in order to get to thier NREN POPs. Engineers of this NREN desided for some reseans to use eBGP from thier POPs to this VPN, and to use OSPF from the VPN to thier members (member routers do not support BGP). In this case the route will originate form the ISP which not actually posses those prefixes. No upstream will accept this unless the NREN removes the local ISP ASN and announce new fresh routes, and this which actually happened with aggregate and suppress-map cisco commands. I hope this a legitmate case. Thanks Tarig Yassin Ahmed On Jan 4, 2011, at 4:38 AM, Akmal Shahbaz <akmal_shahbaz@yahoo.com> wrote:
Hi
I am looking for example routing policies when any AS receiving BGP advertisement changes Origin AS in BGP AS set attribute to remove the received AS number and puts its own AS number.[legitimate cases]
1. customer AS advertises the prefix however provider AS announce the aggregate(super prefix) shall put it's AS number in the BGP announcement.It may or may not suppress the customer BGP announcement based on multihoming.Well, we may say this is not a change in origin AS but new BGP announcement.
2.Can it happen in the case of private/public peering ?
3.ASes managed by same organization?
4.Are there cases it can be done for sub prefix or exact prefix announcement forwarding?
Thank you.
Akmal PhD Student MMLAB,SNU,Korea
--- On Tue, 1/4/11, nanog-request@nanog.org <nanog- request@nanog.org> wrote:
From: nanog-request@nanog.org <nanog-request@nanog.org> Subject: NANOG Digest, Vol 36, Issue 7 To: nanog@nanog.org Date: Tuesday, January 4, 2011, 12:00 PM
Send NANOG mailing list submissions to nanog@nanog.org
To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request@nanog.org
You can reach the person managing the list at nanog-owner@nanog.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..."
Today's Topics:
1. Re: Router only speaks IGP in BGP network (Tarig Ahmed) 2. Software For Telcos (jacob miller) 3. 2010 IPv4 (and IPv6) Address Use Report (Iljitsch van Beijnum) 4. RES: Software For Telcos (Takashi Tome)
----------------------------------------------------------------------
Message: 1 Date: Tue, 4 Jan 2011 09:00:27 +0300 From: Tarig Ahmed <tariq198487@hotmail.com> Subject: Re: Router only speaks IGP in BGP network To: Jeff Aitken <jaitken@aitken.com> Cc: nanog@nanog.org Message-ID: <BLU0-SMTP1103BD6461EF9DAA4EAFAD0BB080@phx.gbl> Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes
On Jan 3, 2011, at 8:02 PM, Jeff Aitken <jaitken@aitken.com> wrote:
On Sat, Dec 25, 2010 at 08:52:42AM -0500, ML wrote:
If you're only redistributing 10 prefixes into OSPF? Problem?
I know I'm a little late to this thread, but figured I'd point out one reason why this can be very dangerous:
In IOS, you use a route-map to control redistribution between protocols. For example, if you want to redist just those BGP prefixes tagged with a specific community into OSPF, you will probably configure something that looks like this:
route-map bgp-to-ospf permit 10 match community $COMMUNITY ! route-map bgp-to-ospf deny 20 ! router ospf $PID redistribute bgp $ASN subnets route-map bgp-to-ospf
Now, consider the following failure scenarios:
1. Someone typo's a BGP config elsewhere in your network and attaches $COMMUNITY to a whole bunch more routes... say, all 350k being sent by your upstream provider. *oops*
2. An engineer thinks that there's something wrong with the redistribution and decides to temporarily disable it as part of the troubleshooting process. He types the following:
conf t router ospf $PID no redistribute bgp $ASN subnets route-map bgp-to-ospf
*boom*
He just dumped all BGP routes into OSPF, due to the way IOS parses the command: it removes the route-map but leaves the redistribution intact. To be fair, Cisco does provide you with tools to mitigate this risk (see the "redistribute maximum-prefix" command) but the point is that this is a fairly easy mistake to make.
At the end of the day, the reason that many folks advise against the redistribution of BGP into an IGP is that it sets the stage for a seemingly insignificant mistake to cause a not-so-insignificant outage.
--Jeff
This is an interesting point. But why cisco *no* command does not remove the redistribute , I think it should do.
Thanks
------------------------------
Message: 2 Date: Mon, 3 Jan 2011 23:04:14 -0800 (PST) From: jacob miller <mmzinyi@yahoo.com> Subject: Software For Telcos To: nanog@nanog.org Message-ID: <360440.86064.qm@web39502.mail.mud.yahoo.com> Content-Type: text/plain; charset=us-ascii
Hi,
I have been wondering what type of Software do top telcos use.
The tracking of Customer circuits to ensure that from marketing,sales,accounts and technical department everything to do with the circuits has to be tracked.
Anyone with any help in regards to top software that can be used to run such a telco to ensure that world class service is obtained will be crucial.
Regards, Jacob
------------------------------
Message: 3 Date: Tue, 4 Jan 2011 12:29:48 +0100 From: Iljitsch van Beijnum <iljitsch@muada.com> Subject: 2010 IPv4 (and IPv6) Address Use Report To: NANOG list <nanog@nanog.org> Message-ID: <49A2BD30-5F17-40FA-A862-FF8C7496DAE0@muada.com> Content-Type: text/plain; charset=us-ascii
[ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. ]
On the web:
IPv4: http://www.bgpexpert.com/addrspace2010.php IPv6: http://www.bgpexpert.com/addrspace-ipv6-2010.php
The IPv4 one is included below:
2010 IPv4 Address Use Report
As of January 1, 2011, the number of unused IPv4 addresses is 495.66 million. Exactly a year earlier, the number of available addresses was 721.06 million. So we collectively used up 225.4 million addresses in 2010.
35 of the 256 the /8s that make up the IPv4 address space have the status "reserved". 0 and 127 have special meaning and can't be used for normal purposes. 224 - 239 are used for multicast and 240 - 255 are "reserved for future use". With only about two years worth of IPv4 addresses remaining on the shelves, it would seem that that future is here now, but unfortunately, pretty much all operating systems balk at using a "reserved" address. So unreserving those addresses means upgrading EVERY system connected to the Internet. If we're going to do that, we may as well skip those reserved IPv4 addresses and upgrade to IPv6. Last but not least, there's block 10, which is the largest of the three address blocks set aside for private use. The others, 172.16.0.0/12 and 192.168.0.0/16, don't show up as reserved, but are obviously not available for regular use.
This makes the total number of usable IPv4 addresses is (256 - 35) * 2^24 - 2^20 - 2^16 = 3706.65 million addresses. The "IANA global pool" consists of 7 /8s (117.44 million) are still unused (unallocated): 39/8, 102/8, 103/8, 104/8, 106/8, 179/8 and 185/8. But there's also a lot of unused space hiding in the "allocated" and "legacy" categories. Each RIR publishes a list of address blocks further delegated to ISPs or end users every day on their FTP servers. If we add up all those blocks, this comes out to 3210.99 million addresses. So the total number of usable-but-unused IPv4 addresses is 3706.65 - 3210.99 = 495.66 million.
Going back to the IANA global pool, these are the changes over the past year:
Delegated Blocks +/- 2010 to/status
AfriNIC 3 +1 APNIC 42 +8 ARIN 35 +4 LACNIC 8 +2 RIPE NCC 34 +4 LEGACY 92 UNALLOCATED 7 -19
There is an agreement between IANA and the RIRs that each RIR will get one of the last five /8s. APNIC has been getting two /8s every three months like clockwork in 2010. If this continues, they'll be getting numbers 7 and 6 later this month, and then the final distribution will look like this:
Delegated Blocks +/- 2010 to/status
AfriNIC 4 APNIC 45 ARIN 36 LACNIC 9 RIPE NCC 35 LEGACY 92 UNALLOCATED -
At this point, it becomes very interesting what the status of the legacy space is, exactly. The legacy blocks are each "administered" by one of the RIRs, but does that mean that that RIR is free to further delegate that space to ISPs and end users? There are 146.92 million unused addresses in legacy space, including 16.65 million returned by Interop a few months ago. This is the used versus unused address space administered by each RIR:
Legacy Allocated total unused total unused AfriNIC 33.55 24.85 50.33 27.06 APNIC 100.66 22.32 704.64 44.38 ARIN 654.31 60.55 587.20 56.21 LACNIC - - 134.22 37.39 RIPE NCC 67.11 5.77 570.43 67.38 IANA 671.09 16.65 - -
AfriNIC used up 8.95 million addresses last year. So their current unused allocated space is good for another three years (if nothing changes) and their final /8 is worth another almost two years. If they get to use their legacy space, that buys them another 2.5 years. So unless IPv4 address use <em>really</em> takes off in Africa, AfriNIC will be handing out addresses for at least three or four years.
APNIC is at the opposite end of the spectrum, using up no less than 126.22 million new IPv4 addresses last year. Even if they get to use the legacy space they administer on top of three of the last seven / 8s and, it's hard to see how APNIC can avoid having to tell people "no" before the year is out. However, there is a caveat: in the 2010 APNIC records, there is 6.65 million addresses worth of space that isn't in the 2011 records. Part of this is address space returned to APNIC. In other cases, an address block delegated in a previous year expands or shrinks retroactively. Depending on what the underlying reason for these changes is, the actual rate at which APNIC and the other RIRs are giving out address space may be different from what it seems to be at first glance.
ARIN, LACNIC, and the RIPE NCC used up 54.55, 17.29, and 75.45 million addresses, respectively, in 2010. However, ARIN saw 27.24 million addresses returned, including the 16.65 million from Interop, which is administered in the ARIN records even though the IANA list doesn't reflect this. For AfriNIC, LACNIC and the RIPE NCC the numbers of addresses that came back were 0.31, 0.22, and 22.62 million, respectively.
With respect to running out of addresses, it's important to realize that the Pareto principle (the 80/20 rule) applies: out of the 7686 address blocks given out last year, only 392 (5 percent) were blocks larger than 100,000 addresses, but those were responsible for 82 percent of the address <em>space</em> given out. Even when the RIRs are no longer able to give out those large blocks, they may still be able to fulfill the requests for address blocks smaller than 10,000 addresses. Last year, 6425 such blocks were given out, totaling 14.03 million addresses. It really only takes a single address to be in the content business; it's the ISPs that need a continuous supply of new addresses to connect new customers. So the address shortages looming beyond the summer will hit ISPs and their broadband/mobile customers first and foremost, and the content industry to a much lesser degree.
The top 15 IPv4 address holding countries:
2011-01-01 2010-01-01 Increase Country
1 - US 1519.53 M 1495.13 M 1.6% United States 2 - CN 277.64 M 232.45 M 19.4% China 3 - JP 186.82 M 177.15 M 5.5% Japan 4 - EU 151.80 M 149.48 M 1.6% Multi-country in Europe 5 (6) KR 103.50 M 77.77 M 33.1% Korea 6 (5) DE 91.61 M 86.51 M 5.9% Germany 7 (9) GB 82.25 M 74.18 M 10.9% United Kingdom 8 - CA 79.53 M 76.96 M 3.3% Canada 9 - FR 79.29 M 75.54 M 5.0% France 10 - AU 49.10 M 39.77 M 23.5% Australia 11 - BR 40.24 M 33.95 M 18.5% Brazil 12 - IT 37.14 M 33.50 M 10.9% Italy 13 - RU 34.66 M 28.47 M 21.7% Russia 14 - TW 31.93 M 27.10 M 17.8% Taiwan 15 (19) IN 28.70 M 19.42 M 47.8% India
Because the US holds so much space, the increase of 25 million addresses seems small, but that's still more than 10% of the address space given out in 2010. China's growth is slowing down a little at 45 million addresses last year compared to 50 million in 2009. But other countries in Asia are picking up the slack and then some: Korea keeps using up large amounts of address space, and India is now also picking up the pace. The US now has 47.3% of the address space in use, down from 50.1% a year ago. The other countries in the top 15 collectively hold 39.7%, up from 38%. That leaves 13% for the rest of the world, up from 12%.
Note that I slightly changed the way addresses are counted: previously, all the legacy blocks that didn't have an RIR listed were assumed to be used 100%. But with the return of most of the Interop block this is no longer the case: although ARIN isn't listed as administering the 45/8 block, they actually are and only have 45.0.0.0/15 listed as in use.
------------------------------
Message: 4 Date: Tue, 4 Jan 2011 09:34:53 -0200 From: "Takashi Tome" <takashi@cpqd.com.br> Subject: RES: Software For Telcos To: <nanog@nanog.org> Message-ID: <E723F40B750C0D47B43CDC67EFC3806E1CE4CE@MAILSRV4.aquarius.cpqd.com.br
Content-Type: text/plain; charset="iso-8859-1"
Hi Jacob,
Generally, top telcos use software made by top telco's software vendors... of course :-)
Say in other words, top telco's equipment vendors have their own sw team or third-party suppliers. Equipment vendors are Alcatel, Lucent (ex-AT&T), Ericsson, Nokia, etc. You can see at those companies' web site to check.
Which kind of software: - system and service management; - CRM; - switching, IMS, etc; - billing; and so on.
Hope it works.
Takashi Tome takashi@cpqd.com.br www.cpqd.com.br
-----Mensagem original----- De: jacob miller [mailto:mmzinyi@yahoo.com] Enviada em: ter?a-feira, 4 de janeiro de 2011 05:04 Para: nanog@nanog.org Assunto: Software For Telcos
Hi,
I have been wondering what type of Software do top telcos use.
The tracking of Customer circuits to ensure that from marketing,sales,accounts and technical department everything to do with the circuits has to be tracked.
Anyone with any help in regards to top software that can be used to run such a telco to ensure that world class service is obtained will be crucial.
Regards, Jacob
------------------------------
_______________________________________________ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
End of NANOG Digest, Vol 36, Issue 7 ************************************
On Tue, Jan 04, 2011 at 04:38:19AM -0800, Akmal Shahbaz <akmal_shahbaz@yahoo.com> wrote a message of 443 lines which said:
I am looking for example routing policies when any AS receiving BGP advertisement changes Origin AS in BGP AS set attribute to remove the received AS number and puts its own AS number.[legitimate cases]
When the old origin AS was a private one? Today, with 32bits AS, everyone should have a public AS number but, in the real world, some people do BGP with private AS that the upstream provider has to change.
When the old origin AS was a private one? NO.Even when old origin AS is not private one.
Don't you think private/pubic AS won't matter in case of provider aggregation? Thanks Akmal --- On Tue, 1/4/11, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote: From: Stephane Bortzmeyer <bortzmeyer@nic.fr> Subject: Re: How many legitimate cases when Origin AS in BGP announcement changed by another AS? To: "Akmal Shahbaz" <akmal_shahbaz@yahoo.com> Cc: nanog@nanog.org Date: Tuesday, January 4, 2011, 4:05 PM On Tue, Jan 04, 2011 at 04:38:19AM -0800, Akmal Shahbaz <akmal_shahbaz@yahoo.com> wrote a message of 443 lines which said:
I am looking for example routing policies when any AS receiving BGP advertisement changes Origin AS in BGP AS set attribute to remove the received AS number and puts its own AS number.[legitimate cases]
When the old origin AS was a private one? Today, with 32bits AS, everyone should have a public AS number but, in the real world, some people do BGP with private AS that the upstream provider has to change.
On Tue, Jan 04, 2011 at 08:22:35AM -0800, Akmal Shahbaz <akmal_shahbaz@yahoo.com> wrote a message of 44 lines which said:
When the old origin AS was a private one? NO.Even when old origin AS is not private one.
You misunderstood me. I replied to your query "When is it legitimate to change an origin AS?" by adding a possibility you did not mention: "When the origin AS is a private one".
participants (3)
-
Akmal Shahbaz -
Stephane Bortzmeyer -
Tarig Ahmed