Chunghwa Telecom Tech Support Reg.
Hi All, Does anyone have the contact number for Chunghwa Telecom's Business Users - Technical Support number ? -Nat
Re: Chunghwa Telecom Tech Support Reg.
Note: I need the Technical Support Contact number for Chunghwa Telecom in Taiwan. --- On Thu, 12/8/10, Natarajan Balasubramanian ptb...@yahoo.com wrote: From: Natarajan Balasubramanian ptb...@yahoo.com Subject: Chunghwa Telecom Tech Support Reg. To: nanog@nanog.org Date: Thursday, 12 August, 2010, 11:48 AM Hi All, Does anyone have the contact number for Chunghwa Telecom's Business Users - Technical Support number ? -Nat
RE: Chunghwa Telecom Tech Support Reg.
0800-080-100 Yasir Abbasi -Original Message- From: Natarajan Balasubramanian [mailto:ptb...@yahoo.com] Sent: Thursday, August 12, 2010 11:24 AM To: nanog@nanog.org Subject: Re: Chunghwa Telecom Tech Support Reg. Note: I need the Technical Support Contact number for Chunghwa Telecom in Taiwan. --- On Thu, 12/8/10, Natarajan Balasubramanian ptb...@yahoo.com wrote: From: Natarajan Balasubramanian ptb...@yahoo.com Subject: Chunghwa Telecom Tech Support Reg. To: nanog@nanog.org Date: Thursday, 12 August, 2010, 11:48 AM Hi All, Does anyone have the contact number for Chunghwa Telecom's Business Users - Technical Support number ? -Nat
Re: off-topic: summary on Internet traffic growth History
MCI and BT had a long courtship. BT left MCI standing at the altar after neighborhoodMCI (a consumer last mile play) announced $400M in losses, twice. WorldCom swooped in after that. jy On 12/08/2010, at 12:12 PM, jim deleskie deles...@gmail.com wrote: CIP went with BT (Concert) I still clearly remember the very long concall when we separated it from it BIPP connections. :) -jim On Wed, Aug 11, 2010 at 4:10 PM, Chris Boyd cb...@gizmopartners.com wrote: On Aug 11, 2010, at 1:13 PM, John Lee wrote: MCI bought MFS-Datanet because MCI had the customers and MFS-Datanet had all of the fiber running to key locations at the time and could drastically cut MCI's costs. UUNET merged with MCI and their traffic was put on this same network. MCI went belly up and Verizon bought the network. Although not directly involved in the MCI Internet operations, I read all the announcements that came across the email when I worked at MCI from early 1993 to late 1998. My recollection is that Worldcom bought out MFS. UUnet was a later acquisition by the Worldcom monster (no, no biases here :-). While this was going on MCI was building and running what was called the BIPP (Basic IP Platform) internally. That product was at least reasonably successful, enough so that some gummint powers that be required divestiture of the BIPP from the company that would come out of the proposed acquisition of MCI by Worldcom. The regulators felt that Worldcom would have too large a share of the North American Internet traffic. The BIPP went with BT IIRC, and I think finally landed in Global Crossing's assets. --Chris
Re: off-topic: summary on Internet traffic growth History
N3 = new network nodes, BIPP wasn't that great a name either. The ASN was always 3561. jy On 12/08/2010, at 8:20 AM, Benson Schliesser bens...@queuefull.net wrote: On 11 Aug 10, at 2:10 PM, Chris Boyd wrote: My recollection is that Worldcom bought out MFS. UUnet was a later acquisition by the Worldcom monster (no, no biases here :-). While this was going on MCI was building and running what was called the BIPP (Basic IP Platform) internally. That product was at least reasonably successful, enough so that some gummint powers that be required divestiture of the BIPP from the company that would come out of the proposed acquisition of MCI by Worldcom. The regulators felt that Worldcom would have too large a share of the North American Internet traffic. The BIPP went with BT IIRC, and I think finally landed in Global Crossing's assets. Actually, Cable Wireless acquired the BIPP after regulators forced Worldcom to divest one of their networks. CW developed a new network architecture as an evolution of BIPP called N3, based on MPLS as an ATM replacement for TE. (Perhaps somebody that worked at CW back then can comment on N3; I can't recall what it stood for.) After a few years, CW reorganized their American operations into a separate entity, which subsequently went bankrupt. Savvis (my current employer) bought the assets out of bankruptcy court. We then upgraded the N3 network to support better QoS, higher capacity, etc, and call it the ATN (Application Transport Network). The current Savvis core network, AS3561, is thus the evolved offspring of the MCI Internet Services / Internet-MCI network. Of course, before all of this, MCI built the network as a commercial Internet platform in parallel to their ARPA network. That's before my time, unfortunately, so I don't know many details. For instance I'm uncertain how the ASN has changed over the years. Anybody with more history and/or corrections would be appreciated. Cheers, -Benson
IPv6 Server Load Balancing - DSR
Dear Colleagues, I've been scratching my head over this for the past couple of months and have come up with blanks, and several weeks of scouring various resources on the net have not yielded anything more fruitful. I'm looking at server load balancing for IPv6 and specifically need DSR (direct server return). Additionally, I need to support both TCP and UDP. I have evaluated a number of different load balancing solutions purporting to support IPv6 with varying results (and costs)... a few examples: F5 : according to marketing blurb supposedly supports IPv6 in NAT and DSR mode, both UDP and TCP. Their documentation, however, has no mention of IPv6 capability. Other disadvantage = cost... Brocade/Foundry: Similar situation to F5 Zeus: IPv6 in NAT only, and even more expensive than F5. Exceliance Aloha: IPv6 in NAT only, and ONLY in TCP (no UDP) A few others also tested... including LVM/HAProxy (same situation as Exceliance Aloha), and others... Finally in the end, only OpenSolaris ILB seems to put all the checks in the right boxes for my requirements. But there is still a problem. 1. IPv4 TCP and UDP work fine in NAT, Half-NAT, and DSR 2. IPv6 I've managed to get working, complete with healthchecks, in TCP and UDP in NAT only although the documentation stipulates that DSR is also possible (but not HalfNAT for the moment). The problem with #2: Using the same server farm behind, but in dual-stack, and configuring ILB for TCP and UDP services using NAT, everything is fine. If I configure it for DSR, immediately it fails (both with and without healthchecks). Although from the ILB host itself, I can certainly do a manual heathcheck.. (e.g. telnet server_real_ipv6_addr 80 and do GET / or HEAD / with no problems. Using ARP poisoning from the shell I can also perform the healthcheck on the real server via telnet using the virtual ip. The servers are configured normally for DSR.. with the virtual IP attached to a local dummy or loopback interface, and with IPv4 DSR works fine. Nevertheless, I've been unable to get DSR working with ILB -- and have found absolutely nothing around the net with working examples of IPv6 SLB with DSR. NAT mode works fine, but the real server loses visibility of the end user's IP as the requests come from the internal IP of the ILB host, and with a system that uses client IP address as part of the various criteria for session tracking, it creates a few problems... I am suspecting that the issue may be related to ND, as the behaviour is similar to the old story with doing DSR on real-servers using older linux distributions that do not by default disable proxy-ARP replies by the server for IP addresses on dummy or loopback interfaces, and of course the proxy ARP causes confusion to the load balancer and breaks the whole thing. But the real servers are recent Debian distributions, and both ipv4 ARP and ipv6 ND is disabled on the dummy interfaces, as is proxy ARP. Would anyone happen to have any useful pointers, tips, or other on how to resolve the issue? Many thanks in advance. Leland
Re: IPv6 Server Load Balancing - DSR
On 2010-08-12 08:32, Leland Vandervort wrote: I'm looking at server load balancing for IPv6 and specifically need DSR (direct server return). Additionally, I need to support both TCP and UDP. This is easily done with OpenBSD. See here for starters: http://www.undeadly.org/cgi?action=articlesid=20080617010016 Simon -- NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Re: IPv6 Server Load Balancing - DSR
Hi Leland, Seems that hardware vendors doesn't like IPv6... for load balancing. I had a look to relayd from OpenBSD, and it seems this can be used a LoadBalancing with DSR... Even if they don't recommand this ... Maybe the is is the time to move from hardware / closed solutions to open ones.. ? Xavier
Re: IPv6 Server Load Balancing - DSR
OpenSolaris ILB is open solution ;) but yea, that's what we've started looking at -- hence LVM / HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for IPv6) does relayd support UDP as well as TCP or is it layer7 only like HAProxy ? In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... cheers, Leland On 12 Aug 2010, at 15:05, Xavier Beaudouin wrote: Hi Leland, Seems that hardware vendors doesn't like IPv6... for load balancing. I had a look to relayd from OpenBSD, and it seems this can be used a LoadBalancing with DSR... Even if they don't recommand this ... Maybe the is is the time to move from hardware / closed solutions to open ones.. ? Xavier
Re: IPv6 Server Load Balancing - DSR
Hi Leland, Le 12 août 2010 à 15:11, Leland Vandervort a écrit : OpenSolaris ILB is open solution ;) but yea, that's what we've started looking at -- hence LVM / HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for IPv6) does relayd support UDP as well as TCP or is it layer7 only like HAProxy ? It does everything... :) L2 - L7... In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... Maybe on some setup you should desactivate ND... Xavier
Re: IPv6 Server Load Balancing - DSR
On 12 Aug 2010, at 15:19, Xavier Beaudouin wrote: In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... Maybe on some setup you should desactivate ND... Yea.. well. .that's the point... can't deactivate ND on the real interface of the server as that's required for the server itself.. but it, according to the kernel, deactivated on the dummy interface carrying the virtual IP of the server farm... exactly as is done for IPv4 and ARP manipulation. Hm... L.
Re: IPv6 Server Load Balancing - DSR
On Thu, 12 Aug 2010, Simon Perreault wrote: On 2010-08-12 08:32, Leland Vandervort wrote: I'm looking at server load balancing for IPv6 and specifically need DSR (direct server return). Additionally, I need to support both TCP and UDP. This is easily done with OpenBSD. See here for starters: http://www.undeadly.org/cgi?action=articlesid=20080617010016 And FreeBSD: http://www.freshports.org/net/relayd/ Simon -- NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Re: IPv6 Server Load Balancing - DSR
On Thu, 12 Aug 2010 14:32:25 +0200 Leland Vandervort lel...@taranta.discpro.org wrote: I'm looking at server load balancing for IPv6 and specifically need DSR (direct server return). Additionally, I need to support both TCP and UDP. IPVS has had IPv6 support for a while: http://www.mindbasket.com/ipvs/ We're using it on our mirror site, http://ftp.heanet.ie, with DSR for http, ftp and rsync load balancing. rg -- Rob Gallagher | Public Key: 0x1DD13A78 HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1. Registered in Ireland, no 275301 T: (+353-1) 6609040 F: (+353-1) 6603666 WWW: http://www.heanet.ie/ HEAnet National Networking Conference, 10-12 November 2010 - Registration is now open at: http://www.heanet.ie/conferences/2010/ signature.asc Description: PGP signature
Re: net-neutrality
valdis.kletni...@vt.edu wrote: On Wed, 11 Aug 2010 12:23:01 CDT, Jeff Harper said: This is kind of like one person saying they're not going to listen to a radio station anymore. And the only reason I'm singing you this song now is cause you may know somebody in a similar situation, or you may be in a similar situation, and if your in a situation like that there's only one thing you can do and that's walk into the shrink wherever you are ,just walk in say Shrink, You can get anything you want, at Alice's restaurant.. And walk out. You know, if one person, just one person does it they may think he's really sick and they won't take him. And if two people, two people do it, in harmony, they may think they're both faggots and they won't take either of them. And three people do it, three, can you imagine, three people walking in singin a bar of Alice's Restaurant and walking out. They may think it's an organization. And can you, can you imagine fifty people a day,I said fifty people a day walking in singin a bar of Alice's Restaurant and walking out. And friends they may thinks it's a movement. Of course, that *does* require finding 49 other like-minded people. You may find these variations even more apt for this discussion: http://www.arlo.net/resources/lyrics/alices-nntp.shtml I went over to the Commissar, said Commissar, you got a lotta damn gall to ask me if I've rehabilitated myself, I mean, I mean, I'm just sittin' here, sittin' on the group H bench 'cause you want to know if I'm *moral* enough to join a Company to grep mail, burn electronic books, and censor feeds after bein' an NNTP hacker. He looked at me, said Kid, we don't like your kind, and we're gonna send your .newsrc down to California... And friends, somewhere in California, enshrined in some little directory, is a study in ones and zeroes of my .newsrc. And the only reason I'm singin' you this song is 'cause you may know somebody in a similar situation, or *YOU* may be in a similar situation, and if you're in a situation like that, there's only one thing you can do and that's post a message to your company's internal newsgroup, saying Commissar, you can get anything you want on Alice's NNTP server. And log off. You know, if one person, just one person does it, they may think he's really sick and won't fire him just yet, just send him down to a Training Session until his brains are jellied up. And if two people, two people do it, in harmony, they may think they're starting a cascade and will only fire one of 'em to establish a precedent and put the fear-o-God in the rest of their workers. And three people, three, can you imagine, three people logging on, posting a message containing a bar of Alice's NNTP Server and walking out, they may think it's an organization. And can you imagine fifty people a day, I said fifty people a day logging on, postin' a bar of Alice's NNTP Server and logging off. And friends, they may think it's a movement. And that's what it is, the Alice's NNTP Server Anti-Censorship Movement, and all you got to do to join is quote it the next time it comes around on the screen. With feelin'. http://www.arlo.net/resources/lyrics/alice_flame.shtml He looked at me and said, ``Kid, we don't like your kind! We're gonna send your subnet mask off to rs.internic.net!'' And, friends, somewhere in Washington, enshrined on some 5.25 inch floppy disk, is a study in ones and zeros of my brain-damaged programming style... And the only reason I'm singin' you the song now is 'cause you may know somebody in a similar situation. Or you may be in a similar situation, and if you're in a situation like that, there's only one thing you can do: [ CHORUS ] You know, if one person, just one person, does it, they may think he's really dangerous and they won't flame him. And if two people do it, in harmony, they may think they're both Perl hackers and they won't flame either of them. And if three people do it! Can you imagine three people loggin' in, singin' a bar of ``Alice's Usenet Flame'' and loggin' out? They may think it's an re-implementation of sendmail! And can you imagine fifty people a day? I said FIFTY people a day, loggin' in, singin' a bar of ``Alice's Usenet Flame'' and loggin' out? Friends, they may think it's a MOVEMENT, and that's what it is: THE INTERNET GLOBAL ANTI-LOSSAGE MOVEMENT! And all you gotta do to join is to sing it the next time it comes around on the /var/spool/news/in.coming directory. With feelin'.
Policy Based Routing advice
Hey all. I'm trying to setup a routing policy on a cat4503-E with Sup6-E and for some reason I can't see it taking effect. I'm definitely sourcing packets from 172.25.0.0/16 (the test machine had 172.25.24.25 address). For some reason the packets still go out towards the default gateway instead of what's specified in the route-map. The switch is running cat4500e-ENTSERVICESK9-M), Version 12.2(52)SG, RELEASE SOFTWARE (fc1) According to stats on the ACL and the route-map it's just not being hit for some reason. Applying the ACL directly to the interface (as an access-group) shows that the ACL is correct and I see hits, however, via the route map it's not being hit. I don't know what those 2 matches are, but there definitely should be a lot more than 2. And in addition, I see the packets arriving on the firewall that is the default gateway. Does anyone have any tips on why this might now work? ip access-list standard acl_Students permit 172.25.0.0 0.0.255.255 route-map Students-Route-Map permit 10 match ip address acl_Students set ip next-hop 192.168.168.22 interface GigabitEthernet2/6 no switchport ip address 192.168.250.1 255.255.255.252 ip pim dense-mode ip policy route-map Students-Route-Map interface GigabitEthernet2/14 no switchport ip address 192.168.168.21 255.255.255.252 no ip redirects no ip mroute-cache flowcontrol send desired cat4503#sh access-lists acl_Students Standard IP access list acl_Students 10 permit 172.25.0.0, wildcard bits 0.0.255.255 (2 matches) cat4503#sh route-map route-map Students-Route-Map, permit, sequence 10 Match clauses: ip address (access-lists): acl_Students Set clauses: ip next-hop 192.168.168.22 Policy routing matches: 2 packets, 180 bytes cat4503#sh ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via static, distance 1, metric 0, candidate default path Redistributing via eigrp 179 Advertised by eigrp 179 Routing Descriptor Blocks: * 192.168.168.10 Route metric is 0, traffic share count is 1 -- Andrey Khomyakov [khomyakov.and...@gmail.com]
Re: IPv6 Server Load Balancing - DSR
On Aug 12, 2010, at 6:19 AM, Xavier Beaudouin wrote: Hi Leland, Le 12 août 2010 à 15:11, Leland Vandervort a écrit : OpenSolaris ILB is open solution ;) but yea, that's what we've started looking at -- hence LVM / HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for IPv6) does relayd support UDP as well as TCP or is it layer7 only like HAProxy ? It does everything... :) L2 - L7... In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... Maybe on some setup you should desactivate ND... Xavier If you're putting the DSR address on an interface other than loopback, you probably need to turn of DAD on the interface with the DSR address otherwise DAD will shut down that address on the interface when it sees other servers with the same address. Sometimes it will shut down all but one, sometimes it will shut down all. Owen
Re: IPv6 Server Load Balancing - DSR
Hi Owen, The DSR address is indeed on a loopback in our case. loLink encap:Local Loopback inet6 addr: ::1/128 Scope:Host inet6 addr: ::x:::xx/128 Scope:Global The mystery continues... Leland On 12 Aug 2010, at 18:28, Owen DeLong wrote: On Aug 12, 2010, at 6:19 AM, Xavier Beaudouin wrote: Hi Leland, Le 12 août 2010 à 15:11, Leland Vandervort a écrit : OpenSolaris ILB is open solution ;) but yea, that's what we've started looking at -- hence LVM / HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for IPv6) does relayd support UDP as well as TCP or is it layer7 only like HAProxy ? It does everything... :) L2 - L7... In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... Maybe on some setup you should desactivate ND... Xavier If you're putting the DSR address on an interface other than loopback, you probably need to turn of DAD on the interface with the DSR address otherwise DAD will shut down that address on the interface when it sees other servers with the same address. Sometimes it will shut down all but one, sometimes it will shut down all. Owen
Re: IPv6 Server Load Balancing - DSR
Brocade basically sucks when it comes to loadbalancing IPv6, the old serveriron platform is EOL and a complete mess which offers some IPv6 support, but not much. The new ADX platform seems to be in a pre-alfa stage at the moment. So normally I would say stand clear, however we do run a (larger) usenet platform on v6 which uses DSR and that part works on the serveriron, running a pre-relase of the 11.0.0f software. Must admit we don't do anything fancy, it's all unprotected and statically routed, ACLs are all done on the reals and on the Juniper in front of the serveriron etc. But it seems to hold, haven't heard any complains yet. But be warned this is a really specifc subset of features. For regular operations like web we still have loads and loads of issues. Basically the other choice is F5. We are busy setting up a PoC with A10, who claim IPv6 support. Hopefully in a few weeks time they can be added to the list of potential suppliers. Other then these two I haven't come across any dedicated stuff and what's left is Linux/BSD based solutions. MarcoH
Re: IPv6 Server Load Balancing - DSR
Well, Frankly our culture is very much open source, so if we can find something along those lines, then it would be preferred. (Hence looking at OpenSolaris and ILB). -- having said that, we do have both F5 and Foundry kit here, but it's all pre-IPv6 so doesn't have the support built in. Not really looking to replace what is in existence already for IPv4 with something new to do both, so really that reinforces the open-source avenue really. I think the biggest problem is really the DSR aspect for IPv6, since the OS/ILB solution works perfectly in NAT mode, and DSR works perfectly with IPv4 on this solution. So either I'm missing something critical on the real server configuration, or ILB's implementation of DSR for IPv6 doesn't really work. The virtual IP is bound to loopback on the real servers, exactly the same was as for IPv4. So other than something quirky going on with ND, or simply ILB not correctly rewriting the L2 frame, or there's something else more sinister afoot that I'm unable to put my finger on. Back to the drawing board... :) Thanks, Leland On 12 Aug 2010, at 19:23, William Cooper wrote: I know there have been quite a few responses for both h/w and s/w solutions, it's not clear which your preference is of the two. I know there are various h/w vendors that offer a s/w solution (mostly in conjunction with some form of virtualization environment), such as A10. I've been testing A10 for a while now, and they seem very keen on developing parity between v4 and v6 feature sets / performance. DSR is more or less a L2 trick that plays on some inherent weaknesses and constraints that are present with v4 local address resolution (don't mean to preach to the chior); I think most responses here have touched on the primary challenges of DSR with v6. I'll be exploring DSR with dual stack v4/6 in the near future, I'll let you know how that turns out. Hmm... not sure how this helped. Regards, -Tony On Thu, Aug 12, 2010 at 12:40 PM, Leland Vandervort lel...@taranta.discpro.org wrote: Hi Owen, The DSR address is indeed on a loopback in our case. loLink encap:Local Loopback inet6 addr: ::1/128 Scope:Host inet6 addr: ::x:::xx/128 Scope:Global The mystery continues... Leland On 12 Aug 2010, at 18:28, Owen DeLong wrote: On Aug 12, 2010, at 6:19 AM, Xavier Beaudouin wrote: Hi Leland, Le 12 août 2010 à 15:11, Leland Vandervort a écrit : OpenSolaris ILB is open solution ;) but yea, that's what we've started looking at -- hence LVM / HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for IPv6) does relayd support UDP as well as TCP or is it layer7 only like HAProxy ? It does everything... :) L2 - L7... In the case of ILB, I'm not convinced that it's a problem with the LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing the problem.. but I may be wrong... at any rate, something's amiss ... Maybe on some setup you should desactivate ND... Xavier If you're putting the DSR address on an interface other than loopback, you probably need to turn of DAD on the interface with the DSR address otherwise DAD will shut down that address on the interface when it sees other servers with the same address. Sometimes it will shut down all but one, sometimes it will shut down all. Owen
Re: Policy Based Routing advice
I bit more explanation: 172.25/16 is a hop away and the packets with that source IP will enter on Gi2/6 and need to exit Gi2/14. So it goes like that: 172.25/16 is vlan25 on the student router Gi0/1 has ip address 192.168.250.2 on the student router default route is towards 192.168.250.1 on the student router On Thu, Aug 12, 2010 at 11:54 AM, Andrey Khomyakov khomyakov.and...@gmail.com wrote: Hey all. I'm trying to setup a routing policy on a cat4503-E with Sup6-E and for some reason I can't see it taking effect. I'm definitely sourcing packets from 172.25.0.0/16 (the test machine had 172.25.24.25 address). For some reason the packets still go out towards the default gateway instead of what's specified in the route-map. The switch is running cat4500e-ENTSERVICESK9-M), Version 12.2(52)SG, RELEASE SOFTWARE (fc1) According to stats on the ACL and the route-map it's just not being hit for some reason. Applying the ACL directly to the interface (as an access-group) shows that the ACL is correct and I see hits, however, via the route map it's not being hit. I don't know what those 2 matches are, but there definitely should be a lot more than 2. And in addition, I see the packets arriving on the firewall that is the default gateway. Does anyone have any tips on why this might now work? ip access-list standard acl_Students permit 172.25.0.0 0.0.255.255 route-map Students-Route-Map permit 10 match ip address acl_Students set ip next-hop 192.168.168.22 interface GigabitEthernet2/6 no switchport ip address 192.168.250.1 255.255.255.252 ip pim dense-mode ip policy route-map Students-Route-Map interface GigabitEthernet2/14 no switchport ip address 192.168.168.21 255.255.255.252 no ip redirects no ip mroute-cache flowcontrol send desired cat4503#sh access-lists acl_Students Standard IP access list acl_Students 10 permit 172.25.0.0, wildcard bits 0.0.255.255 (2 matches) cat4503#sh route-map route-map Students-Route-Map, permit, sequence 10 Match clauses: ip address (access-lists): acl_Students Set clauses: ip next-hop 192.168.168.22 Policy routing matches: 2 packets, 180 bytes cat4503#sh ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via static, distance 1, metric 0, candidate default path Redistributing via eigrp 179 Advertised by eigrp 179 Routing Descriptor Blocks: * 192.168.168.10 Route metric is 0, traffic share count is 1 -- Andrey Khomyakov [khomyakov.and...@gmail.com] -- Andrey Khomyakov [khomyakov.and...@gmail.com]
Re: Chunghwa Telecom Tech Support Reg.
Thanks a lot for your immediate reply. I tried calling the number you provided, that does not lead to Chunghwa Telecom in Taiwan. However, it leads to some other organization and they are unable to understand when I speak in English :-( try mandarin randy
Re: Policy Based Routing advice
Andrey, It looks like you're doing everything right here so this might seem like a dumb question, but how sure are you that it's not working? In my experience on the 4500, 6500, 3560/3750, those ACL/route-map counters sometimes don't work because of CEF and friends, and at best they count number of flows that matched the ACL, if even that. Before knowing this, once upon a time I was absolutely convinced that my policy routing wasn't working and it turns out that no, the counters had fooled me. Perhaps try a SPAN session on g2/14 and see whether or not the packets you expect are exiting that interface, or watch the interface counters. HTH, Bill On Thu, Aug 12, 2010 at 11:16, Andrey Khomyakov khomyakov.and...@gmail.com wrote: I bit more explanation: 172.25/16 is a hop away and the packets with that source IP will enter on Gi2/6 and need to exit Gi2/14. So it goes like that: 172.25/16 is vlan25 on the student router Gi0/1 has ip address 192.168.250.2 on the student router default route is towards 192.168.250.1 on the student router On Thu, Aug 12, 2010 at 11:54 AM, Andrey Khomyakov khomyakov.and...@gmail.com wrote: Hey all. I'm trying to setup a routing policy on a cat4503-E with Sup6-E and for some reason I can't see it taking effect. I'm definitely sourcing packets from 172.25.0.0/16 (the test machine had 172.25.24.25 address). For some reason the packets still go out towards the default gateway instead of what's specified in the route-map. The switch is running cat4500e-ENTSERVICESK9-M), Version 12.2(52)SG, RELEASE SOFTWARE (fc1) According to stats on the ACL and the route-map it's just not being hit for some reason. Applying the ACL directly to the interface (as an access-group) shows that the ACL is correct and I see hits, however, via the route map it's not being hit. I don't know what those 2 matches are, but there definitely should be a lot more than 2. And in addition, I see the packets arriving on the firewall that is the default gateway. Does anyone have any tips on why this might now work? ip access-list standard acl_Students permit 172.25.0.0 0.0.255.255 route-map Students-Route-Map permit 10 match ip address acl_Students set ip next-hop 192.168.168.22 interface GigabitEthernet2/6 no switchport ip address 192.168.250.1 255.255.255.252 ip pim dense-mode ip policy route-map Students-Route-Map interface GigabitEthernet2/14 no switchport ip address 192.168.168.21 255.255.255.252 no ip redirects no ip mroute-cache flowcontrol send desired cat4503#sh access-lists acl_Students Standard IP access list acl_Students 10 permit 172.25.0.0, wildcard bits 0.0.255.255 (2 matches) cat4503#sh route-map route-map Students-Route-Map, permit, sequence 10 Match clauses: ip address (access-lists): acl_Students Set clauses: ip next-hop 192.168.168.22 Policy routing matches: 2 packets, 180 bytes cat4503#sh ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via static, distance 1, metric 0, candidate default path Redistributing via eigrp 179 Advertised by eigrp 179 Routing Descriptor Blocks: * 192.168.168.10 Route metric is 0, traffic share count is 1 -- Andrey Khomyakov [khomyakov.and...@gmail.com] -- Andrey Khomyakov [khomyakov.and...@gmail.com]
Re: Policy Based Routing advice
I did try an extended ACL and had the same result. The way I know that it's not working is that I see these packets arriving on a wrong interface on the firewall and therefor being dropped. I actually had to open a CR with Cisco and they verified the config and said nothing is wrong with it. They are escalating and will hopefully get back to me about this. Andrey
Re: Policy Based Routing advice
Have you tried set interface instead of set ip? Sent from my iPhone On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov khomyakov.and...@gmail.com wrote: I did try an extended ACL and had the same result. The way I know that it's not working is that I see these packets arriving on a wrong interface on the firewall and therefor being dropped. I actually had to open a CR with Cisco and they verified the config and said nothing is wrong with it. They are escalating and will hopefully get back to me about this. Andrey
Re: Policy Based Routing advice
I dont' think this will work. Here is the formal description of set interface from cisco.com: This action specifies that the packet is forwarded out of the local interface. The interface must be a Layer 3 interface (no switchports), and the destination address in the packet must lie within the IP network assigned to that interface. If the destination address for the packet does not lie within that network, the packet is dropped. Since in my case the packets are destined to random addresses on the webz, my understanding that this will effectively be a drop statement for them. But, no, I have not tried it. On Thu, Aug 12, 2010 at 3:25 PM, Rogelio rgam...@gmail.com wrote: Have you tried set interface instead of set ip? Sent from my iPhone On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov khomyakov.and...@gmail.com wrote: I did try an extended ACL and had the same result. The way I know that it's not working is that I see these packets arriving on a wrong interface on the firewall and therefor being dropped. I actually had to open a CR with Cisco and they verified the config and said nothing is wrong with it. They are escalating and will hopefully get back to me about this. Andrey -- Andrey Khomyakov [khomyakov.and...@gmail.com]
Springnet Underground
Does anyone have any experience with the Springnet Underground in Springfield, MO? In case people don't know it's a working limestone mine. In the areas that have already been mined close to the entrance, they've sold or rented out space between the rock pillars that hold up the mine roof. The city of Springfield put in a data center and started selling services out of it that complimented their city-wide fiber plant. They've been suggested as a site for hosting a cabinet full of gear. I'm wondering what the connectivity options are for that facility and so far haven't been able to get a straight answer from anyone. For the most part it looks like the SprintNet folks want to sell you their own upstream which won't cut it for our needs. ATT serves the area of course but I will not have them as my last mile (or any mile for that matter). Does L3 or any other large carrier have facilities there? Does anyone have any experience with the facility in general? Thanks Justin
Re: Policy Based Routing advice
A 'debug ip policy' should show if it's hitting or not... IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, len 100,FIB flow policy match IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, len 100,FIB PR flow accelerated! IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, g=10.0.0.8, len 100, FIB policy routed On Thu, Aug 12, 2010 at 2:33 PM, Andrey Khomyakov khomyakov.and...@gmail.com wrote: I dont' think this will work. Here is the formal description of set interface from cisco.com: This action specifies that the packet is forwarded out of the local interface. The interface must be a Layer 3 interface (no switchports), and the destination address in the packet must lie within the IP network assigned to that interface. If the destination address for the packet does not lie within that network, the packet is dropped. Since in my case the packets are destined to random addresses on the webz, my understanding that this will effectively be a drop statement for them. But, no, I have not tried it. On Thu, Aug 12, 2010 at 3:25 PM, Rogelio rgam...@gmail.com wrote: Have you tried set interface instead of set ip? Sent from my iPhone On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov khomyakov.and...@gmail.com wrote: I did try an extended ACL and had the same result. The way I know that it's not working is that I see these packets arriving on a wrong interface on the firewall and therefor being dropped. I actually had to open a CR with Cisco and they verified the config and said nothing is wrong with it. They are escalating and will hopefully get back to me about this. Andrey -- Andrey Khomyakov [khomyakov.and...@gmail.com]
Two /8s allocated to APNIC from IANA (49/8 and 101/8)]
Forwarding on behalf of APNIC. _ Two /8s allocated to APNIC from IANA (49/8 and 101/8) _ Dear colleagues The information in this announcement is to enable the Internet community to update network configurations, such as routing filters, where required. APNIC received the following IPv4 address blocks from IANA in August 2010 and will be making allocations from these ranges in the near future: 49/8 101/8 Reachability and routability testing of the new prefixes will commence soon. The daily report will be published at the usual URL: http://www.ris.ripe.net/debogon For more information on the resources administered by APNIC, please see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, please see: http://www.apnic.net/db/min-alloc.html Please be aware, there are now just 14 /8s remaining in IANA's unallocated IPv4 address pool. Kind regards, Sunny ATT1..c Description: ATT1..c
Re: Policy Based Routing advice
Hmmm... The reason I recommended that is because I think I remember reading somewhere that the set ip command does not work on point-to-point interfaces. The outbound interface in your config has a /30 assigned to it so maybe it is seeing it as a p-t-p interface? Do you have a less preferred route via that interface for the destination ip's? If not, I don't think your pbr will work either. Sent from my iPhone On Aug 12, 2010, at 3:33 PM, Andrey Khomyakov khomyakov.and...@gmail.com wrote: I dont' think this will work. Here is the formal description of set interface from cisco.com: This action specifies that the packet is forwarded out of the local interface. The interface must be a Layer 3 interface (no switchports), and the destination address in the packet must lie within the IP network assigned to that interface. If the destination address for the packet does not lie within that network, the packet is dropped. Since in my case the packets are destined to random addresses on the webz, my understanding that this will effectively be a drop statement for them. But, no, I have not tried it. On Thu, Aug 12, 2010 at 3:25 PM, Rogelio rgam...@gmail.com wrote: Have you tried set interface instead of set ip? Sent from my iPhone On Aug 12, 2010, at 3:13 PM, Andrey Khomyakov khomyakov.and...@gmail.com wrote: I did try an extended ACL and had the same result. The way I know that it's not working is that I see these packets arriving on a wrong interface on the firewall and therefor being dropped. I actually had to open a CR with Cisco and they verified the config and said nothing is wrong with it. They are escalating and will hopefully get back to me about this. Andrey -- Andrey Khomyakov [khomyakov.and...@gmail.com]
Re: Two /8s allocated to APNIC from IANA (49/8 and 101/8)]
Good news for IPV6 fans! Forwarding on behalf of APNIC. _ Two /8s allocated to APNIC from IANA (49/8 and 101/8) _ Dear colleagues The information in this announcement is to enable the Internet community to update network configurations, such as routing filters, where required. APNIC received the following IPv4 address blocks from IANA in August 2010 and will be making allocations from these ranges in the near future: 49/8 101/8 Reachability and routability testing of the new prefixes will commence soon. The daily report will be published at the usual URL: http://www.ris.ripe.net/debogon For more information on the resources administered by APNIC, please see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, please see: http://www.apnic.net/db/min-alloc.html Please be aware, there are now just 14 /8s remaining in IANA's unallocated IPv4 address pool. Kind regards, Sunny
Re: Cost of transit and options in APAC
On Aug 11, 2010, at 10:01 PM, Matthew Palmer wrote: On Wed, Aug 11, 2010 at 12:53:18PM -0700, Joel Jaeggli wrote: On 8/11/10 12:29 PM, Franck Martin wrote: Nice to see this change APAC has been obliged to pay the cost to peer with the US (long distance links are expensive). Now that US wants to peer with Asia, pricing may become more balanced... I think the question is more like why am I being quoted $100 A megabit in India for transit in India? Not why am I being charged for for the transport cost across the pacific. Because the percentage of traffic that actually stays in India, as compared to that which transits the Pacific, is miniscule. If you're asking for enough bandwidth / throwing enough money around, I'm sure you could get an Indian-only deal, but you'd need to make it worth the while for the provider to setup the config, given that either way they'll be getting your money, and you won't be using a lot of transpacific traffic. Note also that it's unlikely that the provider will be getting a differentiated rate from their upstreams for internal traffic, and you may have to settle for peering-only access (if your chosen provider is connected to any peering points). You do not need to throw a lot of money around. Lots of places in Asia give you separate in-country and international rates, and charge you accordingly. People have been talking about distance-sensitive pricing for IP traffic for years, without realizing people have been doing it in Asia for years. Back to topic of why prices are high in some places (and it is not just Asia), it is trivial to prove objectively that monopoly power keeps prices ridiculously high. Before anyone jumps on me, there are many reasons for high prices. Monopoly power is only one, but clearly and obviously the biggest one. When I say objectively, I mean it. Look at any country which has gone through any type of transition from gov't owned monopoly telco to competition-based market. South Africa instantly springs to mind. Prices are still high, but have dropped, what, 75% in just a year or two once the monopoly power was broken? And this is after a decade or more of little to no decrease. Of course, this does not mean .za will have $1/Mbps transit like the US any time soon. As I said, there are other factors - geography, scale, local economy, even import policies, etc. But getting prices to go from US$2000/Mbps to, say, $100/Mbps is more important than the $100 - $1 drop. (Hrmm, I wonder who will say the first is only 20 times, the second is 100 times! to prove me wrong? :) Plus there are a myriad of factors keeping that last step from happening, not just one. So wich do you think is more important, the monopoly power or the dozens of other factors? That said, this is not really on-topic for NANOG. So if you would like to argue the point, please e-mail privately, or let's take it to another list. End of day, the important thing is to break the monopoly. After that, prices will almost always drop, then you can work on other stuff. -- TTFN, patrick
Re: Cost of transit and options in APAC
On 12 Aug 10, at 7:26 AM, Dorian Kim wrote: Sadly, I have no first-hand knowledge of these costs. How does in-country transport compare to trans-Pacific transport cost? (i.e. on a per Mbps per kilometer or similar metric) I assume it's cheaper in-country / in-region compared to trans-oceanic. Is this true? This is not an assumption you can make safely depending on the country and specific sub-region you are talking about. That's fair; I'm not surprised to hear it. But I'm curious about the details. In specific cases like India and China, what is the underlying contributor to higher relative transport costs? (i.e. taxes, ROW fees, extraordinary shipping or operational costs, inadequate competition, low supply, greed, etc) Further, how does the situation compare to past examples like Europe? I doubt the AP region is forever doomed to exchange traffic via the US, but can't quite anticipate change without first understanding the current environment. Network interconnects are designed the way they are, today, for a reason. If anybody has insight they can share on the situation I would appreciate it. Cheers, -Benson
Reminder: DENOG 2 Call for Participation and Papers
DENOG 2 - Call for Participation and Papers The second meeting of the German Network Operators Group (DENOG) will be held in Frankfurt, Germany on the 4th of November 2010. We are pleased to hereby invite applications for presentations or lightning talks to be held at this event. General Information === DENOG is a community for professionals within Germany who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community. More information about DENOG (in German) can be found at http://www2.denog.de/ Information about the meeting will be published at http://www.denog.de/. Meeting Countdown = What When -- Publication of Call for Papers May 11th, 2010 Deadline for all submissions September 15th, 2010 Beginning of Registration Period End of August, 2010 Publication of final programme End of September, 2010 Deadline for receipt of final slides October 24th, 2010 Meeting DayNovember 4th, 2010 Topics for Presentations/Talks == The day will be divided into several sessions. The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 10 to 30 minutes. However proposals for longer/shorter presentations or presentations whose subject falls outside of the topics below are also welcome; please do not hesitate to submit them. Lightning Talks --- In addition to the topics mentioned below we will reserve slots for lightning talks, which consist of a few slides and will not last longer than 5 minutes. Lightning talks can be submitted until October 29th, with the deadline for submission of the corresponding slides being November 3rd. Topic #1: Power Efficiency in Networks --- For operators of networks and data centres of any size power efficiency has become more important. Servers and network gear with high power consumption are expensive because of high operating and cooling power costs; also in many places supplying more power into the location is no longer possible. How are you dealing with power problems in your environment? How do you efficiently cool a rack/a room/a datacenter? Can a migration to VoIP help you save power? Topic #2: Social Networks, Cloud Services and Information Security -- Social Networks are an essential working tool for networkers and cloud services are also becoming increasingly popular. The security of your information and data in these networks is a crucial aspect which we want to discuss in this session. Topic #3: Network Neutrality In the US, Network Neutrality has been a subject of controversy and debate. Is an ISP allowed to sell Internet access which only offers access to a subset of the whole Internet? Is an ISP allowed to prioritise video streams from Company A while imposing a higher delay to video streams from Company B? In Germany Network Neutrality is mainly an issue for mobile networks and not extensively discussed thus far. But what kind of problems will an upcoming debate on Network Neutrality bring to German ISPs and is there a good way to address these problems? Topic #4: Peering -- Everything about your peering experience. Why are you doing it? How are you doing it? Have you written any useful tools which others might find interesting? Topic #5: ISP BOF - All things ISP. From Network/SLA Management (for or against it), abuse handling and log systems to data centre layout and planning (including power and cooling), everything that is interesting to you as an ISP can be presented or discussed within this topic. Language of Slides and Talks To appeal to an international audience we ask you to produce your slides in English, but the spoken language of the presentation itself can be either German or English. Submission Guidelines = All submissions must have a strong technical bias and must not be solely promotional for your employer. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, we request that you provide the following information as plain text or PDF format to denog...@denog.de: * the name of the presenter (and if applicable your affiliation) *
Re: Cost of transit and options in APAC
+10 Once you pass a threshold of affordability (by breaking the monopoly), then the network use explodes and other issues can be worked out by more or less by consumer pressure (and economies of scale)... You need to reach Packet Storm level. - Original Message - From: Patrick W. Gilmore patr...@ianai.net To: NANOG list nanog@nanog.org Sent: Friday, 13 August, 2010 6:29:02 AM Subject: Re: Cost of transit and options in APAC Back to topic of why prices are high in some places (and it is not just Asia), it is trivial to prove objectively that monopoly power keeps prices ridiculously high. Before anyone jumps on me, there are many reasons for high prices. Monopoly power is only one, but clearly and obviously the biggest one. When I say objectively, I mean it. Look at any country which has gone through any type of transition from gov't owned monopoly telco to competition-based market. South Africa instantly springs to mind. Prices are still high, but have dropped, what, 75% in just a year or two once the monopoly power was broken? And this is after a decade or more of little to no decrease. Of course, this does not mean .za will have $1/Mbps transit like the US any time soon. As I said, there are other factors - geography, scale, local economy, even import policies, etc. But getting prices to go from US$2000/Mbps to, say, $100/Mbps is more important than the $100 - $1 drop. (Hrmm, I wonder who will say the first is only 20 times, the second is 100 times! to prove me wrong? :) Plus there are a myriad of factors keeping that last step from happening, not just one. So wich do you think is more important, the monopoly power or the dozens of other factors? That said, this is not really on-topic for NANOG. So if you would like to argue the point, please e-mail privately, or let's take it to another list. End of day, the important thing is to break the monopoly. After that, prices will almost always drop, then you can work on other stuff. -- TTFN, patrick
Cisco Security Advisory: Cisco IOS Software TCP Denial of Service Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software TCP Denial of Service Vulnerability Advisory ID: cisco-sa-20100812-tcp http://www.cisco.com/warp/public/707/cisco-sa-20100812-tcp.shtml Revision 1.0 For Public Release 2010 August 12 2130 UTC (GMT) +- Summary === Cisco IOS Software Release, 15.1(2)T is affected by a denial of service (DoS) vulnerability during the TCP establishment phase. The vulnerability could cause embryonic TCP connections to remain in a SYNRCVD or SYNSENT state. Enough embryonic TCP connections in these states could consume system resources and prevent an affected device from accepting or initiating new TCP connections, including any TCP-based remote management access to the device. No authentication is required to exploit this vulnerability. An attacker does not need to complete a three-way handshake to trigger this vulnerability; therefore, this this vunerability can be exploited using spoofed packets. This vulnerability may be triggered by normal network traffic. Cisco has released Cisco IOS Software Release 15.1(2)T0a to address this vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100812-tcp.shtml. Affected Products = This vulnerability affects only Cisco IOS Software Release 15.1(2)T. No other Cisco IOS Software Releases are affected. Cisco IOS XE Software, Cisco IOS XR Software, and Cisco NX-OS Software are not affected by this vulnerability. Vulnerable Products +-- A Cisco device is vulnerable when it is running Cisco IOS Software Release 15.1(2)T. To determine the Cisco IOS Software Release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to Cisco Internetwork Operating System Software or Cisco IOS Software. The image name displays in parentheses, followed by Version and the Cisco IOS Software Release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.1(2)T with an installed image name of C2800NM-ENTSERVICES-M: Router#show version Cisco IOS Software, 2800 Software (C2800NM-ENTSERVICES-M), Version 15.1(2)T, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2010 by Cisco Systems, Inc. Compiled Mon 19-Jul-10 16:38 by prod_rel_team output truncated Additional information about Cisco IOS Software Release naming conventions is available in the White Paper: Cisco IOS Reference Guide. Products Confirmed Not Vulnerable + No other Cisco IOS Software versions are affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details === TCP provides reliable data transmission services in packet-switched network environments. TCP corresponds to the transport layer (Layer 4) of the OSI reference model. Among the services TCP provides are stream data transfer, reliability, efficient flow control, full-duplex operation, and multiplexing. When TCP connections are terminated in Cisco IOS Software, they are allocated a transmission control block (TCB). All allocated TCBs, associated TCP port numbers, and the TCP state are displayed in the output of the show tcp brief all command-line interface (CLI) command. Cisco IOS Software version 15.1(2)T contains a vulnerability that could cause an embryonic TCP connection to remain in SYNRCVD or SYNSENT state without a further TCP state transition. Examining the output of the show tcp brief all command multiple times will indicate if TCP sessions remain in one of these states. This vulnerability is triggered only by TCP traffic that is terminated by or originated from the device. Transit traffic will not trigger this vulnerability. Both connections to and from the router could trigger this vulnerability. An example of a connection to the router is that you may still be able to ping the device, but fail to establish a TELNET or SSH connection to the device. For example, an administrator may still be able to ping the device but fail to establish a Telnet or SSH connection to the device. Administrators who attempt a Telnet or a SSH connection to a remote device from the CLI prompt will encounter a hung session and the Trying ip address|hostname ... prompt. The connection that is initiated or terminated by the router can be removed from the socket table by clearing the associated TCB with the clear tcp tcb 0xaddress command. Devices could be vulnerable if examining the output of the CLI command debug ip tcp transactions, displays the error messages connection
Re: Cost of transit and options in APAC
On Thu, 12 Aug 2010, Benson Schliesser wrote: Further, how does the situation compare to past examples like Europe? Countries in Europe are all in different phases of competition and pricing. There is at least 10x difference in transit prices across Europe, with central and northern Europe being the cheapest, and southern and eastern being the most expensive. I agree totally with Mr Gilmore that it's all about competition. When there are 3+ (preferrably 4+) providers or something and the market is de-regulated then you get huge downward pressure on price and you soon hit levels of 5-20% operating margin and a mature market. I still remember back around 2000-2001 when we purchased 30 megs of transit from Ebone at around 120 USD per megabit/s, 2-3 years later the price was down to ~10-20 USD/megabit/s and then it's slowly decreased over time from that, basically as new faster technology came online so things could be done cheaper and at grander scale (you need the same amount of people to run a 155 megabit/s network as a 5*10G network, so price per bit goes down. APAC needs to go thru this as well, but things are generally still heavily regulated and the people are still adopting internet use instead of the situation in most of Europe and US where everybody who wants Internet connection has one. It's when mass market deployment and deregulation happen together that sensible pricing occurs. Oh, competition needs to happen at all levels, from fiber in the ground to end user access. You can't have any single entity having a (de facto) monopoly/duopoly on any part of the chain. You need 4+ here as well (or a neutral party who just do one part and does it well, like municipal fiber rented at decent prices to anyone who wants to rent). -- Mikael Abrahamssonemail: swm...@swm.pp.se
