On 18/Jun/20 14:30, adamv0...@netconsultings.com wrote:
> Hence our current strategy is to stay on IPv4 control-plane (and IPv4
> management plane) as it suits, and for the foreseeable future will suite, all
> our needs (which are to transport v4 data packets via L2 MPLS VPN
> services),
On 18/Jun/20 14:28, Saku Ytti wrote:
> ACK. Good Internet is almost an emergent feature, not something we
> really designed for. The main remaining problems are congested
> peerings, which is a silly political problem which ends up hurting
> customers and not helping anyone.
It's easier to
On 18/Jun/20 13:23, adamv0...@netconsultings.com wrote:
> You do have the LDP vs SR choice (in v4 anyways) yes there's not a good 1:1
> feature parity with v6, but the important point...
But the lack of IPv4/IPv6 parity is a crucial one.
There is only so long we can stretch IPv4, if one can
On 18/Jun/20 12:51, Nick Hilliard wrote:
>
> The customer monitoring system is very reliable and often superior to
> in-house solutions.
What really made the experience great for us is that directly contacting
the remote network (somewhere in Eastern Europe) and getting them to fix
the issue
On 18/Jun/20 12:28, Robert Raszuk wrote:
> To your IGP point let me observe that OSPF runs over IP and ISIS does
> not. That is first fundamental difference. There are customers using
> both all over the world and therefore any suggestion to just use
> OSPFv3 is IMHO quite unrealistic.
Are
On 18/Jun/20 04:00, Owen DeLong wrote:
> OTOH, I bet if you’d had two of those cards fail, you might
> have been SOL on the second one for a couple of days.
Quite possibly, who knows :-). Perhaps I should ask them, just to get a
squirm :-).
Then again, we had enough redundancy built into the
On 18/Jun/20 00:50, Warren Kumari wrote:
>
> A number of customers (myself included) had 4 hour replacement
> contracts, which the vendor really could not meet - so we agreed to
> take a new, much larger/better model as a replacement.
It's one of the reasons we never pay for 24/7/365.
In many
On 17/Jun/20 22:47, Dovid Bender wrote:
> Hi,
>
> My 9-5 is working for a VoIP provider. When we started in 2006 we had
> a lot of issues with the quality of the internet in eastern europe and
> central Asia. It was not rare for us to have to play around with
> routing to get the quality that
On 17/Jun/20 21:16, Tim Warnock wrote:
> How did you know? Is there some monitoring system available to let you know
> or do you have your own?
The usual way - a customer complained :-).
Mark.
On 17/Jun/20 20:31, Bryan Fields wrote:
>
>
> How is IPv6 coming on Mikrotik? It's a no-go at least for my
> deployment on
> 6.4 code. Not sure I want to run beta in a quasi-production network.
In my home, basic IPv6 + SLAAC is working fine on Mikrotik, on 6.47.
I have a mate who adds
On 17/Jun/20 19:19, Job Snijders wrote:
>
> Our hero Massimiliano Stucchi in Switzerland started doing the legwork.
> He is is sharing the test results here:
>
> http://as58280.net/en/articles/RPKI-on-Mikrotik
>
> Enjoy!
Thanks, and great to see.
Shame IPv6 keeps being sent to the
On 18/Jun/20 09:30, Saku Ytti wrote:
> Yes work left to be done. Ultimately the root problem is, no one cares
> about IPv6. But perhaps work with vendors in parallel to LDPv6 to get
> them to fix OSPFv3 and/or ISIS.
Yes, this.
Vendor feedback for those not supporting LDPv6 is that there is
On 18/Jun/20 07:25, Saku Ytti wrote:
> The IGP mess we are in is horrible, but I can't blame SR for it. It's
> really unacceptable we spend NRE hours developing 3 identical IGP
> (OSPFv2, OSPFv3, ISIS). We all pay a 300-400% premium for a single
> IGP.
>
> In a sane world, we'd retire all of
On 18/Jun/20 02:32, Phil Bedard wrote:
> I look at the basic SR via IGP extensions like VPLS vs. EVPN. If we had a
> way to go back in history I'm not sure anyone would have said VPLS was a good
> idea vs. EVPN.
>
> There were reasons back in the day why something like SR wasn't done.
On 18/Jun/20 00:29, Robert Raszuk wrote:
>
> Example: If your hardware ASICs do not support IPv6 while support IPv4
> - LDPv4 will work just fine while LDPv6 will have a rather a bit of
> hard time :)
Well, safe to say that if your box doesn't support IPv6, MPLSv6 is
probably the least of your
On 17/Jun/20 23:46, Tom Hill wrote:
> Unsurprisingly, there would be no way on Earth that I could have said
> that better, so you shall find only loud cheering from over here.
Out of pure curiousity, have you deployed (or are you deploying)?
Mark.
On 17/Jun/20 23:07, adamv0...@netconsultings.com wrote:
> First of all the "SR = network programmability" is BS, SR = MPLS, any
> programmability we've had for MPLS since ever works the same way for SR.
I see it the same way.
> Yes anything that works for RSVP-TE (i.e. PCEP), if you want
On 17/Jun/20 20:40, Dave Bell wrote:
> I don't understand the point of SRv6. What equipment can support IPv6
> routing, but can't support MPLS label switching?
Indeed.
Anything that can support LDPv4 today can support LDPv6, in hardware.
SRv6 and SRv6+ is a whole other issue, not to mention
On 17/Jun/20 19:38, Saku Ytti wrote:
> I don't like this, SR-MPLS and SRv6 are just utterly different things
> to me, and no answer meaningfully applies to both.
I know they are different, but that was on purpose, because even with
SR-MPLS, there are a couple of things to consider:
* IOS XR
Hi all.
When the whole SR concept was being first dreamed up, I was mildly
excited about it. But then real life happened and global deployment (be
it basic SR-MPLS or SRv6) is what it is, and I became less excited. This
was back in 2015.
All the talk about LDPv6 this and last week has had me
On 17/Jun/20 16:30, Robert Blayzor wrote:
>
> They are truly ridiculous to deal with. Turning up a new 10G dual stack
> link with BGP. At turn-up time they tell us we have to order BGP for
> IPv6 separately. So you order a circuit with IPv4+IPv6 w/ BGP, but it
> doesn't click to them you need
On 17/Jun/20 16:25, Jon Lewis wrote:
>
> The flip side of this though is that every time an IP space owner
> publishes an ROA for an aggregate IP block and overlooks the fact that
> they have customers BGP originating a subnet of the aggregate with an
> ASN not permitted by an ROA, HE has
On 16/Jun/20 14:24, adamv0...@netconsultings.com wrote:
> Actually I was exactly I that situation and v4 RFC 1918 space worked out just
> fine.
In that way, you are braver than me. But hey, if you need IPv4 and can't
get the public stuff, I won't fault you for going with the private stuff
On 17/Jun/20 10:20, Baldur Norddahl wrote:
>
>
> On Wed, Jun 17, 2020 at 10:07 AM Niels den Otter
> mailto:niels.denot...@surfnet.nl>> wrote:
>
> Hello Baldur,
>
> If you want to validate routes in a VRF you need to configure;
>
> set routing-options validation notification-rib
>
>
On 17/Jun/20 09:22, Baldur Norddahl wrote:
>
> After clearing the relevant BGP sessions the Cloudflare invalid
> prefixes are gone from our routing table and we pass the test again.
Are you running RTR to the validator for the router, or using RPKI
communities?
Mark.
On 16/Jun/20 23:26, Owen DeLong wrote:
> Count your blessings…
I know that we are lucky that in the markets we operate, local depots
are available. There are other markets in Africa that may not be so
lucky. If we ever built into those markets, we'd certainly cold spare as
much as possible,
On 16/Jun/20 22:07, Job Snijders wrote:
> Since it is with words that we construct the magic of our reality, let's
> assign a name specific to this engineering effort:
>
> Reactive RPKI ROV
> =
Reactive RPKI ROV, it is, then :-).
A great effort by HE for a network that may
On 16/Jun/20 22:43, Owen DeLong wrote:
> Covering them all under vendor contract doesn’t necessarily guarantee that
> the vendor does, either. In general, if you can cover 10% of your hardware
> failing in the same 3-day period, you’re probably not going to do much better
> with vendor
On 16/Jun/20 12:00, adamv0...@netconsultings.com wrote:
> Hence my earlier comment on why I think it's not commercially feasible to
> switch to v6 control plane,
Personally, I've never been a fan of a single-stack backbone. I can,
however, understand the use-case where a new or growing
On 16/Jun/20 08:32, Baldur Norddahl wrote:
>
> Why pay someone else for having a cold spare ready for next day
> replacement when you can have it yourself? Having a lab router to test
> config before rollout has really been a life saver.
Depends on network size. You can have multiple failures
On 14/Jun/20 20:09, Randy Bush wrote:
> charlie lynn wrote the first rpki draft in 1999. the steves
> shanghaied me in 2000. considering it took eight years for the
> ietf to change a constant of 4k to 64k, rpki/rov is moving right
> along at a swift pace.
>
> thanks to a few vendor engineers
On 15/Jun/20 12:13, adamv0...@netconsultings.com wrote:
> Not to mention this whole thread is focused solely on next-hop
> identification -which is just the lowest of the layers of abstraction
> in the vertical stack. We haven’t talked about other "entities" that
> need identification like:
On 15/Jun/20 12:13, adamv0...@netconsultings.com wrote:
> Not to mention this whole thread is focused solely on next-hop identification
> -which is just the lowest of the layers of abstraction in the vertical stack.
> We haven’t talked about other "entities" that need identification like:
On 13/Jun/20 01:32, Randy Bush wrote:
>
> we have rov in rfps received from paying customers
I hope this becomes the norm, globally.
Mark.
On 13/Jun/20 08:00, Saku Ytti wrote:
>
> ECMP appears to be your main pain point, the rich features are not
> relevant, and you mentioned commodity hardware being able to hash on
> IPIP. I feel this may be a very special case where HW can do IPIP hash
> but not MPLSIP hash. Out of curiosity,
On 12/Jun/20 17:19, David Sinn wrote:
> Yes. Path enumeration when you use mult-tier Clos topologies within a PoP
> causes you many, many problem.
Okay, got you. I thought you were running into these problems on the
"usual suspect" platforms.
Yes, commodity hardware certainly has a number
On 11/Jun/20 19:19, Saku Ytti wrote:
> The demand is, we need tunneling, then the question is what are the
> metrics of a good tunneling solution. By answering this honestly, MPLS
> is better. We could do better surely, but IP is not that.
One unexpected benefit, I will say, with going native
On 11/Jun/20 23:45, adamv0...@netconsultings.com wrote:
> Right I see what you are striving to achieve is migrate from BGP in a core to
> a BGP free core but not leveraging 6PE or 6VPE?
Yes sir.
> So considering you already had v4 FECs wouldn't it be simpler to do 6PE/6VPE,
> what do you
On 12/Jun/20 04:01, Michael Hare wrote:
> Mark (and others),
>
> I used to run loose uRPF on peering/transit links for AS3128 because I used
> to think that tightening the screws was always the "right thing to do".
>
> I instrumented at 60s granularity with vendor J uRPF drop counters on
On 11/Jun/20 17:32, David Sinn wrote:
> Respectfully, that is deployment dependent. In a traditional SP topology that
> focuses on large do everything boxes, where the topology is fairly
> point-to-point and you only have a small handful of nodes at a PoP, labels
> can be fast, cheap and
On 11/Jun/20 00:41, Job Snijders wrote:
>
> Back to basics: as Ytti suggested earlier in the thread, it might be more
> sensible to generate your own default route based on a 'stable anchor prefix'
> coming from the ISP rather than accepting the default your ISP originates
> towards you.
On 10/Jun/20 19:31, William Herrin wrote:
>
> Sorry, it'd be pre-coffee if I drank coffee and I was overly harsh
> here. Let me back up:
>
> The most basic spoofing protection is: don't accept remote packets
> pretending to be from my IP address.
>
> Strict mode URPF extends this to networks:
On 11/Jun/20 16:25, adamv0...@netconsultings.com wrote:
> Good PR might ;)
I'm old school - build something customers want to use, and the money
follows.
Care to guess how much PR Tik Tok do :-)? But I digress.
> No, my line of reasoning is if you have MPLS LSPs signalled over v4 I see no
On 11/Jun/20 16:36, adamv0...@netconsultings.com wrote:
> Case in point.
>
> On the other hand not sure if any of the customers would care whether LSPs
> are signalled over v4 as opposed to v6.
They care if your core router CPU doesn't struggle from dealing with
churning BGP routes at
On 11/Jun/20 16:28, Saku Ytti wrote:
> I'm sure we can blame Job for this, why not. But probably because of
> his lobbying some customers are _requiring_, i.e. flat out told they
> will stop accepting transit offers from providers who don't do RPKI.
As my Chad friend would say, "I like the
On 11/Jun/20 15:34, Saku Ytti wrote:
>
> Unsure of others, but we didn't implement RPKI for shit and giggles,
> we implemented it, because customers wanted us to do RPKI.
I'll be honest, none of our customers ever asked us to deploy RPKI and
ROV. Will they benefit from it, sure? Is it about
On 11/Jun/20 14:43, Gert Doering wrote:
>
> Not "in addition to" but "to throw out the IPv4 part" :-)
That's another view-point, yes.
There are plenty of networks that can't afford to keep buying IPv4 on
the open market. They want to go single-stack IPv6.
Today, you would need to build a 6PE
On 11/Jun/20 14:17, adamv0...@netconsultings.com wrote:
> Well RPKI or DNSSEC is at least adding a value, even something you can brag
> about to your customers (we are part of the solution not part of the problem
> etc...).
Bragging doesn't bring in income, it's just PR :-).
>
> But
On 11/Jun/20 13:03, Drikus Brits wrote:
> We're deploying some new POPs with a mix of IOS-XR as borders, BNG and
> PEs and IOS-XE for LNSs. LDPv6 would be awesome to have availabke on
> IOS-XE alongside LDPv4. We're being pushed by Cisco to go one flavour
> or another of SR as well by Cisco,
On 11/Jun/20 11:57, Robert Raszuk wrote:
>
> Nope that was not the main reason.
>
> Main reason was the belief that labels MUST be locally significant -
> and not domain wide unique. Just look at Juniper's SRm6 or now SRH ...
> they keep this notion of locally significant SIDs. It is deep in
On 11/Jun/20 11:58, Nick Hilliard wrote:
> Nearly impossible, apparently.
>
> It would require a change of mindset.
I'll leave that to the Coronavirus - it will open eyes.
Mark.
On 11/Jun/20 09:58, Radu-Adrian FEURDEAN wrote:
> Well, given their (Cisco's) braindead policy regarding non-implementation of
> LDPv6 on XE, no wonder people are looking for alternatives, and SRv6 is one
> of them.
Which doesn't track because there are a number of IOS XE boxes that do
not
On 11/Jun/20 10:32, adamv0...@netconsultings.com wrote:
> Hey Mark,
> My stance is that should I go with anything "new" for label distribution the
> MPLS SR/SPRING is getting to a point where it might be mature enough.
"Getting to a point" doesn't really work if you are actively running a
On 11/Jun/20 09:42, Saku Ytti wrote:
>
> I don't like to conflate these two; SR is great, SRv6 is horrible
> abomination. SR is what MPLS should have been day1, but it probably
> was easier to market LDP than to say 'we need to change all IGP
> protocols'.
Fair point.
Mark.
On 11/Jun/20 06:51, Saku Ytti wrote:
> Every HW designer
> has sighed in relief when I've said I don't care about it, because
> it's also very HW unfriendly, like IPv6 generally. Unfortunately SRv6
> is somewhat easy to market with the whole 'it's simple, just IP'
> spiel.
Mine have sighed
On 10/Jun/20 21:36, Phil Bedard wrote:
> In its simplest form without TE paths, there isn't much to SRv6. You use a
> v6 address as an endpoint and a portion of the address to specify a specific
> VPN service. You completely eliminate the label distribution protocol.
A BGPv6-free core is
On 10/Jun/20 21:20, Gert Doering wrote:
> Oh. Indeed, sorry for being unclear here.
>
> SR/MPLS sounds like a good idea (reducing label state).
>
> SR/IPv6 does not sound convincing.
+1.
2010 - 2019 has been a decade of "pushing stuff".
2020 is the year of deciding what snake oil no longer
On 10/Jun/20 21:17, Gert Doering wrote:
>
> We do have IOS XEs today (ASR920), and based on that, we're not going
> to buy new IOS XE devices any time soon.
>
> The amount of... strangeness... that this BU considers acceptable
> is... not.
It's been a week of trying to get them to see reason.
On 10/Jun/20 20:45, Saku Ytti wrote:
> I'm pretty sure that one or more of Mark, Gert or Tim are thinking
> SR/MPLS IPv6 when they say SRv6?
Oh, not at all, Saku.
> No one in their right minds thinks SRv6 is a good idea, terrible snake
> oil and waste of NRE. SR/MPLS IPv6 of course is
On 10/Jun/20 20:29, Tim Durack wrote:
> I would take either LDPv6 or SRv6 - but also need L3VPN (and now EVPN)
> re-wired to use IPv6 NH.
At the moment, LDPv6 doesn't have what I call "service" support, i.e.,
l3vpn's, l2vpn's, MPLSv6-TE, mLDP, CsC, e.t.c. To be honest, I don't
mind those so
On 10/Jun/20 20:10, Gert Doering wrote:
> To be honest, I do not think we're going to buy any IOS XE gear in the
> foreseeable future. But if we did, LDPv6 would be nice to have - to get
> rid of IPv4 in the backbone network.
We have LDPv6 working beautifully between IOS XR (6.4.2) and Junos
Hi all.
Just want to sample the room and find out if anyone here - especially
those running an LDP-based BGPv4-free core (or something close to it) -
would be interested in LDPv6, in order to achieve the same for BGPv6?
A discussion I've been having with Cisco on the matter is that they do
not
On 8/Jun/20 04:34, Brian Johnson wrote:
> I’ve seen horror stories for almost every platform from every vendor over my
> time. It usually is caused from using the wrong device for the wrong purpose.
>
> If you know its limitations, and use it with in the bounds of its
> capabilities, you will
On 7/Jun/20 00:07, Bryton Herdes wrote:
> However many less horror stories than any of the lower-ends in the ACX
> line... i.e. 1100..
Juniper are meant to be pushing out the ACX710 which is meant to be
better with Broadcom's latest chip sets.
I, generally, don't have much faith in
On 5/Jun/20 19:45, Chuck Anderson wrote:
>
> I do the above using routes to *.root-servers.net to contribute to the
> aggregate 0/0.
What about if you learn those via peering and not transit :-)?
Mark.
On 5/Jun/20 18:49, Saku Ytti wrote:
>
> The comparison isn't between full or default, the comparison is
> between static default or dynamic default. Of course with any default
> scenario there are more failure modes you cannot route around. But if
> you need default, you should not want to use
On 5/Jun/20 18:30, Michael Hare via NANOG wrote:
>
> I'm considering an approach similar to Tore's blog where at some point I keep
> the full RIB but selectively populate the FIB. Tore, care to comment on why
> you decided to filter the RIB as well?
We do this in the Metro, where FIB is
On 5/Jun/20 15:21, JASON BOTHE via NANOG wrote:
> Hi all
>
> Just curious if anyone on is using the ACX5448 and what their thoughts are on
> it.
Last time I asked, plenty of horror stories.
Check the Juniper archives.
Mark.
On 24/May/20 15:55, Tarko Tikan wrote:
>
> DDoS can be a problem in this scenario. Assuming the PEs have plenty
> of capacity available and you can afford DDoS to reach PE, then you
> would shape to customer contract speed, drop the DDoS traffic and
> would not congest your access device
On 21/May/20 21:08, Bryan Holloway wrote:
>
> * Rate-limit at the Layer 2 switch for both customer ingress/egress,
In the past, we did this on the routers, as most switches only supported
ingress policing and egress shaping, often with very tiny buffers.
Recently, some switches do now
On 19/May/20 10:31, Mukund Sivaraman wrote:
>
> (1) Check the size of your cache and ensure that it is not too small and
> that it is bound. The max-cache-size config option will limit it. In old
> versions of named, there was no limit. Current versions have an
> automatic limit. You want this
On 18/May/20 16:45, Kevin Burke wrote:
> They have an Ethernet version and GPON version.
>
> The GPON version is the same price their Ethernet version + low end GPON ONT.
>
>
> We stayed away from the GPON version for WiFi reasons. Want the techs
> thinking about a good RF location.
On 18/May/20 07:00, K MEKKAOUI wrote:
>
> Hi NANOG Community
>
>
>
> Anyone knows about a good integrated WIFI router and phone adapter
> that can be used to provide home and business internet and phone
> service. We tried couple of them but we’ve seen some instability and
> reliability issues
On 15/May/20 21:14, Gary Godard wrote:
> We had an eBGP session with them at that time but it was very
> problematic. It is strange that the IP blocks that had the issue were
> the same blocks that we advertised with them and the ones that we were
> using with Level 3 at the time were
On 15/May/20 19:13, Gary Godard wrote:
>
> We did previously have a relationship with 10 years ago in the
> Thibodaux/Hammond area.
Do you recall whether you had an eBGP session with them, or if they
originated your prefixes on your behalf behind their own AS?
>
> Not sure who resolved
On 14/May/20 22:53, Gary Godard via NANOG wrote:
> Hi,
> We are having an issue with Charter Communications advertising 2
> of our IP ranges.
> We are in the process of implementing RPKI now, but does anyone have a
> suggestion on how to get them to stop? We have tried contacting them
>
On 21/Apr/20 12:46, Randy Bush wrote:
> essentially agree. my pedantic quibble is that i would like to
> differentiate between the RPKI, which is a database, and ROV, which
> uses it.
And I think that is a very important distinction to be clear about.
Right now, it's not completely
On 20/Apr/20 20:21, Andrey Kostin wrote:
>
> So this means that there is no single source of truth for PRKI
> implementation all around the world and there are different shades,
> right? As a logical conclusion, the information provided on that page
> may be considered incorrect in terms of
On 21/Apr/20 08:51, Matt Corallo via NANOG wrote:
> Instead of RIRs coordinating address space use by keeping a public list which
> is (or should be) checked when a new peering session is added, RPKI shifts
> RIRs into the hot path of routing updates. Next time the US government
> decides
On 20/Apr/20 19:01, Andrey Kostin wrote:
> Thank you Mark, Tom and Chris for your responses that confirmed my
> "mixed feelings" about this tool.
> As a side note, I mentioned from https://bgp.he.net/AS13335#_prefixes
> that AS13335 advertises a bunch or prefixes without RoA and even one
>
On 20/Apr/20 18:50, Tom Beecher wrote:
>
> Work on a technical level, yes. But there are legal concerns in the
> ARIN region with that, some of which are spelled out here, by ACTUAL
> lawyers.
>
>
On 20/Apr/20 18:24, Tom Beecher wrote:
> Technical people need to make the business case to management for RKPI
> by laying out what it would cost to implement (equipment, resources,
> ongoing opex), and what the savings are to the company from protecting
> themselves against hijacks. By taking
On 20/Apr/20 17:31, Tom Beecher wrote:
> ( Speaking 100% for myself. )
>
> I think it was tremendously irresponsible, especially in the context
> of current events, to take a complex technical issue like this and
> frame it to the general public as a 'safety' issue.
>
> It's created articles
On 20/Apr/20 17:31, Mark Tinka wrote:
> On count two, my experience with doing the RPKI deployathon in Melbourne
> during this past APRICOT led to some random news web site talking about
> how "I would be shedding all invalid routes blah blah", which while not
> untrue,
On 20/Apr/20 16:26, adamv0...@netconsultings.com wrote:
>
> Interesting, so it is an MTU problem after all, I take it there’s no
> way to adjust the BPF (Berkeley Packet Filter) limit to let the 6020B
> sized PSNPs through?
>
Probably could - but I'd prefer solutions that don't mess with the
pr 18, 2020, at 3:08 AM, adamv0...@netconsultings.com wrote:
>>
>>
>>
>> Just shooting in the dark, Isn’t the PSNP padded to some ISIS defined
>> max MTU and that somehow fails due to mismatch on em0 L2 MTU?
>>
>>
>>
>> adam
>>
>> *From:*NAN
Hi all.
I'm almost there getting IS-IS to work without issue. I'm now faced with
the following error log:
2020/04/17 10:02:01 ISIS: IS-IS bpf: could not transmit packet on em0:
Input/output error
2020/04/17 10:02:01 ISIS: [EC 67108865] ISIS-Snp (1): Send L2 PSNP on
em0 failed
This repeats every
On 16/Apr/20 16:50, Saku Ytti wrote:
> That would be in IGP, so that'll work. The other way that some people
> do this, is that next-hop is CE, which is in iBGP, but recurses to
> loop0. There are some TE reasons why people might do this, and it
> would not work with Cisco ORR.
Reasonably
On 16/Apr/20 15:17, Chris Jones wrote:
> We’re testing ORR at the moment as part of core upgrades (XRv on ESXi), and
> next-hop self not only works, it’s required for ORR to work properly
Yes, that would be my simple 1+1, as it's all about optimizing for the
best IGP exit for far-away nodes.
On 15/Apr/20 19:07, Saku Ytti wrote:
>
> Don't run Cisco ORR RR or have IGP next-hops :/
Does it break NEXT_HOP=self in Cisco-land?
Mark.
On 15/Apr/20 17:59, Deepak Jain wrote:
> Thanks for your input. How do you handle next-hops? Tunnels between all eBGP
> speakers as if they were fully meshed as their potential next-hops?
I should imagine NEXT_HOP=self still works in an ORR world, non :-)?
Mark.
On 15/Apr/20 17:51, Deepak Jain wrote:
>
> How is this approach working for you?
It's working out beautifully, since 2014.
We wanted ORR at the time, but it was immature, so this was our only option.
Yes, it's an old school approach, but it's simple, so we don't have to
enable any trickery.
On 15/Apr/20 14:53, Tarko Tikan wrote:
>
>
> Well ISIS works with bridge but we like to keep our virtualized NFs
> simple so KVM hosts have dedicated 10G port for NFs (that connects
> directly to a metro node) and we run SR-IOV.
Got you.
Mark.
On 15/Apr/20 14:40, Tarko Tikan wrote:
>
> No, we had RR function inline on ASBRs.
>
> To be clear, our RRs are not BIRD but Nokia VSRs.
I was asking in relation to your IS-IS + SR-IOV issues.
Mark.
On 15/Apr/20 14:28, Tarko Tikan wrote:
>
> It is usable, we have taken it even a step forward:
>
> - virtualized RR
> - add-path
> - ORR
> - IGP topology to RR via BGP-LS so we don't have to extend ISIS to VMs
> (there are some issues with SR-IOV)
Awesome!
Never been a fan of Add-Path or
On 15/Apr/20 13:36, Saku Ytti wrote:
>
> ORR is not an RFC and there are some open questions. What to reflect,
> when next-hop is not in IGP? Do we hope that receiver would recurse to
> the same IGP next-hop? Juniper makes this assumption, which to me is
> decidedly the common case. Cisco
On 13/Apr/20 23:04, Bryan Holloway wrote:
>
>
> Oh, it works ... just not for anything pragmatically useful.
In 2020, no less.
Can't recall the last time I used this feature, even if it's one we
offer for BGP communities we accept from customers.
Admittedly, I don't think of any of them
So the South African president has just extended our lockdown by another
2 weeks, to run until the end of April.
We expect network operations to remain an essential service, so if any
of you have any infrastructure down here, keep doing what you're doing.
Mark.
On 9/Apr/20 19:27, Randy Bush wrote:
>
> i think i will add those last prefixes to my filters. will shut some of
> the mailing list noise down. :)
:-).
Mark.
On 9/Apr/20 15:24, Tom Hill wrote:
> Short answer: filter 100.64.0.0/10 from your upstreams, as you would
> 192.168.0.0/16 or 10.0.0.0/8.
I was trying to remind myself what we did back in the day. Looks like
that's been in on our end for yonks:
tinka@all.boxes-re0# show firewall family inet
1201 - 1300 of 2587 matches
Mail list logo
