Re: question on algorithm for radius based accouting
Hello Joe - The Acct-Session-Time is what the NAS is reporting as the duration of the session, and the Acct-Delay-Time is the NAS reporting any delay in sending the accounting request (usually due to retransmissions). The time the accounting request(s) is(are) received by the RADIUS server host may or may not be relevant, depending on where the NAS and the RADIUS host are located geographically and whether or not the time on the RADIUS server host is correct. The best approach is to generate an event timestamp which is the time the accounting stop is received minus the Acct-Delay-Time (if present). The start time is therefore the corrected timestamp minus the Acct-Session-Time. Note that RFC 2869 specifies an Event-Timestamp attribute which is meant to indicate the time on the NAS that the accounting event occurred, but I have never seen it used. regards Hugh On 17 Aug 2007, at 11:53, Joe Shen wrote: hi, I 'google' algorithm for radius based accounting. but can't find anything. My question is: what's the best algorithm for constrcting broadband access record from radius accouting packets? To my knowledge, some system takes: Record Accouting-on packet arriving time - record Accouting-Off packet's Acct-Session-Time and Acct-Delay-Time - The Log-off time is calculated as: Accouting-on time + ( Acct-Session-Time - Acct_delay-Time) But, some other takes : Record Accouting-off arriving time -- record Accouting-Off packet's Acct-Session-Time and Acct-Delay-Time -- Log-on time is calculated as: Accouting-off arriving time - ( Acct-Session-Time - Acct_delay-Time) Are the two methods have the same effect on calculating result? If radius packets were sent to two accouting systems simulataneusly, while the two system takes the different algorithm, will there be any difference between the result of accouting ? regards Joe __ Yahoo! Movies - Search movie info and celeb profiles and photos. http://sg.movies.yahoo.com/ NB: Have you read the reference manual (doc/ref.html)? Have you searched the mailing list archive (www.open.com.au/archives/ radiator)? Have you had a quick look on Google (www.google.com)? Have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening? Have you checked the RadiusExpert wiki: http://www.open.com.au/wiki/index.php/Main_Page -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows, MacOS X. Includes support for reliable RADIUS transport (RadSec), and DIAMETER translation agent. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. - CATool: Private Certificate Authority for Unix and Unix-like systems.
Anyone seeing ongoing issues with AOL?
Anyone else seeing ongoing issues with AOL? I started having users badger me about not being able to reach our video site about 3 days ago. With traces out, I am seeing in the range of 50% packet losses when I get into AOL. I tried this from both my Cogent, and another location where we have a link going via Telia. Packets Pings HostLoss% Snt Last Avg Best Wrst StDev 14. aol-114080-ldn-b2.telia.net 0.0% 100 94.9 103.9 94.0 159.4 9.6 15. aol-114080-ldn-b2.telia.net 0.0% 100 103.3 97.8 92.8 134.3 7.0 16. bb2-loh-S1-1-0.atdn.net 0.0% 100 94.6 97.9 93.1 149.4 8.1 17. accessl1-los-S0-3-0.atdn.net 0.0% 100 95.8 96.7 92.8 120.9 3.8 18. accessl1-los-S0-1-0.atdn.net 51.5% 100 95.5 96.5 92.9 125.5 4.9 19. rt-lostb06.proxy.aol.com 51.0% 100 93.6 96.3 93.6 116.1 4.1 Packets Pings HostLoss% Snt Last Avg Best Wrst StDev 3. v3489.mpd01.dca02.atlas.cogentco 0.0% 1000.9 9.3 0.8 205.3 29.9 4. v3494.mpd01.iad01.atlas.cogentco 0.0% 1009.5 16.6 1.1 191.9 34.1 5. verio.iad01.atlas.cogentco.com 27.0% 1001.0 1.5 0.9 12.3 1.9 6. pop2-ash-S2-1-1.atdn.net 23.2% 1001.1 2.3 1.0 25.1 3.9 7. bb2-ash-P2-0.atdn.net24.0% 1001.1 17.8 0.9 192.6 42.7 8. bb1-nye-P3-0.atdn.net20.0% 1006.6 20.8 6.4 212.3 44.2 9. bb1-loh-S1-2-0.atdn.net 28.3% 100 81.8 83.1 81.6 100.8 4.3 10. pop1-loh-S1-0-0.atdn.net28.0% 100 77.3 79.3 77.2 98.5 2.8 11. accessl1-los-S0-1-0.atdn.net22.2% 100 81.9 81.6 79.5 90.7 2.7 Find it hard to believe this is killing us, and not affecting a lot of others, but I haven't seen any chatter on list about it.. --- Howard Leadmon
Re: Extreme congestion (was Re: inter-domain link recovery)
On 8/17/07, Adrian Chadd [EMAIL PROTECTED] wrote: On Thu, Aug 16, 2007, [EMAIL PROTECTED] wrote: I'm pushing an agenda in the open source world to add some concept of locality, with the purpose of moving traffic off ISP networks when I can. I think the user will be just as happy or happier, and folks pushing large optics will certainly be. This is badly needed in my humble opinion; regarding the wireless LAN case described, it's true that this behaviour would be technically suboptimal, but interestingly the real reason for implementing it would be maintained - economics. After all, the network operator (the owner of the wireless LAN) isn't consuming any more upstream as a result. When you hear stories like the Icelandic ISP who discovered that P2P was 80% of their submarine bandwidth and promptly implemented P2P throttling, I think that the open source P2P will be driven to it by their user demand. Yes. An important factor in future design will be network friendliness/responsibility. .. or we could start talking about how Australian ISPs are madly throttling P2P traffic. Not just because of its impact on international trunks, but their POP/wholesale DSL infrastructure method just makes P2P even between clients on the same ISP mostly horrible. Similar to the pre-LLU, BT IPStream ops in the UK. Charging flat rates to customers and paying per-bit to wholesalers is an obvious economic problem; possibly even more expensive to localise the p2p traffic, if the price of wholesale access bits is greater than peering/transit ones!
Re: Extreme congestion (was Re: inter-domain link recovery)
Ted Hardie wrote: Fred Baker writes: Hence, moving a file into a campus doesn't mean that the campus has the file and will stop bothering you. I'm pushing an agenda in the open source world to add some concept of locality, with the purpose of moving traffic off ISP networks when I can. I think the user will be just as happy or happier, and folks pushing large optics will certainly be. As I mentioned to Fred in a bar once, there is at least one case where you have to be a bit careful with how you push locality. In the wired campus case, he's certainly right: if you have the file topologically close to other potentially interested users, delivering it from that nearer source is a win for pretty much everyone. This is partly the case because the local wired network is unlikely to be resource constrained, especially in comparison to the upstream network links. In some wireless cases, though, it can be a bad thing. Imagine for a moment that Fred and I are using a p2p protocol while stuck in an airport. We're both looking for the same file. The p2p network pushes it first to Fred and then directs me to get it from him. If he and I are doing this while we're both connected to the same resource-constrained base station, we may actually be worse off, as the same base station has to allocate data channels for two high data traffic flows while it passes from him to me. If I/the second user gets the file from outside the pool of devices connected to that base station, in other words, the base station , I, and its other users may well be better off. A similar (and far more common) issue exists in the UK where ISPs are buying their DSL 'last mile' connectivity via a BT central pipe. Essentially in this setup BT owns all the exchange equipment and the connectivity back to a central hand-off location - implemented as a L2TP VPDN. When the DSL customers connects, their realm is used to route their connection over the VPDN to the ISP. The physical hand-off point between BT and the ISP is what BT term a BT Central Pipe, which is many orders of magnitude more expensive than IP transit. In this scenario it's more expensive for the ISP to have a customer retrieve the file from another customer on their network, then it is to go off net for the file. (LLU (where the ISP has installed their own equipment in the exchange) changes this dynamic obviously). S
Re: Extreme congestion (was Re: inter-domain link recovery)
Sam Stickland wrote: Ted Hardie wrote: Fred Baker writes: Hence, moving a file into a campus doesn't mean that the campus has the file and will stop bothering you. I'm pushing an agenda in the open source world to add some concept of locality, with the purpose of moving traffic off ISP networks when I can. I think the user will be just as happy or happier, and folks pushing large optics will certainly be. As I mentioned to Fred in a bar once, there is at least one case where you have to be a bit careful with how you push locality. In the wired campus case, he's certainly right: if you have the file topologically close to other potentially interested users, delivering it from that nearer source is a win for pretty much everyone. This is partly the case because the local wired network is unlikely to be resource constrained, especially in comparison to the upstream network links. In some wireless cases, though, it can be a bad thing. Imagine for a moment that Fred and I are using a p2p protocol while stuck in an airport. We're both looking for the same file. The p2p network pushes it first to Fred and then directs me to get it from him. If he and I are doing this while we're both connected to the same resource-constrained base station, we may actually be worse off, as the same base station has to allocate data channels for two high data traffic flows while it passes from him to me. If I/the second user gets the file from outside the pool of devices connected to that base station, in other words, the base station , I, and its other users may well be better off. A similar (and far more common) issue exists in the UK where ISPs are buying their DSL 'last mile' connectivity via a BT central pipe. Essentially in this setup BT owns all the exchange equipment and the connectivity back to a central hand-off location - implemented as a L2TP VPDN. When the DSL customers connects, their realm is used to route their connection over the VPDN to the ISP. The physical hand-off point between BT and the ISP is what BT term a BT Central Pipe, which is many orders of magnitude more expensive than IP transit. In this scenario it's more expensive for the ISP to have a customer retrieve the file from another customer on their network, then it is to go off net for the file. (LLU (where the ISP has installed their own equipment in the exchange) changes this dynamic obviously). S Also bear in mind that many wireless systems have constrained uplink capacity and anything P2P can quite happily kill a wireless network by using up too much uplink resource. -- Leigh Porter
Re: Extreme congestion (was Re: inter-domain link recovery)
On Fri, Aug 17, 2007 at 10:54:47AM +0100, Sam Stickland wrote: Ted Hardie wrote: Fred Baker writes: Hence, moving a file into a campus doesn't mean that the campus has the file and will stop bothering you. I'm pushing an agenda in the open source world to add some concept of locality, with the purpose of moving traffic off ISP networks when I can. I think the user will be just as happy or happier, and folks pushing large optics will certainly be. As I mentioned to Fred in a bar once, there is at least one case where you have to be a bit careful with how you push locality. In the wired campus case, he's certainly right: if you have the file topologically close to other potentially interested users, delivering it from that nearer source is a win for pretty much everyone. This is partly the case because the local wired network is unlikely to be resource constrained, especially in comparison to the upstream network links. In some wireless cases, though, it can be a bad thing. Imagine for a moment that Fred and I are using a p2p protocol while stuck in an airport. We're both looking for the same file. The p2p network pushes it first to Fred and then directs me to get it from him. If he and I are doing this while we're both connected to the same resource-constrained base station, we may actually be worse off, as the same base station has to allocate data channels for two high data traffic flows while it passes from him to me. If I/the second user gets the file from outside the pool of devices connected to that base station, in other words, the base station , I, and its other users may well be better off. A similar (and far more common) issue exists in the UK where ISPs are buying their DSL 'last mile' connectivity via a BT central pipe. Essentially in this setup BT owns all the exchange equipment and the connectivity back to a central hand-off location - implemented as a L2TP VPDN. When the DSL customers connects, their realm is used to route their connection over the VPDN to the ISP. The physical hand-off point between BT and the ISP is what BT term a BT Central Pipe, which is many orders of magnitude more expensive than IP transit. In this scenario it's more expensive for the ISP to have a customer retrieve the file from another customer on their network, then it is to go off net for the file. Hey Sam, thats an excellent point made.. Altho I dont think its unique to UK/BT .. since last mile is recognised as most places as the big cost (in the UK its around 100x the cost of the backbone roughly) .. here anything traversing the last mile is not desirable, especially if it does it twice. Steve
Re: Extreme congestion (was Re: inter-domain link recovery)
On Thu, Aug 16, 2007 at 09:07:31AM -0700, Hex Star wrote: How does akamai handle traffic congestion so seamlessly? Perhaps we should look at existing setups implemented by companies such as akamai for guidelines regarding how to resolve this kind of issue... and if you are a Content Delivery Network wishing to use a cache deployment architecture you should do just that ... but for networks with big backbones as per this discussion we need to do something else Steve
Re: Extreme congestion (was Re: inter-domain link recovery)
On Aug 17, 2007, at 6:57 AM, Stephen Wilcox wrote: On Thu, Aug 16, 2007 at 09:07:31AM -0700, Hex Star wrote: How does akamai handle traffic congestion so seamlessly? Perhaps we should look at existing setups implemented by companies such as akamai for guidelines regarding how to resolve this kind of issue... and if you are a Content Delivery Network wishing to use a cache deployment architecture you should do just that ... but for networks with big backbones as per this discussion we need to do something else Ignoring Akamai and looking at just content providers (CDN or otherwise) in general, there is a huge difference between telling a web server do not serve more than 900 Mbps on your GigE port, and a router which simply gets bits from random sources to be forwarded to random destinations. IOW: Steve is right, those are two different topics. -- TTFN, patrick
BGP Update Report
BGP Update Report Interval: 16-Jul-07 -to- 16-Aug-07 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS14906 173904 2.7% 34780.8 -- 2 - AS9583 150061 2.4% 128.5 -- SIFY-AS-IN Sify Limited 3 - AS701863517 1.0% 41.0 -- ATT-INTERNET4 - ATT WorldNet Services 4 - AS24731 62197 1.0%1480.9 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 5 - AS14201 61213 1.0%6121.3 -- 6 - AS30850 58130 0.9% 29065.0 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 7 - AS13285 48474 0.8%6924.9 -- OPALTELECOM-AS Opal Telecom 8 - AS462147071 0.7% 318.0 -- UNSPECIFIED UNINET-TH 9 - AS27685 40263 0.6%2368.4 -- PEOPLE ONLINE 10 - AS24326 36235 0.6% 204.7 -- TTT-AS-AP Maxnet, Internet Service Provider, Bangkok 11 - AS21452 35613 0.6%5087.6 -- skannet-ibadan 12 - AS24863 33878 0.5% 93.1 -- LINKdotNET-AS 13 - AS702 32951 0.5% 49.9 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe 14 - AS21332 31655 0.5%1266.2 -- NTC-AS New Telephone Company 15 - AS19444 31341 0.5% 460.9 -- CHARTER-STL - CHARTER COMMUNICATIONS 16 - AS876429725 0.5% 17.8 -- TEOLTAB TEO LT AB Autonomous System 17 - AS26210 29694 0.5% 285.5 -- AES Communications Bolivia S.A. 18 - AS580328406 0.4% 208.9 -- DDN-ASNBLK - DoD Network Information Center 19 - AS651728391 0.4% 47.6 -- YIPESCOM - Yipes Communications, Inc. 20 - AS815127341 0.4% 29.5 -- Uninet S.A. de C.V. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS14906 173904 2.7% 34780.8 -- 2 - AS30850 58130 0.9% 29065.0 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 3 - AS27289 22605 0.3% 22605.0 -- CLEOCOMMUNICATIONS - CLEO COMMUNICATIONS INC 4 - AS22072 18947 0.3% 18947.0 -- 5 - AS22433 10103 0.2% 10103.0 -- HRMC - Human Resource Management Center, Inc. 6 - AS268299025 0.1%9025.0 -- YKK-USA - YKK USA,INC 7 - AS13285 48474 0.8%6924.9 -- OPALTELECOM-AS Opal Telecom 8 - AS430436523 0.1%6523.0 -- INTERKOM-AS Interkom Sp. z o.o. 9 - AS14201 61213 1.0%6121.3 -- 10 - AS21348 10682 0.2%5341.0 -- KOPTERIFI KOPTERIFI is autonomous system. Located in Vammala Finland 11 - AS19001 10230 0.2%5115.0 -- AVENTCOMMTECH - Aventure Communications 12 - AS21452 35613 0.6%5087.6 -- skannet-ibadan 13 - AS30707 14112 0.2%4704.0 -- 14 - AS394083099 0.1%3099.0 -- CZ-ETHERNET AVI ethernet.cz 15 - AS41688 17508 0.3%2918.0 -- COSMOFON-AS AS for Cosmofon 16 - AS208162905 0.1%2905.0 -- IIP-NET-AS20816 Science and Society Telecomm Center 17 - AS9660 7396 0.1%2465.3 -- KANNET-AS-AP Telecommunication and ISP company 18 - AS13620 26365 0.4%2396.8 -- ASN-ELAN - Elan Communications, Inc. 19 - AS27685 40263 0.6%2368.4 -- PEOPLE ONLINE 20 - AS303752298 0.0%2298.0 -- TEVA-NA - Teva Pharmaceuticals USA, INC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 194.110.73.0/24 58106 0.8% AS30850 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 2 - 221.135.22.0/24 51573 0.8% AS9583 -- SIFY-AS-IN Sify Limited 3 - 62.24.238.0/2448431 0.7% AS13285 -- OPALTELECOM-AS Opal Telecom 4 - 221.135.253.0/24 44992 0.7% AS9583 -- SIFY-AS-IN Sify Limited 5 - 12.27.90.0/24 38559 0.6% AS14906 -- 6 - 12.27.91.0/24 38541 0.6% AS14906 -- 7 - 12.27.88.0/24 33324 0.5% AS14906 -- 8 - 12.27.89.0/24 33197 0.5% AS14906 -- 9 - 170.65.189.0/24 30613 0.5% AS14201 -- 10 - 80.243.64.0/2030527 0.5% AS21332 -- NTC-AS New Telephone Company 11 - 170.65.176.0/22 30507 0.5% AS14201 -- 12 - 12.27.88.0/22 30283 0.4% AS14906 -- 13 - 210.214.198.0/24 23672 0.3% AS9583 -- SIFY-AS-IN Sify Limited 14 - 208.46.32.0/2422605 0.3% AS27289 -- CLEOCOMMUNICATIONS - CLEO COMMUNICATIONS INC 15 - 200.123.224.0/24 19731 0.3% AS27685 -- PEOPLE ONLINE 16 - 200.123.225.0/24 19728 0.3% AS27685 -- PEOPLE ONLINE 17 - 12.106.30.0/2418947 0.3% AS22072 -- 18 - 203.23.208.0/24 17831 0.3% AS7604 -- HWY1-AS Highway 1 19 - 117.58.192.0/19 14500 0.2% AS7491 -- PI-PH-AS-AP PI-PHILIPINES 20 - 64.95.193.0/2414087 0.2% AS30707 -- Details at http://bgpupdates.potaroo.net Copies of this report are mailed to: nanog@merit.edu [EMAIL PROTECTED]
The Cidr Report
This report has been generated at Fri Aug 17 21:15:09 2007 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
10-08-07232344 152445
11-08-07232549 152848
12-08-07232750 153190
13-08-07232943 153449
14-08-07233036 153758
15-08-07233441 154200
16-08-07233579 154379
17-08-07233289 154764
AS Summary
26065 Number of ASes in routing system
11030 Number of ASes announcing only one prefix
1496 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
88769536 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 17Aug07 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 233590 1547927879833.7% All ASes
AS18566 1019 111 90889.1% COVAD - Covad Communications
Co.
AS4755 1325 432 89367.4% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS6478 1115 280 83574.9% ATT-INTERNET3 - ATT WorldNet
Services
AS4134 1332 569 76357.3% CHINANET-BACKBONE
No.31,Jin-rong Street
AS11492 1124 435 68961.3% CABLEONE - CABLE ONE
AS4323 1327 696 63147.6% TWTC - Time Warner Telecom,
Inc.
AS9394 848 238 61071.9% CRNET CHINA RAILWAY
Internet(CRNET)
AS19262 763 235 52869.2% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS15270 568 77 49186.4% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS17488 759 269 49064.6% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS7018 1496 1008 48832.6% ATT-INTERNET4 - ATT WorldNet
Services
AS7545 716 231 48567.7% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS9498 998 521 47747.8% BBIL-AP BHARTI BT INTERNET
LTD.
AS8151 920 455 46550.5% Uninet S.A. de C.V.
AS2386 1207 749 45837.9% INS-AS - ATT Data
Communications Services
AS17676 503 65 43887.1% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS4766 797 360 43754.8% KIXS-AS-KR Korea Telecom
AS18101 588 161 42772.6% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS9443 482 82 40083.0% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS4812 543 153 39071.8% CHINANET-SH-AP China Telecom
(Group)
AS22773 753 376 37750.1% CCINET-2 - Cox Communications
Inc.
AS6197 1031 656 37536.4% BATI-ATL - BellSouth Network
Solutions, Inc
AS19916 568 205 36363.9% ASTRUM-0001 - OLM LLC
AS4808 476 116 36075.6% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS4668 516 168 34867.4% LGNET-AS-KR LG CNS
AS16814 426 86 34079.8% NSS S.A.
AS9942 439 121 31872.4% COMINDICO-AP SOUL Converged
Communications Australia
AS577572 265 30753.7% BACOM - Bell Canada
AS3602 390 84 30678.5% AS3602-RTI - Rogers Telecom
Inc.
AS7029 417 118 29971.7% WINDSTREAM - Windstream
Re: question on algorithm for radius based accouting
On 17 Aug 2007, at 04:52, Alex Rubenstein wrote: My question is: what's the best algorithm for constrcting broadband access record from radius accouting packets? [snip] They should yield (approximately) the same result. But, to be pedantic, you haven't accounted for latency within the network. Somebody should be whipped, either for: 1) If you can find a network where that matters, even in the slightest, the oerson responsible for the design and/or maintainance OR 2) You, for making even this aged arch-pedant wince. :-) Seriously, can I also add that RADIUS interim accounting is almost essential in this scenario. Real world accounting and session boundaries mis-match badly making it almost mandatory to use interim accounting records to get an approximation of what the figures look like from a billing perspective. I'll also add watch out for missing records - I've found RADIUS to be the lossiest network protocol per foot of cabling that I've ever used.
Paetec outage
Hi all, we are getting complaints from a bunch of our clients with Paetec circuits in the Newark, NJ area. Anyone know of any outages in the area? Tim Donahue
RE: question on algorithm for radius based accouting
They should yield (approximately) the same result. But, to be pedantic, you haven't accounted for latency within the network. Somebody should be whipped, either for: 2) You, for making even this aged arch-pedant wince. :-) Ding! Seriously, can I also add that RADIUS interim accounting is almost essential in this scenario. Real world accounting and session boundaries mis-match badly making it almost mandatory to use interim accounting records to get an approximation of what the figures look like from a billing perspective. I'll also add watch out for missing records - I've found RADIUS to be the lossiest network protocol per foot of cabling that I've ever used. I can't say I've seen this. Having collected hundreds of millions of radius packets in my years (hell, we were running PM-2e's in 1996), and have written several accounting collectors, I can't say I agree. If you follow the specifications properly, unless you have issues with the transmitting device (read: BUG), RADIUS accounting has always been good to me. And, I've not seen the behavior you describe that requires interim.
AS14906: wtf? (Fwd: BGP Update Report)
OK, I have to ask... Begin forwarded message: From: [EMAIL PROTECTED] Date: August 17, 2007 5:00:04 AM PDT To: [EMAIL PROTECTED] Cc: nanog@merit.edu, [EMAIL PROTECTED], [EMAIL PROTECTED], routing- [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: BGP Update Report BGP Update Report Interval: 16-Jul-07 -to- 16-Aug-07 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS14906 173904 2.7% 34780.8 -- ... 14906 has been getting busy for a while now. I found it associated with SCS/Netsite Inc. in a 4 year old file (http:// www.employees.org/~tbates/autnums.html), but it isn't in any registry database (at least that I can tell). Can anybody explain this to me? Just curious. Thanks, -drc
Kill this thread (Re: DNS not working)
I think this thread is obviously silly, so please refrain from posting further on this and feeding the troll... Thanks! On Thu, 16 Aug 2007 [EMAIL PROTECTED] wrote: Hi, I try adding google.com to my dns server to get more visitors but google.com still show search engine. Please advise how to do so more visitor in return? May the Gods be with you!
Road Runner / Sprint routing / DNS issues this morning?
I've had a steady trickle of reachability complaints coming from Road Runner users over the course of the day today. I started seeing wackiness about 7:30AM Eastern this morning when a VPN tunnel into a Road Runner customer dropped off. It seems as if the problems have stabilized over the last hour or so, but I'm curious as to what happened. I'm hearing rumors of some type of Road Runner outage and/or DNS problems and/or general routing brokenness that may or may not have involved Sprint. (How's that for specificity?) Any truth to the rumors, or can anyone provide more detail? Thanks, Andrew Cruse
Re: Re: DNS not working - Rank High
On 8/17/07, Hex Star [EMAIL PROTECTED] wrote: On Thu, 16 Aug 2007 [EMAIL PROTECTED] wrote: Hi, I try adding google.com to my dns server to get more visitors but google.com still show search engine. Please advise how to do so more visitor in return? May the Gods be with you! There is a special secret to getting Google to rank you highest in the world. The first thing you have to do is get a dictionary and make one webpage for every single word in the dictionary. You CANNOT automate this, you have to type in every single word in the dictionary. When you have finished this, email me and I will continue to help you dominate the search rankings. See only true network ninjas and dojo webmasters will help you not those NANOG sissies. All those guys do is drink Mountain Dew and eat Soda Pop fizzy candy all day (http://www.groovycandies.com/V2ProdDetail1.asp?Product_ID=8038 ) I don\'t know why they do this must be some form of Tymnet pre Internet BBS thing from Bolt, Beranek and Newman days. So when you finished making these pages in both english and spanish, e-mail me. I can make you seriously richer then Deng Xiaoping overnight. -- J. Oquendo \Excusatio non petita, accusatio manifesta\ http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF684C42E sil . infiltrated @ net http://www.infiltrated.net Thank you oh wise wonton soop!
Re: Do I or RR need dns clue?
In article [EMAIL PROTECTED] you write:
Tuc at T-B-O-H.NET wrote:
Down is there isn't power to it until it gets repaired. So its not
answering period. A nslookup shows timed-out. A dig shows
connection timed out; no servers could be reached (When querying ONLY
against the down server).
So how do I go back to RR, who told me to take it out of my
NS records, that DNS is supposed to be silently falling back and trying
again?
The fact that they're rejecting on a 5xx error based on no DNS PTR is a
bit harsh. While I'm all for requiring all hosts to have valid PTR
records, there are times when transient or problem servers can cause a
DNS lookup failure or miss, etc. If anything they should be returning a
4xx to have the remote hosttry again later.
Robert,
Sorry, they aren't giving a hard fail. Its a soft fail, so we'll
retry. But after 5 days of retrying, my servers will give up. (And, in
the mean time, the mail isn't getting through, so my users are without mail
{We store/forward for them} I don't know if the down (hard) server will be
back that soon (Its been 2 days as is). But the whole POINT of DNS is I have
a 2nd one listed, and they don't seem to care. They are telling me that they
want my primary one back up and running.
Tuc/TBOH
I know this is strange for nanog but if you actually stated the
IP addresses of the mail servers we could look to see if there
is a problem other than what you think the problem is.
You havn't stated it here or on bind-users
Mark
Hi,
Just a note to let everyone know its all working again. I was
escalated to someone else in RR and intelligent things came out of their
mouth and its not an issue anymore.
The initial responder at RR needs a clue, and the bind-users said
I was doing something moderately bad at the same time. I'm working out
a tactic to resolve my bent-clue issue. I hope to have that fixed in a
week or so. RR is now accepting my mail despite my bent clue and one
DNS server being down.
Tuc/TBOH
Re: Re: DNS not working - Rank High
On 8/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 8/17/07, Hex Star [EMAIL PROTECTED] wrote: On Thu, 16 Aug 2007 [EMAIL PROTECTED] wrote: Hi, I try adding google.com to my dns server to get more visitors but google.com still show search engine. Please advise how to do so more visitor in return? May the Gods be with you! There is a special secret to getting Google to rank you highest in the world. The first thing you have to do is get a dictionary and make one webpage for every single word in the dictionary. You CANNOT automate this, you have to type in every single word in the dictionary. When you have finished this, email me and I will continue to help you dominate the search rankings. See only true network ninjas and dojo webmasters will help you not those NANOG sissies. All those guys do is drink Mountain Dew and eat Soda Pop fizzy candy all day (http://www.groovycandies.com/V2ProdDetail1.asp?Product_ID=8038 ) I don\'t know why they do this must be some form of Tymnet pre Internet BBS thing from Bolt, Beranek and Newman days. So when you finished making these pages in both english and spanish, e-mail me. I can make you seriously richer then Deng Xiaoping overnight. -- J. Oquendo \Excusatio non petita, accusatio manifesta\ http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF684C42E sil . infiltrated @ net http://www.infiltrated.net Thank you oh wise wonton soop! Please note that I did not write that, I am confused as to why Lee Yao decided to replace the original senders name (whoever it is, I can only assume Lee Yao received the post offlist and decided to reply on list anyways...) with mine and am very unhappy that he is trying to get me involved is his games. He should be unsubscribed from the list as he has contributed absolutely nothing but garbage!
Re: DNS not working - Rank High
Hex Star wrote: On 8/17/07, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 8/17/07, Hex Star [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Thu, 16 Aug 2007 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I try adding google.com http://google.com to my dns server to get more visitors but google.com http://google.com still show search engine. Please advise how to do so more visitor in return? May the Gods be with you! There is a special secret to getting Google to rank you highest in the world. The first thing you have to do is get a dictionary and make one webpage for every single word in the dictionary. You CANNOT automate this, you have to type in every single word in the dictionary. When you have finished this, email me and I will continue to help you dominate the search rankings. See only true network ninjas and dojo webmasters will help you not those NANOG sissies. All those guys do is drink Mountain Dew and eat Soda Pop fizzy candy all day (http://www.groovycandies.com/V2ProdDetail1.asp?Product_ID=8038 ) I don\'t know why they do this must be some form of Tymnet pre Internet BBS thing from Bolt, Beranek and Newman days. So when you finished making these pages in both english and spanish, e-mail me. I can make you seriously richer then Deng Xiaoping overnight. -- J. Oquendo \Excusatio non petita, accusatio manifesta\ http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF684C42E http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF684C42E sil . infiltrated @ net http://www.infiltrated.net Thank you oh wise wonton soop! Please note that I did not write that, I am confused as to why Lee Yao decided to replace the original senders name (whoever it is, I can only assume Lee Yao received the post offlist and decided to reply on list anyways...) with mine and am very unhappy that he is trying to get me involved is his games. He should be unsubscribed from the list as he has contributed absolutely nothing but garbage! I disagree, he contributed comedy, which always helps when you're up at midnight watching your GGSN die :) -- Leigh Porter UK Broadband
