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, <[email protected]> wrote: > Send NANOG mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > Subject: RE: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Cameron Byrne <[email protected]> > Cc: "[email protected]" <[email protected]>, > NANOG list <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > > > > -----Original Message----- > > From: Cameron Byrne [mailto:[email protected]] > > Sent: 28 June 2011 16:53 > > To: Leigh Porter > > Cc: Andreas Ott; Eugen Leitl; [email protected]; 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 <[email protected]> > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Leigh Porter <[email protected]> > Cc: "[email protected]" <[email protected]>, > NANOG list <[email protected]> > Message-ID: > <BANLkTi=nbqdV+=zuvlaiwy_zhws_fk79amzfxxyb-ca_mst...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > <[email protected]> wrote: > > > > > >> -----Original Message----- > >> From: Cameron Byrne [mailto:[email protected]] > >> Sent: 28 June 2011 16:53 > >> To: Leigh Porter > >> Cc: Andreas Ott; Eugen Leitl; [email protected]; 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 <[email protected]> > Subject: Re: Announcing Project BISMark: ISP Performance Measurements > from Home Routers > To: [email protected] > Message-ID: <[email protected]> > 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 <[email protected]> > > Subject: Re: Announcing Project BISMark: ISP Performance Measurements > > from Home Routers > > To: nanog <[email protected]> > > Message-ID: <[email protected]> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Hello, > > > > On Mon, Jun 27, 2011 at 9:48 PM, Nick Feamster <[email protected]> > > 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 <[email protected]> > Subject: Re: website in ipv6 > To: Mark Andrews <[email protected]> > Cc: nanog list <[email protected]> > Message-ID: <[email protected]> > 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 <[email protected]> > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Cameron Byrne <[email protected]> > Cc: "[email protected]" <[email protected]>, > NANOG list <[email protected]> > Message-ID: <[email protected]> > 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 <[email protected]> > wrote: > > > On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > > <[email protected]> wrote: > > > > > > > > >> -----Original Message----- > > >> From: Cameron Byrne [mailto:[email protected]] > > >> Sent: 28 June 2011 16:53 > > >> To: Leigh Porter > > >> Cc: Andreas Ott; Eugen Leitl; [email protected]; 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 <[email protected]> > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: PC <[email protected]> > Cc: "[email protected]" <[email protected]>, > NANOG list <[email protected]> > Message-ID: > <BANLkTin4RBcVAZaz9kwoBouHmT1TBndkbQ_xc9E=offx4ge...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Jun 28, 2011 at 1:24 PM, PC <[email protected]> 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 <[email protected]> > wrote: > >> > >> On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > >> <[email protected]> wrote: > >> > > >> > > >> >> -----Original Message----- > >> >> From: Cameron Byrne [mailto:[email protected]] > >> >> Sent: 28 June 2011 16:53 > >> >> To: Leigh Porter > >> >> Cc: Andreas Ott; Eugen Leitl; [email protected]; 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 <[email protected]> > Subject: DENOG 3 - Call for Participation and Papers > To: [email protected] > Message-ID: <[email protected]> > 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 <[email protected]>: > > * 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 > [email protected] > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 41, Issue 165 > ************************************** >
