RE: Cisco interface - GB of transfer software
I have had good success with Netflow data to solve this, and if you don't mind spending a little money, Scrutinizer is a good tool to use. Mike -Original Message- From: Jack Bates [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 8:58 AM To: Daniel Senie Cc: nanog@nanog.org Subject: Re: Cisco interface - GB of transfer software Daniel Senie wrote: > MRTG provides graphs of usage, but I'm not aware of it providing a > monthly total usage (or 95% or other) in report form (though would be > happy to learn otherwise). > > Does ntop provide a way to generate a monthly report? > > I believe the others posting are interested in this from a billing > perspective. I share their interest. > Cacti and MRTG both have support for rrdtool backends. How the rrd is processed is up to you. A simple script to poll data and do some basic math and email the results, or generate a graph. Cacti has several plugins for sending reports. MRTG users tend to just script additionals. It's not as gui oriented as cacti, IMO. Each has pros and cons. If you have a sound internal php/mysql setup, cacti is a breeze and the plugin php scripts are cute for the non-techies. -Jack -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM.
RE: Verizon/UU.net/Alternet Routing issue
I was told this was a Level3 router leaking bad routes into Verizon, and was told the problem is now resolved. Mike -Original Message- From: Paul Jasa [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2008 2:27 PM To: jamie rishaw; Peter Beckman Cc: nanog@nanog.org Subject: RE: Verizon/UU.net/Alternet Routing issue Same here. Saw the issue from Los Angeles, and from New York. Traces were dropping a few hops into the Verizon cloud. BGP stayed up, but routing went nowhere. Paul From: jamie rishaw [mailto:[EMAIL PROTECTED] Sent: Wed 11/12/2008 3:14 PM To: Peter Beckman Cc: nanog@nanog.org Subject: Re: Verizon/UU.net/Alternet Routing issue Confirmed here as well; Saw loss on DS3s between 424 and 440 EST. BGP survived but routing didnt .. No RCA yet from VZN (on hold). On Wed, Nov 12, 2008 at 3:47 PM, Peter Beckman <[EMAIL PROTECTED]> wrote: > At about 4:24pm EDT, I lost connectivity from Verizon to destinations in > New York, Seattle and others. Came back up (4:46pm) while composing this > email. Anyone else notice? Major problem or minor routing issue? > > Packets Pings > HostLoss% Snt Last Avg Best Wrst StDev > 1. localrouter 67.6% 3950.6 1.6 0.5 18.8 2.3 > 2. 10.1.41.150.0% 3955.7 5.1 1.8 306.0 > 17.4 > 3. P4-2.LCR-02.WASHDC.verizon-g 0.0% 3957.4 2.7 1.2 19.0 2.5 > 4. 130.81.29.218 0.0% 3956.0 3.8 1.8 40.9 > 4.2 > 5. 152.63.39.177 0.0% 3958.6 6.8 3.9 71.3 > 4.4 >152.63.36.213 > 6. 152.63.69.11371.6% 395 120.7 44.0 31.2 186.7 > 30.3 > 7. POS7-0-0.GW4.IND6.ALTER.NET 30.7% 395 1179. 133.3 121.3 1179. > 79.5 > 8. 152.63.67.25093.9% 395 121.5 125.4 121.0 186.2 > 13.0 > 9. POS6-0-0.GW4.IND6.ALTER.NET 53.0% 395 318.9 217.7 206.8 722.0 > 43.3 > 10. 152.63.67.25096.2% 395 211.1 211.1 209.0 215.7 > 1.8 > 11. POS6-0-0.GW4.IND6.ALTER.NET 67.0% 395 422.1 305.9 294.9 692.1 > 37.5 > 12. 152.63.67.25097.5% 394 295.1 298.0 295.1 303.6 > 2.5 > 13. POS6-0-0.GW4.IND6.ALTER.NET 73.5% 394 523.9 391.5 382.1 523.9 > 17.7 > 14. 152.63.67.25098.7% 392 388.5 386.6 381.9 389.5 > 3.1 > 15. POS6-0-0.GW4.IND6.ALTER.NET 82.6% 392 632.9 481.2 468.6 632.9 > 22.2 > 16. 152.63.67.25099.2% 388 472.7 472.2 470.2 473.6 > 1.8 > 17. POS6-0-0.GW4.IND6.ALTER.NET 85.8% 388 737.0 573.3 559.4 737.0 > 27.8 > 18. 152.63.67.25099.2% 387 560.5 562.0 560.5 565.1 > 2.7 > 19. POS6-0-0.GW4.IND6.ALTER.NET 89.6% 387 839.0 664.8 644.9 839.0 > 38.6 > 20. 152.63.67.25099.2% 387 649.3 649.6 649.3 649.9 > 0.3 > 21. POS6-0-0.GW4.IND6.ALTER.NET 94.8% 383 946.4 763.8 734.6 946.4 > 48.5 > 22. 152.63.67.25099.7% 376 735.5 735.5 735.5 735.5 > 0.0 > 23. POS6-0-0.GW4.IND6.ALTER.NET 92.5% 376 895.4 842.2 819.1 909.0 > 26.8 > 24. ??? > 25. POS6-0-0.GW4.IND6.ALTER.NET 96.7% 365 1153. 955.9 908.9 1153. > 78.7 > 26. ??? > 27. POS6-0-0.GW4.IND6.ALTER.NET 96.6% 328 1261. 1057. 998.8 1261. > 86.8 > 28. 152.63.67.25099.6% 245 999.3 999.3 999.3 999.3 > 0.0 > 29. POS6-0-0.GW4.IND6.ALTER.NET 98.8% 245 1189. 1123. 1086. 1189. > 57.5 > 30. ??? > > Beckman > --- > Peter Beckman Internet Guy > [EMAIL PROTECTED] > http://www.angryox.com/ > --- > > -- .!google!arpa.com!j The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM.
RE: Recommendation of Tools
If the question is to measure hop by hop latency from source to destination, perhaps across routers you don't manage, how can this be done without using the ICMP time exceeded messages? End to end latency is easily done with Smokeping and the use of TCP (SYN, SYN ACK, ACK, RST) and them timestamp it. This gives you a very clear idea on application latency on any tcp port. Hop by hop is a different story and the only option I know of is with the reliance on the ICMP mechanism. One additional question on this; how do you measure hop by hop when the path dynamically changes, and then record the path change (time/date and the differences in latency on the new path)? Mike -Original Message- From: Anders Lindbäck [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2008 10:02 AM To: Pekka Savola Cc: nanog@nanog.org Subject: Re: Recommendation of Tools Mtr is even less usefull then that, in its default mode it does a traceroute and then proceeds to ICMP Ping flood each IP in the list generated by the traceroute, the result is usually completly useless on WAN topologies due to asym-routing, ICMP node protections by carriers and punting etc.. And using UDP will not really provide better results due to the same thing, and IIRC Cisco from 12.0 has a standard setting of no more then 1 ICMP Unreach per 500ms.. -- Anders Lindbäck [EMAIL PROTECTED] On 3 dec 2008, at 12.00, Pekka Savola wrote: > On Tue, 2 Dec 2008, Antonio Querubin wrote: >> On Wed, 3 Dec 2008, Pekka Savola wrote: >>> FWIW, Mtr measures latency/delay and loss based on ICMP messages >>> heard >>> back from the routers on path. As a result, in almost all >>> cases, the real >>> hop-by-hop latency of actual end-to-end data packets is better >>> than it can >>> report. >> >> mtr has a recently added '-u' option to use UDP instead of ICMP >> echo requests. > > But that doesn't change the gist of my message: it's still relying > on ICMP ttl exceeded messages sent by the routers on the path to > check the delays etc. As such it suffers from basically the same > limitations as ICMP probing. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oykingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM.
RE: Failover solution using BGP
Why not just AS prepend your secondary site if the services to the Internet are the same at both sites and tied to the same IP addresses? Mike -Original Message- From: Chandler Bassett [mailto:chandler.bass...@gmail.com] Sent: Tuesday, December 30, 2008 4:15 PM To: Naveen Nathan Cc: nanog@nanog.org Subject: Re: Failover solution using BGP If the infrastructure is the same in both locations, why not load balance with stateful failover? If it's not the same in both locations, what are they doing for replication and the such in the event a site does go down? - Chandler On Dec 30, 2008, at 7:08 PM, Naveen Nathan wrote: > Hi, > > I would appreciate insight and experience for the following situation. > > I have a client that would like to announce a /18 & /19 over BGP in > Sacramento and LA, us being the second location in LA. Our location > will be a failover location incase Sacramento goes down. > > They want failover for extreme cases when they're completly down in > Sacramento. They have strict requirements so that traffic to their > blocks > should exclusively go to Sacramento or LA. > > This seems difficult to automate and they are aware of this. They will > contact their provider to stop announcing the blocks and subsequently > contact us to announce their routes. > > I am wondering is there a better way to approaching the situation > without resorting to announcing the routes when the client calls us > and tells us to failover. This seems to be the inherent problem aswell > because the customer wants this to be a manual process. > > -- > Naveen Nathan > > To understand the human mind, understand self-deception. - Anon > -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM.
