RE: OT: VPS with Routed IP space
ARP Networks: https://www.arpnetworks.com/vps Routed IP space (v4 and v6) as well as BGP peering. > -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Zachary > Giles > Sent: Tuesday, February 24, 2015 12:29 PM > To: Owen DeLong > Cc: NANOG > Subject: Re: OT: VPS with Routed IP space > > > How about VPS providers who will do BGP... Do they exist? > > [...] > > > Den 24/02/2015 19.25 skrev "Alex Buie" : > > > > > >> Anybody know of or have recommendations for providers of small > > >> VPS-line boxen (or alternative solutions) to serve as GRE endpoints? > > [...]
RE: AWS Elastic IP architecture
> -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Christopher > Morrow > Subject: Re: AWS Elastic IP architecture > [...] > i sort of doesn't matter right? it is PROBABLY some form of encapsulation > (like gre, ip-in-ip, lisp, mpls, vpls, etc) ... > [...] I don't know how the public blocks get to the datacenter (e.g. whether they are using MPLS) but after that I think it is pretty straightforward. All of the VMs have only one IPv4 address assigned out of 10/8. This doesn't change when you attach an Elastic IP to them. All that is happening is that they have some NAT device somewhere (maybe even just a redundant pair of VMs?) that has a block of public IPs assigned to it and they are static NAT'ing the Elastic IP to the VM. They control the allocation of the Elastic IPs, so they just pick one that is routed out of that datacenter already. They probably don't need to do anything out of the ordinary to get it there. (See: http://aws.amazon.com/articles/1346 )
RE: AWS Elastic IP architecture
> -Original Message- > From: christopher.mor...@gmail.com > Subject: Re: AWS Elastic IP architecture > > [...] > > All that is happening is that they have some NAT device somewhere > > (maybe even just a redundant pair of VMs?) that has a block of public > > IPs assigned to it and they > > i'd question scalability of that sort of thing... but sure, sounds like a > reasonable model to think about. I agree it appears ugly from a traditional network service provider perspective, but to my understanding much of the large scale cloud stuff is built using the cheapest, dumbest switching you can find and as little rich L3 routing gear (e.g. ASR/MX) as you can get away with. The more functionality you can pack into software (with the universal building block being a VM), the less you have to worry about buying network hardware to any particular requirement other than "forwards Ethernet most of the time." It gives more control and agility to the developers of the platform, and spending a few gigabytes of RAM for every /23 and adding a little more latency and jitter ultimately becomes an economical trade off. You can also move the network stuff up to the hypervisor layer (which I am sure they have done for things like Security Groups), but it makes rolling out updates harder and increases the general hack-level.
Good MPLS/VPLS book?
Does anyone have a favorite book or resource discussing MPLS and all associated Lego blocks (e.g. LDP, TE, VPLS, martini, mBGP et. al.)? I understand the basics of what MPLS is and how you create a circuit from A to B but I'm afraid it still escapes me when trying to figure out how someone would, say, create a multicast capable VPN with 5 edge points. Any pointers to a good way to reduce my level of ignorance on this subject would be appreciated. Vendor literature doesn't bother me as long as the concepts are there. Regards, Michael H.
Re: Good MPLS/VPLS book?
Thanks for the suggestions, all! Looks like I have some reading to do. On Thu, 23 Dec 2010 18:49:46 -0500 Dan Snyder wrote: > > > On Dec 23, 2010, at 5:49 PM, Michael Helmeste wrote: > > > Does anyone have a favorite book or resource discussing MPLS and all > > associated Lego blocks (e.g. LDP, TE, VPLS, martini, mBGP et. al.)? > > > > I understand the basics of what MPLS is and how you create a circuit from > > A to B but I'm afraid it still escapes me when trying to figure out how > > someone would, say, create a multicast capable VPN with 5 edge points. > > > > Any pointers to a good way to reduce my level of ignorance on this subject > > would be appreciated. Vendor literature doesn't bother me as long as the > > concepts are there. > > > > Regards, > >Michael H. > > > > > > Designing and Implementing IP/MPLS-Based Ethernet Layer 2 VPN Services: An > Advanced Guide for VPLS and VLL (Paperback) > Zhuo Xu > > I thought was pretty good.
Re: Speed Testing and Throughput testing
We had a problem where our (mostly research network connected, international) users were getting generally low HTTP transfer speeds, even though the path was often gigabit. The classic high bandwidth/high latency problem. Initially I tried using iperf/ndt and friends but found that iperf required too much user knowledge and interaction, and NDT was sometimes inaccurate at diagnosing problems -- it seemed to be overly fond of saying there was a duplex mismatch or congestion. Iperf in TCP mode either requires manually seeking the number of streams to try and find optimum throughput, or doing window size tweaks. I also found that packet captures were useful for discovering problems in the path; you can load it up in wireshark or tcptrace and get a sequence no. vs time graph, look for packetloss, or other good things like that. Anyways I didn't find much out there in terms of automating this type of thing (simple throughput tests with packet capture) so I just ended up making my own. It does a dump of 10 sec. of test traffic, uses a somewhat dumb algorithm to seek up the number of TCP streams, and gets an AS path from a BGP route server and displays it to the user. The caveat is that it only tests your download speed, not upload, since that was primarily what I was interested in. You can give it a try at: http://caranthir.dao.nrc.ca/netperf-www/ (login nanog/nanog). User guide here: http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/netperf/testdetail.shtml I might end up packaging and releasing the code if there is interest. On Mon, 2 Nov 2009 15:56:56 -0600 Mark Urbach wrote: > Anyone have a good solution to get "accurate" speed results when testing at > 10/100/1000 Ethernet speeds? > > Do you have a server/software that customer can test too? > > > > Thanks, > Mark Urbach > PinPoint Communications, Inc. > 100 N. 12th St Suite 500 > Lincoln, NE 68508 > 402-438-6211 ext 1923 Office > 402-660-7982 Cell > mark.urb...@pnpt.com > [cid:image003.jpg@01CA5BD5.1A5CEE20] > >
ACLs vs. full firewalls
Hi all, One of the duties of my current place of employ is reorganizing the network. We have a few Catalyst 6500 series L3 switches, but currently do all packet filtering (and some routing) using a software based firewall. Don't ask me, I didn't design it :) Current security requirements are only based on TCP and non-stateful UDP src/dst net/port filtering, and so my suggestion was to use ACLs applied on the routed interface of each VLAN. There was some talk of using another software based firewall or a Cisco FWSM card to filter traffic at the border, mostly for management concerns. We expect full 1 gig traffic levels today, and 10 gig traffic levels in the future. I view ACLs as being a cheap, easy to administrate solution that scales with upgrades to new interface line speeds, where a full stateful firewall isn't necessary. However, I wanted to get other opinions of what packet filtering solutions people use in the border and in the core, and why. What's out there, and why do you guys use it? How do you feel about the scalability, performance, security, and manageability of your solution? What kind of traffic levels do you put through it?
Re: ACLs vs. full firewalls
While there are no specific audit requirements, overall traffic auditing (not just for dropped packets) is definitely something I'm considering. One way of gathering this data without using a firewall would seem to be netflow; I don't think netflow specifically calls out (or even shows?) traffic blocked by ACLs though, which could be a point for consideration. Eric Gauthier wrote: > Michael, > > Do you have logging or audit requirements to your filters? > We use ACLs almost everywhere for non-stateful filtering, but > there are a few locations (e.g. HIPPA) that require an > audit trail which is perhaps better accomplished by a firewall. > > Eric :) > [...]
