Re: NANOG Digest, Vol 41, Issue 165

29 Jun 2011

      Hi,
There is a command to limit the number of redistributed route.

redistribute maximum-prefix

Say, if ISIS imports routes, it will redistribute only the number of
configured routes in 'redistribute maximum-prefix .

My question is: say I make the number as 10. So initially ISIS will
redistribute inly 10 routes recvd from say BGP, and drop other packets. But
later, if I change the number to 20, how should it work? How will BGP send
other routes?
'

I think Huawei doed not have this command, but Cisco has

Regards,
Savyasachi
7676077879

On Wed, Jun 29, 2011 at 3:00 AM, <nanog-request@nanog.org> wrote:
...
Send NANOG mailing list submissions to
       nanog@nanog.org
To subscribe or unsubscribe via the World Wide Web, visit
       https://mailman.nanog.org/mailman/listinfo/nanog
or, via email, send a message with subject or body 'help' to
       nanog-request@nanog.org
You can reach the person managing the list at
       nanog-owner@nanog.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of NANOG digest..."
Today's Topics:
1. RE: [pfSense Support] Strange TCP connection behavior 2.0 RC2
     (+3) (Leigh Porter)
  2. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
     (+3) (Cameron Byrne)
  3. Re: Announcing Project BISMark: ISP Performance Measurements
     from      Home Routers (Daniel Espejel)
  4. Re: website in ipv6 (Kenny Sallee)
  5. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
     (+3) (PC)
  6. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
     (+3) (Cameron Byrne)
  7. DENOG 3 - Call for Participation and Papers (Marcus Stoegbauer)
----------------------------------------------------------------------
Message: 1
Date: Tue, 28 Jun 2011 16:11:23 +0000
From: Leigh Porter <leigh.porter@ukbroadband.com>
Subject: RE: [pfSense Support] Strange TCP connection behavior 2.0 RC2
       (+3)
To: Cameron Byrne <cb.list6@gmail.com>
Cc: "williamejsalt@googlemail.com" <williamejsalt@googlemail.com>,
       NANOG list <nanog@nanog.org>
Message-ID:
       <D181DDABABE57E4DB72FEE0033147864075D66@EALPO1.ukbroadband.com>
Content-Type: text/plain; charset="us-ascii"
...
-----Original Message-----
From: Cameron Byrne [mailto:cb.list6@gmail.com]
Sent: 28 June 2011 16:53
To: Leigh Porter
Cc: Andreas Ott; Eugen Leitl; williamejsalt@googlemail.com; NANOG list
Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
(+3)
In the 3G world, i have had good results overcoming longish RTT by
using the Hybla TCP algorithm  http://hybla.deis.unibo.it/
I am hoping it gets more default traction, especially in wireless
where the radio link is a pretty big latency source
Cameron
How do you implement this for lots of clients and servers that have out of
the box implementations? The FastSoft box is a TCP man-in-the-middle box
that essentially implements the FAST TCP algorithm without either end having
to worry about it.
I have also used home-fudged TCP proxies with some success.
Some 3G/wireless/VSAT vendors implement their own TCP modification stacks
but they usually only fiddle with window sizes and such.
--
Leigh
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
------------------------------
Message: 2
Date: Tue, 28 Jun 2011 09:16:13 -0700
From: Cameron Byrne <cb.list6@gmail.com>
Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
       (+3)
To: Leigh Porter <leigh.porter@ukbroadband.com>
Cc: "williamejsalt@googlemail.com" <williamejsalt@googlemail.com>,
       NANOG list <nanog@nanog.org>
Message-ID:
       <BANLkTi=nbqdV+=ZUvLaiwy_ZHwS_fk79amzFXxYB-ca_MSt7ZA@mail.gmail.com
...
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter
<leigh.porter@ukbroadband.com> wrote:
...
...
-----Original Message-----
From: Cameron Byrne [mailto:cb.list6@gmail.com]
Sent: 28 June 2011 16:53
To: Leigh Porter
Cc: Andreas Ott; Eugen Leitl; williamejsalt@googlemail.com; NANOG list
Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
(+3)
In the 3G world, i have had good results overcoming longish RTT by
using the Hybla TCP algorithm ?http://hybla.deis.unibo.it/
I am hoping it gets more default traction, especially in wireless
where the radio link is a pretty big latency source
Cameron
How do you implement this for lots of clients and servers that have out
of the box implementations? The FastSoft box is a TCP man-in-the-middle box
that essentially implements the FAST TCP algorithm without either end having
to worry about it.
...
You don't, the full benefits only come with a Linux kernel patch.  The
good news is that it only has to be implemented on the client end.
...
I have also used home-fudged TCP proxies with some success.
Some 3G/wireless/VSAT vendors implement their own TCP modification stacks
but they usually only fiddle with window sizes and such.
That's why i said i hope it catches on as default :)  If Android
implemented Hybla, i think it would be a great improvement for user
experience.  Nobody likes the middleboxes that proxy TCP.... they cost
money, don't scale well, and are generally fragile.  Hybla is not a
solution for the OPs issue, just a solution for high RTT links where
the client can do Hybla.  It an evolutionary step that i think would
make a great fit in smartphones like Android.
Cameron
...
--
Leigh
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
------------------------------
Message: 3
Date: Tue, 28 Jun 2011 12:50:29 -0500
From: Daniel Espejel <daniel.unam.ipv6@gmail.com>
Subject: Re: Announcing Project BISMark: ISP Performance Measurements
       from    Home Routers
