- Test - lists.nanog.org

Coded TCP
by Rodrick Brown 24 Oct '12

24 Oct '12

"With coded TCP, blocks of packets are clumped together and then transformed into algebraic equations that describe the packets. If part of the message is lost, the receiver can solve the equation to derive the missing data. The process of solving the equations is simple and linear, meaning it doesn't require much processing on behalf of the router/smartphone/laptop. In testing, the coded TCP resulted in some dramatic improvements. MIT found that campus WiFi (2% packet loss) jumped from 1Mbps to 16Mbps. On a fast-moving train (5% packet loss), the connection speed jumped from 0.5Mbps to 13.5Mbps." http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf --RB

6 6

Issues encountered with assigning .0 and .255 as usable addresses?
by Paul Zugnoni 24 Oct '12

24 Oct '12

Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255. Any experience or recommendations? Besides replace the ISA proxy…. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason.

18 20

Tech for blocking particular YouTube video - Wired.com question
by Ryan Singel 24 Oct '12

24 Oct '12

A colleague is working on a story that a particular country not to be named implemented technology to block a particular infamous riot-inducing video for a certain section of its populace. The questions are: 1) how hard is this to do at scale, 2) does it require DPI equipment and 3) is there a way to prove, from an end node, that it's happening? Off-list replies are fine, even better are folks willing to talk on record. I appreciate any help you can give. Ryan Singel Editor Wired Threat Level

4 3

BGPttH. Neustar can do it, why can't we?
by jamie rishaw 23 Oct '12

23 Oct '12

discuss.

16 31

MP-BGP next hop tracking delay 0
by Adam Vitkovsky 23 Oct '12

23 Oct '12

I was wondering whether you have some experience with setting of the next hop tracking delay value for BGP to 0 for critical changes please There's gonna be only a few prefixes registered with BGP so far, around 150+ adam

2 1

Re: Issues encountered with assigning .0 and .255 as usable addresses?
by james machado 23 Oct '12

23 Oct '12

On Mon, Oct 22, 2012 at 6:49 PM, Justin Krejci <jkrejci(a)usinternet.com> wrote: > And since owen has not yet mentioned it, consider something that supports having : in its address as well. > > Sort of tangentially related, I had a support rep for a vendor once tell me that a 255 in the second or third octet was not valid for an ipv4 address. Hard to troubleshoot a problem when I had to first explain how ip addressing worked because the rep was so fixated on the 255 we were using on the network. If any product really doesn't like 255 in any position then you should consider yourself lucky to still be in business at all. Jimmy Hess <mysidia(a)gmail.com> wrote:On 10/22/12, Paul Zugnoni <paul.zugnoni(a)jivesoftware.com> wrote: > [snip] >> Any experience or recommendations? Besides replace the ISA proxy…. Since >> it's not mine to replace. Also curious whether there's an RFC recommending >> against the use of .0 or .255 addresses for this reason. > > ISA is old, and might not be supported anymore, unless you have an > extended support contract. If it's not supported anymore, then don't > be surprised if it has breakage you will not be able to repair. I > don't recommend upgrading to TMG, either: although still supported, > that was just discontinued. > > If ISA is refusing traffic to/from IPs ending in .0, then ISA is > either broken, or misconfigured. > Get a support case with the vendor, raise it as a critical issue -- > unable to pass traffic to critical infrastructure that ends with a > .255 or .0 IP address, demand that the vendor provide a resolution, > And explain that changing the IP address of the remote server is not an option. > > > If the vendor can't or won't provide a resolution, then not only is > the proxy server broken, > but malfunctioning in a way that has an impact on network connectivity. > > I would consider its removal compulsory, as you never know, when a > network resource, web site, e-mail server, etc. your org has a > business critical need to access, or be accessed from; may be > placed on .255 or .0 > > -- > -JH > this was also discussed back in August in this thread http://mailman.nanog.org/pipermail/nanog/2012-August/051290.html james

1 0

[NANOG-announce] vote.nanog.org
by Betty Burke <betty＠nanog.org> 23 Oct '12

23 Oct '12

NANOGers: If you have not yet joined NANOG as a member, become a member by visiting https://www.nanog.org/signup/ .. Members do play an important role in helping to sustain and direct NANOG. Note, voting for the 2011/2013 Board and Bylaw amendments will close at 5:00 PM CST on October 23, 2012. Should you have any questions or problems with joining or voting, send email to nanog-support(a)nanog.org or stop by the NANOG 56 Registration Desk... Sincerely, Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 _______________________________________________ NANOG-announce mailing list NANOG-announce(a)mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Semi-automated L3 interface DNS records
by Pedersen, Sean 23 Oct '12

23 Oct '12

Does anyone out there have any experience with a script, tool or appliance that would help manage the creation and maintenance of DNS records for Layer 3 interfaces on routers and switches? We'd like to move toward this practice to help with troubleshooting and IPAM, but it's not feasible to do it manually. At a minimum, I was mulling over the idea of writing a script that would poll a device via SNMP to obtain interface information, parse it, compare the results to DNS, then generate a report if it found a miss. It wouldn't be fully-automated, but it would be better than doing that portion of the work manually. Cleaning up dead entries would be another issue.

5 5

Re: Issues encountered with assigning .0 and .255 as usable addresses?
by Justin Krejci 23 Oct '12

23 Oct '12

And since owen has not yet mentioned it, consider something that supports having : in its address as well. Sort of tangentially related, I had a support rep for a vendor once tell me that a 255 in the second or third octet was not valid for an ipv4 address. Hard to troubleshoot a problem when I had to first explain how ip addressing worked because the rep was so fixated on the 255 we were using on the network. If any product really doesn't like 255 in any position then you should consider yourself lucky to still be in business at all. Jimmy Hess <mysidia(a)gmail.com> wrote:On 10/22/12, Paul Zugnoni <paul.zugnoni(a)jivesoftware.com> wrote: [snip] > Any experience or recommendations? Besides replace the ISA proxy…. Since > it's not mine to replace. Also curious whether there's an RFC recommending > against the use of .0 or .255 addresses for this reason. ISA is old, and might not be supported anymore, unless you have an extended support contract. If it's not supported anymore, then don't be surprised if it has breakage you will not be able to repair. I don't recommend upgrading to TMG, either: although still supported, that was just discontinued. If ISA is refusing traffic to/from IPs ending in .0, then ISA is either broken, or misconfigured. Get a support case with the vendor, raise it as a critical issue -- unable to pass traffic to critical infrastructure that ends with a .255 or .0 IP address, demand that the vendor provide a resolution, And explain that changing the IP address of the remote server is not an option. If the vendor can't or won't provide a resolution, then not only is the proxy server broken, but malfunctioning in a way that has an impact on network connectivity. I would consider its removal compulsory, as you never know, when a network resource, web site, e-mail server, etc. your org has a business critical need to access, or be accessed from; may be placed on .255 or .0 -- -JH

1 0

Re: Issues encountered with assigning .0 and .255 as usable addresses?
by Scott Weeks 22 Oct '12

22 Oct '12

--- job(a)instituut.net wrote: From: Job Snijders <job(a)instituut.net> > Curious whether it's commonplace to find systems that automatically regard > .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should > be considered invalid. When you have a pool of assignable addresses, you > should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT > pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product > and getting reports of M$ ISA proxy that is specifically blocking traffic for an > IP ending in .0 or .255. I used about a /15s worth of /23s for DHCP at a previous employer for 5 years (2005 - 2010) and they're still using them today years later. Never got one complaint AFAIK. I even got one of the .0 or .255 addresses for a while and never had trouble. This was discussed in detail a while back. Look in the archives. scott

1 0