Level3 Question
Okay, so I've been reading this thread on L3, and I'm a little curious as to what this potential de-peering means in one unique situation. A friend of mine has got a colo box sitting, single-homed, in a (3) data center. At the end of this, is this going to mean I can't reach Cogent? I've seen something in the discussions that imply this will be the case, but am not ultimately sure. Then again, is anyone? Thanks, -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
Re: Level3 Question
On Sun, 23 Oct 2005, Dan Mahoney, System Admin wrote: Okay, so I've been reading this thread on L3, and I'm a little curious as to what this potential de-peering means in one unique situation. A friend of mine has got a colo box sitting, single-homed, in a (3) data center. At the end of this, is this going to mean I can't reach Cogent? I've seen something in the discussions that imply this will be the case, but am not ultimately sure. Yes. When Level3 depeers Cogent again, unless Cogent buys transit to or makes other arrangements for reaching Level3, you will be unable to reach single-homed Cogent customers (or Cogent itself) from your friend's single-homed Level3 colo...as you were when Level3 depeered Cogent previously. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
h-root-servers.net (Level3 Question)
Dan Mahoney, System Admin wrote: Okay, so I've been reading this thread on L3, and I'm a little curious as to what this potential de-peering means in one unique situation. I means, here in germany we cannot see h.root-servers.net soa(.,2005102201,a.root-servers.net,198.41.0.4). soa(.,2005102201,b.root-servers.net,192.228.79.201). soa(.,2005102201,c.root-servers.net,192.33.4.12). soa(.,2005102201,d.root-servers.net,128.8.10.90). soa(.,2005102201,e.root-servers.net,192.203.230.10). soa(.,2005102201,f.root-servers.net,192.5.5.241). soa(.,2005102201,g.root-servers.net,192.112.36.4). error(.,h.root-servers.net,128.63.2.53,no response). soa(.,2005102201,i.root-servers.net,192.36.148.17). soa(.,2005102201,j.root-servers.net,192.58.128.30). soa(.,2005102201,l.root-servers.net,198.32.64.12). soa(.,2005102201,l.root-servers.net,198.32.64.12). soa(.,2005102201,m.root-servers.net,202.12.27.33). Ok, it is only one of the root servers. But have a look who h.root-servers.net is. It is one of the originals not an anycasted copy. Maybe it is only dtag.de the uplink of my ISP but they are the uplink of mostly any ISP here in germany. I guess half of the world cannot reach your site and they cannot even send you an email to tell you. Here is my traceroute to h.root-servers.net right now: 2005-10-23 (296) 11:48:46 loc 2005-10-23 (296) 09:48:46 UTC traceroute to h.root-servers.net (128.63.2.53), 30 hops max, 40 byte packets 1 echnaton.lomiheim (192.168.48.228) 4.675 ms 5.587 ms 6.364 ms 2 DARX41-erx (217.0.116.49) 116.568 ms 132.257 ms 137.536 ms 3 sepia (217.0.67.106) 119.249 ms 124.106 ms 134.971 ms 4 62.156.131.150 230.077 ms 233.444 ms 237.907 ms 5 sl-gw31-nyc-12-0.sprintlink.net (144.223.27.133) 248.150 ms 254.276 ms 262.928 ms 6 sl-bb23-nyc-12-0.sprintlink.net (144.232.13.33) 271.683 ms 278.948 ms 286.979 ms 7 sl-bb20-nyc-8-0.sprintlink.net (144.232.7.13) 288.615 ms 296.159 ms 304.545 ms 8 0.so-2-3-0.BR1.NYC4.ALTER.NET (204.255.174.225) 153.352 ms 160.090 ms 168.617 ms 9 0.so-6-0-0.XL1.NYC4.ALTER.NET (152.63.21.78) 177.012 ms * 184.325 ms 10 0.so-7-0-0.XL1.CHI2.ALTER.NET (152.63.68.81) 202.066 ms 205.084 ms 207.531 ms 11 POS6-0.GW10.CHI2.ALTER.NET (152.63.69.169) 214.184 ms 221.166 ms 228.862 ms 12 0.so-3-3-0.dng.dren.net (65.195.244.54) 323.133 ms * 325.671 ms 13 so12-0-0-0.arlapg.dren.net (138.18.1.3) 373.705 ms 381.351 ms 393.036 ms 14 * * * ; DiG 9.1.3 . @h.root-servers.net ;; global options: printcmd ;; connection timed out; no servers could be reached A friend of mine has got a colo box sitting, single-homed, in a (3) data center. At the end of this, is this going to mean I can't reach Cogent? I've seen something in the discussions that imply this will be the case, but am not ultimately sure. Then again, is anyone? I am shure I cannot reach h-root-servers.net and a lot of other sites. Here is what I see from another host in the netherlands: traceroute to h.root-servers.net (128.63.2.53), 30 hops max, 40 byte packets 1 Bifroest (84.22.100.1) 0.181 ms 0.156 ms 0.155 ms 2 Charybdis (84.22.96.245) 2.016 ms 3.895 ms 3.545 ms 3 217.195.244.142 104.799 ms 103.670 ms 102.902 ms 4 213.201.252.230 103.338 ms 101.735 ms 100.100 ms 5 ge0-0-0-1.gr0.tcams.nl.easynet.net (207.162.205.113) 98.449 ms 96.802 ms 95.168 ms 6 so0-1-0-0.gr0.tclon.uk.easynet.net (207.162.205.49) 101.366 ms 100.190 ms 98.656 ms 7 ge0-3-0-0.gr1.thlon.uk.easynet.net (207.162.205.21) 96.926 ms 95.480 ms 93.871 ms 8 ge0-0-0-0.gr0.thlon.uk.easynet.net (207.162.198.12) 92.276 ms 90.543 ms * 9 ge0-2-0-0.gr0.bllon.uk.easynet.net (207.162.205.13) 22.415 ms 21.672 ms 20.266 ms 10 br0.bllon.uk.easynet.net (207.162.204.5) 21.576 ms 20.171 ms 23.452 ms 11 ge-1-0-0-0.br0.tclon.uk.easynet.net (82.108.6.122) 21.855 ms 20.237 ms 21.863 ms 12 ge0-0-0-0.br0.thlon.uk.easynet.net (195.172.211.205) 20.422 ms 23.193 ms 21.581 ms 13 ip-217-204-60-90.easynet.co.uk (217.204.60.90) 20.976 ms 20.646 ms 20.409 ms 14 ge-5-0-2.402.ar2.LON3.gblx.net (67.17.212.93) 90.475 ms 89.058 ms 87.318 ms 15 so6-0-0-2488M.ar2.NYC1.gblx.net (67.17.64.158) 97.484 ms 110.351 ms 108.752 ms 16 POS1-0.BR3.NYC8.ALTER.NET (204.255.168.133) 107.855 ms POS1-1.BR3.NYC8.ALTER.NET (204.255.168.61) 106.842 ms 118.576 ms 17 0.so-5-2-0.XL1.NYC8.ALTER.NET (152.63.19.54) 118.120 ms 116.336 ms 114.644 ms 18 0.so-7-0-0.XL1.CHI2.ALTER.NET (152.63.68.81) 137.482 ms 135.923 ms 134.144 ms 19 POS6-0.GW10.CHI2.ALTER.NET (152.63.69.169) 132.387 ms 130.567 ms 129.078 ms 20 0.so-3-3-0.dng.dren.net (65.195.244.54) 116.936 ms 116.027 ms 114.271 ms 21 so12-0-0-0.arlapg.dren.net (138.18.1.3) 126.768 ms 125.046 ms 126.627 ms 22 cperouter.arlapg.dren.net (138.18.21.2) 126.067 ms 124.259 ms 127.054 ms 23 * * * ; DiG 9.2.4 . @h.root-servers.net ;; global
Re: estimating VoIP data traffic size from VoIP signaling traffic size ?
Your signaling traffic will be incredibly low compared to your RTP streams (especially for G.711u). For G.711u if 2Mbps is your peak think somewhere in the range of 10kbps or so (complete SWAG but I hope you get the picture). Use about 100k per call for 711u and it will help make the numbers nice and round. If you are trying to calculate busy hour search for Erlang on your nearest web confabulator. There are also innumerable spots on the web where you can find typical numbers for various codecs. On Oct 22, 2005, at 1:34 PM, Joe Shen wrote: Hi, is there any statistics on aggregated VoIP signaling bandwidth and aggregated VoIP data bandwidth? eg. if we monitored there is 2Mbps(average) traffic on VoIP signaling protocol ports ( including SIP, H.323, MGCP), how could we estimate average VoIP data bandwidth? Joe __ Meet your soulmate! Yahoo! Asia presents Meetic - where millions of singles gather http://asia.yahoo.com/meetic
Re: h-root-servers.net (Level3 Question)
On Sun, Oct 23, 2005 at 11:59:15AM +0200, Peter Dambier wrote: I means, here in germany we cannot see h.root-servers.net Nonsense. There is nothing like geopolitical routing. Ok, it is only one of the root servers. But have a look who h.root-servers.net is. It is one of the originals not an anycasted copy. And it's not singlehomed to Cogent. Maybe it is only dtag.de the uplink of my ISP but they are the uplink of mostly any ISP here in germany. Absolute nonsense again. Here is my traceroute to h.root-servers.net right now: So, where do you see a problem related to L3/Cogent there? Your traceroute hits DREN, the operator of h.root-servers.net. ; DiG 9.1.3 . @h.root-servers.net ;; global options: printcmd ;; connection timed out; no servers could be reached DREN seems to have a problem there. I can see absolutely NO connection to any L3/Cogent dispute. And testing from DTAG 84/8 space myself I have the same prob. Perhaps some bogus anti-bogon-filters at DREN in place? Please stop your constant flood of nonsense and misinformation to the NANOG mailing list. Thank you. Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: estimating VoIP data traffic size from VoIP signaling traffic size ?
On Sun, Oct 23, 2005 at 07:28:33AM -0400, Blaine Christian wrote: Your signaling traffic will be incredibly low compared to your RTP streams (especially for G.711u). For G.711u if 2Mbps is your peak think somewhere in the range of 10kbps or so (complete SWAG but I hope you get the picture). Use about 100k per call for 711u and it will help make the numbers actually around 88.2k. nice and round. If you are trying to calculate busy hour search for Erlang on your nearest web confabulator. There are also innumerable spots on the web where you can find typical numbers for various codecs. I'd like to suggest to people looking at these things to insure that your stats toolset includes both bps and pps in the polls. SYNs are low bps rate, but a high pps rate of them can mean something bad.. it's useful to know how fast these counters are incrementing. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: estimating VoIP data traffic size from VoIP signaling traffic size ?
Blaine Christian [EMAIL PROTECTED] wrote: [...] Use about 100k per call for 711u and it will help make the numbers nice and round. It's something like about 80kb/s (each way) for a single G.711 call over IAX2. Extra channels will take 80kb/s if you're not using trunking, or 64kb/s if you are. It's probably best to not assume trunking is in use when doing your calculations. -- PGP key ID E85DC776 - finger [EMAIL PROTECTED] for full key
Re: design of a real routing v. endpoint id seperation
the internet model is to expect and route around failure. You cannot stop the last mile backhoes. no, but if your facility is critical, you have redundant physical and layer one exits from it. and you have parallel sites. randy
Re: h-root-servers.net (Level3 Question)
* Daniel Roesen: On Sun, Oct 23, 2005 at 11:59:15AM +0200, Peter Dambier wrote: I means, here in germany we cannot see h.root-servers.net Nonsense. There is nothing like geopolitical routing. I wouldn't call it geopolitical routing, routing according to local policy is more appropriate. And it's quite common (especially in Germany, for quite a few reasons). DREN seems to have a problem there. Not clear to me. A traceroute with the wrong protocol (i.e. not 53/UDP nor 53/TCP) is not particularly enlightening. I can see absolutely NO connection to any L3/Cogent dispute. This is something I can agree with. 8-)
Re: Level3 Question
A friend of mine has got a colo box sitting, single-homed friends don't let friends home singly randy
Re: estimating VoIP data traffic size from VoIP signaling traffic size ?
Hi, is there any statistics on aggregated VoIP signaling bandwidth and aggregated VoIP data bandwidth? eg. if we monitored there is 2Mbps(average) traffic on VoIP signaling protocol ports ( including SIP, H.323, MGCP), how could we estimate average VoIP data bandwidth? Joe As mentioned in prior responses to this thread: there are several ways to guess, but mostly the answer is No, not easily. The good news is that excepting proprietary protocols like Skype and efficient trunking protocols like IAX2, RTP is standardized. This means one VoIP protocol is pretty similar to the other as far as RTP size goes, so at least that part of the equation isn't open-ended. (I'll assume you're looking for end-user statistics, and not inter-nodal statistics where some type of aggregated IP header compression or trunking might make flows more IP-header-friendly.) Looking just at protocols that use RTP, it's still not quite possible to map RTP volume simply from signalling volume without opening up the signalling to see what codec is being used. If you have a mix of codecs, then your bitstreams for the RTP can range from (typically) ~24kbps for G.729 up to ~80kbps for G.711 (1). Each call can be different, depending on the ability of the originating and terminating gateway/useragent to accept or prefer each codec during the call set-up. You'd need a clear understanding of what codecs your user community was utilizing in order to build an assumption table on number of streams using each codec and/or protocol. The media stats in SIP BYE signalling Bill Woodcock mentioned in his message (jitter, packets, loss, latency, etc.) are only available in a few end devices at the moment, notably Cisco. The RTCP XR (RFC3611) standards might be visible in signalling soon via SIP NOTIFY messages (2), but I don't know of any equipment that supports this right now. I think the best way to do this would be to graph the signalling volumes and the media volumes over a week or two, and then build assumption charts for future use. It may not be a big win if the effort to measure signalling is the same as the effort to measure the media, since you have to sample at a point(s) where all this data crosses your measurement instrumentation. If you're really a masochist, or you can't see the media for architecture reasons, you could write an extension to tethereal or ettercap or a similar network monitoring and packet analysis tool which unfolded each signalling message, extracted the codec descriptors, and calculated flows. You'd then have to keep state on each call, etc. etc. etc. - not simple, but not impossible. Lastly, I'm betting there are some signalling analysis tools on the market that already do this, but I would expect that they will not be cheap. If you're looking at traffic generated by Skype or other closed-protocol system, you're really hanging out in the wind but I'm sure that can be averaged and extrapolated if you have access to a number of media streams from your user population to examine. (Does Skype use extensively variable bitrates depending on endpoint capabilities?) JT (1) http://www.erlang.com/calculator/lipb/ (note: RTP for SIP and H323 is identical) http://www.voxgratia.org/docs/codecbw.html Take all media flow estimates with a grain of salt; typically numbers are higher than reported, like G.711 being just shy of 90kbps instead of 80kbps as noted in most charts. (2) http://www.ietf.org/internet-drafts/draft-johnston-sipping-rtcp-summary-08.txt
Re: estimating VoIP data traffic size from VoIP signaling traffic size ?
On Sun, 23 Oct 2005, John Todd wrote: The media stats in SIP BYE signalling Bill Woodcock mentioned in his message (jitter, packets, loss, latency, etc.) are only available in a few end devices at the moment, notably Cisco. Ah, that's right, I'd forgotten that, sorry. On INOC-DBA we have a preponderance of Cisco phones, so one end or the other (all that's necessary) of most calls is a Cisco, and I tend to not worry too much about whether the remainder are a statistically similar subset of the total. I think the best way to do this would be to graph the signalling volumes and the media volumes over a week or two, and then build assumption charts for future use. Agreed. If you're really a masochist, or you can't see the media for architecture reasons, you could write an extension to ethereal or ettercap or a similar network monitoring and packet analysis tool which unfolded each signalling message, extracted the codec descriptors, and calculated flows. You'd then have to keep state on each call, etc. It's not quite that bad... You don't need to keep state, you just need to know how much signalling is associated with each call, on average. If you know the average amount of signalling per call for your traffic mix (which can be calculated from a baseline analysis of the signalling alone), the total amount of signalling, and the ratio of codecs in use (which can be a sample rather than a full count), you should be able to get a pretty accurate estimate, without ever tracking on a per-call basis. -Bill
Re: h-root-servers.net (Level3 Question)
On Sun, Oct 23, 2005 at 08:00:10PM +0200, Florian Weimer wrote: On Sun, Oct 23, 2005 at 11:59:15AM +0200, Peter Dambier wrote: I means, here in germany we cannot see h.root-servers.net Nonsense. There is nothing like geopolitical routing. I wouldn't call it geopolitical routing, routing according to local policy is more appropriate. And it's quite common (especially in Germany, for quite a few reasons). He talked about here in germany. germany is a nonexistant entity in BGP and global routing. You cannot talk about observation of connectivity problems with location specification in terms of countries. DREN seems to have a problem there. Not clear to me. A traceroute with the wrong protocol (i.e. not 53/UDP nor 53/TCP) is not particularly enlightening. I did the traces myself, with dest port 53. I'm not stupid (at least not that much). Given that DREN is the operator of the root server, and the trace ends _within_ DREN, it's highly likely that the problem is inside DREN. Anyway, even that can be filtered by a firewall with protocol inspection, and the actual problem can be on the path back. This is why I said seems to be, not is. Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: Level 3 RFO
However, due to the number of flooded LSAs, other devices in the Level 3 network had difficulty fully loading the OSPF tables and processing the volume of updates. This caused abnormal conditions within portions of the Level 3 network. Manual intervention on specific routers was required to allow a number of routers to return to a normal routing state. This isn't the first time this has happened to an ISP. 8-( Are there any configuration tweaks which can locally confine such an event? Something like the hard prefix limit for BGP, perhaps. (I'm not an OSPF expert, and understand that things are generally more difficult with link-state protocols.)
Re: Level 3 RFO
On Sun, Oct 23, 2005 at 09:48:58PM +0200, Florian Weimer wrote: This isn't the first time this has happened to an ISP. 8-( Indeed. Are there any configuration tweaks which can locally confine such an event? Something like the hard prefix limit for BGP, perhaps. JunOS: set protocols ospf prefix-export-limit n set protocols isis level n prefix-export-limit n I'm told IOS has the ~same. Best regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: h-root-servers.net (Level3 Question)
Daniel Roesen wrote: He talked about here in germany. germany is a nonexistant entity in BGP and global routing. You cannot talk about observation of connectivity problems with location specification in terms of countries. Hi Daniel, I thought it might make more sense telling where I am than saying downstream of DARX41-erx (217.0.116.49) And here is the traceroute repeated for port 53 udp: host_name(84.167.253.32,p54A7FD20.dip.t-dialin.net). /usr/sbin/traceroute -p 53 h.root-servers.net traceroute to h.root-servers.net (128.63.2.53), 30 hops max, 40 byte packets 1 echnaton.lomiheim (192.168.48.228) 4.835 ms 5.754 ms 6.609 ms 2 DARX41-erx (217.0.116.49) 102.306 ms 109.711 ms 121.313 ms 3 sepia (217.0.67.106) 125.160 ms 132.543 ms 140.217 ms 4 62.156.131.150 230.469 ms 237.826 ms 245.680 ms 5 sl-gw31-nyc-12-0.sprintlink.net (144.223.27.133) 255.599 ms 263.358 ms 271.387 ms 6 sl-bb23-nyc-12-0.sprintlink.net (144.232.13.33) 280.600 ms 287.696 ms 296.003 ms 7 sl-bb20-nyc-8-0.sprintlink.net (144.232.7.13) 242.799 ms 250.392 ms 367.674 ms 8 0.so-2-3-0.BR1.NYC4.ALTER.NET (204.255.174.225) 156.870 ms 164.751 ms 172.858 ms 9 0.so-6-0-0.XL1.NYC4.ALTER.NET (152.63.21.78) 182.478 ms 189.745 ms 197.843 ms 10 0.so-7-0-0.XL1.CHI2.ALTER.NET (152.63.68.81) 239.347 ms 246.224 ms 254.247 ms 11 POS6-0.GW10.CHI2.ALTER.NET (152.63.69.169) 262.775 ms 270.860 ms 277.932 ms no answer beyond this point This traceroute is for the system that can dig h.root-servers.net. This system lives downstream of host_name(84.22.96.245,cb-sr1-e0.cb3rob.net). host_name(84.22.100.150,tourelle.serveftp.com). /usr/sbin/traceroute -p 53 h.root-servers.net traceroute to h.root-servers.net (128.63.2.53), 30 hops max, 40 byte packets 1 Bifroest (84.22.100.1) 0.186 ms 0.155 ms 0.157 ms 2 Charybdis (84.22.96.245) 1.555 ms 3.820 ms 3.135 ms 3 217.195.244.142 11.756 ms 16.716 ms 15.451 ms 4 213.201.252.230 14.394 ms 13.954 ms 12.179 ms 5 ge0-0-0-1.gr0.tcams.nl.easynet.net (207.162.205.113) 13.406 ms 12.134 ms 13.903 ms 6 so0-1-0-0.gr0.tclon.uk.easynet.net (207.162.205.49) 21.128 ms 28.479 ms 27.220 ms 7 ge0-3-0-0.gr1.thlon.uk.easynet.net (207.162.205.21) 25.672 ms 24.268 ms 22.498 ms 8 ge0-0-0-0.gr0.thlon.uk.easynet.net (207.162.198.12) 30.448 ms 29.706 ms 28.133 ms 9 ge0-2-0-0.gr0.bllon.uk.easynet.net (207.162.205.13) 27.087 ms 25.549 ms 21.555 ms 10 br0.bllon.uk.easynet.net (207.162.204.5) 20.339 ms 27.891 ms 26.280 ms 11 ge-1-0-0-0.br0.tclon.uk.easynet.net (82.108.6.122) 25.986 ms 25.646 ms 37.109 ms 12 ge0-0-0-0.br0.thlon.uk.easynet.net (195.172.211.205) 32.720 ms 31.975 ms 31.447 ms 13 ip-217-204-60-90.easynet.co.uk (217.204.60.90) 29.707 ms 25.448 ms 21.981 ms 14 ge-5-0-2.402.ar2.LON3.gblx.net (67.17.212.93) 18.514 ms 21.786 ms 21.109 ms 15 so6-0-0-2488M.ar2.NYC1.gblx.net (67.17.64.158) 89.241 ms 91.517 ms 91.639 ms 16 POS1-1.BR3.NYC8.ALTER.NET (204.255.168.61) 90.138 ms 92.526 ms POS1-0.BR3.NYC8.ALTER.NET (204.255.168.133) 90.929 ms 17 0.so-5-2-0.XL1.NYC8.ALTER.NET (152.63.19.54) 90.694 ms 89.473 ms 90.154 ms 18 0.so-7-0-0.XL1.CHI2.ALTER.NET (152.63.68.81) 115.216 ms 113.511 ms 116.485 ms 19 POS6-0.GW10.CHI2.ALTER.NET (152.63.69.169) 114.734 ms 115.800 ms 114.189 ms 20 0.so-3-3-0.dng.dren.net (65.195.244.54) 113.536 ms * * 21 * * * Please note it is the same 84/8 so I dont think it is about the old 84.0.0.0 bogon. I know of one host here in germany who can see h.root-servers.net. That host is living in a KPN data centre directly connected to Amterdam IX. All others I have asked cannot see h.root-servers.net. ISPs used were t-online, gmx, heag-media, arcor, aol and manet. Kind regards, Peter Dambier -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.kokoom.com/iason
Re: h-root-servers.net
* [EMAIL PROTECTED] (Peter Dambier) [Sun 23 Oct 2005, 22:34 CEST]: I know of one host here in germany who can see h.root-servers.net. That host is living in a KPN data centre directly connected to Amterdam IX. Peter, please stop posting nonsense. -- Niels.
Re: h-root-servers.net
No, why don't you stop insulting people, Niels. You attack Peter because of his involvment in the Inclusive Namespace. FYI: Public root servers are online and available. Maybe the h-root ops should ask the P-R technical committee for assistance if they cannot keep their servers up. - Original Message - From: Niels Bakker [EMAIL PROTECTED] To: Peter Dambier [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: Sunday, October 23, 2005 3:48 PM Subject: Re: h-root-servers.net * [EMAIL PROTECTED] (Peter Dambier) [Sun 23 Oct 2005, 22:34 CEST]: I know of one host here in germany who can see h.root-servers.net. That host is living in a KPN data centre directly connected to Amterdam IX. Peter, please stop posting nonsense. -- Niels.
Update: h-root-servers.net
h-root-servers.net works now, even from dtag.de It was not about level 3. It was a firewall. Kind regards Peter and Karin Dambier -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.kokoom.com/iason
Re: h-root-servers.net
On Sun, 23 October 2005 16:07:03 -0500, John Palmer (NANOG Acct) wrote: No, why don't you stop insulting people, Niels. You attack Peter because of his involvment in the Inclusive Namespace. FYI: John, I disagree. A person lacking the clues so badly and wildly guessing (and posting it) is dangerous and has to be told. I would prefer to see more research before such nonsense is posted again. But with this being the 20th time for this person I do not see that works. Procmail helps, but it still surfaces again and again it seems. Regards, Alexander
RIR Resource Allocation Data Inconsistencies
so, looking for somehting, i am wandering around potaroo etc, and i find these really strange reports about inconsistent data http://www.cidr-report.org/bogons/rir-data.html http://bgp.potaroo.net/stats/nro/ http://www.potaroo.net/drafts/draft-huston-ipv4-iana-registry-01.html and they seem to be current, in the sense they look to be generated daily (except the internet-draft, which i imagine is generated once a decade). are these, expecially one registry's data, as ahem unhappy as they seem? and how long has this been the case? randy
Re: h-root-servers.net (Level3 Question)
On Sun, 23 Oct 2005, Daniel Roesen wrote: On Sun, Oct 23, 2005 at 11:59:15AM +0200, Peter Dambier wrote: I means, here in germany we cannot see h.root-servers.net Here is my traceroute to h.root-servers.net right now: So, where do you see a problem related to L3/Cogent there? Your traceroute hits DREN, the operator of h.root-servers.net. agreed, looks like a dren 'issue' which MAY be a planned event? DREN probably shouldn't filter traffic to/from h-root (aside from udp/53 | tcp/53 traffic) no 'prefix-X not allowed to have access to h-root' sorts of things) That said, they MAY have done that, did someone (peter?) ask them? ; DiG 9.1.3 . @h.root-servers.net ;; global options: printcmd ;; connection timed out; no servers could be reached DREN seems to have a problem there. I can see absolutely NO connection to any L3/Cogent dispute. And testing from DTAG 84/8 space myself I have the same prob. Perhaps some bogus anti-bogon-filters at DREN in place? That could be as well, I might be able to ask them perhaps as well.
Re: estimating VoIP data traffic size from VoIP signaling traffic size ?
Use about 100k per call for 711u and it will help make the numbers actually around 88.2k. I did say round you know! Lol... Things like VAD would drop the numbers even lower for G.711. nice and round. If you are trying to calculate busy hour search for Erlang on your nearest web confabulator. There are also innumerable spots on the web where you can find typical numbers for various codecs. I'd like to suggest to people looking at these things to insure that your stats toolset includes both bps and pps in the polls. SYNs are low bps rate, but a high pps rate of them can mean something bad.. it's useful to know how fast these counters are incrementing. Agree with you on that one... PPS is commonly overlooked. Folks are so interested in those bits per second they sometimes miss the obvious. From the VoIP perspective it would also be helpful to keep track of your signaling to RTP traffic ratio. If you find that your signaling demands have increased dramatically compared to your RTP traffic you may have other problems to worry about besides maintaining link capacity. If you find that your RTP traffic has suddenly increased it is certainly a potential worry factor as well. I just finished dealing with a mysterious sudden growth in RTP traffic. The bad part was that it caused initial happiness (the money dance) followed by oh crap we have a bug a couple days later. Incomplete signaling can bite you pretty hard when DSPs don't know they are supposed to hang up.
Re: estimating VoIP data traffic size from VoIP signaling traffic size ?
Media traffic volumes are generally not visible, because they're from endpoint to endpoint, so unless you've got really detailed monitoring (which the original poster said they didn't), you're not going to see traffic between two phones in the same building, or traffic between buildings that don't have the call manager in them. Obviously the measurement problems are different for ISPs, enterprises with IP-PBXs, and VOIP companies. Also, the amount of media volume not only depends on the codec, but also on the length of the call, while the signalling volume mainly depends on the number of calls. So if your customers are averaging 3 minute calls, that's a much different ratio than if they're doing 10-second credit card validation calls or one-minute voicemail pickups or 60-minute teleconferences. If you had enough measurement capability to estimate this, you could use that directly instead of guessing from signalling traffic, but otherwise you're just guessing.
Re: Level3 Question
On Sun, 23 Oct 2005 11:16:58 PDT, Randy Bush said: A friend of mine has got a colo box sitting, single-homed friends don't let friends home singly I dunno. I got a lot of single-homed friends. If I got them all to multihome, and everybody else on NANOG got all *their* single-homed friends multihome, it might do something suboptimal to the routing tables. Do we *really* want to do anything to encourage a higher burn rate of AS numbers before we've deployed 32-bit AS number support? pgpn9g3eAZCq2.pgp Description: PGP signature
Re: Level3 Question
On Mon, 24 Oct 2005, [EMAIL PROTECTED] wrote: Do we *really* want to do anything to encourage a higher burn rate of AS numbers before we've deployed 32-bit AS number support? Consider it a looming incentive to do so. Fundamently, if economic decisions create holes in the routing infrastucture, it seems likely if not inevitable that the people who are adversly affected will plug the hole from their perspective before it affects their bottom line. Obviously it has a cost both locally and globally, but a few more people tune their risk mangement model (or decide they need one) everytime this happens. joelja -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