To: nanog@nanog.org
Message-ID: <BANLkTimbkG9CyN2PjiA7AECbok-V5Fenkw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi.
I would like to participate in the Bismark project, for now only as a
poller-kind user.
While checking the router n600 specifications datasheet it seems that this
device is IPv6 compliant in some degree (because of the IPv6 Ready Logo
included at the bottom of the sheet).
I'm really interested in performing some test about that issue; but I'm
also
worried about privacy/confidentiality and navigation speed features.
It's likely all those whom participate may find related information about
this topics in the project website and related mailing list.
Well, I'm waiting to get my hands dirty on N600 and this way trying to
solve
some of my doubts (or catch a lot more).
...
----------------------------------------------------------------------
Message: 1
Date: Tue, 28 Jun 2011 11:30:07 +0100
From: Alex Brooks <askoorb+nanog@gmail.com>
Subject: Re: Announcing Project BISMark: ISP Performance Measurements
       from    Home Routers
To: nanog <nanog@nanog.org>
Message-ID: <BANLkTikuyoBbOJotA3qrJQRDWjvd-cWWOA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
On Mon, Jun 27, 2011 at 9:48 PM, Nick Feamster <feamster@cc.gatech.edu>
wrote:
...
Hello NANOG,
We've launched Project BISMark, a project that performs active
performance measurements of upload and download throughput, latency, etc.
from OpenWRT-based routers running inside of homes. ? We have tested our
OpenWRT image on the NetGear WNDR 3700v2 and are currently shipping out
NetGear routers with the BISMark firmware to anyone who is interested.
...
--
*Daniel Espejel Perez
*
------------------------------
Message: 4
Date: Tue, 28 Jun 2011 11:09:04 -0700
From: Kenny Sallee <kenny.sallee@gmail.com>
Subject: Re: website in ipv6
To: Mark Andrews <marka@isc.org>
Cc: nanog list <nanog@nanog.org>
Message-ID: <BANLkTikt-7aRAXBYzUk0ao9V5DBeKz-0eg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
...
...
...
I did this by creating a 6to4 tunnel to a relay provided by
6in4, not 6to4.  While HE do operate 6to4 relays, the brokered tunnel
service is 6in4.
A very important distinction I didn't have clear in my head.  To
regurgitate
some reading I just completed: both methods use v6 in v4 tunneling using ip
proto 41 in the IPv4 protocol field.  However, 6to4 derives the IPv4 tunnel
destination of an IPv6 packet based on bits 17-48 of the IPv6 packet -
which
when converted, equals the 32 bit IPv4 destination.  While 6in4 is
statically configured IPv4 source and destination IP addresses on the
Tunnel
(gre) interface.  In Cisco world the config comes down to 'tunnel mode
ipv6ip' vs 'tunnel mode ipv6ip 6to4' and a few other lines of config.
Of course there are a lot more details then that searchable via google.
 Thanks for pointing out my mistake - it helped me learn some more!  Later,
Kenny
------------------------------
Message: 5
Date: Tue, 28 Jun 2011 14:24:59 -0600
From: PC <paul4004@gmail.com>
Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
       (+3)
To: Cameron Byrne <cb.list6@gmail.com>
Cc: "williamejsalt@googlemail.com" <williamejsalt@googlemail.com>,
       NANOG list <nanog@nanog.org>
