Re: Off Topic Friday
You get a 60 day trial with unlimited bandwidth and full features. After the 60 days are up, your throughput goes down to 2.5 mbps. I recommend running the latest version, IOS-XE 3.12. *Pablo Lucena* On Mon, Jun 2, 2014 at 2:05 AM, Mark Tinka wrote: > On Sunday, June 01, 2014 10:38:01 PM Rakesh M wrote: > > > if you want support for standards and RFC , emulating > > Major players sounds good. Just like IOS-XRV if you are > > looking for latest SP emulation, this depends on how > > much traffic / testing you are looking at. > > With CSR1000v (and IOS XRv), if all you want is to test > features, I think you get up to 2.5Mbps worth of throughput > free (I know this about CSR1000v, not sure about IOS XRv). > > If you want more, you then start to pay. > > Mark. >
Re: BGP process torture
Cisco's Pagent (a modified IOS image with numerous testing capabilities) can also be used to do this. *Pablo Lucena* On Mon, Nov 3, 2014 at 12:47 PM, chip wrote: > Exabgp should be able to help you out here. Great for doing fun things > with BGP. > > https://github.com/Exa-Networks/exabgp > > --chip > > On Mon, Nov 3, 2014 at 12:41 PM, Brandon Martin > wrote: > > > I'm attempting to help somebody re-produce a possible glitch that relies > > on heavily loading the BGP process on their router. Anybody know a > > good/pre-canned way to synthesize, preferably with some knobs to control > > behavior, a couple of full-table edge-like session in terms of number of > > routes as well as amount of churn? > > > > -- > > Brandon Martin > > > > > > -- > Just my $.02, your mileage may vary, batteries not included, etc >
Re: wanted: tool for traffic generation / characteristics / monitoring
Cisco has an IOS version called Pagent which allows you to craft whatever traffic types you want (you can even push MPLS labels on the packets if you want). I've used this in the past for generating client/server traffic flows and measuring stats on the flows. On Thu, Oct 1, 2015 at 12:20 PM, Matthias Flittner < matthias.flitt...@gmail.com> wrote: > Dear colleagues, > > Currently we are looking for a magic tool with which it is possible to > generate specific (realistic) traffic patterns between client and server > to analyze (monitor) traffic characteristics (jitter, delay, inter > arrival times, etc.). > > It would be good if that wanted tool is not only able to generate > different traffic patterns but also is able to collect different traffic > metrics over time. So that it is possible to create catchy plots. :) > > Any hints or links would be greatly appreciated. > > Thanks in advance. > > Best regards, > -FliTTi > >
Re: IGP choice
It comes down to personal preference now days in my opinion. Both ISIS and OSPFv3 allow you to run multi-af using the same protocol. Both of them dont run full SPF when a stub network is added/removed (unlike OSPFv2). How about vendor support? Perhaps ISIS has the upper hand here since its been around for so long, as compared to multi-af OSPFv3. If I had to build a network from scratch that need to support v4/v6, I would go with ISIS...but thats just personal preference. Some DC gear doens't support ISIS, so I guess it depends what the network is going to support. BGP as an IGP is also an interesting option =). *Pablo Lucena* On Thu, Oct 22, 2015 at 6:07 PM, Baldur Norddahl wrote: > On 22 October 2015 at 22:57, wrote: > > > - Needing OSPFv3 for IPv6 when you're alredy running OSPFv2 for IPv4 > > is less than optimal. I believe nowadays several vendors support > > OSPFv3 for both IPv4 and IPv6 - but this is not universal. > > > > Our configuration is MPLS VPNv6 for IPv6. Therefore we have no native IPv6 > in the backbone and no need for OSPFv3. > > The IPv4 internet is MPLS VPNv4 so there should be no easy way to attack > our OSPFv2 instance from outside. The attacker is simply not in the same > VRF as the routing protocol. > > Is this such an uncommon configuration? I am asking because nobody > mentioned this in the thread. > > Regards, > > Baldur >
Re: IGP choice
> A lot of carriers use ISIS in the core so they can make use of the' > overload bit' with a 'set-overload-bit on-startup wait-for-bgp". Keeps > them from black holing Traffic while BGP reconverges., when you have > millions of routes to converge it can take forever. It's also a really > handy tool when you're troubleshooting or repairing a link, set the OL > bit, and traffic gracefully moves, then when you're done it gracefully > moves back. You can do the same thing with the Metric, and Cost in OSPF, > just not quite as elegant. > That feature is also present in OSPF. 'max metric router-lsa'.
Re: The spam is real
On Sun, Oct 25, 2015 at 12:22 AM, Josh Luthman wrote: > Can we please get a filter for messages with the subject "Fw: new message" > ??? > > So far I've dealt with it via Gmail's 'mute conversation' setting somewhat effectively.
Re: Long-haul 100Mbps EPL circuit throughput issue
With default window size of 64KB, and a delay of 75 msec, you should only get around 7Mbps of throughput with TCP. You would need a window size of about 1MB in order to fill up the 100 Mbps link. 1/0.75 = 13.333 (how many RTTs in a second) 13.333 * 65535 * 8 = 6,990,225.24 (about 7Mbps) You would need to increase the window to 1,048,560 KB, in order to get around 100Mbps. 13.333 * 1,048,560 * 8 = 111,843,603.84 (about 100 Mbps) *Pablo Lucena* *Cooper General Global Services* *Network Administrator* *Office: 305-418-4440 ext. 130* *pluc...@coopergeneral.com * On Thu, Nov 5, 2015 at 6:31 PM, Bob Evans wrote: > Eric, > > I have seen that happen. > > 1st double check that the gear is truly full duplexseems like it may > claim it is and you just discovered it is not. That's always been an issue > with manufactures claiming they are full duplex and on short distances > it's not so noticeable. > > Try to perf in both directions at the same time and it become obvious. > > Thank You > Bob Evans > CTO > > > > > > Hello NANOG, > > > > We've been dealing with an interesting throughput issue with one of our > > carrier. Specs and topology: > > > > 100Mbps EPL, fiber from a national carrier. We do MPLS to the CPE > > providing > > a VRF circuit to our customer back to our data center through our MPLS > > network. Circuit has 75 ms of latency since it's around 5000km. > > > > Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco > > 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network <-> > > Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test > > machine in customer's VRF > > > > We can full the link in UDP traffic with iperf but with TCP, we can reach > > 80-90% and then the traffic drops to 50% and slowly increase up to 90%. > > > > Any one have dealt with this kind of problem in the past? We've tested by > > forcing ports to 100-FD at both ends, policing the circuit on our side, > > called the carrier and escalated to L2/L3 support. They tried to also > > police the circuit but as far as I know, they didn't modify anything > else. > > I've told our support to make them look for underrun errors on their > Cisco > > switch and they can see some. They're pretty much in the same boat as us > > and they're not sure where to look at. > > > > Thanks > > Eric > > > > >
Re: Long-haul 100Mbps EPL circuit throughput issue
> With default window size of 64KB, and a delay of 75 msec, you should only > get around 7Mbps of throughput with TCP. > > You would need a window size of about 1MB in order to fill up the 100 Mbps > link. > > 1/0.75 = 13.333 (how many RTTs in a second) > 13.333 * 65535 * 8 = 6,990,225.24 (about 7Mbps) > > You would need to increase the window to 1,048,560 KB, in order to get > around 100Mbps. > > 13.333 * 1,048,560 * 8 = 111,843,603.84 (about 100 Mbps) > >> >> >> > I realized I made a typo: 1/*0.075* = 13.333 not 1/0.75 = 13.333
Re: Long-haul 100Mbps EPL circuit throughput issue
> > > Modern TCPs support and typically use window scaling (RFC 1323). You > may not notice it in packet dumps because the window scaling option is > negotiated once for the connection, not repeated in every packet. > > Absolutely. Most host OS should support this by now. Some test utilities however, like iperf (at least the versions I've used) default to a 16 bit window size though. The goal of my response was to allude to the fact that TCP relies on windowing unlike UDP, thus explaining the discrepancies. This is a good article outlining these details: https://www.edge-cloud.net/2013/06/measuring-network-throughput/
Re: What happened to Schprokits?
I have great hopes for Schprokits. The idea behind it is outstanding - an Ansible for networking. It must be tough though, integrating all major vendor APIs seamlessly into a product. I have faith in Jeremy and his team...hopefully they are close to shipping code =) *Pablo Lucena* On Fri, Mar 13, 2015 at 2:36 PM, Steve Noble wrote: > There are other stealth companies the space. I still see activity on > Twitter (favorites, etc) so I he is still active. We will see good things > in the space. > On Mar 13, 2015 11:31 AM, "Adrian Beaudin" > wrote: > > > it looks like (according to linkedin) that Jeremy has moved to a stealth > > startup. > > > > -a > > > > > > Adrian Beaudin > > Principal Architect, Special Projects > > Nominum, Inc. > > o: +1.650.587.1513 > > adrian.beau...@nominum.com > > > > > > > > > > From: NANOG [nanog-boun...@nanog.org] on behalf of Scott Whyte [ > > swh...@gmail.com] > > Sent: Friday, March 13, 2015 11:09 AM > > To: nanog@nanog.org > > Subject: What happened to Schprokits? > > > > Schprokits was mentioned at NANOG63 but http://www.schprokits.com/ > > doesn't look too good. > > > > What happened? > > >
Re: What happened to Schprokits?
This is great, had not heard of Trigger. Finding that it has native support for asynchronous processing makes it even better =). Thanks for sharing Charles. Regards, On Sat, Mar 14, 2015 at 6:29 AM, Charles N Wyble wrote: > Checkout trigger for what seems to be the most viable system: > > https://trigger.readthedocs.org/en/latest/ > > > > On March 13, 2015 7:59:13 PM CDT, Pablo Lucena > wrote: >> >> I have great hopes for Schprokits. The idea behind it is outstanding - an >> Ansible for networking. It must be tough though, integrating all major >> vendor APIs seamlessly into a product. I have faith in Jeremy and his >> team...hopefully they are close to shipping code =) >> >> *Pablo Lucena* >> On Fri, Mar 13, 2015 at 2:36 PM, Steve Noble wrote: >> >> There are other stealth companies the space. I still see activity on >>> Twitter (favorites, etc) so I he is still active. We will see good things >>> in the space. >>> On Mar 13, 2015 11:31 AM, "Adrian Beaudin" >>> wrote: >>> >>> it looks like (according to linkedin) that Jeremy has moved >>>> to a stealth >>>> startup. >>>> >>>> -a >>>> >>>> >>>> Adrian Beaudin >>>> Principal Architect, Special Projects >>>> Nominum, Inc. >>>> o: +1.650.587.1513 >>>> adrian.beau...@nominum.com >>>> >>>> >>>> >>>> -- >>>> >>>> From: NANOG [nanog-boun...@nanog.org] on behalf of Scott Whyte [ >>>> swh...@gmail.com] >>>> Sent: Friday, March 13, 2015 11:09 AM >>>> To: nanog@nanog.org >>>> Subject: What happened to Schprokits? >>>> >>>> Schprokits was mentioned at NANOG63 but http://www.schprokits.com/ >>>> doesn't look too good. >>>> >>>> What happened? >>> >>> >>> >>> >> !DSPAM:55038897231179442818726! >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >
Re: FIB Sizing
> > > > When will router vendors learn to do even simple aggregation before > loading > > routes into FIB? It appears that most hardware will have plenty of FIB > > space if this was done. Also that aggregated routes are increasing at a > > slower pace. > > Howdy, > > You can get a good reduction with FIB aggregation, but only upwards of > 50% or so, and that only with the some pretty costly algorithms. Also, > you tend to get better gains at the cheaper edge nodes rather than the > more expensive core nodes. For now it's more cost effective to leave > the code alone and just double the size of the TCAM. > > Regards, > Bill Herrin > > There are also features such as Selective RIB Download (or its equivalent in other vendors) which help out in different portions of the network. Definitely not applicable to all router types though.
Re: free Tools to monitor website performance
I've also heard good things about ThousandEyes. On Wed, Aug 5, 2015 at 10:27 PM, Suresh Ramasubramanian wrote: > Nagios will do it at a pinch but only from one location. But if you want > professional URL monitoring from across multiple locations worldwide, you > need Gomez, Neustar Webmetrics etc. Not quite cheap. > > > On 05-Aug-2015, at 7:23 PM, sathish kumar Ippani < > sathish.kumar.ipp...@gmail.com> wrote: > > > > Hi All, > > > > Thanks to all for reviewing my topic, may it is slightly off topic. > > > > We have almost 300 URL's (local and web) and we want to monitor few of > them > > which are very critical URL's for web access and local access. > > > > I would like to know is there any free tool or software with I can use to > > monitor url performance in terms of response time. Which gives more > > information like how much time it taken to connect the server and time to > > load the page and total response time. > > > > Thanks in advance. > > > > > > > > -- > > With Regards, > > > > Sathish Ippani > >
Re: Yet Another BGP (Border Gateway Protocol) Python Implementation
This is a nice Python implementation. Thanks for open sourcing this! On Thu, Aug 6, 2015 at 6:40 PM, Randy Bush wrote: > perhaps dissing someone for their free code is even ruder than not doing > ipv6 in 2015? you don't have to use either. > > randy >
Re: Branch Location Over The Internet
DMVPN is very flexible, and is designed for this type of scenario. Cisco definitely supports it. Not sure about Juniper, but its essentially mGRE + NHRP. You can use IPSec to encrypt the tunnels, and if you require spoke-to-spoke connectivity, there are some optimizations in Phase-3 DMVPN that make it scalable. I would recommend using BGP as the routing protocol in this type of setup as well. Newer versions of Cisco code support "next-hop-self all", which will allow you to use iBGP between HQ and the branches without having to complicate the config too much. LISP is also a great solution. Its supported across the Cisco product line, and there are other open source implementations. This really simplifies your routing, as you can just rely on static default routes into the "internet" at each branch, and allow LISP to take care of the rest. You can also use encryption ontop of it. Not sure why you think it would be ideal to have a Layer-2 solution...I would personally stay away from it for this type of setup. Regards, Pablo On Tue, Aug 11, 2015 at 2:21 PM, Colton Conor wrote: > We have an enterprise that has a headquarter office with redundant fiber > connections, its own ASN, its own /22 IP block from ARIN, and a couple of > gigabit internet connections from multiple providers. The office is taking > full BGP routes from tier 1 providers using a Juniper MX80. > > They are establishing their first branch location, and need the branch > location to be able to securely communicate back to headquarters, AND be > able to use a /24 of headquarters public IP addresses. Ideally the device > at the HQ location would hand out public IP address using DHCP to the other > side of the tunnel at the branch location. > > We know that in an ideal world it would be wise to get layer 2 transport > connections from HQ to the branch location, but lets assume that is not an > option. Please don't flood this thread about how it could be an option > because it's not at this time. This setup will be temporary and in service > for the next year until we get fiber to the branch site. > > Let's assume at the branch location we can get a DOCSIS cable internet > connection from a incumbent cable provider such as Comcast, and that > provider will give us a couple static IP address. Assume as a backup, we > have a PPPoE DSL connection from the ILEC such as Verizon who gives us a > dynamic IP address. > > What solution could we put at the HQ site and the branch site to achieve > this? Ideally we would want the solution to load balance between the > connections based on the connections speeds, and failover if one is down. > The cable connection will be much faster speed (probably 150Mbps down and > 10 Upload) compared to the DSL connection (10 download and 1 upload). If we > need more speed we can upgrade the cable modem to a higher package, but for > DSL that is the max speed so we might have to get multiple DSL lines. The > cable solution could always be used as the primary, and the DSL connection > could only be used as backup if that makes things easier. > > If you were to do this with Juniper or Cisco gear what would you have at > each location? What technology would you use? > > I know there is Pepewave and a couple of other software solutions that seem > to have a proprietary load balancing solutions developed, but I would > prefer to use a common Cisco or Juniper solution if one exists. > > There will be 50 users at the branch office. There is only one branch > location at this time, but they might expand to a couple more but under 10. >
Re: Best band for your buck router and switch (gigabit)
What about a Cisco cloud services router? These devices scale quite nicely. You can even use them for 60 days on a trial license. On Sat, Nov 16, 2013 at 6:50 PM, Mike Hale wrote: > We get ours from Network Hardware Resellers. It's > Smartnet-contractable, which is important for us, and was pretty > cheap. > > Shoot me a message offlist if you want our sales rep's info. He might > be able to help you out. > > On Sat, Nov 16, 2013 at 3:35 PM, Nick Cameo wrote: > > If anyone has one for sale that has not had it's ports beat to hell > > please let us know. > > We would be interested. > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > -- *Pablo Lucena* *Cooper General Global Services* *Network Administrator* *Office: 305-418-4440 ext. 130* *pluc...@coopergeneral.com *
