❦ 2 octobre 2018 23:07 +0200, Mark Tinka :
>> Dunno with IS-IS, but with BGP, BFD is advertised as control plane
>> independent when using public IPv6 addresses. However, I've just noticed
>> that when using an IRB, BFD is handled by the control plane, both for
>> IPv6 and IPv4.
>
> It's clear
On 2/Oct/18 23:01, Vincent Bernat wrote:
> Dunno with IS-IS, but with BGP, BFD is advertised as control plane
> independent when using public IPv6 addresses. However, I've just noticed
> that when using an IRB, BFD is handled by the control plane, both for
> IPv6 and IPv4.
It's clear that
On 2/Oct/18 23:01, Vincent Bernat wrote:
> Dunno with IS-IS, but with BGP, BFD is advertised as control plane
> independent when using public IPv6 addresses. However, I've just noticed
> that when using an IRB, BFD is handled by the control plane, both for
> IPv6 and IPv4.
It's clearly that
❦ 2 octobre 2018 20:13 +0100, James Bensley :
>> > Not exactly your scenario but we had the same problems with eBGP with
>> > IPv6 link-local addresses on QFX10K platform.
>> > Dev Team had replied that rather than hardware limitation it's more of
>> > a "design decision" to not distribute IPv6
On 2/Oct/18 21:13, James Bensley wrote:
> I presume that if one were to run MT-ISIS there would be no impact to IPv4?
We already run MT for IS-IS. I consider this as basic a requirement as
"Wide Metrics".
However, the issue here is BFD sees the whole of IS-IS as a client. So
if BFD has a
There is no such product as an MX9K. Is your product some form of MX or an
EX9200 of some type?
In either case would need to know which exact modules within the MX or EX
product you are using or are involved.
When using the CAT6K was the edge QFX5100 previously as well? I assume QFX5100
is
On Tue, 2 Oct 2018 at 19:59, james list wrote:
>
> Can you elaborate?
> Why just every 30 minutes the issue?
Seeing as you have an all Juniper set up I don't think there is a need
to cross-post to two lists simultaneously. If you feel there is a
need, please post to the two lists separately as
On Tue, 2 Oct 2018 at 16:39, Mark Tinka wrote:
> The real-world problem we are seeing is when, for whatever reason, the
> RE CPU spikes and BFD for IPv6 sneezes, we also lose IPv4 because, well,
> IS-IS integrates both IP protocols.
I presume that if one were to run MT-ISIS there would be no
Can you elaborate?
Why just every 30 minutes the issue?
Il Mar 2 Ott 2018, 20:34 Tom Beecher ha scritto:
> You have switches with completely different buffer depths than you used
> to. You prob want to look into that.
>
> On Tue, Oct 2, 2018 at 9:39 AM james list wrote:
>
>> Dear experts
>>
>>
Hi,
On Tue, Oct 02, 2018 at 05:39:06PM +0200, Mark Tinka wrote:
> On 2/Oct/18 17:05, Gert Doering wrote:
>
> > "nobody is using this for real, so just make sure we can tick the
> > marks on the customers' shopping lists"
>
> The real-world problem we are seeing is when, for whatever reason, the
You have switches with completely different buffer depths than you used to.
You prob want to look into that.
On Tue, Oct 2, 2018 at 9:39 AM james list wrote:
> Dear experts
>
> I’ve a strange issue.
>
> Our customer replaced two L2/3 switches (C6500) where a pure L2 and L3
> (hsrp) environment
Dear experts
I’ve a strange issue.
Our customer replaced two L2/3 switches (C6500) where a pure L2 and L3
(hsrp) environment was set-up with a couple of new MX9k running the same L2
and L3 services but those two MX are running MPLS/VPLS to transport L3/L2
frames. Access switches are QFX5k
I think the answer would depend upon feature set you might want to use, or
specific hardware. If neither of these matter, I think 16.2R2-S6 is probably
safest choice. If you need newer feature/functions, I might suggest 18.1R3.
Good luck, and no promises!
Rich
On 10/2/18, 11:44 AM, "Matthew
Hello,
I'm running an Enhanced MX480 Midplane with RE-S-2X00x6 and Enhanced MX SCB 2
with MPC3E NG PQ & Flex Q & MPC7E 3D MRATE-12xQSFPP-XGE-XLGE-CGE cards.
Currently running : Junos: 15.1F7.3 it appears stable but I don't' have it in
production yet and want to upgrade if needed before it
On 2/Oct/18 17:05, Gert Doering wrote:
> "nobody is using this for real, so just make sure we can tick the
> marks on the customers' shopping lists"
The real-world problem we are seeing is when, for whatever reason, the
RE CPU spikes and BFD for IPv6 sneezes, we also lose IPv4 because, well,
Hi,
On Tue, Oct 02, 2018 at 03:37:15PM +0200, Mark Tinka wrote:
> Definitely makes the case for anyone that says IPv6 is not as ready as
> IPv4... did Juniper elaborate what "design decision" actually means?
"nobody is using this for real, so just make sure we can tick the
marks on the
On 2/Oct/18 15:38, adamv0...@netconsultings.com wrote:
> Hi folks,
>
> I'm glad the thread spun up an interesting discussion but my original
> question was more around why would anyone prefer IntServ to DiffServ in an
> RSVP-TE environment.
> Personally I prefer RSVP-TE solely for TE
Hi folks,
I'm glad the thread spun up an interesting discussion but my original
question was more around why would anyone prefer IntServ to DiffServ in an
RSVP-TE environment.
Personally I prefer RSVP-TE solely for TE purposes and QoS for QoS purposes,
but there are always compromises if you
On 2/Oct/18 15:30, Виталий Венгловский wrote:
> Mark,
>
> Not exactly your scenario but we had the same problems with eBGP with
> IPv6 link-local addresses on QFX10K platform.
> Dev Team had replied that rather than hardware limitation it's more of
> a "design decision" to not distribute IPv6
On Tue, 2 Oct 2018 at 14:03, Tim Cooper wrote:
> The QoS obligations has been pretty much cut/paste from PSN into HSCN
> obligations, if you haven’t come across that yet. So look forward to that...
> ;)
>
> Tim C
Unfortunately yes
James.
___
> On 2 Oct 2018, at 11:24, James Bensley wrote:
>
>> On Tue, 2 Oct 2018 at 10:57, Mark Tinka wrote:
>> I've never quite understood it when customers ask for 8 or even 16 classes.
>> When it comes down to it, I've not been able to distill the queues to more
>> than 3. Simply put, High,
On 2/Oct/18 14:49, Saku Ytti wrote:
> No is saying you must do that. What I'm trying to say, if you already
> do overlay QoS, then retaining DSCP should be best practice. If you
> cannot do overlay QoS, then of course you must reset.
Fair point.
In my case, I map all DSCP values used on
Hi all.
I've been going back & forth with JTAC on this, and they seem a bit lost.
Does anyone know whether BFD for IPv6 (IS-IS) is supported in the PFE on
the MX?
On the router, it clearly isn't:
*
Destination: aaa.bb.cc.2, Protocol: BFD, Transmission interval: 2000
*Distributed: TRUE*,
On Tue, 2 Oct 2018 at 15:36, Mark Tinka wrote:
> In order to do UHP, a network has to run MPLS, and support it up to final
> edge where IP/MPLS services are delivered. I know dozens of networks that
> will never run MPLS as a matter of principle, and these are not small
> networks on a global
On 2/Oct/18 14:25, adamv0...@netconsultings.com wrote:
> Mark, it's a simple premise based on live and let live.
>
> MPLS enabled core network allows operators to treat the traffic the way they
> want regardless of what QOS markings the traffic is arriving with at the AS
> borders.
> You
On 2/Oct/18 13:21, Alexandre Snarskii wrote:
> Retaining DSCP in juniper networks leads to consequence of not showing
> egress router in traceroute. Well, it's quite easy to classify packet
> on ingress (based on interface), and it's quite easy to mark packet
> with MPLS EXP and use this
On Tue, 2 Oct 2018 at 14:22, Alexandre Snarskii wrote:
> marking to [mis]classify packet. Of course, you can use ultimate-hop
> popping (explicit-null) so MPLS EXP can be used at egress router too,
> but in this case egress router will not decrement ip ttl and generate
> icmp unreachable/ttl
> Of Mark Tinka
> Sent: Tuesday, October 02, 2018 11:56 AM
>
>
>
> On 2/Oct/18 12:48, Saku Ytti wrote:
>
> > You tell to them DSCP values do not affect forwarding or queueing
> > behaviour in your network.
>
> If only the whole Internet was ran by just one AS.
>
Mark, it's a simple premise
On 2/Oct/18 13:03, Saku Ytti wrote:
> You continue to miss the point. You brought antispoofing as an
> example, it's same thing, not everyone needs to do the right thing,
> anyone changing is better. And as I pointed out, the discussion isn't
> even 'how widely it works, if it doesn't work
On 02/10/18 20:26, Saku Ytti wrote:
> On Tue, 2 Oct 2018 at 13:21, Julien Goodwin wrote:
>
>> The trouble is, some providers might use a bit to mean something like
>> "prefer cheap EU paths" for Asia->AU traffic, leaving it set then causes
>> hundreds of milliseconds of latency. Some might
On Tue, Oct 02, 2018 at 01:10:14PM +0300, Saku Ytti wrote:
> Hey Mark,
>
> > We remark all incoming Internet traffic DSCP values to 0.
> >
> > A few years ago, not doing this led to issues where customers were
> > handling the DSCP values in such a way that any traffic marked as
> > such was
On Tue, 2 Oct 2018 at 13:56, Mark Tinka wrote:
> If only the whole Internet was ran by just one AS.
You continue to miss the point. You brought antispoofing as an
example, it's same thing, not everyone needs to do the right thing,
anyone changing is better. And as I pointed out, the discussion
On 2/Oct/18 12:47, Saku Ytti wrote:
> I think this is wrong thing to focus on. Should we focus on 'will it
> work now universally' or should we focus on 'should we strive it to
> work'.
>
> I feel like you're saying 'because it does not work universally, we
> shouldn't try to ensure it works'.
On Tue, 2 Oct 2018 at 13:45, Mark Tinka wrote:
> So when my customer says to me... "I sent DSCP=46 to Yahoo, but I think my
> Yahoo is still not faster?", what do I tell them?
>
> Or, when customer says to me... "I sent DSCP=3 from my office in Nairobi to
> my office in Perth, but the Perth
On Tue, 2 Oct 2018 at 13:43, Mark Tinka wrote:
> In theory, the Internet needs to just pass those bits. But in practice, can
> you actually expect any guarantee of that when those SSH packets are
> traveling from Taipei, to Hong Kong, to Beijing, to Moscow, to Kiev, to
> Frankfurt, to London,
On 2/Oct/18 12:37, Saku Ytti wrote:
> I'm not proposing any global agreement on DSCP, I'm proposing passing
> them as-is so when there is same instance in ingress and egress, they
> can do with them what they want.
So when my customer says to me... "I sent DSCP=46 to Yahoo, but I think
my
On 2/Oct/18 12:31, Saku Ytti wrote:
> This is not the point here, the point is are you guaranteeing
> something with the DSCP. The point is opposite, if you can avoid
> caring or acting on them, then you do not need to change them.
The implementation is irrelevant. Whether I use DSCP, IPP,
On Tue, 2 Oct 2018 at 13:33, Mark Tinka wrote:
> So what is easier to fix? Agreeing on a global standard for what DSCP values
> to use in our own internal networks?
I'm not proposing any global agreement on DSCP, I'm proposing passing
them as-is so when there is same instance in ingress and
On 2/Oct/18 12:26, Saku Ytti wrote:
> I don't think so, If they use DSCP values as-is, then they MUST
> nullify them. Full and short pipe assume you use MPLS TC for internal
> decision, at which point you don't need to care or trust DSCP. If you
> use DSCP internally _AND_ trust Internet DSCP,
On Tue, 2 Oct 2018 at 13:23, Mark Tinka wrote:
> Since we cannot guarantee the end-to-end quality of off-net traffic, it does
> not make sense to have any DSCP values for Internet traffic other than 0.
> Because even though I might not remark it, I can't guarantee that my peers,
> transit
On 2/Oct/18 12:24, James Bensley wrote:
> I'm not saying I agree with this 8 classes - just stating what it was
> :) I also agree that most people genuinely don't need more than 3-4.
> We often "helped" (nudged) customers to design their traffic into just
> a few classes.
>
> Here in the land
On Tue, 2 Oct 2018 at 11:23, Mark Tinka wrote:
> If you are a large network (such as yourselves, Saku) where it's very likely
> that the majority your customers are talking to each other directly across
> your backbone, then I could see the case. But when you have customers
> transiting
On Tue, 2 Oct 2018 at 13:21, Julien Goodwin wrote:
> The trouble is, some providers might use a bit to mean something like
> "prefer cheap EU paths" for Asia->AU traffic, leaving it set then causes
> hundreds of milliseconds of latency. Some might even implement VPNs that
> way causing
On Tue, 2 Oct 2018 at 10:57, Mark Tinka wrote:
> I've never quite understood it when customers ask for 8 or even 16 classes.
> When it comes down to it, I've not been able to distill the queues to more
> than 3. Simply put, High, Medium and Low. The 4th queue is for the network
> itself.
I'm
On 2/Oct/18 12:21, Julien Goodwin wrote:
> The trouble is, some providers might use a bit to mean something like
> "prefer cheap EU paths" for Asia->AU traffic, leaving it set then causes
> hundreds of milliseconds of latency. Some might even implement VPNs that
> way causing blackholing.
>
>
On 02/10/18 20:10, Saku Ytti wrote:
> Hey Mark,
>
>> We remark all incoming Internet traffic DSCP values to 0.
>>
>> A few years ago, not doing this led to issues where customers were handling
>> the DSCP values in such a way that any traffic marked as such was being
>> dropped. Took weeks
On Tue, 2 Oct 2018 at 10:10, Saku Ytti wrote:
>
> Hey James,
Hi Saku
> > Yeah so not already using RSVP means that we're not going to deploy it
> > just to deploy an IntServ QoS model. We also use DSCP and scrub it off
> > of dirty Internet packets.
>
> Have you considered full or short pipe?
Hey Mark,
> We remark all incoming Internet traffic DSCP values to 0.
>
> A few years ago, not doing this led to issues where customers were handling
> the DSCP values in such a way that any traffic marked as such was being
> dropped. Took weeks to troubleshoot.
Dropped by who? I as an
On 2/Oct/18 11:10, Saku Ytti wrote:
> Have you considered full or short pipe? It would be nice if we'd
> transport DSCP bits as-is, when we don't have to care about them.
> Far-ends may be able to utilise them for improved UX if we don't strip
> them.
We remark all incoming Internet traffic
On 2/Oct/18 10:21, James Bensley wrote:
> Yeah so not already using RSVP means that we're not going to deploy it
> just to deploy an IntServ QoS model. We also use DSCP and scrub it off
> of dirty Internet packets.
>
> Like with many things, it depends on your requirements. Having worked
> for
Hey James,
> Yeah so not already using RSVP means that we're not going to deploy it
> just to deploy an IntServ QoS model. We also use DSCP and scrub it off
> of dirty Internet packets.
Have you considered full or short pipe? It would be nice if we'd
transport DSCP bits as-is, when we don't have
> On 1/Oct/18 12:16, adamv0...@netconsultings.com wrote:
>
> > Hi folks,
Hi Adam,
On Mon, 1 Oct 2018 at 12:00, Mark Tinka wrote:
>
> So we don't do any label signaling via RSVP-TE at all.
>
> We use DSCP, but really only for on-net traffic.
>
> Off-net traffic (like the Internet) is really
52 matches
Mail list logo