Message-ID: <BANLkTi=xzzwc_vj=cA+aZLpZ5=M_tgFaUA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I have found most/all modern 3g networks can achieve optimal download speed
within their latency limitations (<200ms domestic end-to-end is normal for
most today) when combined with a modern operating system that does
automatic
TCP receive window adjustments based on per-flow characteristics.  I never
had a problem getting ~2 megabit from EVDO-revA, and can get ~20 megabit
without issue from the new Verizon LTE network.  (Windows XP is not
modern).
As for VSAT, most every vsat equipment manufacturer has TCP
acceleration/proxy support built into the satellite modem.  They basically
forge acks at the hub site to buffer data from the server, then deliver it
it to the remote end in a continuous flow.  Many also have protocol
optimizations for some of the more "chatty" protocols.  If you use it, your
10 megabit should be achievable for typical HTTP/FTP consumer internet
activities, and it's surprisingly fast.  I've sustained 6 without issue on
VSAT, only limited by bandwidth available, doing a simple SCP file
transfer.
Of course, none of this is to the scale of transatlantic gigabit transfers
with a single flow...
On Tue, Jun 28, 2011 at 10:16 AM, Cameron Byrne <cb.list6@gmail.com>
wrote:
...
On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter
<leigh.porter@ukbroadband.com> wrote:
...
...
-----Original Message-----
From: Cameron Byrne [mailto:cb.list6@gmail.com]
Sent: 28 June 2011 16:53
To: Leigh Porter
Cc: Andreas Ott; Eugen Leitl; williamejsalt@googlemail.com; NANOG
...
...
Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
(+3)
In the 3G world, i have had good results overcoming longish RTT by
using the Hybla TCP algorithm  http://hybla.deis.unibo.it/
I am hoping it gets more default traction, especially in wireless
where the radio link is a pretty big latency source
Cameron
How do you implement this for lots of clients and servers that have out
of the box implementations? The FastSoft box is a TCP man-in-the-middle
box
list
that essentially implements the FAST TCP algorithm without either end
having
to worry about it.
...
You don't, the full benefits only come with a Linux kernel patch.  The
good news is that it only has to be implemented on the client end.
...
I have also used home-fudged TCP proxies with some success.
Some 3G/wireless/VSAT vendors implement their own TCP modification
stacks
but they usually only fiddle with window sizes and such.
That's why i said i hope it catches on as default :)  If Android
implemented Hybla, i think it would be a great improvement for user
experience.  Nobody likes the middleboxes that proxy TCP.... they cost
money, don't scale well, and are generally fragile.  Hybla is not a
solution for the OPs issue, just a solution for high RTT links where
the client can do Hybla.  It an evolutionary step that i think would
make a great fit in smartphones like Android.
Cameron
...
--
Leigh
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
------------------------------
Message: 6
Date: Tue, 28 Jun 2011 13:35:16 -0700
From: Cameron Byrne <cb.list6@gmail.com>
Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
       (+3)
To: PC <paul4004@gmail.com>
Cc: "williamejsalt@googlemail.com" <williamejsalt@googlemail.com>,
       NANOG list <nanog@nanog.org>
Message-ID:
       <BANLkTin4RBcVAZaz9kwoBouHmT1TBndkbQ_xc9E=OFFx4GEr5w@mail.gmail.com
...
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Jun 28, 2011 at 1:24 PM, PC <paul4004@gmail.com> wrote:
...
I have found most/all modern 3g networks can achieve optimal download
speed
within their latency limitations (<200ms domestic end-to-end is normal
for
most today) when combined with a modern operating system that does
automatic
TCP receive window adjustments based on per-flow characteristics.? I
never
had a problem getting ~2 megabit from EVDO-revA, and can get ~20 megabit
without issue from the new Verizon LTE network.? (Windows XP is not
modern).
AFAIK, Verizon and all the other 4 largest mobile networks in the USA
have transparent TCP proxies in place.
My point was that if end-hosts had Hybla or something similar, these
proxies can be removed providing a better end-to-end solution.
Cameron
...
As for VSAT, most every vsat equipment manufacturer has TCP
acceleration/proxy support built into the satellite modem.? They
basically
forge acks at the hub site to buffer data from the server, then deliver
it
it to the remote end in a continuous flow.? Many also have protocol
optimizations for some of the more "chatty" protocols.? If you use it,
your
10 megabit should be achievable for typical HTTP/FTP consumer internet
activities, and it's surprisingly fast.? I've sustained 6 without issue
on
VSAT, only limited by bandwidth available, doing a simple SCP file
transfer.
Of course, none of this is to the scale of transatlantic gigabit
transfers
with a single flow...
On Tue, Jun 28, 2011 at 10:16 AM, Cameron Byrne <cb.list6@gmail.com>
wrote:
...
On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter
<leigh.porter@ukbroadband.com> wrote:
...
...
-----Original Message-----
From: Cameron Byrne [mailto:cb.list6@gmail.com]
Sent: 28 June 2011 16:53
To: Leigh Porter
Cc: Andreas Ott; Eugen Leitl; williamejsalt@googlemail.com; NANOG
list
...
...
...
Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0
RC2
(+3)
In the 3G world, i have had good results overcoming longish RTT by
using the Hybla TCP algorithm ?http://hybla.deis.unibo.it/
I am hoping it gets more default traction, especially in wireless
where the radio link is a pretty big latency source
Cameron
How do you implement this for lots of clients and servers that have
out
of the box implementations? The FastSoft box is a TCP
man-in-the-middle box
that essentially implements the FAST TCP algorithm without either end
having
to worry about it.
You don't, the full benefits only come with a Linux kernel patch. ?The
good news is that it only has to be implemented on the client end.
...
I have also used home-fudged TCP proxies with some success.
Some 3G/wireless/VSAT vendors implement their own TCP modification
stacks but they usually only fiddle with window sizes and such.
That's why i said i hope it catches on as default :) ?If Android
implemented Hybla, i think it would be a great improvement for user
experience. ?Nobody likes the middleboxes that proxy TCP.... they cost
money, don't scale well, and are generally fragile. ?Hybla is not a
solution for the OPs issue, just a solution for high RTT links where
the client can do Hybla. ?It an evolutionary step that i think would
make a great fit in smartphones like Android.
Cameron
...
--
Leigh
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
------------------------------
Message: 7
Date: Tue, 28 Jun 2011 23:30:19 +0200
From: Marcus Stoegbauer <marcus@grmpf.org>
Subject: DENOG 3 - Call for Participation and Papers
To: nanog@nanog.org
Message-ID: <4E0A47EB.5060808@grmpf.org>
Content-Type: text/plain; charset=UTF-8
DENOG 3 - Call for Participation and Papers
The third meeting of the German Network Operators Group (DENOG) will be
held in Frankfurt, Germany on the 20th of October 2011. We are pleased
to hereby invite applications for presentations or lightning talks to be
held at this event.
General Information
===================
DENOG is a community for professionals within Germany who are operating,
designing or researching the Internet. It provides a technical forum
where those working on, with and for the Internet can come together to
solve problems with every aspect of their (net)work.
The meeting is designed to provide an opportunity for the exchange of
information among network operators, engineers, researchers and other
professionals close to the network community.
More information about DENOG (in German) can be found at
 http://www.denog.de/
