Re: [j-nsp] Junos OS Evolved
Whats its history? (will Google it too) I mean, from a software engineering point if view, it's a tough call to start again. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 upgrade path 18.4R
Thanks. Tons. May just go to the MX204 then. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 upgrade path 18.4R
Hi Robert, Have you seen any memory usage improvements yet? We're on v14 and need to upgrade or get a pair of mx204 for our second PoP, to match our first PoP. Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX204 vs. MX240??
Can't you do: https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html#id-configuring-rate-selectability-on-mx204-to-enable-different-port-speeds ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX204 vs. MX240??
> > The 10/40/100 capabilities of the MPC7 look great, but there are few > isolated > > cases where I need to support legacy 1 gig, and the MX204 can now handle > > that. Is this true? > > > Yup on the 10g for sure, but if you need 1G in volume you can pair it with a > simple 1RU switch. Yep, we pair 2 x MX204s with 2 x EX4300s for 1G optics and higher. Just migrating from a pair of MX5's to this set up. > The short answer is it's complicated. > You got to compare the probabilities of different failure scenarios, > probabilities of brown failures and see if it's worth spending a significant > extra for a resilient RE, ideally you'd just use 204s in pairs if necessary. As above. Recommended. For pricing, a license to light up a 10GB port on an MX5 was the same price as buying a MX204 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 7 July 2016 at 12:11, Saku Ytti wrote: > On 7 July 2016 at 13:22, Gavin Henry wrote: > > Hey, > >> Any developer can introduce bugs irrelevant of the language but some >> languages just have bugs that you >> would need to know C to fix. At Arista's level they are using C as >> everything touches C at some point be it >> bootstrapping the mini-any-lang to get to the state of compiling a >> language implementation from source. > > There are actually many languages with no runtime, which you can write > lowest level at possible. It's entirely possible to write all the low > level stuff in C++ or better yet Rust, you'll get sparser version of > the language, but it can be done. I'm not fluent in all programming languages at all, but I'd be interested in ready up on those that don't use C to get their main binaries to a certain point to compile the rest to get the final main binary ready. For example Perl's miniperl etc. >> I would say using C in the right place within a company puts them at a >> *massive* advantage. > > In comparison to what language, all languages? Why? The "in the right place" is the strong emphasis here, which goes back to the right tool for the right job. > C++ and Rust are > arguably more complicated languages, and it will take more time to > learn them. But we're talking about senior developers anyhow, so it's > an advantage that some experience is needed before you appear > proficient. And after you've paid the complexity tax, there are > dividends. Agreed. It's Senior devs that will have the confidence to say out loud that "this is better done in X language". >> Some interesting reading: > >> Again, very true. Further proof that the language is irrelevant and >> the "right tool for the job". The issue being >> algorithms, architecture of said toolset/project need to be understood >> clearly. The language is the second bit. >> Is that level still being taught or is it learned on the job? > > Aren't these mutually exclusive 'language is irrelevant' and 'right > tool for the job', I am arguing C is not the right tool for the job, > when talking about vast majority of things written in C. Routing stack > is way too high level for C. "Vast majority of things written in C"? For example? I would say things as critical as a routing stack would need C and that's why most are written in C. But again, this comes down to your other points about inhouse skillset vs "the right tool for the job". If a routing stack can be written in X language and supported by X company and it's "fast enough" or "good enough", then that's what it should be written in as X language is then the right tool for the job. > Kernel is probably fine in C, but even for that, I'd rather consider Rust > today. Understood. > I think good portion of IOS and RPD are written by people who learned > C on the job. They didn't enter the company as developer, but as they > were dealing with customer issues and had access to code base, they > started hacking on it. How many years until they realised how things > should have been written, 5? 10? No idea how their ecosystems work. >> Test, test and test as you know. It's very easy to write crap code, >> full stop :-) > > It is considerably harder to write bad code higher level languages > than in C. Especially in garbage collected ones, which are perfectly > acceptable for majority of use-cases, when it does not matter if you > pause for few milliseconds now and then. For our comments we need to define "bad code". Is that not using the write techniques or writing slow code. Test and benchmark when it's needed. > I'm not making absolute statements, I'm trying say there is some > probability of introducing a bug per feature or line of code written, > and I don't think this probability is constant and I believe this > probability is amongst highest in C. I would say it depends. If that code base has it's own memory management routines and pointer routines it may be safe to add lines of code where errors get caught. Software crashes with any language as us humans write it: https://github.com/search?q=This+should+never+happen&type=Code&utf8=%E2%9C%93 >> There in lies the whole point which I do agree with. Finding good or >> great C programmers is hard. Lots of C++. > > And if you can't find them for the salary which makes economically > sense, then you are in disadvantage compared to company who is using > tools to which they can find them. And said tools will be the "right tool for the job". -- Kind Regards, Gavin Henry. Winner of the Best Business ITSP (Medium Enterprise) 2016! http://www.surevoip.co.uk/2016-best-provider ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 7 July 2016 at 08:59, Phil Mayers wrote: > On 07/07/16 02:21, Gavin Henry wrote: > >> That last sentence is quite a sweeping statement about C. > > > The underlying basis for the statement - C is a hard language to program > well - is not at this point a controversial one, IMHO. Agreed. >> You can make great software in any language. I think this argument is >> false. > > > I think the argument has a lot going for it. OK. > C is a difficult language to use well; even developers with decades of > experience get caught out by the subtleties of things like pointer aliasing > and integer behaviour. There's a huge research effort by smart people to > improve that situation - as an example, things like ubsan in Clang to detect > and warn on use of undefined behaviour. John Regehr's blog is a good read on > the topic of how gnarly C can be, for those interested. Excellent to hear. > I think it's totally reasonable to argue that other languages can fit a > problem set better than C, can reduce the cognitive load on the developer, > and can prove more amenable to things like static analysis and automated > testing. Again agreed. I didn't say otherwise. > Other languages could include, here, a restricted subset of C with > least-surprise behaviours. But TBH, given the focus on multicore, I think a > language with better support for concurrency would be a more appropriate > choice (Erlang was mentioned; it's a shame that never took off, it's really > ideally suited for the task of network protocol speaker). Erlang is nice, but again the developers of this language do need C to get to the first point of building the language, as do most compilers as you know. C needs to be taught more as the fundamentals are not hard but everything in our world today relies on it. > Developers are people, and recognising the human limits of the process is > important. Frankly, I would agree with the notion that C is a very poor > choice for almost anything outside hardware-level work (kernel, driver) > these days, simply because CPU is cheap, and human cognition expensive, and > higher level languages trade costs in former for savings in the latter. I would also agree. But since the thread is ending about Arista, they are using it in the right place and as Saku states they are moving to the top of their game. As some point, not using the right tool means your technical dept is huge to repay. But that's what refactoring is for :-) My fear, like what is happening in the Oil Industry here, not just in Scotland, but globally, is that because the workforce is ageing, knowledge is getting lost. The things taught at Uni are not attractive and are hard for paying students, so they are dropped. This in turn means those coming into industry are not as good or as many and as the workforce ages there is a massive gap. Players like Arista and other commercial bodies need to help improve this. Thanks. P.S. My son was up until 02:45 today so some of above may hurt your eyes and mess with your brain. -- Kind Regards, Gavin Henry. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 7 July 2016 at 08:33, Saku Ytti wrote: > On 7 July 2016 at 04:21, Gavin Henry wrote: > > Hey, > >>> This comment was specifically about how they write the software. I >>> don't believe market has enough skilled labour to write any >>> significant SLOC on C. I think use of C puts any company in >>> disadvantage due to the cost of introducing bugs. >>> >> That last sentence is quite a sweeping statement about C. > > I accept that it is controversial. But it should be uncontroversial to > state, that some languages make more compile-time promises of > correctness than C does. True. My point was "I think use of C puts any company in disadvantage due to the cost of introducing bugs." Any developer can introduce bugs irrelevant of the language but some languages just have bugs that you would need to know C to fix. At Arista's level they are using C as everything touches C at some point be it bootstrapping the mini-any-lang to get to the state of compiling a language implementation from source. I would say using C in the right place within a company puts them at a *massive* advantage. Some interesting reading: https://ca.linkedin.com/jobs/view/17353638 http://blog.tsunanet.net/2013/03/why-i-joined-arista-networks.html http://www.bctechnology.com/jobs/Arista-Networks/106315/Software-Engineers-(multiple-positions).cfm >> There are massive Linux Kernel Hackers of course, which of course uses C. > > Kernel is one of the very few things you have to write in language > like C, C++ or Rust. I suspect many of top class Linux hackers can't > be hired to write RPD or iosd. Given environment, which you view as > broken, but not being allowed to fix it may not be acceptable to > people who are passionate about their work. Again, very true. Further proof that the language is irrelevant and the "right tool for the job". The issue being algorithms, architecture of said toolset/project need to be understood clearly. The language is the second bit. Is that level still being taught or is it learned on the job? >>> Combine these, and I think it makes Arista fundamentally more able to >>> produce better software. >> >> You can make great software in any language. I think this argument is false. > > I'm not argumenting it's impossible to make great software in any > language, I'm argumenting different languages give you different > probability of ending up with good software. Mainly because C makes > very few compile time guarantees, it's powerful tool, but it's also > very easy to write bad, yet seemingly working code on it. I'm sorry, I just don't agree. Ending up with good software comes down to design, understanding, maintaining and testing (not in that order). The choice of language makes no difference. Yes, you may get to the "good software" position sooner using a certain language, but just because something is hard, doesn't mean it shouldn't be done. Just look at Arista. "it's powerful tool, but it's also very easy to write bad, yet seemingly working code on it." Test, test and test as you know. It's very easy to write crap code, full stop :-) > I don't think market has sufficient amount of economically viable > people who can produce good C code. So my argument is, by generating > lot of code and by using C++, it is fundamentally cheaper for Arista > to produce quality code, giving them competitive advantage. There in lies the whole point which I do agree with. Finding good or great C programmers is hard. Lots of C++. I've found that out this month myself. I did C at Uni 15 years ago and just finished a 16 week C course here: http://www.cs.manchester.ac.uk/study/professional-development/study-options/distance-learning/foundation/course-modules/programming-in-c/ C is my world as everything we use (SureVoIP and Suretec) is written in it, even other languages we use are initially written in C. I've tried to find a Masters in Software Engineering with a strong emphasis in C in the UK, but they all use Java but you can use C for you dissertation. I've joined professional commercial groups like ACCU (http://accu.org/) but everyone is doing C++. I have found some mentoring programs though. The MSc is not needed for my job though. Anyway, my final point is as generations move on, tough things that we all rely on are getting left behind because there's a quicker way to do it. Problems solved and solutions get re-invented as they aren't taught anymore. But we all know that as human beings. Doing something the hard way that takes longer is not always doing it badly. -- Kind Regards, Gavin Henry. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 22 Jun 2016 13:51, "Saku Ytti" wrote: > > On 22 June 2016 at 10:41, joel jaeggli wrote: > >>> Can you expand on what you mean by the following quote: "I think they are > >>> fundamentally able to produce less buggy code than > >>> JNPR or CSCO. > > > > yeah if there's any fundamental about it, it's that it carry less > > legacy, is more general purpose, and has less hardware, wierd corner > > cases and unreasonable customer demands to support. It has it share of > > bugs, missing features and hardware specific limitations and quirks. > > This comment was specifically about how they write the software. I > don't believe market has enough skilled labour to write any > significant SLOC on C. I think use of C puts any company in > disadvantage due to the cost of introducing bugs. > That last sentence is quite a sweeping statement about C. > Arista, as I understand it, does not use C, but code is predominantly > C++, and even for that, good portions of the C++ code are generated > from higher level internal language. There are massive Linux Kernel Hackers of course, which of course uses C. > Combine these, and I think it makes Arista fundamentally more able to > produce better software. You can make great software in any language. I think this argument is false. -- Kind Regards, Gavin Henry. Winner of the Best Business ITSP (Medium Enterprise) 2016! http://www.surevoip.co.uk/2016-best-provider ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JTAC Recommended Junos Software Versions Old?
> About memory leak on PFE with inline jflow, this is PR1071289, affected > releases 13.3R5, 14.1R4, 14.2R1. How long does it take to show? -- Kind Regards, Gavin Henry. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Sampling - High CPU
On 1 October 2014 12:09, Brendan Mannella wrote: > We have a mx240 with inline flow enable, we were getting frequent cpu > spikes, we installed 12.3R8 yesterday and the spikes are resolved. Hi Brendan, What is your monitoring frequency to pick up the spikes? We're running the recommended junos on MX80's and only saw spikes/high usage for the first 10mins or so then it settled down. We're using the standard recommended config with a sample rate 1 but every 10 secs not 10 secs or 1000 packets. Most of ours is RTP traffic so we stuck to 10 secs. Thanks. -- Kind Regards, Gavin Henry. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cosmetic bug? - mx80 12.2r7.7
> That looks to be it. I had regular flow monitoring yesterday. Changed to > inline this morning and only noticed CPU then. Rolled back to regular, but > CPU still at 100% - Looks like I need to restart FPC... We get this too when enabledin 1:1 IPFIX sampling with sampled using all the CPU. If 1000:10 then it's OK. Have you seen this? -- Kind Regards, Gavin Henry. http://www.surevoip.co.uk OpenPGP (GPG/PGP) Public Key: 0x8CFBA8E6 - Import from hkp://subkeys.pgp.net or http://www.suretecgroup.com/0x8CFBA8E6.gpg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Question about inline flow sampling on MX 480 / Treo based interfaces
I'm mainly just wanting to make sure if I set 1:1 I won't blow up the boxes.:) > > I'm getting more confused the more I google so hopefully we can get some definitive answer. How did you get on? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Feature difference between latest Junos 12 and 13
Found it: http://pathfinder.juniper.net/feature-explorer/compare-softwares.html?swName=Junos+OS&typ=1#bm=cmpsw&pl=MX80&rel1=13.3R2&rel2=12.3R6 Sent from my iPad 2 On 31 May 2014, at 19:26, Gavin Henry wrote: Hi all, I can only find the release notes between point releases on each version. Anyone found a link covering this? We're on latest recommended right now on our mx80's and are happy but wanted to see what we're missing. Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Feature difference between latest Junos 12 and 13
Hi all, I can only find the release notes between point releases on each version. Anyone found a link covering this? We're on latest recommended right now on our mx80's and are happy but wanted to see what we're missing. Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 RE performance
Any news yet? Am looking at a new MX5 with upgrade licenses vs this with 2 x 10G Thanks. On 14 Jul 2013 01:53, "Darius Jahandarie" wrote: > On Sat, Jul 13, 2013 at 7:28 PM, Mark Tees wrote: > > Has anyone had a chance to compare the MX104 RE performance against the > MX80s line? > > > > Or is it not out in the wild yet? > > > > I have heard some pretty bad stories about the MX80 line in terms of RE > performance when converging full IPv4 tables from 3-4 BGP peerings and > comments here seem to indicate the same. > > My understanding is that it's not shipping yet, so it wouldn't be in > production anywhere, but some people have it in labs. > > At the very least, it has redundant REs, which makes it a much nicer > box than the MX80 IMO -- but whether the performance issues are solved > or not is another issue. I'd be very happy to hear if there are any > improvements on that front. > > -- > Darius Jahandarie > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JFLOW
On 28 Mar 2014 08:10, "Timh Bergström" wrote: > > We have similar traffic-levels (a bit more actually) and sample 1:100 > and handle the analysis on an E3 3.0Ghz/16GB RAM/2x500GB SATA SW-RAID1 > with 10G card with no problems and loads of capacity to spare. > > Is that inline JFLOW and IPFIX? Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Error with Juniper mibs, SNMPv2 Traps and mib-bgpmib.txt
On 10 February 2014 14:48, Gavin Henry wrote:
> Hi all,
>
> Has anyone experienced this? When our MX5's generate a BGP trap the
> corresponding bgptrap mib
> available from the Juniper website does not have the correct OID:
>
> Our error/trap is: bgpTraps.0.2
>
> In the file, there is no option '0' (zero) in there, here is a snippet
> of the mib file.
>
> bgpTraps OBJECT IDENTIFIER ::= { bgp 7 }
>
> bgpEstablished NOTIFICATION-TYPE
> OBJECTS { bgpPeerLastError,
> bgpPeerState }
> STATUS current
> DESCRIPTION
> "The BGP Established event is generated when
> the BGP FSM enters the ESTABLISHED state."
> ::= { bgpTraps 1 }
>
> bgpBackwardTransition NOTIFICATION-TYPE
> OBJECTS { bgpPeerLastError,
> bgpPeerState }
> STATUS current
> DESCRIPTION
> "The BGPBackwardTransition Event is generated
> when the BGP FSM moves from a higher numbered
> state to a lower numbered state."
> ::= { bgpTraps 2 }
>
>
> We have options 1 and 2, but no option 0.
>
> I can find a thread from Cisco from 1996 about this but Juniper are
> shipping the wrong mib or I've got the wrong one:
>
> http://www.ietf.org/mail-archive/web/idr/current/msg07056.html
>
> I downloaded them from:
>
> http://www.juniper.net/techpubs/software/junos/junos123/juniper-mibs-12.3R5.7.tgz
>
> we're on 12.3R4.6 but have also checked:
>
> http://www.trapezenetworks.com/techpubs/software/junos/junos123/juniper-mibs-12.3R4.6.tgz
So just a follow up from a ridiculous JTAC response:
"have now confirmed with engineering team that in fact Junos still
utilizes the deprecated OID for bgpTrap. It is not an error on the MIB
file. The decision to maintain the deprecated is based on the fact
that we would like to maintain cross platform support with network
monitoring systems. The behavior you are seeing is the expected
behavior within Junos platforms."
Do they not understand that NMS use the mibs they ship and if their
mib is wrong the trap is not processed?
Totally confused. Where can I get the right mib from? Anyone?
--
Kind Regards,
Gavin Henry.
OpenPGP (GPG/PGP) Public Key: 0x8CFBA8E6 - Import from hkp://subkeys.pgp.net
or http://www.suretecgroup.com/0x8CFBA8E6.gpg
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Error with Juniper mibs, SNMPv2 Traps and mib-bgpmib.txt
Hi all,
Has anyone experienced this? When our MX5's generate a BGP trap the
corresponding bgptrap mib
available from the Juniper website does not have the correct OID:
Our error/trap is: bgpTraps.0.2
In the file, there is no option '0' (zero) in there, here is a snippet
of the mib file.
bgpTraps OBJECT IDENTIFIER ::= { bgp 7 }
bgpEstablished NOTIFICATION-TYPE
OBJECTS { bgpPeerLastError,
bgpPeerState }
STATUS current
DESCRIPTION
"The BGP Established event is generated when
the BGP FSM enters the ESTABLISHED state."
::= { bgpTraps 1 }
bgpBackwardTransition NOTIFICATION-TYPE
OBJECTS { bgpPeerLastError,
bgpPeerState }
STATUS current
DESCRIPTION
"The BGPBackwardTransition Event is generated
when the BGP FSM moves from a higher numbered
state to a lower numbered state."
::= { bgpTraps 2 }
We have options 1 and 2, but no option 0.
I can find a thread from Cisco from 1996 about this but Juniper are
shipping the wrong mib or I've got the wrong one:
http://www.ietf.org/mail-archive/web/idr/current/msg07056.html
I downloaded them from:
http://www.juniper.net/techpubs/software/junos/junos123/juniper-mibs-12.3R5.7.tgz
we're on 12.3R4.6 but have also checked:
http://www.trapezenetworks.com/techpubs/software/junos/junos123/juniper-mibs-12.3R4.6.tgz
Thanks.
--
Kind Regards,
Gavin Henry.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Command
Hi, Is the same info available via SNMP? Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Console server recommendations
Agreed. Love the IM4XXX series. We just got a IM4216 with dual psu, dual lan, modem plus tons other things and works with Juniper and Cisco with just Cat5. Thanks. On 7 Sep 2013 05:41, "Matt Hite" wrote: > Opengear -- http://www.opengear.com/ > > Very impressive feature set and affordable. > > > > On Fri, Sep 6, 2013 at 9:23 PM, Luechtefeld, Daniel G < > daniel.luechtef...@providence.org> wrote: > > > My QFabric will need at least 24 terminal server ports for all the > console > > ports. I'd like one with options for an OOB POTS and/or cellular modem. > > What are your recommendations? > > > > Regards, > > Daniel Luechtefeld > > Network Engineer > > Providence Health & Services > > Renton, WA > > > > > > > > This message is intended for the sole use of the addressee, and may > > contain information that is privileged, confidential and exempt from > > disclosure under applicable law. If you are not the addressee you are > > hereby notified that you may not use, copy, disclose, or distribute to > > anyone the message or any information contained in the message. If you > have > > received this message in error, please immediately advise the sender by > > reply email and delete this message. > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX110H2-VA temperature sitting at 67c
Hi James, Thanks for this. Should be fine and Juniper have confirmed the temp range too. Now trying to get Pulse to work on things :-) On 24 August 2013 10:30, James Baker wrote: > TBF it's fully passive so it's not surprising. Think of them like an ASA > (they get really hot as well) > > I have 2 at home and it's not wise to stack them on top of each other; they > complain at around 70-72 degrees and get rather hot to the touch. But this is > my house with no A/C. > > Mine is currently @ 67 degrees with an ASA on top of it. > > You'll be fine in a DC > > > > -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of > Gavin Henry > Sent: Saturday, 24 August 2013 7:09 p.m. > To: Graham Brown > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] SRX110H2-VA temperature sitting at 67c > > Thanks all. Normal then. Just a lot hotter than I thought it would be to > touch. Will see what it's like when it goes to Telehouse East. > > Gavin. > On 24 Aug 2013 03:07, "Graham Brown" wrote: > >> Hi Gavin, >> >> I have a box sat on my desk and it's running a similar temperature: >> admin@GB-DESK-TEST-UNIT> show chassis routing-engine Routing Engine >> status: >> Temperature 65 degrees C / 149 degrees F >> >> This is running 12.1X44-D20.3. >> >> HTH, >> Graham >> >> >> >> On 24 August 2013 09:46, Gavin Henry wrote: >> >>> Hi all, >>> >>> Just got one of these in for OoB management and noted it's sitting at >>> around 67 Celsius on a lab test bench with lots of space around it in >>> a not really hot room. >>> >>> On latest 12.1X too. Others seeing this? When it goes to the DC I'm >>> sure it will be cooler due to Airton, but all its doing is ADSL and >>> a few ipsec inbound tunnels. >>> >>> Cheers. >>> ___ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >> >> >> >> -- >> Graham Brown >> Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer> >> LinkedIn <http://www.linkedin.com/in/grahamcbrown> >> > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX110H2-VA temperature sitting at 67c
Thanks all. Normal then. Just a lot hotter than I thought it would be to touch. Will see what it's like when it goes to Telehouse East. Gavin. On 24 Aug 2013 03:07, "Graham Brown" wrote: > Hi Gavin, > > I have a box sat on my desk and it's running a similar temperature: > admin@GB-DESK-TEST-UNIT> show chassis routing-engine > Routing Engine status: > Temperature 65 degrees C / 149 degrees F > > This is running 12.1X44-D20.3. > > HTH, > Graham > > > > On 24 August 2013 09:46, Gavin Henry wrote: > >> Hi all, >> >> Just got one of these in for OoB management and noted it's sitting at >> around 67 Celsius on a lab test bench with lots of space around it in a >> not >> really hot room. >> >> On latest 12.1X too. Others seeing this? When it goes to the DC I'm sure >> it >> will be cooler due to Airton, but all its doing is ADSL and a few ipsec >> inbound tunnels. >> >> Cheers. >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > > > -- > Graham Brown > Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer> > LinkedIn <http://www.linkedin.com/in/grahamcbrown> > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX110H2-VA temperature sitting at 67c
Hi all, Just got one of these in for OoB management and noted it's sitting at around 67 Celsius on a lab test bench with lots of space around it in a not really hot room. On latest 12.1X too. Others seeing this? When it goes to the DC I'm sure it will be cooler due to Airton, but all its doing is ADSL and a few ipsec inbound tunnels. Cheers. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX devices upgraded to 2GB ram
This is the info we got from our supplier in UK who is a Juniper Elite partner: " It's the same functionality and operation, just comes with 2G memory. It's part of a general refresh of the line that Juniper are doing just now to support future applications." Not sure how close those applications are. Some more UTM apps? Gavin. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 3rd optics on MX/EX/SRX
On 27 June 2013 09:27, Fearghas McKay wrote: > Gavin > > On 26 Jun 2013, at 21:52, Gavin Henry wrote: > >> Ours arrived this week and works on a Linux desktop :-) Nice idea too >> buying credits for 0.25 cents to reconfigure. > > You only need credits for >1G optics - the 1G are free to reprogram. Once an > optic has been configured to a platform it can always go back to that one for > free if you subsequently reprogram it. > > Cheers OK, thanks. Didn't know that! -- Kind Regards, Gavin Henry. Did you see our API? http://www.surevoip.co.uk/api ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 3rd optics on MX/EX/SRX
On 26 June 2013 21:46, Nick Ryce wrote: > We can't speak highly enough of Flexoptix. Agreed! This thing is great : http://www.flexoptix.net/en/flexbox-v2-transceiver-programmer.html Ours arrived this week and works on a Linux desktop :-) Nice idea too buying credits for 0.25 cents to reconfigure. -- Kind Regards, Gavin Henry. Did you see our API? http://www.surevoip.co.uk/api ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 11.4R1.6 shipping on new EX-series switches, serious problems
>> Why is that not the version that ships on new kit from the >> distributors? Bad management. We're getting two EX4200's and two MX5's delivered this week. Hope they have the recommend JTAC versions on them! -- Kind Regards, Gavin Henry. Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What is this ethernet switching trace telling us?
Hi Phil, Thanks. Yes, we used those too. Forgot to say. There are a few more iirc in there. Gavin. On 8 Jun 2013 09:54, "Phil Mayers" wrote: > On 06/08/2013 08:35 AM, Gavin Henry wrote: > > your email to /etc/aliases. We found that the Linux kernel doesn't >> send the same arp response out of the same interface. For example, one >> interface was a public IP and one was a private IP. The kernel would >> send a "I'm on MAC blah" for the private IP out of the public IP port! >> >> arptables is the solution, but in 10 years it's the first time I'd >> > > The behaviour you describe can be disabled by sysctl, which is rather > cleaner than arptables IMO; our cfengine config puts the following > /etc/sysctl.conf: > > # These values make linux be sensible about making and replying > # to ARP requests - specifically they force ARP requests to come > # from an in-subnet IP, and ignore ARP replies for out-of-subnet > # addresses > net.ipv4.conf.all.arp_ignore = 1 > net.ipv4.conf.all.arp_announce = 2 > > AIUI the Linux behaviour is intentional, claiming to be the letter of the > relevant RFCs, but it's certainly problematic in a number of scenarios, > including multihoming, transparent load-balancing and anycast routes. > There's more documentation in the kernel source for the above sysctls. > > I have no idea if this is actually the OPs problem. > __**_ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp> > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What is this ethernet switching trace telling us?
Hi John, We (SureVoIP) have seen this on some of our hosted SIP servers which run on Linux with multiple interfaces. This was connected to a Cisco switch though. If the SBC is on linux then install arpwatch and add your email to /etc/aliases. We found that the Linux kernel doesn't send the same arp response out of the same interface. For example, one interface was a public IP and one was a private IP. The kernel would send a "I'm on MAC blah" for the private IP out of the public IP port! arptables is the solution, but in 10 years it's the first time I'd seen this. Google shows otherwise (me): http://www.gossamer-threads.com/lists/drbd/users/24805 http://serverfault.com/questions/58146/what-can-cause-two-network-interfaces-on-the-same-machine-to-flip-flop-their-ip arpwatch will report "flip flop" in the logs. If you're not on Linux then I'm not sure :-( Thanks. On 8 June 2013 01:49, John Neiberger wrote: > Here is another example of the same type of thing. In this case, a MAC > address appears to be jumping from one four-port card to another on the same > switch. Port 5 is connected to one NIC, while port 8 is on another four-port > NIC and should never, ever use the MAC address we're learning on port 5. Do > these logs really indicate that the MAC is being learned on those > interfaces, or is it cryptically trying to tell us something else? I don't > want to assume. > > Jun 7 23:21:15.686871 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:91, > ifname ge-0/0/8.0, pnac_status 0, 0 > > Jun 7 23:21:15.686981 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40), iif = > ge-0/0/8.0: present in FDB > > Jun 7 23:21:15.687048 (3, 00:08:25:fa:3c:91) next-hop index change [1330 -> > 1329] > > Jun 7 23:21:15.687172 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:91, > ifname ge-0/0/5.0, pnac_status 0, 0 > > Jun 7 23:21:15.687267 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40), iif = > ge-0/0/5.0: present in FDB > > Jun 7 23:21:15.687501 (3, 00:08:25:fa:3c:91) next-hop index change [1329 -> > 1330] > > Jun 7 23:21:15.687672 KRT enqueue FDB (3, 00:08:25:fa:3c:91) nh-index 1330 > > Jun 7 23:21:15.687732 l3nh_fdb_notify: FDB CHANGE vlan mac > 00:08:25:fa:3c:91 > > Jun 7 23:21:49.269317 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:91, > ifname ge-0/0/5.0, pnac_status 0, 0 > > Jun 7 23:21:49.269427 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40), iif = > ge-0/0/5.0: present in FDB > > Jun 7 23:21:49.269583 KRT enqueue FDB (3, 00:08:25:fa:3c:91) nh-index 1330 > > Jun 7 23:21:49.269646 krt_dequeue: type FDB op change 3, 00:08:25:fa:3c:91 > Direct nh 1330 > > Jun 7 23:21:49.270539 l3nh_fdb_notify: FDB CHANGE vlan mac > 00:08:25:fa:3c:91 > > Jun 7 23:37:09.776588 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:91, > ifname ge-0/0/8.0, pnac_status 0, 0 > > Jun 7 23:37:09.776953 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40), iif = > ge-0/0/8.0: present in FDB > > Jun 7 23:37:09.777140 (3, 00:08:25:fa:3c:91) next-hop index change [1330 -> > 1329] > > > > On Fri, Jun 7, 2013 at 6:30 PM, John Neiberger wrote: >> >> I just checked and we do not have spanning tree enabled on this switch or >> its partner. We have two switches with a 10-gig link between them. Each >> switch is connected to a different upstream router. The device in question >> is a session border controller for VoIP. It is a chassis with multiple >> four-port NICs that are in redundant pairs. Two four-port cards connect to >> one switch and the other two connect to the second switch. The cards use >> virtual IPs and MAC addresses. If a failover is required, an entire >> four-port card fails to the card connected to the other switch. At that >> point the NIC is supposed to send gratuitous ARPs to repopulate the MAC >> address table with the correct location. Based on the ethernet switching >> trace logs, it looks to us like the virtual MAC addresses on those NICs are >> regularly jumping around between interfaces, which is definitely not >> supposed to be happening. We're now stuck in a battle between Juniper and >> the SBC vendor over whose equipment is misbehaving. I wanted to make sure we >> were correctly interpreting those trace logs. I'm also still curious about >> why the MAC learning log is not updating. There hasn't been a new entry in >> the log in nearly two months, which just can't be true. >> >> Thanks! >> John >> >> >> On Fri, Jun 7, 2013 at 5:05 PM, Harold 'Buz' Dale >> wrote: >>> >>> Are you running spanning tree ? >>> >>> Sent from my iPhone >>> >>> On Jun 7, 2013, at 1
Re: [j-nsp] What is this ethernet switching trace telling us?
Is this a server connected via two ports? Sent from my iPad 2 On 7 Jun 2013, at 23:12, John Neiberger wrote: > Also, another interesting thing about this is that the output of "show > ethernet mac-learning-log" stops at April 13th. I have no idea why. If a > MAC address were jumping around, we'd see it in the MAC learning log...if > it were up to date. What would cause a Juniper switch to stop logging to > the MAC learning log? > > By the way, this is an EX4200 running 10.4R6.5. > > > On Fri, Jun 7, 2013 at 4:07 PM, John Neiberger wrote: > >> We're trying to troubleshoot an odd issue and this log output makes it >> appear that a MAC address is flipping between interfaces. There are other >> interfaces involved later in the logs. I'm starting to think this isn't >> telling us what we think it's telling us. Does this indicate that the MAC >> address really is being learned from multiple interfaces? The confusing >> thing about the logs is the mention of l3nh. Is that layer three next hop? >> If so, why are we seeing that in ethernet-level trace options and what is >> the significance? >> >> I'm a little confused. Here is an example: >> >> Jun 4 13:07:22.953201 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, >> ifname ge-0/0/6.0, pnac_status 0, 0 >> Jun 4 13:07:22.953312 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = >> ge-0/0/6.0: present in FDB >> Jun 4 13:07:22.953374 (3, 00:08:25:fa:3c:82) next-hop index change [1344 >> -> 1328] >> Jun 4 13:07:22.953562 KRT enqueue FDB (3, 00:08:25:fa:3c:82) nh-index 1328 >> Jun 4 13:07:22.953712 krt_dequeue: type FDB op change 3, >> 00:08:25:fa:3c:82 Direct nh 1328 >> Jun 4 13:07:22.954372 l3nh_fdb_notify: FDB CHANGE vlan mac >> 00:08:25:fa:3c:82 >> Jun 4 13:21:18.041160 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, >> ifname ge-0/0/5.0, pnac_status 0, 0 >> Jun 4 13:21:18.041271 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = >> ge-0/0/5.0: present in FDB >> Jun 4 13:21:18.041332 (3, 00:08:25:fa:3c:82) next-hop index change [1328 >> -> 1327] >> Jun 4 13:21:18.041670 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, >> ifname ge-0/0/6.0, pnac_status 0, 0 >> Jun 4 13:21:18.041767 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = >> ge-0/0/6.0: present in FDB >> Jun 4 13:21:18.041807 (3, 00:08:25:fa:3c:82) next-hop index change [1327 >> -> 1328] >> Jun 4 13:21:18.041962 KRT enqueue FDB (3, 00:08:25:fa:3c:82) nh-index 1328 >> >> It looks to me like the MAC address is jumping around. What do you think? >> >> Thanks, >> John > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundancy with MX
Any constraints? Power? Bandwidth? What's the driver/function? Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk On 21 Jan 2013, at 20:40, Markus H wrote: > Hi, > > I wonder what kind of redundancy the community would prefer for > small-medium sized PoPs. > This is what I have come up with so far: > > a) 2xMX80 > Pro: Two seperate devices so less prone to config errors and chassis failure > Con: Using redundant uplinks is more complicated (LB would need to be > done via routing protocol) > > b) 1xMX240/480 with redundant SCB and RE > Pro: Easier to use redundant uplinks (LACP) > Con: Config error as well as chassis failure brings the whole PoP down > > Any further arguments? Best practices? What did you deploy? > > > Best regards, > Markus > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5 with bras?
How come its so new in the mx range? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk On 8 Dec 2012, at 13:07, Gordon Smith wrote: > > > >> >> This all doesn't sounds very encouraging to use Juniper for this. >> Others have recommended the Cisco ASR1kx for this instead and keed >> Juniper in the core :-( >> >> -- >> Kind Regards, >> >> Gavin Henry. >> Managing Director. >> >> T +44 (0) 1224 279484 >> M +44 (0) 7930 323266 >> F +44 (0) 1224 824887 >> E ghe...@suretec.co.uk >> >> Open Source. Open Solutions(tm). >> >> http://www.suretecsystems.com/ >> >> Suretec Systems is a limited company registered in Scotland. Registered >> number: SC258005. Registered office: 24 Cormack Park, Rothienorman, >> Inverurie, >> Aberdeenshire, AB51 > > Could always use an ERX - they're a good BRAS box, and Juniper have been > selling them for a long time now. I've used both Cisco & Juniper BRAS's, and > I do prefer the flexibility of the Junipers... The ERX's do not run junos, > which some may find a bit confusing at first ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5 with bras?
http://www.cisco.com/en/US/prod/collateral/routers/ps9343/solution_overview_c22-449961_ps9343_Product_Solution_Overview.html Service Provider (MPLS Provider Edge) and Broadband QoS Finally, Cisco ASR 1000 Series Routers offer a high throughput and highly scalable Broadband Remote Access Server (BRAS) solution, with complex hierarchical QoS schemes and IPv4 or IPv6 Multicast video streams. You could also combine this solution with and MPLS Provider Edge (MPLS PE) environment, where the different tunnels modes to offer Differentiated Services and QoS transparency. Figure 9 gives a high level overview of this possible solution. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5 with bras?
ASR1001 will do LNS. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5 with bras?
> Thanks Skeeve… > > > > We have had MX5/MX10/MX80 doing BRAS at customer deployments since around > March – the 11.2R5.4 release has a number of nasty bugs and wish they would > stop recommended it on their site… that was the second release in 11.2 we > had ran at the time. Then we went into two different 11.4R code releases > and ran into some other issues and finally 11.4X27 came out and squashed > most of those bugs (but not nearly all of them unfortunately). The > issues/bugs we ran into were mainly PPPOE related. > > > > Also, we have seen a lot of similarity in the bugs on MX80 based hardware > as we have seen in MX480/960 BRAS boxes – some different, some the same to > date.. > > > > At the moment, we are faced with a few challenges on this platform .. one > is the load on the box with under 4k users (quite high at times) and a more > recent issue has re-surfaced involving PPPOE sessions not timing out > properly. > > > > YMMV of course… This all doesn't sounds very encouraging to use Juniper for this. Others have recommended the Cisco ASR1kx for this instead and keed Juniper in the core :-( -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5 with bras?
Hi all, Can an MX5 do BRAS? Thanks. On 22 November 2012 20:50, Gavin Henry wrote: > Hi all, > > Is anyone running this or any MX series with wholesale ADSL services in the > UK? > > Any issues, gotchas or recommendations? > > This is for an entry level broadband sp focused on VoIP but to scale up. > > Thanks. > > -- > Kind Regards, > > Gavin Henry. > Managing Director. > > T +44 (0) 1224 279484 > M +44 (0) 7930 323266 > F +44 (0) 1224 824887 > E ghe...@suretec.co.uk > > Open Source. Open Solutions(tm). > > http://www.suretecsystems.com/ > > Suretec Systems is a limited company registered in Scotland. Registered > number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, > Aberdeenshire, AB51 8GL. > > Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html > > Do you know we have our own VoIP provider called SureVoIP? See > http://www.surevoip.co.uk -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX5 with bras?
Hi all, Is anyone running this or any MX series with wholesale ADSL services in the UK? Any issues, gotchas or recommendations? This is for an entry level broadband sp focused on VoIP but to scale up. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLS labels on a traceroute across an IXP?
>> on a traceroute before (being new to MPLS too :-) ) and presume it's >> showing because of the junos traceroute, whereas I don't see it from >> the same >> network on a linux box? > > Yes. You need to use the -e flag if you want it to show on a Linux traceroute. Ah, cool. I should have man traceroute / MPLS :-) So, running that again with -e didn't show the same thing as the junos one. traceroute -e on linux: 3 lonap-gw2.plus.net (193.203.5.155) 13.001 ms 12.993 ms 13.022 ms 4 te-9-1.ptw-gw02.plus.net (212.159.1.19) 13.512 ms 13.607 ms 13.795 ms 5 link8-central10.ptw-ag01.plus.net (84.93.248.15) 17.695 ms 18.456 ms 19.484 ms and on JUNOS Software Release [10.4R11.4] (Export edition): 3 lonap-gw2.plus.net (193.203.5.155) 15.569 ms 22.826 ms 22.150 ms 4 te-9-1.ptw-gw02.plus.net (212.159.1.19) 186.604 ms 197.964 ms 202.049 ms MPLS Label=9814 CoS=0 TTL=1 S=1 5 link6-central10.ptw-ag01.plus.net (84.93.248.11) 19.876 ms 18.910 ms 18.918 ms The label is different, but always the same on each version. I presume that's because the linux one, even though using the same gateway as the junos router, is going on to link8 and the junos one on to link6. >> My other question is should this actually show and not be remove by >> the egress LER? > > Without ICMP extensions, when an LSR receives an undeliverable > MPLS-encapsulated datagram, it strips the MPLS label stack and punts > that IP datagram to the error processing module, which then generates > the, e.g., Time Exceeded ICMP. > > With ICMP extensions, the LSR instead provides the MPLS label stack to > the error processing module, which appends that information to the > ICMP using a "MPLS Label Stack Object". > > So, as long as the router received the datagram as MPLS, it can/will > send back the ICMP with a MPLS Label Stack Object. This applies to an > LER. Thanks Darius, much appreciated. That's probably covered in my MPLS-Enabled Applications book that I've just started...maybe not. Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MPLS labels on a traceroute across an IXP?
Hi all, Please excuse my ignorance, but having just got into junos I've noticed on a traceroute today this: traceroute to xx.xx.xx.xx (xx.xx.xx.xx), 30 hops max, 40 byte packets 1 xx.xx.xx.xx (xx.xx.xx.xx) 2.504 ms 5.024 ms 2.937 ms 2 xx.xx.xx.xx (xx.xx.xx.xx) 15.254 ms 15.300 ms 15.887 ms 3 lonap-gw2.plus.net (193.203.5.155) 15.076 ms 15.103 ms 16.043 ms 4 te-9-1.ptw-gw02.plus.net (212.159.1.19) 15.844 ms 16.082 ms 15.642 ms MPLS Label=9814 CoS=0 TTL=1 S=1 5 link6-central10.ptw-ag01.plus.net (84.93.248.11) 20.964 ms 32.774 ms 55.808 ms 6 * * * 7 * * * 8 * * * Now I've never seen: MPLS Label=9814 CoS=0 TTL=1 S=1 on a traceroute before (being new to MPLS too :-) ) and presume it's showing because of the junos traceroute, whereas I don't see it from the same network on a linux box? My other question is should this actually show and not be remove by the egress LER? Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX5 vs Brocade CER
> How do you get the PDF version? I don't see it mentioned anywhere. I'd love > to be able to order paperback but get the PDF now :D http://shop.oreilly.com/product/0636920023760.do PDF ebook. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX5 vs Brocade CER
> I think you should check out the new MX book then. You'll be surprised at > the amount of shell commands. The architecture chapter does cover a day in > the life of a packet on all of the major MPCs. Just bought the PDF! I'm almost finished the other Junos O'Reilly books on Safari (but have also bought the PDFs) and think it's brilliant the authors are on this list too! Thanks, Gavin. P.S. Just got our ASN and IPv6 space last last week and loving Junos! They get routed this Wed! -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
