Re: NANOG Digest, Vol 41, Issue 165

[Savyasachi Choudhary <savyasachi.choudhary () gmail com>]

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
> 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: 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
> **************************************