Re: AS-Path - ORF Draft
Nokia SR OS defaults to pre-policy but can be configured to post-policy by adding "post-import". prefix-limit ipv4 100 // pre-policy prefix-limit ipv6 100 post-import // post-policy Greg -- Greg Hankins <ghank...@mindspring.com> -Original Message- Date: Mon, 23 Oct 2017 12:37:13 +0200 From: Job Snijders <j...@ntt.net> To: nanog@nanog.org Subject: Re: AS-Path - ORF Draft On Mon, Oct 23, 2017 at 08:35:42AM +0200, Job Snijders wrote: > > or it could compare each additional prefix received to already learned > > prefixes and decide to drop one to make room for the new one. For > > example you could drop the most specific routes before less specific > > routes. > > The moment a BGP implementation can do such RIB compression, it may > indeed make sense to offer two types of limits: a 'pre-policy maximum > prefix limit' and a 'post-policy maximum prefix limit'. The former type > of limit would be useful in context of route leaks, the latter in > context of protecting against overflow of the FIB capability. Apparently this already exists and is widely available, Saku Ytti gave me some additional information. There are various keywords available, and they operate at different attachment points in the conceptual model. | IOS XR | Junos === pre-policy keyword | | prefix-limit +--+ post-policy keyword | maximum-prefix | accepted-prefix-limit (? means the keyword does not exist) Now I wonder what Arista EOS, Nokia SR-OS, etc offer in this regard. :-) (screenshot here http://instituut.net/~job/screenshots/baf76f9c29a31d2e55454ddd.png for those of you who can't easily view ASCII tables) Kind regards, Job
Re: BGP Route Reflector - Route Server, Router, etc
On Mon, Mar 20, 2017 at 12:35:24PM +0200, Mark Tinka wrote: >On 14/Jan/17 00:39, Brandon Ewing wrote: >> Work is being done to allow RRs to compute metrics from the client's >> position in the IGP: See >> https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-13 >> for more information > >BGP-ORR is currently supported in Junos and IOS XR (ASR9000, I >believe... I haven't confirmed for other IOS XR platforms). > >I feel, is one of those features that doesn't need a business case - >much like ketchup at a fast-food joint. Mark is spot on, this is an important point. We just added ORR to SR OS 15.0.R1 on the 7x50/VSR. Greg -- Greg Hankins <ghank...@mindspring.com>
RFC 8092 on BGP Large Communities Attribute
Hey NANOG, As a followup to our NANOG 68 presentation in Dallas on BGP Large Communites (https://www.nanog.org/meetings/abstract?id=2990), RFC 8092 as just published on Thursday. BGP Large Communities solve a big issue for network operators, by providing a simple way to signal meta-information between networks using 16-bit or 32-bit ASNs. Publication as an RFC was accomplished in a remarkably short time, due to the close cooperation and strong consensus between the IETF IDR Working Group and network operators. The idea progressed rapidly from its inception in March 2016, to the first Internet-Draft in September 2016, to its final IESG approval stages in December 2016, and finally to publication as an RFC in barely seven months. In addition the the final standard, a number of implementations and tools were developed along the way, so that network operators can test and deploy the new technology now. The latest list of software that support BGP Large Communities is here: http://largebgpcommunities.net/implementations/ . While the final milestone to RFC publication has been reached, this is by no means the end of the story! Work on the "Usage of BGP Large Communities" I-D (https://tools.ietf.org/html/draft-ietf-grow-large-communities-usage) continues, to provide examples and inspiration for network operators on how to use BGP Large Communities. It’s time to celebrate, as 32-bit ASNs are first class citizens now too! More information can be found here: http://largebgpcommunities.net/ . RFC 8092 can be found here: https://tools.ietf.org/html/rfc8092 . Kind regards, Greg -- Greg Hankins <ghank...@mindspring.com> - Forwarded message from rfc-edi...@rfc-editor.org - Date: Thu, 16 Feb 2017 10:23:49 -0800 (PST) From: rfc-edi...@rfc-editor.org To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org Cc: drafts-update-...@iana.org, i...@ietf.org, rfc-edi...@rfc-editor.org Subject: [Idr] RFC 8092 on BGP Large Communities Attribute A new Request for Comments is now available in online RFC libraries. RFC 8092 Title: BGP Large Communities Attribute Author: J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard Status: Standards Track Stream: IETF Date: February 2017 Mailbox:jhe...@cisco.com, j...@ntt.net, ke...@arrcus.com, ibagdona.i...@gmail.com, n...@inex.ie Pages: 8 Characters: 15979 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-idr-large-community-12.txt URL:https://www.rfc-editor.org/info/rfc8092 DOI:10.17487/RFC8092 This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with all Autonomous System Numbers (ASNs) including four-octet ASNs. This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ Idr mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/idr - End forwarded message -
Re: Equipment Supporting 2.5gbps and 5gbps
The goals of these BASE-T projects are specifically to extend the life of the large installed base of Cat 5e/6 cabling with higher speeds. I wouldn't expect there to be a fiber interface, because we already have much higher speeds that are supported on MMF/SMF at better costs (ie if you had a fiber cable, would you really want to run 2.5 GE when 10 GE is so affordable now). Anything is possible though, if there is enough demand and a market then someone will make it. Greg -- Greg Hankins <ghank...@mindspring.com> -Original Message- Date: Thu, 28 Jan 2016 01:51:06 +0100 From: Baldur Norddahl <baldur.nordd...@gmail.com> To: nanog@nanog.org Subject: Re: Equipment Supporting 2.5gbps and 5gbps Will we also get 2.5 Gbps fiber optics? SFP modules should support it? Regards Baldur Den 27. jan. 2016 23.00 skrev "Greg Hankins" <ghank...@mindspring.com>: > Fortunately the two groups came together in the IEEE, and there are no > competing standards. > > IEEE P802.3bz 2.5/5GBASE-T Task Force stared in March 2015: > - 2.5GBASE-T: 4 x 625 Mb/s over 100 m Cat 5e (Class D) or Cat 6 (Class E) > unshielded twisted-pair copper cabling > - 5GBASE-T: 4 x 1.250 Gb/s over 100 m Cat 5e (Class D) or Cat 6 (Class E) > unshielded twisted-pair copper cabling > - MultiGBASE-T auto-negotiation between 2.5GBASE-T, 5GBASE-T, 10GBASE-T, > 25GBASE-T, 40GBASE-T > - Automatic MDI/MDI-X configuration > - PoE support including IEEE 802.3bt amendment (power over 4 pairs) > - Optional Energy Efficient Ethernet (EEE) support > - Standard expected in September 2016 > - Interfaces expected on the market in 2016 > - Task Force web page http://www.ieee802.org/3/bz/ > > You might have seen my Ethernet speeds presentation... the most recent > one is here: > http://ix.br/pttforum/9/slides/ixbr9-ethernet.pdf (December 2015) > > It's slightly out of date as the IEEE Interim was just last week. > > Greg > > -- > Greg Hankins <ghank...@mindspring.com> > > -Original Message- > Date: Wed, 27 Jan 2016 21:45:27 + > From: a.l.m.bu...@lboro.ac.uk > To: Justin Krejci <jkre...@usinternet.com> > Cc: "nanog@nanog.org" <nanog@nanog.org> > Subject: Re: Equipment Supporting 2.5gbps and 5gbps > > Hi, > > I've a couple 10 port Cisco switches that support 2.5 and 5gbps over > cat5e, just wondering if there are any other vendors out there with > offerings that support these newer ethernet speeds. Supporting cat5e for > these multi-gig speeds is a real boon in many circumstances given the wide > popularity of it in many buildings. > > > > Does anyone have any experience with or knowledge of other products, > switches in particular, supporting 2.5 and 5 gbps? > > well, until the standard is ratified, these Multi-Gig offerings are quite > proprietary.. > > there are 2 competing campshopefully they will be compatible and not > end up like beta/vhs once the dust settles > > > camp 1 - http://www.nbaset.org/ > > > camp 2 - http://www.mgbasetalliance.org/ > > > look at those vendors. I think they hope by avoiding IEEE int he early > stages and taping silicon they'll > get the job done quicker - the drive mainly being faster wireless APs and > cheaper data centre interconnects... > > alan >
Re: Equipment Supporting 2.5gbps and 5gbps
Fortunately the two groups came together in the IEEE, and there are no competing standards. IEEE P802.3bz 2.5/5GBASE-T Task Force stared in March 2015: - 2.5GBASE-T: 4 x 625 Mb/s over 100 m Cat 5e (Class D) or Cat 6 (Class E) unshielded twisted-pair copper cabling - 5GBASE-T: 4 x 1.250 Gb/s over 100 m Cat 5e (Class D) or Cat 6 (Class E) unshielded twisted-pair copper cabling - MultiGBASE-T auto-negotiation between 2.5GBASE-T, 5GBASE-T, 10GBASE-T, 25GBASE-T, 40GBASE-T - Automatic MDI/MDI-X configuration - PoE support including IEEE 802.3bt amendment (power over 4 pairs) - Optional Energy Efficient Ethernet (EEE) support - Standard expected in September 2016 - Interfaces expected on the market in 2016 - Task Force web page http://www.ieee802.org/3/bz/ You might have seen my Ethernet speeds presentation... the most recent one is here: http://ix.br/pttforum/9/slides/ixbr9-ethernet.pdf (December 2015) It's slightly out of date as the IEEE Interim was just last week. Greg -- Greg Hankins <ghank...@mindspring.com> -Original Message- Date: Wed, 27 Jan 2016 21:45:27 + From: a.l.m.bu...@lboro.ac.uk To: Justin Krejci <jkre...@usinternet.com> Cc: "nanog@nanog.org" <nanog@nanog.org> Subject: Re: Equipment Supporting 2.5gbps and 5gbps Hi, > I've a couple 10 port Cisco switches that support 2.5 and 5gbps over cat5e, > just wondering if there are any other vendors out there with offerings that > support these newer ethernet speeds. Supporting cat5e for these multi-gig > speeds is a real boon in many circumstances given the wide popularity of it > in many buildings. > > Does anyone have any experience with or knowledge of other products, switches > in particular, supporting 2.5 and 5 gbps? well, until the standard is ratified, these Multi-Gig offerings are quite proprietary.. there are 2 competing campshopefully they will be compatible and not end up like beta/vhs once the dust settles camp 1 - http://www.nbaset.org/ camp 2 - http://www.mgbasetalliance.org/ look at those vendors. I think they hope by avoiding IEEE int he early stages and taping silicon they'll get the job done quicker - the drive mainly being faster wireless APs and cheaper data centre interconnects... alan
Re: Dual stack IPv6 for IPv4 depletion
We added LDP IPv6 support in SR OS 13.0.R1 for Alcatel-Lucent 7x50 platforms earlier this year. Regards, Greg -- Greg Hankins ghank...@mindspring.com -Original Message- Date: Wed, 8 Jul 2015 06:50:27 +0200 From: Mark Tinka mark.ti...@seacom.mu To: Mel Beckman m...@beckman.org, andrew and...@ethernaut.io Cc: Josh Moore jmo...@atcnetworks.net, nanog@nanog.org nanog@nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion On 6/Jul/15 16:49, Mel Beckman wrote: MPLS requires an IPv4 core. You can't run an IPv6-only infrastructure because neither CSCO or JNPR have implemented LDP to distribute labels for IPV6 prefixes. Not true - Cisco have it in IOS XR since 5.3.0. Juniper expect to start shipping it later in 15. Mark.
Re: /. Terabit Ethernet is Dead, for Now
Several good presentations were given at the IEEE meeting in Geneva last week about why we should do 400 GbE and not TbE. You can find them here: http://www.ieee802.org/3/ad_hoc/hse/public/12_09/index.shtml . Greg -- Greg Hankins ghank...@mindspring.com
Re: Advice regarding Cisco/Juniper/HP
Changes to the Brocade and legacy Foundry support sites are in progress. The candid comments from the community expressed here in numerous threads this year have captured your frustration for me to explain to management in far better words than I can write myself. I've had several mail and phone conversations with the team in charge of our support site about our current practice of requiring a login to access documentation, and they understand why this is not at all helpful and a bad way of doing business. It's the way it is for various historical reasons. Product documentation will be freely available on the new MyBrocade support site that is under construction. This is part of a huge effort to integrate the disparate support sites' software, knowledge bases, manuals, etc. into one new happy place. Stand by, and thanks for your patience. Greg (works for Brocade) -- Greg Hankins ghank...@mindspring.com -Original Message- Date: Thu, 17 Jun 2010 14:12:40 -0700 From: Kevin Oberman ober...@es.net To: William Pitcock neno...@systeminplace.net Cc: nanog@nanog.org Subject: Re: Advice regarding Cisco/Juniper/HP From: William Pitcock neno...@systeminplace.net Date: Thu, 17 Jun 2010 13:35:30 -0500 On Thu, 2010-06-17 at 11:07 -0700, Seth Mattinen wrote: On 6/17/2010 11:01, Sandone, Nick wrote: I would also add Brocade/Foundry to the mix as well. We've been deploying these switches with great results. Since the IOS is very similar to Cisco's, the transition has been quite easy. Do you still have to pay them to read the manual? We have plenty of Foundry gear and we've never had to pay anything to read the manuals for them. Then again, we bought it all new, so it came with printed manuals. There's a 1000+ page manual on the management software itself. The Brocade manuals are good, but you need to have a customer account to access them. Very annoying when you are trying to do an evaluation. I have spoken with one of their engineers about that and he said that they (the engineers and sale folks) are trying to get that changed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: 32 bits ASN on Cisco
The AS4 Wiki has a list of software support for most vendors, as well as a bunch of other information related to 32-bit ASNs. http://as4.cluepon.net/index.php/Software_Support More information is always welcome, if you'd like to add something. Greg -- Greg Hankins ghank...@mindspring.com
Re: 32-bit AS numbers
On Fri, Oct 09, 2009 at 10:31:52AM +0200, Iljitsch van Beijnum wrote: As you (hopefully) know, as of 1-1-2010, the RIRs will only be giving out 32-bit AS numbers. I'm writing an article for Ars Technica about this, and I was wondering about the perspective of network operators who may be faced with customers with a 32-bit AS number in the near future, and how the vendor support for 32-bit AS numbers is working out. If you send me info in private mail, let me know your title/affiliation and whether I can quote you or not. Chris Malayter and I gave a presentation at NANOG45 earlier this year that touches on some of the operational issues. http://www.nanog.org/meetings/nanog45/presentations/Tuesday/Hankins_4byteASN_N45.pdf We also started a Wiki with content based on the presentation that has more updated information, including a current list of vendor support. If you see a vendor missing, let us know and we can update the list. Or better yet, create an account and add some content yourself :-). http://as4.cluepon.net/index.php/Main_Page Greg -- Greg Hankins ghank...@mindspring.com
Re: 23456 without AS4_PATH?
These prefixes all appeared with this problem late last December: 91.207.218.0/23 35320 196629 23456 195.128.230.0/24 35320 196629 23456 35748 195.128.231.0/24 35320 196629 23456 35748 The ill side effects of the AS_CONFED_SEQUENCE in an AS4_PATH and analysis on what is going on were covered in excellent detail by Andy Davidson, Jonathan Oddy, and Rob Shakir: - NANOG thread: http://www.merit.edu/mail.archives/nanog/msg14345.html - NANOG45 presentation: http://www.nanog.org/meetings/nanog45/presentations/Monday/Davidson_asn4_breaks_light_N45.pdf - AS4 Wiki: http://as4.cluepon.net/index.php/Operational_Issues#AS_CONFED_SEQUENCE_in_AS4_PATH Numerous attempts to contact AS 35320's NOC and peering folks about the problem by several people have pretty much been ignored. 91.196.186.0/24 looks like it just showed up with a broken AS path in the past couple of days. We'll probably see it a lot more regular invalid uses of 23456 in the future... I mean, how often does someone leak a private ASN :-)? Perhaps it is a good idea for router and routing software vendors to add 23456 to neighbor remove-private-as. Incidentally, while RFC 4893bis will include better error handling for 32-bit ASNs, a new I-D to suggest better error handling for all optional transitive attributes was just released yesterday (http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00.txt). Greg -- Greg Hankins ghank...@mindspring.com +1 404 542 5530
Re: BCP38 dismissal
On Thu, Sep 04, 2008 at 01:14:20PM -0400, Paul Wall wrote:
On Thu, Sep 4, 2008 at 12:45 PM, Jo Rhett [EMAIL PROTECTED] wrote:
I'm sorry, but nonsense statements such as these burn the blood. Sure, yes,
protecting yourself is so much more important than protecting anyone else.
Anyone else want to stand up and join the I am an asshole club?
uRPF is important. But all the uRPF in the world won't protect you
against a little tcp/{22,23,179} SYN aimed at your Force 10 box.
Ya know what I mean?
Hey Paul, would you be able to demonstrate this problem? I'd like to see
it so that we can investigate and fix it.
You are correct that the first generation of E-Series hardware (EtherScale)
had little control plane protection.
The current E-Series hardware (TeraScale) has a completely different
architecture that rate limits, queues and filters all packets destined to
the control plane.
Greg*
(* I am currently employed by Force10.)
--
Greg Hankins [EMAIL PROTECTED]
