Hi all,
I an IOS fellow and my Junos fu is sub-par, so I need some help;
We have some new junipers in the lab, some MX80's we're going to be
bringing up peering on in the near future. Can anybody share with me
(on or off list) some configuration templates for setting up prefix
filters such as max
Thanks everyone for your on and off list replies, everyone's help has
been greatly appreciated.
This is the configuration I have come up with [1].
If anyone has any further input on this I'm all ears.
Kind regards,
James.
[1] http://paste.org/flat/68022
_
I have never used such a configuration but I can't understand from
look at this how it would possible work? Having the same inner and
outer tag means there is no way to differentiate between the incoming
frames. How did you imagine that would work?
Cheers,
James.
__
On 20 July 2014 18:47, wrote:
> Regarding the comment in a different reply, "Having the same inner and
> outer tag means there is no way to differentiate between the incoming
> frames" - I'm afraid I don't see the problem. You lookup the outer
> VLAN tag and then you lookup the inner VLAN tag.
W
On 28 March 2018 at 11:55, Pierre Emeriaud wrote:
> Gents,
>
> I just noticed an issue on a couple of option B gateways in our
> network. The max-prefix within routing-instances is not enforced. It's
> although taken into account.
>
> This is on M120 running 12.3R6-S3 (yes I know, ancient. No, can
On 11 April 2018 at 10:31, Saku Ytti wrote:
> New RE for MX104 was on the table early on in the MX104 history, but
> then JNPR changed tracks, citing XEON not being thermally possible on
> it.
I had heard (more or less from the horses mouth) that the MX104's were
initially developed for an Indian
>>> On 11 April 2018 at 13:43, Ola Thoresen wrote:
>>> Granted at least JNPR offering allows you to run same device as pure
>>> L2, with Cisco offering it is satellite-only box, cannot be used as
>>> L2.
>>
>> I know what you mean, but I must say that this time it seems like they have
>> more or
On 16 April 2018 at 20:58, Aaron Gould wrote:
> See juniper interface MTU is set to max 16000 bytes. but when I ping I can
> only get 9584 bytes through to the other side of the link. This mx960 is
> linked to another mx960, but Ciena 6500 dwdm is in between the mx960's.
Hi Aaron,
I think MTU c
On 17 April 2018 at 11:57, Gert Doering wrote:
> Hi,
>
> On Tue, Apr 17, 2018 at 12:34:18PM +0300, Saku Ytti wrote:
>> On 17 April 2018 at 11:25, James Bensley wrote:
>>
>> > Also you say you have OSPF and LDP up but if you bring up BGP over
>> > this lin
On 1 May 2018 at 17:07, A. Camci wrote:
> does anyone have an idea why it does not work on Acx( vrf+ vrrp).
>
> Br ap
How have you tried to debug this set up?
>From your original em ail:"maybe vrf+vrrpdoesnt work on a ACX." - Have
you confirmed this, are you trying something that isn't
supported
Hi Arie,
On 1 May 2018 at 23:21, Arie Vayner wrote:
> user@MX104> show route table mpls.0
> 16 *[VPN/0] 00:25:28
> to table vpn_public_vrf.inet.0, Pop
>
>
> While if we do the same on our MX240 it looks like this:
> 18 *[VPN/0] 4d 21:24:17
>
Hi All,
Does anyone know of a command like the Cisco CEF "exact-route" command
on Juniper?
I've seen this older thread: https://lists.gt.net/nsp/juniper/50645
Which links to a post on using JSIM but for DPC cards, but I'm
interested in MPC cards:
http://junosandme.net/article-junos-load-balancin
On 15 May 2018 at 02:51, Nikolas Geyer wrote:
> Someone at Juniper has kindly reached out and advised that a similar command
> was added in 17.1R1 for the MX;
>
> https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/show-forwarding-options-load-balance-ingress-interf
On 15 May 2018 at 10:20, Zsolt Hegyi wrote:
> In case you haven't read it yet, there is a free book called This Week: An
> Expert Packet Walkthrough on the MX Series 3D by David Roy, it has a bunch
> of examples on using jsim and other FPC/PFE commands, including what I think
> might be your exact
y,
> One can use [ location node-id ] with the above commands to instruct the
> simulation what hash function to use in an environment with multiple NPU
> versions (Trident, Typhoon, Tomahawk, etc...).
>
> Oh and there's a bug as well, CSCug36061 (affected 4.2.3. and 4.3.2)
As p
On 31 May 2018 at 18:04, Chris Adams wrote:
> I had an MX80 crash (insert sad face here) - worse problem was that it
> did a crash dump and then did NOT reboot. I have out-of-band serial
> access to the console, so I could see that, after the dump completed, it
> just printed:
>
> watchdog: sched
On 4 June 2018 at 13:46, Martin T wrote:
> Hi!
Hi!
> When I deploy a vMX using orchestration scripts, then I end up with
> following virtualized topology:
>
> https://i.imgur.com/bBTXGM0.png
>
> Now when I execute "file copy root@192.168.122.1:/tmp/1G_file
> /dev/zero" in vMX, then I can see tha
On 21 June 2018 at 15:09, Chris Adams wrote:
> I'm testing some BGP policy changes, and I'm running into an odd thing.
> There are some routes that I don't want to export in general, but I do
> want to send them to a couple of specific eBGP neighbors. For these
> routes, I've got an import policy
On 29 June 2018 at 13:55, Gert Doering wrote:
> Hi,
>
> On Fri, Jun 29, 2018 at 01:49:46PM +0100, adamv0...@netconsultings.com wrote:
>> Just wondering what's the latest on the GPU for packet forwarding front (or
>> is that deemed legacy now)?
>
> Last I've heard is that pixel shaders do not map
On 4 July 2018 at 10:09, Mark Tinka wrote:
>
>
> On 4/Jul/18 10:58, Niall Donaghy wrote:
>> Hi Mark,
>>
>> As for segment routing, several of our NREN partners have SR up and running
>> in their backbones.
>> We in GÉANT (the backbone that connects these NRENs) are looking toward
>> deploying SR
On 4 July 2018 at 17:09, James Bensley wrote:
> On 4 July 2018 at 10:09, Mark Tinka wrote:
>>
>>
>> On 4/Jul/18 10:58, Niall Donaghy wrote:
>>> Hi Mark,
>>>
>>> As for segment routing, several of our NREN partners have SR up and running
>>&g
On 4 July 2018 at 22:25, Aaron Gould wrote:
> I'm concerned how to go from my LDP environment to SR/SPRING and what if some
> of my gear doesn't support SR/SPRING ? Is this LDP/SR mapping thing easy ?
>
>
> Aaron
Hi Aaron,
I think you're running Cisco gear too right so hopefully it's OK if I
s
On 4 July 2018 at 18:13, Mark Tinka wrote:
>
>
> On 4/Jul/18 18:28, James Bensley wrote:
>
> Also
>
> Clarence Filsfils from Cisco lists some of their customers who are
> happy to be publicly named as running SR:
>
> https://www.youtube.com/watch?v=NJxtvNs
On 5 July 2018 14:08:02 BST, Aaron Gould wrote:
>I really like the simplicity of my ldp-based l2vpn's... eline and elan
>
>You just made me realize how that would change if I turned off ldp.
>
>So, SR isn't able to signal those l2circuits, and manual vpls instances
>?
>... I would have to do a
On 5 July 2018 09:56:40 BST, adamv0...@netconsultings.com wrote:
>> Of James Bensley
>> Sent: Thursday, July 05, 2018 9:15 AM
>>
>> - 100% rFLA coverage: TI-LA covers the "black spots" we currently
>have.
>>
>Yeah that's an interesting use c
On 5 July 2018 at 09:40, Mark Tinka wrote:
>
> In our case, we have different boxes from Cisco, each with varying support
> for SR. This makes things very tricky, and then we need to also throw in our
> Juniper gear. For me, the potential pain isn't worth the hassle, as we are
> not suffering in a
On 8 July 2018 21:35:36 BST, adamv0...@netconsultings.com wrote:
>Hold on gents,
>You are still talking about multi-hop TCP sessions, right? Sessions
>that
>carry information that is ephemeral to the underlying transport network
>-why
>would you want those session ever go down as a result of anythi
Hi All,
Has anyone used Egress Protection/Service Mirroring, anyone got any
stories they can share good or bad?
To clarify, I'm talking about:
https://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-03
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/Ed
On 15 July 2018 at 12:47, Saku Ytti wrote:
> On Sun, 15 Jul 2018 at 13:12, wrote:
Hi Saku, Adam,
>> > a) If P2->PE2 goes down, we have to wait for PE1 to experience it, after
>> PE1
>> > experiences it, it can immediately redirect to PE3
>> > b) If PE2->CE2 goes down, PE2 should be able to red
On 15 July 2018 at 11:12, wrote:
> @James is on my todo list so maybe we can exchange notes, (I plan on using
> it in RSVP-TE environment so the added complexity will be only marginal).
> Yes I've been waiting for this feature for quite some time in cisco (got
> promises that maybe on SR) -maybe
On 15 July 2018 at 19:20, Krzysztof Szarkowicz wrote:
...
>>> https://pc.nanog.org/static/published/meetings/NANOG71/1451/20171004_Szarkowicz_Fast_Egress_Protection_v1.pdf
>>> https://www.youtube.com/watch?v=MoZn4qq3FcU&index=69&t=0s&list=UUIvcN8QNgRGNW9osYLGsjQQ
...
>> I was originally refering t
Hi All,
Like my other post about Egress Protection on Juniper, is anyone using
what Juniper call "Longest Match for LDP" - their implementation of
RFC5283 LDP Extension for Inter-Area Label Switched Paths (LSPs) ?
The Juniper documentation is available here:
https://www.juniper.net/documentation
On 24 July 2018 at 14:35, wrote:
> Hi James
Hi Adam,
> Suppose I have ABR advertising default-route + label down to a stub area,
> And suppose PE-3 in this stub area wants to send packets to PE1 and PE2 in
> area 0 or some other area.
> Now I guess the whole purpose of "Longest Match for LDP"
Hi Krasimir, Krzysztof,
On 24 July 2018 at 17:25, Krasimir Avramski wrote:
> It is used in Access Nodes(default route to AGN) with
> LDP-DOD(Downstream-on-Demand) Seamless MPLS architectures - RFC7032
> A sample with LDP->BGP-LU redistribution on AGN is here.
Thanks Krasimir. Sorry for the delay
actly my point:
> On Mon, Jul 30, 2018, 11:15 James Bensley wrote:
>> unless we create horrible per-LDP
>> neighbour policies on the agg node that only allow the labels for the
>> exact loopbacks that access node needs to reach.
Cheers,
James.
_
On 31 July 2018 at 15:29, wrote:
> One follow up question,
> What about the case, where the minimum set of /32 loopback routes and
> associated labels is simply beyond the capabilities of an access node.
> Is there a possibility for such access node to rely on default route + label
> -where ori
Hi Aaron,
I'm not 100% what you're asking here. Opaque LSAs are used in SR to
advertise the SID for a prefix/node/adj within the IGP:
https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-25
Cheers,
James.
___
juniper-nsp mailing list
On Tue, 4 Sep 2018 at 01:33, Jason Taranto wrote:
>
> Hi All,
>
> After a while of my head colliding with the wall beside me, would anyone know
> how to get a variable into an rpc command via pyez.
>
> My latest attempt is below.
>
> r2check = raw_input("Route to check e.g XXX.XXX.XXX.XXX : ")
On Wed, 12 Sep 2018 at 13:17, Matthew Crocker wrote:
>
>
> Hello,
>
> I’m turning up some peering in New York in the coming weeks (NYIIX, DE-CIX)
> and will need to configure several hundred BGP sessions. Is there an easy
> (open source) way of managing the BGP sessions & generating automatic
Hi All,
Have anyone used this feature, did it actually help you pin-point the
source of an IGP issue?
https://www.juniper.net/documentation/en_US/junos/topics/concept/isis-poi-tlv-overview.html
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/purge-origi
On Mon, 1 Oct 2018 at 06:49, tim tiriche wrote:
>
> hello,
>
> i have 5 PE routers running with full iBGP/RSVP-TE MPLS Mesh.
>
> There is a CE connected to PE5 and PE4.
>
> Based on BGP Path selection all of the PE {1,2,3,4} are preferring route to
> PE5 due to BGP Path selection based on AS PATH
On Fri, 28 Sep 2018 at 11:48, Saku Ytti wrote:
>
> Hey James,
>
> In this failure mode this feature would help to find the rogue ISIS
> speaker, so looks sensible feature to me, even when very partial
> support it will limit limit the domain where the suspect exists. I've
> personally not used it,
> 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 treat
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? It
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 n
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 multipl
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.
___
juniper
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 impa
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 no
On Tue, 2 Oct 2018 at 21:46, Mark Tinka wrote:
> 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"
On Tue, 2 Oct 2018 at 15:11, Mark Tinka wrote:
> Of course, in the real world,
> it was soon obvious that your Windows laptop or your iPhone XS sending
> RSVP messages to the network will not scale well.
A point I was trying to make way back in this thread, was that IntServ
doesn't scale well for
On Wed, 3 Oct 2018 at 10:13, Mark Tinka wrote:
> On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote:
>
> If you'd have separate ISIS process for v6 would it be possible to spin up a
> separate/dedicated BFD process for that ISIS?
Unless I'm mistaken BFD isn't "multi-tenant", so only one set of
On 4 October 2018 19:34:01 BST, james list wrote:
>Due to the fact that access switch are QFX5100 in virtual chassis, does
>anybody know if IS-IS managing virtual- chassis has something happening
>every 30 minutes which could cause delay?
>
>Cheers
As per my previous message, you should see su
On 17 October 2018 20:53:44 CEST, Colton Conor wrote:
>I was wondering if Juniper supports anything like fq-codel to prevent
>buffer bloat? Specifically we would like to do rate shaping and
>subscriber
>management on core Juniper MX's. However, most network devices do
>simple
>buffers and queui
have occurred in the first place.
Taking this full circle - fq-codel is aimed at addressing bufferbloat,
not congested up-links on the devices in your network, please note
that these are two seperate problems. A port/link/line card upgrade
fixes the congested core/backhaul link problem.
On Thu, 18
On Thu, 18 Oct 2018 at 10:36, Benny Lyne Amorsen
wrote:
>
> James Bensley writes:
>
> > If customers have WAN links that are slower than their LAN links -
> > that is where fq-codel was designed to be implemented and that is why
> > it should be implemented on the CPE
On Thu, 18 Oct 2018 at 16:00, Benny Lyne Amorsen
wrote:
>
> The CPE can't do anything if a large flow fills up the pipe.
You have fully missed my point.
> It cannot work reliably if there is WAN-side congestion, which makes it
> less useful for cable or (non-point-to-point) wireless networks.
W
On Wed, 7 Nov 2018 at 13:03, Antti Ristimäki wrote:
> Wrt the original question about possible issues with Fusion, we have faced
> quite a many. Currently one of the biggest pains is to get CoS configured
> properly on Fusion ports. We have a case open, where any CoS scheduler change
> stops tr
On 8 November 2018 14:23:02 GMT, Tarko Tikan wrote:
>hey,
>
>> There is
>> nothing wrong with layer 2 aggregation switches in my opinion, the
>> only technical advantage in my opinion to using SP Fusion for a layer
>> 1 extension to a router compared to a layer 2 switch is that SP
>Fusion
>> is
On 30 December 2018 18:12:43 CET, Aaron1 wrote:
>With vMX I understand that as more performance is needed, more vcpu,
>network card(s) and memory are needed. As you scale up, a single vcpu
>is still used for control plane, any additional vcpu‘s are used for
>forwarding plane. The assignment of
On 30 December 2018 18:40:50 CET, James Bensley wrote:
> Text with lots of typos
^ Sorry about that, on a mobile.
>I often make notes and never get around to publishing them online
>anywhere. Nearly 2 Yeats ago (where did the time go?) I was testing
>CRS1000v performance. Thi
On 30 December 2018 21:54:17 CET, Robert Hass wrote:
...
>My confusion is related to HT setting, as you wrote to disable it.
>
>But vMX Getting Started Guide for KVM says:
>
>"CPU pinning with flow caching enabled (performance mode) is different
>than
>with flow
>caching disabled (lite mode). F
On Mon, 21 Jan 2019 at 20:09, Jason Lixfeld wrote:
>
> Hi all,
>
> I’m doing some RFC2544 tests through an MX204. The tester is connected to
> et-0/0/2, and the test destination is somewhere out there via et-0/0/0. 64
> byte packets seem to be getting dropped, and I’m trying to find where on t
On Wed, 16 Jan 2019 at 15:06, Event Script wrote:
>
> In the process of adding 100G, LAGs with multiple 100G, and to be prepared
> for 400G, looking for feedback on setting ospf reference-bandwidth to 1T.
>
> Please let me know if you have had any issues with this, or if it has been
> a smooth tra
On Thu, 17 Jan 2019 at 18:09, Saku Ytti wrote:
> It boggles my mind which network has _common case_ where
> bandwidth is most indicative of best SPT.
Hi Saku,
I've worked on several small networks where you don't have equal
bandwidth links in the network. I don't mean U/ECMP, I mean a ring
topol
TLDR; metrics aren't a purely design/academic decision, they are
operational too.
On Thu, 24 Jan 2019 at 09:27, Saku Ytti wrote:
> I don't disagree, I just disagree that there are common case where
> bandwidth is most indicative of good SPT.
If by "good" you mean "shortest" (least number of hops
On Thu, 25 Apr 2019 at 08:49, Tarko Tikan wrote:
>
> hey,
>
> > Please let me know if anything was unclear or if someone has other
> > ideas or theories.
>
> Been following this thread and do not have anything to contribute at
> this point but wanted to say I (and I hope many others) appreciate th
On Sat, 24 Aug 2019 at 10:06, Saku Ytti wrote:
Hi Saku,
> Has anyone ran into a set of flows where ostensibly you have enough
> entropy to balance fairly, but you end up seeing significant imbalance
> anyhow? Can you share the story? What platform? How did you
> troubleshoot? How did you fix?
N
On Wed, 28 Aug 2019 at 08:21, Saku Ytti wrote:
> I've had two issues where I cannot explain why there is imbalance. One
> in MX2020 another in PTX. I can't find any elephant flows in netflow,
> but I can find traffic grouped around with modest amount of IP address
> entropy (like 20-32 SADDR + 20-
On Wed, 28 Aug 2019 at 08:21, Saku Ytti wrote:
> SRC: (single 100GE interface, single unit 0)
> 23.A.B.20 .. 23.A.B.46
> TCP/80
> DST: (N*10GE LACP)
> 157.C.D.20 .. 157.C.D.35
> TCP 2074..65470 (RANDOM, this alone, everything else static, should
> have guaranteed fair balancing)
>
> I'm ru
On Mon, 21 Dec 2020 at 09:56, Mark Tees wrote:
>
> Hello
>
> I remember when I originally got my mittens on VMX there was a boot
> flag to tell it to use an integrated FPC or integrated RIOT without a
> separate VM running forwarding. I can't find my notes on that.
>
> Does anyone know if that's s
On 14 July 2015 at 16:13, Aaron wrote:
> Thanks everyone for your input.
>
>
>
> Does the mx80 support all the mpls L3vpn and L2vpn things I mentioned ?
It does do all this:
> I'm needing more 10 gig ports in my CO's for purposes of upgrading my FTTH
> OLT shelves with 10 gig. I currently use
Hi Mohammad,
I think you are looking for the following commands on your Cisco
device (if I have understood the problem correctly),
IOS:
interface x/y/z
mpls ldp discovery transport-address interface
IOS-XR:
mpls ldp
vrf ABC123
interface GigabitEthernet0/0/0/1
address-family ipv4
disco
On 31 July 2015 at 11:41, Marcin Kurek wrote:
> Hello,
>
> I'm doing some interoperability tests between Cisco and Juniper routers and
> I wanted to ask about a particular piece of config.
> I would expect that it shouldn't work, but it works perfectly, so I'm a bit
> confused.
>
> There is a l2vp
iving them so I'm just trying to get some directly
connected return routes back from PE2 via RR to PE1.
Many thanks,
James.
bensley@RR1> show configuration protocols bgp group Core-MX480
type internal;
local-address RR1.Lo0.IP.165;
family inet {
unicast;
}
family inet-vpn {
unic
On 1 December 2015 at 17:29, Stepan Kucherenko wrote:
> My biggest gripe with ASR9k (or IOS XR in particular) is that Cisco stopped
> grouping BGP prefixes in one update if they have same attributes so it's one
> prefix per update now (or sometimes two).
>
> Transit ISP we tested it with pinged TA
On 2 December 2015 at 09:17, Mark Tinka wrote:
>
>
> On 1/Dec/15 17:49, john doe wrote:
>
>>
>>
>>
>> Yeah, I was just referring to cli experience. commits, rollback, hierarchy
>> within. Prior XR IOS was wall of text, no?
>
> Still is, but you get used to working with what you have :-).
IOS doe
On 1 December 2015 at 14:14, Mark Tinka wrote:
>
>
> On 1/Dec/15 15:03, john doe wrote:
>
>>
>>
>> I think price wise MX is a better deal. ASR fully loaded with cards and
>> licences for various services gets expensive fast.
>
> Depends what cards you are loading in there.
>
> If you're packing a
On 17 November 2015 at 15:49, Dave Bell wrote:
> Hi James,
>
> Your export policy isn't adding on your community.
>
> Try:
> term 10 {
> from {
> protocol direct;
> interface [ ge-0/1/0.89 fe-1/1/3.89 ];
> }
> community add 0089_VRF;
> then accept;
> }
Ah, I'm so g
On 5 March 2016 at 15:17, Jesper Skriver wrote:
>
>> On 05 Mar 2016, at 16:41, Saku Ytti wrote:
>>
>> On 5 March 2016 at 15:22, Adam Vitkovsky wrote:
(b) Are there any noticeable behavioral differences between SPRING and
LDP implementations?
>>> Yes instead of label swap routers d
On 7 April 2016 at 19:46, Aaron wrote:
> Hi James, I have the book "MPLS in the SDN Era" and it shows some SPRING/SR
> config for Junos and IOS XR on Page 94
>
> One of the key contributors to the book is cc'd here... David might be able
> to speak to some of the SPRING existence in Junos
>
> I'm
Hi All,
I am migrating from one Cacti box to another, the new one polls some
MX boxes inside a routing instance but the old one polls in inet0 in
no routing instance.
When I snmpwalk the MX boxes from the new Cacti box I am only returned
the interfaces which are inside that routing instance the p
On 27 April 2016 at 17:10, Phil Mayers wrote:
> On 27/04/16 16:58, Per Westerlund wrote:
>>
>> That is default behavior, but you can access other RI's interfaces by
>> explicitly using the RI name. No way to reach all IFs at once via a RI.
>
>
> I'm a bit confused now.
>
> I just tested (SRX240H r
On 28 April 2016 at 12:50, Dale Shaw wrote:
> Hi James,
> My memory's a bit hazy on this, but do you see everything you want to see if
> you prefix the community string with a "@" in your cacti config?
Hi Dale,
As per my original email, I am prefixing the routing-instance name on
the SNMP get'
On 28 April 2016 at 17:16, Hugo Slabbert wrote:
> Use a community of simply "@SecretCommunity", *WITHOUT* the actual RI
> specified. That will pull everything. It's a little weird, but it works.
Yeah I had someone point that out to me offlist. I can confirm it's
now working as desired. Weird in
In Cisco land we have the interface command "carrier-delay", for Junos
(this scenario) can the OP not use some variant of "set interfaces
xe-0/0/1 hold-time up 5000" ?
Cheers,
James.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.n
On 19 May 2016 at 10:53, Mark Tinka wrote:
>
>
> On 19/May/16 11:49, James Bensley wrote:
>
>> In Cisco land we have the interface command "carrier-delay", for Junos
>> (this scenario) can the OP not use some variant of "set interfaces
>> xe-0/0/1
Hi all,
Just noticed this the lab that between an ASR9K (5.3.3) and MX480
(13.3R8.7), nothing "major" as it work but just curious is anyone else
has seen this (especially between two MXs), I haven't.
On the MX the RD for the ABC VRF was set to "route-distinguisher
196744L:200;" and the RT is "196
I have had an off list resposne confirming that others have seen this
issue, so I'm not totally mad.
Will speak to JTAC if I get the chance.
Cheers,
James.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo
On 23 August 2016 at 13:40, Olivier Benghozi
wrote:
> And about a limitation to 10 communities:
> I've seen that on SEOS (Redback/Ericsson OS for SmartEdge routers) when using
> "set community" in a route-map. This is a ridiculous arbitrary limitation, of
> course.
>
> Hopefully the limitation w
Thanks all :)
Cheers,
James.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
On 18 Jul 2016 11:58, "James Bensley" wrote:
>
> I have had an off list resposne confirming that others have seen this
> issue, so I'm not totally mad.
>
> Will speak to JTAC if I get the chance.
>
> Cheers,
> From: Josh Reynolds
> Sent: Friday, September 9, 2016 7:41:13 PM
> To: Alex Valo
> Cc: Juniper List
> Subject: Re: [j-nsp] Juniper vMX
>
>
> Disclaimer: I have not used vMX.
>
> You might be better off going with something like VyOS/Vyatta. A quad core
> high clock xeon with 8+ GB of RAM and a
> On 22/09/2016 14:41, Joe Freeman wrote:
>> I've been asked to put together a solution that allows us to do SAT on
>> every new turnup. These are all Ethernet services.
>>
>> I've been trying to figure out how to do it in the MX platform since that's
>> what we predominately have in our CO's, but
You need to share the configs I think you want much help with this.
Also from the Cisco side can you give the full output from...
show xconnect interface Gi0/1 detail
show mpls l2transport vc 2 detail
show mpls l2transport binding 2
show mpls forwarding-table labels 18 detail
Cheers,
James.
On 1 October 2016 at 01:02, Caio wrote:
> It looks like I need to configure service instance and something like that.
You don't need a service instance to run a port based xconnect.
These are examples of working IOS to Junos pseudowires I have made;
https://null.53bits.co.uk/index.php?page=pwe3
It's not supported by the Intel drivers.
Travelling, I'll try and find you a link tomorrow.
Cheers,
James.
On 23 Mar 2017 21:18, "Stefan Stoyanov" wrote:
> Hi everyone,
>
> Does anyone have an idea, why vMX SR-IOV vlan-tagging isn't working?
> If I use "unit 0" without any VLANs configured on
On 5 April 2017 at 15:38, wrote:
> The NIC is an Intel XL710 running at 10Gbps.
I don't know about vMX for Junos 17, is the i40evf driver supported
(for X710 Intel NICs)?
We are having a similar issue with Cisco's CSR1000v on CentOS with KVM
and X710 NICs. The i40evf driver isn't support by the
On 19 April 2017 at 17:20, Dragan Jovicic wrote:
> What Cisco originally calls "PIC Core" is simply indirect-next-hop feature
> on routers, same on Juniper. On "flat" architectures without indirect
> next-hop, a failure of an uplink (a core link) on a PE router would require
> this PE to reprogram
On 27 April 2017 at 14:41, wrote:
>> James Bensley
>> Sent: Thursday, April 27, 2017 9:13 AM
>>
>> It might be worth pointing out that on Cisco you need to enable PIC Core for
>> PIC Edge to work at its best.
> So it's either Core or Core+Edge.
That's
1 - 100 of 114 matches
Mail list logo