Information about the meeting will be published at
 http://www.denog.de/meetings/
Meeting Countdown
=================
What                                   When
------------------------------------------------------
Publication of Call for Papers         June 28th, 2011
Deadline for all submissions           August 22th, 2011
Publication of final programme         September 3rd, 2011
Deadline for receipt of final slides   October 13th, 2011
Meeting Day                            October 20th, 2011
Topics for Presentations/Talks
==============================
The day will be divided into several sessions. The number and length of
presentations per session is not fixed, although due to time constraints
we would prefer the length of the presentations to be between 10 to 30
minutes.
However proposals whose subject fall outside of the topics below are
also welcome; please do not hesitate to submit them.
Lightning Talks
---------------
In addition to the topics mentioned below we will reserve slots for
lightning talks, which consist of a few slides and will not last longer
than 5 minutes. Lightning talks can be submitted until October 13th,
with the deadline for submission of the corresponding slides being
October 19th.
Topic #1: Power Efficiency in Networks
---------------------------------------
For operators of networks and data centres of any size power efficiency
has become more important. Servers and network gear with high power
consumption are expensive because of high operating and cooling power
costs; also in many places supplying more power into the location is no
longer possible. How are you dealing with power problems in your
environment? How do you efficiently cool a rack/a room/a datacenter? Can
a migration to VoIP help you save power?
Topic #2: Social Networks, Cloud Services and Information Security
------------------------------------------------------------------
Social Networks are an essential working tool for networkers and cloud
services are also becoming increasingly popular. The security of your
information and data in these networks is a crucial aspect which we want
to discuss in this session.
Topic #3: Peering
------------------
Everything about your peering experience. Why are you doing it? How are
you doing it? Have you written any useful tools which others might find
interesting?
Topic #4: ISP BOF
-----------------
"All things ISP". From Network/SLA Management (for or against it), abuse
handling and log systems to data centre layout and planning (including
power and cooling), everything that is interesting to you as an ISP can
be presented or discussed within this topic.
Language of Slides and Talks
============================
To appeal to an international audience we ask you to produce your slides
in English, but the spoken language of the presentation itself can be
either German or English.
Submission Guidelines
=====================
All submissions must have a strong technical bias and must not be solely
promotional for your employer.
Please remember that your presentations should be suitable for a target
audience of technicians from varied backgrounds, working for companies
whose sizes may vary considerably.
To submit a proposal for a presentation, we request that you provide the
following information as plain text or PDF format to <denog-pc@denog.de>:
* the name of the presenter (and if applicable your affiliation)
* a working email address
* the name and number of the topic which will contain the presentation
* the title of the presentation
* its expected length (in minutes)
* the preferred spoken language for the presentation
* a short abstract of the presentation (not more than 200 words)
We also welcome suggestions for specific presentations which you feel
would be valuable to the DENOG community.
Please be aware that your presentation will be published on the DENOG
website after the event.
------------------------------
_______________________________________________
NANOG mailing list
NANOG@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog
End of NANOG Digest, Vol 41, Issue 165
**************************************

Savyasachi Choudhary

tags

participants (1)