FRR fix went into 9.0 and has been back ported to 8.5 and 8.4 , Cumulus 5.6
will include the fix.
Cheers,
Jeff
> On Aug 30, 2023, at 5:32 AM, Mark Prosser wrote:
>
> Thanks for sharing this, Mike. I saw it on lobste.rs yesterday and figured
> everyone would be ahead.
>
> I'm running VyOS in
Saying that IS-IS in FRR is broken is incorrect, that it is in many ways weird
- no offense to folks who coded it :) (especially if you have worked with
commercial code bases), that it doesn’t scale/naive, missing features - for
sure.
FRR runs today some of the biggest DCs in the world and
All fixed (thanks Donald)
CVE-2022-40302 and CVE-2022-40318: https://github.com/FRRouting/frr/pull/12043
CVE-2022-43681: https://github.com/FRRouting/frr/pull/12247
Cheers,
Jeff
> On May 3, 2023, at 2:52 AM, Hank Nussbacher wrote:
>
> On 02/05/2023 17:56, Warren Kumari wrote:
>
> For those
If you are looking for BGP in DC (either unicast and/or VPN) we (Jeff Doyle and I) have published a significant number of podcasts on “between 0x2 nerds”(from basic BGP to EVPN to BGP security to HW) - https://youtube.com/playlist?list=PLMYH1xDLIabuZCr1Yeoo39enogPA2yJB7Cheers,JeffOn Apr 27, 2023,
FRR hasn’t implemented RFC4364 (nor planning to my knowledge (unless someone
comes and codes it ;-))
I believe - Arccus has implemented it (Keyur to confirm).
Cheers,
Jeff
> On Feb 26, 2023, at 22:58, Paul Rolland wrote:
>
> Hello,
>
>> On Sun, 26 Feb 2023 17:46:42 -0300
>> Douglas Fischer
You might want to search for “policy based add-path”, same idea (BGP listener + flow collector), different issue (60M+ entries BGP RIB), all clouds use some version of that, not sure about open sourcing it though Cheers,JeffOn Jan 6, 2023, at 17:00, Mike Hammett wrote:Right.Only I'm not the guy
Freertr folks have just published (I didn’t look into the details of their implementation though):“rare/freertr just got fib compression.. in our nren, the v4 table can be compressed from 900k to 260k, the v6 table from 160k to 52k... the tofino2 asic with our dataplane code (
Hey,
BCM DNX ASICs don’t make a device a white-box, many commercial vendors
programming it either completely or at least partially avoiding using BCM SDK,
using DB’s in different ways, etc.
Looking at a choice of modern NOSes, Arrcus is a high performance,YANG
programmable vertically
Link to Arista article about their Spotify deployment (2016), has all the relevant links, can be implemented on variety of vendors https://aristanetworks.force.com/AristaCommunity/s/article/spotifys-sdn-internet-routerCheers,JeffOn Oct 10, 2022, at 15:57, Ryan Rawdon wrote:On Oct 10, 2022, at
There has been a number of efforts to implement FIB (actually BGP RIB)
compression. There’s a white paper from MS research; I recall Spotify talking
of running off-box BGP compression SW and re-injecting summarized BGP RIB;
Volta Networks had an implementation of full BGP table compression to
Looking at the fix, Donald has only removed IPV4_CLASS_DE(a) uint32_t)(a))
& 0xe000) == 0xe000)
validation but kept INADDR_ANY.
I’ll bring up RFC6286 to him
Cheers,
Jeff
> On Sep 12, 2022, at 13:41, Bjørn Mork wrote:
> Jeff Tantsura writes:
>
>> Indeed, s
Indeed, someone was recently complaining that FRR is unhappy with a peer with
router-id from class E range…
Cheers,
Jeff
> On Sep 9, 2022, at 09:30, Saku Ytti wrote:
>
> On Fri, 9 Sept 2022 at 09:31, Crist Clark wrote:
>
>> As I said in the original email, I realize router IDs just need to
https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-path-prepending
Cheers,
Jeff
> On Aug 25, 2022, at 11:00, Tom Beecher wrote:
>
>
>
>> Usually What shoud we do ? Should we filter it ?
>
>
> As with many things, the answer depends on your situation.
>
> If I was running an edge
, we have line rate pre-classifiers do proper drops based on WAN
queue priority.
Cheers,
Jeff
> On Aug 9, 2022, at 16:34, Jeff Tantsura wrote:
>
>
> Saku,
>
> I have forwarded your questions to Sharada.
>
> All,
>
> For this week – at 11:00am PST, Thu
WAN ingress might not get access toingress buffer causing drop. Would it be practical in terms ofwattage/area to add some sort of preQoS towards the shallow ingressbuffer, so each WAN ingress has a fair guaranteed-rate to shallowbuffers? On Fri, 5 Aug 2022 at 02:18, Jeff Tantsura wrote:> >
Broadcom DNX (Jericho/Qumran/Ramon)
For both - the guests are main architects of the silicon
Enjoy
On Wed, Aug 3, 2022 at 5:06 PM Jeff Tantsura wrote:
>
> Hey,
>
>
>
> This is not an advertisement but an attempt to help folks to better
> understand networking HW.
>
>
Hey, This is not an advertisement but an attempt to help folks to better understand networking HW. Some of you might know (and love ) “between 0x2 nerds” podcast Jeff Doyle and I have been hosting for a couple of years. Following up the discussion we have decided to dedicate a number of upcoming
FYI
https://community.juniper.net/blogs/nicolas-fevrier/2022/07/27/voq-and-dnx-pipeline
Cheers,
Jeff
> On Jul 25, 2022, at 15:59, Lincoln Dale wrote:
>
>
>> On Mon, Jul 25, 2022 at 11:58 AM James Bensley
>> wrote:
>
>> On Mon, 25 Jul 2022 at 15:34, Lawrence Wobker wrote:
>> > This is
As Lincoln said - all of us directly working with BCM/other silicon vendors
have signed numerous NDAs.
However if you ask a well crafted question - there’s always a way to talk about
it ;-)
In general, if we look at the whole spectrum, on one side there’re massively
parallelized “many core”
Important note - Arista has 2 BGP implementations in the routing stack, old
(NH/ribd) that has been there since day 1 and newly written (I believe mostly
driven by EVPN development), when compared to other vendors - make sure to
compare with the new (modern code, highly multithreaded, cache
IOS- XR and Junos (don’t know about others) expose service level APIs that
allow offbox best path selection and consequently injecting these back into RIB.
FRR is in process of implementing customized best path using lua scripts.
Cheers,
Jeff
> On Mar 16, 2022, at 16:15, Anurag Bhatia wrote:
>
’ business doing ok.
How’s life on your side?
Would love to meet, lunch or so?
Cheers,
Jeff
> On Jan 16, 2022, at 13:19, Jeff Tantsura wrote:
>
>
> Plane IP underlay works real well, I’m yet to see tangible proof of TE in DC
> (outside of niche HPC/IB cases).
> SR in DC - wit
Plane IP underlay works real well, I’m yet to see tangible proof of TE in DC
(outside of niche HPC/IB cases).
SR in DC - with overlay starting on the host SR-MPLSoUDP(RFC8663) is a perfect
representation of a working technology that works in IP environment as well as
allows end2end programming
+1 Mark
There’s no modern silicon that doesn’t support MPLS (and is capable of imposing
at least 3 labels). There’s 0 additional price for vendors to enable MPLS on
their devices. The rest is subject to vendors’ licensing and is completely
artificial.
SR-MPLS uses MPLS data-plane and requires
Adrian,
//Speaking as RTGWG co-chair
As commutated to SCION proponents before, a detailed presentation at IETF RTGWG
would be a good starting point.
Please consider doing so at the upcoming IETF113.
The best way is to subscribe to rtgwg mailing list and respond to chairs email
request for
LAG - Micro BFD (RFC7130) provides per constituent livability. MLAG is much
more complicated (there’s a proposal in IETF but not progressing), so LACP is
pretty much the only option.
ECMP could use old/good single hop BFD per pair.
Practically - if you introduce enough flows with one of the hash
129.134.30.0/23, 129.134.30.0/24, 129.134.31.0/24. The specific routes covering
all 4 nameservers (a-d) were withdrawn from all FB peering at approximately
15:40 UTC.
Cheers,
Jeff
> On Oct 4, 2021, at 22:45, William Herrin wrote:
>
> On Mon, Oct 4, 2021 at 6:15 PM Michael Thomas wrote:
>>
Every major vendor at some point in time has implemented RIB->FIB(really
BGP->RIB->FIB) filtering, on Redback/Ericsson routers we did around
2013/2014(@Jakob Heitz;-))
Route compression is a more complex topic, it is not difficult to aggregate, it
is to effectively disaggregate on changes.
MS
Buffer size has nothing to do with feature richness.
Assuming you are asking about DC - in a wide radix low oversubscription
network shallow buffers do just fine, some applications (think map reduce/ML
model training) have many to one traffic patterns and suffer from incast as the
result, deep
For DNS fundamentals - I’d definitely recommend DNS deep dive we have recorded
at IETF108.
https://www.youtube.com/watch?v=DV0q9s94RL8
Cheers,
Jeff
On Nov 21, 2020, 8:49 AM -0800, NANOG News , wrote:
> Career Opportunities In Network Engineering
> “Be curious and passionate; this is a lifelong
YANG is the right direction.
OpenConfig BGP and policy models are supported by every vendor on the earth.
We are finalizing IETF BGP and policy models
draft-ietf-rtgwg-policy-model is about to be last-called
draft-ietf-idr-bgp-model is pretty much ready
Cheers,
Jeff
On Nov 5, 2020, 4:57 AM -0800,
Hi Thomas,
We had a similar discussion on FRR slack, there are some duplicates indeed.
Are you planing to test FRR at some point in time?
Cheers,
Jeff
On Oct 21, 2020, 3:58 PM -0700, Jakob Heitz (jheitz) via NANOG
, wrote:
> Thomas,
>
> I confirmed your case and took a look at the code.
> The
MPLSoUDP is not the technology you should be looking at, SRoUDP (RFC8663) is.
draft-bookham-rtgwg-nfix-arch describes an architecture that makes use of it to
provide an end2end SR path.
Cheers,
Jeff
On Sep 17, 2020, 9:32 AM -0700, James Bensley ,
wrote:
>
>
> On 17 September 2020 11:05:24 CEST,
Randy,
Was meant as the reply to Aaron’s comment about VPN’s over non MPLS underlay,
not the encryption of it (which is orthogonal).
Cheers,
Jeff
On Sep 15, 2020, 12:59 PM -0700, Randy Bush , wrote:
> > GRE, VXLAN or any other tunneling encap of the day.
> > As long as next-hop could be
GRE, VXLAN or any other tunneling encap of the day.
As long as next-hop could be resolved behind remote end
Regards,
Jeff
> On Sep 15, 2020, at 11:14, Randy Bush wrote:
>
>
>>
>> I'm still learning, but, It does seem interesting that the IP layer
>> (v6) can now support vpn's without mpls.
I have described what SR is, not what vendors (for variety of reasons) do with
it, hence “could” ;-)
As a side note - SRoUDP works seamlessly over either v4 or v6.
Regards,
Jeff
> On Sep 10, 2020, at 12:35, Mark Tinka wrote:
>
>
>
>> On 10/Sep/20 10:40, Jeff Tantsura
SR could be instantiated with 2 data planes, MPLS and IPv6 - SR-MPLS and SRv6
respectively.
MPLS data plane could be instantiated over either IPv4 or IPv6 (similarly to
LDP6), MPLSoUDP->SRoUDP allows transport of SR-MPLS over IP/UDP(RFC8663) and
could be used to build innovative, end2end
beit concentrated around security)
>
> adam
>
> From: Jeff Tantsura
> Sent: Wednesday, September 9, 2020 9:52 AM
> To: adamv0...@netconsultings.com
> Cc: nanog@nanog.org
> Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN
> r
Great excuse ;-)
Regards,
Jeff
> On Sep 9, 2020, at 15:16, Mike Hammett via NANOG wrote:
>
>
> If history has taught us anything, everything we do will be ignored by those
> that most need it. :-)
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
out IGP left and right when even today bunch of DCs can do
> just fine with current IGPs scaling wise is IMO not a good thing.
>
> Thx
> R.
>
>> On Wed, Sep 9, 2020, 10:55 Jeff Tantsura via NANOG wrote:
>> I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP,
I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example of
“ab”use of ASN0 is a de-facto artifact (unfortunate one).
My goal would be to provide a viable source of information to someone who is
setting up a new ISP and has a very little clue as where to start. Do’s and
De-facto standards are as good as people implementing them, however in order to
enforce non ambiguous implementations, it has to be de-jure (e.g. a standard
track RFC).
While I’m sympathetic to the idea, I’m quite skeptical about its viability.
A well written BCP would be much more valuable, and
Aaron,
Out of curiosity - if you are interested in SR, where are you getting your
information from if not IETF (SPRING)?
As for history - we (at Redback) have published 1st draft describing SR-MPLS
data plane in 2003 (LDP control plane).
Regards,
Jeff
> On Sep 6, 2020, at 09:53, Saku Ytti via
/RTGWG chair hat on
Dear NANOG,
For those, who might be interested, on January 25 we (IETF Routing Area RTGWG)
will be having an interim online meeting, dedicated to Existing problems for
routing in the large Data Centers and potential solutions. Presenters will be
describing (15
Saku,
Jericho is in no sense a low end chip, while there are some scale limitations
(what can be done with SuperFEC, some bridging related stuff), from
functionality prospective it is a very capable silicon.
One has to:
Understand how to program it properly (recursiveness, ECMP’s, etc)
Know
of silicon made by
clueful folks… watch this space closely
Jeff
From: Colton Conor <colton.co...@gmail.com>
Date: Monday, April 18, 2016 at 11:44 AM
To: lincoln dale <l...@interlink.com.au>
Cc: Jeff Tantsura <jeff.tants...@ericsson.com>, "nanog@nanog.org"
<nan
Lincoln,
Why wouldn’t they?
What is it Arista did others didn’t?
Cheers,
Jeff
From: lincoln dale <l...@interlink.com.au<mailto:l...@interlink.com.au>>
Date: Monday, April 18, 2016 at 11:42 AM
To: Colton Conor <colton.co...@gmail.com<mailto:colton.co...@gmail.com>>
Cc: Je
Hi,
Some points:
1.DNX SDK is significantly different from SGX, adopted by Cumulus and such, yet
to be done, and this is not negligible amount of work
2.if you are not interested in capacity but in scale, there’re other BCM chips,
perhaps more suitable
3.you don’t have to have all the
In 2016 we will start seeing first massive EVPN deployments.
If you really need L2 with multihoming and BGP FRR speeds in service recovery -
look for EVPN, otherwise, as mentioned below - L3 is your friend.
Regards,
Jeff
> On Jan 1, 2016, at 7:21 AM, Nick Hilliard wrote:
>
>
In that case multihop BFD (if supported on both sides) would really help.
Regards,
Jeff
> On Nov 28, 2015, at 11:37 AM, Matthew Petach wrote:
>
> One thing I notice you don't mention is whether your
> BGP sessions to your upstream providers are direct
> or multi-hop
Been forever since i looked at cisco, however sounds like vc type mismatch.
They used to have it as a platform capability, perhaps SW upgrade changed the
default.
to my memory "show mpls l2 transport" should provide enough details.
Hope this helps
Regards,
Jeff
> On Nov 14, 2015, at 4:50 AM,
s: receive 0, seq error 0, send 0
>pe#
>
>Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching.
>
>Best regards,
>Jonas Bjork
>
>
>> On 15 Nov 2015, at 1:26, Jeff Tantsura <jeff.tants...@ericsson.com> wrote:
>>
>> Been foreve
Hi,
In most well designed IP routing stacks the way to get to a labeled
(tunneled) next hop is decoupled from a service, so if a service requires
such next hop it is upto (usually RIB) to return one (best, multiple might
exist) which would be used for forwarding. If it is a Segment Routed one
so
Hi,
In your case I¹d recommend to use diverse path, due to its simplicity and
non disruptive deployment characteristics.
As you know - diverse path requires additional BGP session per additional
(second, next, etc) path, in most cases not a problem, however mileage
might vary.
To my memory, in
Hi Peng,
Good stuff!
Any plans for multicast, RTC and EVPN AF's?
Regards,
Jeff
On Aug 6, 2015, at 7:43 PM, Peng Xiao (penxiao) penx...@cisco.com wrote:
Hi guys,
Ipv6 and other address families are under development. We have already
designed the data structures for them as you can see
ASR1K (XE) has great BGP implementation, go for it if you are OK with
density/throughput.
Regards,
Jeff
On May 19, 2015, at 11:35 PM, Mark Tees markt...@gmail.com wrote:
For the lists benefit, there is a 6 X 10GBE option for the ASR1000
series it seems. No idea on pricing though.
For L2VPN if you could make it work - go with EVPN day 1, it solves most of the
issues present in both LDP and BGP VPLS implementations.
Be aware of differences in PBB vs plain EVPN and platform support.
EVPN, specifically multhoming/split horizon/some other stuff as well as
presence of L3
From market prospective v6 SR is definitely lower priority. Comcast and few
more are looking into native rather than v6 with MPLS encap.
Wrt v4 - 2 weeks ago at EANTC in Berlin we have tested 3 implementations of
ISIS SR v4 MPLS with L3VPN and 6VPE over SR tunnels. Worked very well, very few
AhhhŠ vertically integrated horizontal API¹s
Cheers,
Jeff
-Original Message-
From: Nick Hilliard n...@foobar.org
Date: Tuesday, January 13, 2015 at 2:23 PM
To: Jeff Tantsura jeff.tants...@ericsson.com, Eduardo Schoedler
lis...@esds.com.br, nanog@nanog.org nanog@nanog.org
Subject: Re
at 2:28 PM
To: nanog@nanog.org nanog@nanog.org
Subject: Re: Recommended L2 switches for a new IXP
My mistake, it's the OCX1100.
http://www.networkworld.com/article/2855056/sdn/juniper-unbundles-switch-h
ardware-software.html
2015-01-13 20:10 GMT-02:00 Jeff Tantsura jeff.tants...@ericsson.com
What does it mean - to be SDN ready?
Cheers,
Jeff
-Original Message-
From: Eduardo Schoedler lis...@esds.com.br
Date: Tuesday, January 13, 2015 at 3:25 AM
To: nanog@nanog.org nanog@nanog.org
Subject: Re: Recommended L2 switches for a new IXP
QFX5100 is SDN ready.
--
Eduardo
+100
Regards,
Jeff
On Jan 2, 2015, at 5:29 AM, Rob Shakir r...@rob.sh wrote:
On 2 Jan 2015, at 01:54, Jeff Tantsura jeff.tants...@ericsson.com wrote:
You don't need LDP on RR as long as clients support not on lsp flag
(different implementation have different names
You don't need LDP on RR as long as clients support not on lsp flag
(different implementation have different names for it)
There are more and more reasons to run RR on a non router HW, there are many
reasons to still run commercial code base, mostly feature set and resilience.
Regards,
Jeff
Hi,
Right, one is when besides forwarding packets a router also functioning as a
RR, another - when RR sets NH to itself and hence forces all the traffic to
pass thru the router in fast path.
Keep in mind - some architectures, such as seamless MPLS would require a RR to
be in the fast path.
It is not the network devices per se, it is additional configuration,
security, MSDP peering, etc, i.e. OPEX
Business justification for such effort is not obvious, (most of multicast
deployments I have done in my previous life were because I loved the
technology, not because of business needs :))
Mark,
BGP to RIB filtering (in any vendor implementation) is targeting RR which
is not in the forwarding path, so there¹s no forwarding towards any
destination filtered out from RIB.
Using it selectively on a forwarding node is error prone and in case of
incorrect configuration would result in
A path to a destination must be loop free, irrespectively.
So it is not a combination of multiple but rather a list of loop free paths to
a destination where any other metrics are used as tie-breakers.
Another story - how do you get all that state distributed, inter-area cases,
how do you make
Yes, 10 years ago on 10720, CDP and LACP worked like a charm
Regards,
Jeff
On Jan 24, 2014, at 7:55 AM, Philip Lavine source_ro...@yahoo.com wrote:
To all,
Has anyone successfully tunneled L2 PDU's (STP, CDP, LLDP) over a L2TPv3
pseudowire tunnel, i.e. should I be able to see CDP
Eric,
Issues:
1.OSPF (SPF) can only produce a SPT based on cost (metric).
Anything else would require CSPF rather than SPF.
2. Delay is not distributed as part of an IGP update
Typical constrains distributed are: bandwidth, color, some others
In IETF we are working to also be able to
Ole is not with Cisco anymore.
Regards,
Jeff
On Nov 17, 2013, at 10:11, Courtney Smith courtneysm...@comcast.net wrote:
Another one bites the dust. Received the below this AM. Hopefully,
something similar finds it's way into an electronic format.
TO OUR READERS
At this time,
Agree, that't why using p2p has been mentioned as BCP in networking howto's
for at least last 10 years.
Regards,
Jeff
On Aug 4, 2013, at 3:14 AM, Saku Ytti s...@ytti.fi wrote:
On (2013-08-04 05:01 -0500), Jimmy Hess wrote:
I would say the risk score of the advisory is overstated. And if
Hi,
As for Ericsson (Redback) products.
We found the issue quite some time ago and fixed it immediately.
Smart Edge code base (SEOS) has been fixed back to the release 6.3
SSR code base (IPOS) - not affected.
Please let me know if you have got any questions.
Regards,
Jeff
On Aug 3, 2013, at
Good times indeed...
Regards,
Jeff
On Feb 7, 2013, at 2:09, Brett Watson br...@the-watsons.org wrote:
Hell, we used to not have to bother notifying customers of anything, we just
fixed the problem. Reminds me a of a story I've probably shared on the past.
1995, IETF in Dallas. The big
Hi Adam,
Works just fine on any relatively modern router.
Cheers,
Jeff
-Original Message-
From: Adam Vitkovsky [mailto:adam.vitkov...@swan.sk]
Sent: Tuesday, October 23, 2012 12:31 AM
To: nanog@nanog.org
Subject: MP-BGP next hop tracking delay 0
I was wondering whether you have some
l2tpv3
Regards,
Jeff
On Sep 12, 2012, at 19:23, Philip Lavine source_ro...@yahoo.com wrote:
To all,
I am trying to extend a layer2 connection over Layer 3 so I can have
redundant Layer connectivity between my HQ and colo site. The reason I need
this is so I can give the appeareance
Nope, run iBGP, have only next-hops in OSPF.
Regards,
Jeff
On May 18, 2012, at 19:14, Deric Kwok deric.kwok2...@gmail.com wrote:
Hi all
Can I have questions about bgp and ospf
1/ Do I have to redistrt bgd in ospf to make ospf to know which
upstrem bgp routers to go out
2/ If yes, how
Hi,
All modern routers support mapping from IGMPv2 to PIM SSM, all static, some
others thru DNS, etc
Regards,
Jeff
On May 3, 2012, at 12:34 PM, Nick Hilliard n...@foobar.org wrote:
On 03/05/2012 21:00, Greg Shepherd wrote:
Sure, but GLOP predated SSM, and was really only an interim fix for
, Jeff Tantsura
jeff.tants...@ericsson.com wrote:
Hi,
All modern routers support mapping from IGMPv2 to PIM SSM, all static, some
others thru DNS, etc
I am not sure what you mean here. To support SSM, you need IGMPv3. Most
routers do support IGMPv3, but there is still a fair amount of legacy
81.169.144 belongs to a German company based in Berlin :)
Regards,
Jeff
On Mar 24, 2012, at 13:39, Randy Bush ra...@psg.com wrote:
81.169.145.156
Mike,
To my knowledge in most today's networks even if legacy equipment don't support
IGMPv3 most likely 1st hop router does static translation and SSM upstream.
The reason not to migrate to SSM is usually - ASM is already there and works
just fine :)
Cost to support RP infrastructure is
Olivier,
Thanks!
We've done our best to provide the fix ASAP.
Regards,
Jeff
-Original Message-
From: Olivier Benghozi [mailto:olivier.bengh...@wifirst.fr]
Sent: Thursday, December 22, 2011 5:20 AM
To: nanog@nanog.org
Cc: Alexandre Snarskii; Jeff Tantsura
Subject: Re: bgp update
Hi David,
You might want to take a look at work happening in ALTO
(http://tools.ietf.org/wg/alto/)
Regards,
Jeff
-Original Message-
From: Holmes,David A [mailto:dhol...@mwdh2o.com]
Sent: Wednesday, December 14, 2011 11:07 AM
To: nanog@nanog.org
Subject: Multiple ISP Load Balancing
, December 02, 2011 5:13 AM
To: Jeff Tantsura; Warren Kumari
Cc: nanog@nanog.org; i...@ietf.org
Subject: draft-ietf-idr-as0-00 (bgp update destroying transit on redback
routers ?)
Hi,
This is true that no-aggregator-id knob zeroes out the AGGREGATOR attribute.
The knob, as far as I was able to find
Snarskii [mailto:s...@snar.spb.ru]
Sent: Friday, December 02, 2011 6:36 AM
To: Jeff Tantsura
Cc: nanog@nanog.org
Subject: Re: bgp update destroying transit on redback routers ?
On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote:
Hi,
Let me take it over from now on, I'm the IP Routing/MPLS
Hi,
Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at
Ericsson responsible for all routing protocols.
There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see
ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came
into the
Thanks Warren!
I have already brought this to the list.
Regards,
Jeff
-Original Message-
From: Warren Kumari [mailto:war...@kumari.net]
Sent: Thursday, December 01, 2011 3:05 PM
To: Christopher Morrow
Cc: nanog@nanog.org
Subject: Re: bgp update destroying transit on redback routers ?
86 matches
Mail list logo