[j-nsp] libcurl for SLAX missing HTTPS/SSL support?
I was hoping to call an API by HTTPS from a script. To my surprise, libcurl on vSRX 15.1X49-D60.7 on AWS doesn't support SSL, and neither does fetch, etc. This seems a little ridiculous, especially since the documentation indicates HTTPS support and provides examples. https://www.juniper.net/documentation/en_US/junos15.1/topics/reference/general/junos-script-automation-libslax-curl-extension-library.html The KB is barren on this topic, too. I saw that Saku Ytti got Juniper to correct missing HTTPS for one use-case some years ago, and a 2013 thread with a similar complaint. What gives? -- Jeff S Wheeler ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Help with MSTP in EX8208
Octavio, notice that the Role of the ports is MSTR not ROOT. Your two EX8200s are not in the same MSTI Region. Compare the configuration-name, revision-level, and VLAN-to-Instance assignments on the two switches; they are not the same. For more on the different MSTP Port Roles and their meanings, see IEEE 802.1Q-2005 Section 12.12 Port Role assignments. Vendor documentation is mostly worse than the IEEE standard, and Juniper's is no exception. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX3300/EX4300 Licensing
On Mon, Nov 18, 2013 at 12:45 PM, James Jun wrote: > BCP38 at customer ports as best practice. Requiring a paid license to > enable sommething as simple as uRPF is Juniper's contribution to further > help discourage BCP38 implementation, imo. uRPF on the small-EX switches has problems that go beyond licensing. When last I checked, you could only enable or disable it globally, even though Junos lets you configure it on an individual port/interface. If it is enabled and the switch has dual uplinks to your distribution / core which are on different interfaces ... it will just urpf-fail all traffic arriving from the uplink interface that isn't the current best-path for 0/0. Because it also won't do MPLS on SVI/RVIs, only on layer-3 ports, you can't design around this problem by using an SVI for your dual-homed layer-3 uplink and relying on STP to provide connection to two upstream devices on a single IFL, using a shared uRPF "filter." Unless, of course, you choose between either MPLS services or layer-3 services and don't mix them together in a stack. Basically, IMO, Juniper takes some great liberties when they claim these switches "support" "uRPF." -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ 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
On Sun, Jun 23, 2013 at 6:02 PM, Chris Adams wrote: > Once upon a time, Gavin Henry said: >> We're getting two EX4200's and two MX5's delivered this week. Hope >> they have the recommend JTAC versions on them! > > Why do you expect they will? The recommended releases are not very old; > it isn't like Juniper (or any other vendor) is going to pull back all > the stock in the supply chain and reload the OS every time they change > the recommended release. I don't expect them to do that. I just expect a Release version that isn't so bad, that the CLI is unusable, to be installed on the switches from the factory. Sure, it may take some weeks to deplete all the remaining inventory that still has 11.4R1 on it, and that's fine. Continuing to ship a version that is so broken is idiotic. Yes, as Mark says, customers who have a clue are going to install a different version anyway. Not every customer has a clue. Some might expect the software that ships on a switch that has been out for 4+ years to basically work right. The reason it doesn't is they seem to change the shipping Junos only when a new extended support release comes out, or when new EX switches come out that they want to be able to stack with older ones "out of the box." That would be fine if those releases worked right. Fix it, EX PMs! This is a simple problem with a simple solution. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Junos 11.4R1.6 shipping on new EX-series switches, serious problems
Junos 11.4R1.6 is currently shipping on new EX-series switches. In this release, the CLI program isn't even stable. I've had it crash on me before I can even get as far as to commit a root password. For the EX PMs who may be reading, please change the version that ships on new-in-box units to one that isn't so buggy that it should never have been released. Is it your express goal to make sure customers buying new units understand than many Junos releases are such garbage as to be unusable? To inform us that your Q/A is non-existent? Is there an 11.4R that basically works? Yes. Is there one that JTAC recommends? Yes. Is the currently-shipping version covered by Juniper security vulnerability notices indicated to be serious? Also, yes. Is that supposedly-serious vulnerability fixed in the JTAC-recommended version, which functions better? Again, yes. Why is that not the version that ships on new kit from the distributors? Bad management. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Inter-racks switch routing recommended practice
On Tue, Jun 4, 2013 at 9:24 PM, Ihsan Junaidi Ibrahim wrote: > I'm thinking multi-areas OSPF/v3 but would a flat OSPF area 0 topology with > BGP make more sense? I don't have a lot of exposure in dense datacenter > routing so I'm bringing the conventional WAN routing thinking cap into the > picture. This is really a scale question. I think you'll find that, if you just dump everything into area 0 for now, it will not be very difficult to change that later on should you need to scale up. Note that the EX4550 has a rather small FIB/TCAM even compared to the EX4200. For tens of racks, this should be no problem. It is not what I would consider a good datacenter aggregation platform, though, due to its limited FIB. If you scale up you may find that you need to move layer-3 aggregation to a different kind of box. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4500 best-effort drops nowhere near congested
On Tue, May 7, 2013 at 4:01 PM, ryanL wrote: > good discussion. the tl;dr - nothing i can do about it. right? You can add LACP/ECMP ports/paths to reduce the chance that packets need to be buffered so long that the buffer becomes full. To use a dirty word, flow-control might be an option as well. However, you need to carefully test the particular switch and software to see if it works with any sanity. Also remember that flow-control is likely to effectively cause HoL blocking on a port transmitting a lot of traffic toward another port that is busy, and other ports which aren't. For example, you would not want to send flow-control to a 10GE storage server's port that is transmitting to any 1GE ports because it would likely be harmful to storage performance for all connected hosts, whenever just one host's port is full. I personally think that the complexity, buggyness, and potential gotchas of flow-control far out-weigh the small potential gains. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4500 best-effort drops nowhere near congested
On Wed, May 1, 2013 at 8:27 PM, ryanL wrote: > i'm guessing this is a buffer thing, but i can't explain why it only > happens on my 1ge ports and not when i punt the traffic over an 10ge Yes, it is a buffer thing. A 10GE interface is basically never going to not have time to transmit frames unless it is receiving from 10 or more 1GE interfaces at the same instant, steadily, for long enough to fill the buffer; or there is at least one 10GE interface also talking to it. On the other hand, two 1GE interfaces transmitting toward the same out-going 1GE port can fill its buffer. This is sometimes not obvious, because you look at the long-term traffic and see a few hundred Mb/s, thinking, "why is there packet loss?" You must keep in mind that the available buffer on modern ToR switches is often less than 1ms worth of traffic. The "buffer bloat" discussion of recent years has not done us any favors. Many customers now think that buffers have historically been too big. In fact, they were just often used incorrectly / configured badly. Now we are not evaluating purchases based on having sufficient buffer, so vendors have spent years developing products that ... lack sufficient buffer. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Wed, Apr 24, 2013 at 7:17 PM, Brandon Ross wrote: > On Wed, 24 Apr 2013, Pavel Lunin wrote: >> This is what I never understood. Why people want to use fxp0 (or any >> other "dedicated management") iface for real production management? > > Are you suggesting that they should purchase a 10/100/1000 copper card just > for management? Or are you suggesting that they should buy 10GbE switches > for their out of band management network? No, he's questioning the wisdom of doing SNMP queries, and other automated, routine management functions, against fxp0 instead of an interface that is protected by the hardware CoPP. One of my clients uses an NMS that sometimes starts sending ~3k PPS of SNMP BulkGets to a router. They don't know why. If that traffic was hitting fxp0 with no policer, etc. then it would consume a lot of CPU. My view is that fxp0 is an out-of-band interface for manual intervention; not one that I ever use for SNMP. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
On Sun, Mar 31, 2013 at 10:18 AM, Mark Tinka wrote: > no answer to Cisco's ASR1000. Even just for route > reflection, I'd be very hard-pressed to choose a US$1 MX480 > with a 16GB RE over a Cisco ASR1001 costing ten thousand > times the price. These are all symptoms of Juniper's incompetent management. * inability to manage supply chain & logistics, leading to 6 month lead times on incredibly high-margin products * essentially no software Q/A * consistently failing to deliver on software commitments / roadmap * big gaps in the product line that could be fixed easily, but aren't * far worse TAC than competitors * refusal to admit basic, obvious, and huge bugs exist so they can be fixed * widespread ineptitude in the sales and sales-support force * misplaced R&D efforts * basic features that customers require missing from products *by choice* while competitors have those features Just problem #1 clearly demonstrates that upper-management has no idea what they are doing. They are managing their inventory like they're making automobiles with razor-thin margins, not I.T. products which sell for many multiples of the manufacturing and logistics cost. Not only that, but they have no systemic way for customers to expedite orders (and generate revenue / additional margin from such expedites), which is just leaving money on the table. They cannot even solve the basic, easily-fixed problems with their business. I have little faith in Juniper's long-term future. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird routing issue on my MX80
On Fri, Mar 29, 2013 at 9:37 AM, Matthew Crocker wrote: > Is it possible for the FIB to contain different information than what's in 'show route'? > How do I look at whats in the FIB? Yes, it is possible. Start with user@cli> *show pfe route ip prefix 192.0.2.0/24* > How do I reset the FIB and resync it with the actual routes? If only Junos would get a command-line tree like *clear cef* so the user has a reasonable option (not rebooting PFEs) for fixing these problems. But that would first require Juniper to admit that this happens often enough that customers need it. It took Cisco a few years to reach that point with customers begging for things like CEF Scanner. I do not think this is your problem though. If you ran show route A.B.C.0 detail on the ASBR that is connected to your customer, you must either be doing ECMP to a customer loopback IP, some other ebgp-multihop business, or whatever. In any case, you didn't provide enough relevant information for anyone to say for certain; but I suspect your router is not malfunctioning. You have probably just made a mistake. > show route A.B.C.0 detail > > inet.0: 439841 destinations, 876907 routes (439825 active, 0 holddown, 32 hidden) > Restart Complete > A.B.C.0/24 (1 entry, 1 announced) > *BGPPreference: 170/-101 > *Next hop type: Indirect* > Address: 0xdeadbeef > Next-hop reference count: 6 > Source: X.Y.Z.11 > Next hop type: Router, Next hop index: 1048574 > Next hop: Q.W.E.195 via ge-1/1/1.0 > Next hop: X.Y.Z.11 via ge-1/1/2.0, selected > Protocol next hop: *T.U.V.122* > Indirect next hop: 160865a0 1048575 > State: > Local AS: Peer AS: > Age: 13:39 Metric: 0 Metric2: 20 > Task: BGP_.X.Y.Z.11+12834 > Announcement bits (3): 0-KRT 4-BGP RT Background 5-Resolve tree 1 > AS path: 2 I > Accepted > Localpref: 100 > Router ID: M.N.O.169 If this were a vanilla eBGP session to the customer and your paste is from the ASBR terminating the customer's session / circuit, it would say *Next hop type: Router* so you might want to double-check the differences between the "correct" and "incorrect" customer routes before investigating further. If you do find the PFE route doesn't match the software's idea of what should be in the FIB, I will be a bit surprised in this case; but I think the above should be helpful either way. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Am I carrying this route or not ?
On Sat, Mar 23, 2013 at 5:21 PM, Zehef Poto wrote: > I just inherited our backbone. We're a small LIR, we have an AS. The > backbone consists of four MX80 routers, all acting as eBGP edge ones (there > are various IP transit links up and running on all of them). I also use > OSPF adjacencies, and iBGP. Again, all of this is very new to me, so I'm > learning little by little. Sorry about possible mistakes/errors. I think you had better get some help before you break your network! > The question is : how can I check if a particular route is being carried in > my backbone ? How can I make sure that's not the case ? I'm being suggested > to "use next-hop-self", but for some reason I can't fully understand what's > involved here... In the CLI, use the command: show route 192.0.2.0/24 Hit ? for options such as exact, detail, etc. Whoever that person is that said something about "use next-hop-self" in this context, either you misunderstood them, or you shouldn't listen to them anymore. That has nothing to do with looking to see if your router knows about a route. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Problems with Link Aggregation
On Wed, Mar 6, 2013 at 9:15 AM, Filippo Cugini wrote: > However, when we send traffic on the aggregated link, just one ge works, and > we experience packet loss when we exceed the throughput of 1000mbps. > Indeed, the statistics of all interfaces show that only the ge-0/0/12 is > utilized to forward the data traffic, while the other two interfaces send > and receive only signaling packets. What kind of traffic are you sending over the LAG? It may be all hashing to one of the member-links. Read this: http://inconcepts.biz/~jsw/disadvantages_of_nxgbe_links.pdf -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX VC mixed mode experience
On Fri, Mar 1, 2013 at 10:50 AM, Riccardo S wrote: > I'm wondering if anybody have info or experience in a scenario > with mixed virtual-chassis (6 equipments between 4500 and 4200) with high > density > (more or less 70) of 10GBs ports. > > Since these architecture should be placed in a > very sensitive position (servers and storage managing online systems of an > important airport), > I'd like to have some "informal" feedbacks if any problems or whatelse have > been experienced by somebody... > > Why chose this design ? only costs... Sounds like "carrier grade" to me. My understanding is there is still no high-speed stacking module for the EX4500 expansion slot. Your virtual-chassis obviously won't approach full wire-speed. With that said, when you need a mixture of 1000baseT and SFP+ ports, it is a decent configuration. ARP still sucks on the small-EX platforms but it has improved in 12.3, which is a welcome change. Still pretty bad though. They have made `clear arp` do what it's supposed to do, but I guess adding something like `clear arp interface all` was too hard. Go figure. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3600 port buffers
On Tue, Feb 12, 2013 at 2:39 PM, Piotr wrote: > I looking some info about buffers size in this model ? Are they > configureable ? It is the same chip as the QFX3500 and has similar < 10MB buffer for the whole chip, which is similar to other products in this segment. It is configurable. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger wrote: > I noticed that a MX80 takes quite a long time after reboot to put all > routes into the KRT. Is that normal for that box? It takes around 10 > minutes after BGP is established to get all the routes into the KRT Yes, the routes taking a long time to install is "normal," unfortunately. I feel like it has got worse since 10.4 but that might be my imagination. I am sorry I missed Richard Steenbergen's lightning talk at NANOG, which was something like "if you want your routers to install routes, call Juniper and reference PR# because they do not want to fix this bug." I am hopeful that the move away from a single Junos release strategy to some segregation among different products will allow Juniper to be more flexible in how they allocate development resources to different platforms. If I had to guess, I'd say the ddos-related log messages you are reading are related to excessive need to generate ttl_exceeded packets because of routing loops while BGP is announcing to neighboring routers but the routes are not actually installed in the FIB yet. Even if I am wrong about the specifics here, I am certain it is only a symptom of the problem which is unrelated to the ddos-protection feature. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] large subnet/no memory
On Mon, Feb 11, 2013 at 1:44 PM, The Drifter wrote: > How would you weigh the effectiveness of using your suggestion versus > Cristian's? Well, Christian's suggestion will not solve your problem at all. I'd say that should be a good indication. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 12.3 Release Date
On Sun, Feb 3, 2013 at 1:52 PM, William McLendon wrote: > I configured virtual routers, OSPFv3, RIPng, MLD, MSDP, and VRRP and did not > get any of "license needed" warnings in the candidate config or when > committing -- the only one I got is the one you always got in previous > versions when configuring BGP, MPLS, and ISIS without a license. I can't > remember if previous versions barked about IPv6 routing protocols or not, but > it is not throwing warnings right now for RIPng or OSPFv3. Older Junos does gripe about configuring OSPFv3 without AFL (or EFL?) It's nice to see them removing this restriction. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 12.3 Release Date
On Sun, Feb 3, 2013 at 6:25 AM, Craig Askings wrote: > Juniper now want you to buy a Advanced features licence to support "Unicast > reverse-path forwarding (RPF)", this is getting absurd. I might think it less absurd if uRPF was more useful on EX3200 and friends. Is the current behavior still that uRPF-strict is enabled globally whenever you configure it for any one interface, and no allowance is made for having two default routes to upstream routers (ingress traffic from one upstream is discarded)? -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Smallest size IPv6 allocation typically advertised?
On Wed, Jan 23, 2013 at 5:50 AM, Saku Ytti wrote: > block in RIPE area, so deaggregation is must. I think in ARIN area this is > different and two DCs would mean you could get two blocks. ARIN rules effectively allow you to manage a /32 (or more) per POP, with every POP getting the same sized block, rounded up to nibble-boundary based on your plans. You then take your number of POPs and round that up to nibble-boundary. This means many networks can effectively go to ARIN and get a /28 or /24 today with no problem; some networks even bigger. It also means for ISPs there is going to be much less need to announce any routes smaller than /32. For PI end-users, though, the waters remain murky. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos labeled-unicast announces unusable routes, certainly this is a bug
On Mon, Jan 21, 2013 at 4:27 AM, Alex Arseniev wrote: > Probably not what you want to hear at the moment but it "is working as > designed". No, it isn't. Junos BGP is announcing routes it knows, for sure, are invalid. It knows that because BGP is making up a wrong label (2^20-1) because it hasn't allocated one, and it can't announce the route without a label. This is an inexcusable bug that is very far from "working as designed." The documentation is wrong, you cannot configure both AFI=1 SAFI=1 and AFI=1 SAFI=4 on the same BGP session. If it worked as documented, the above behavior would not happen, and AFI=1 SAFI=1 would be available to use for these routes. That is not the case. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Junos labeled-unicast announces unusable routes, certainly this is a bug
Dear List, The process of raising a PR with JTAC generally makes me want to scream, so I thought I would post first, and perhaps some kind Juniper person can input a PR# without me having to reproduce the problem again and jump through twenty hoops to later be told "working as designed." When configuring BGP labeled-unicast on Junos, you might think (like I hoped) that you could use LDP to create FECs and allocate labels, and then use those labels in your MP-BGP session. Unfortunately this does not work, and the basic reason is Junos BGP wants to allocate its own labels, and won't consult the LDP FEC table to see if any already exist for a given protocol next-hop which is being announced to the neighbor. Fine, so it wants to allocate its own labels. However, trying to avoid this behavior, I found it's pretty easy to get Junos to announce broken labeled-unicast routes that can never work, even though the receiving BGP speaker has no idea they are invalid. The receiver will just install the routes, forward traffic, and the traffic will get blackholed. This happens because Junos is trying to announce NLRI with no allocated labels (because layer-3 next-hop is not "self") and it can't announce them when labeled-unicast is configured, because the documentation is wrong, and you canNOT actually configure both AFI=1 SAFI=1 and AFI=1 SAFI=4 on the same BGP session. It simply does not work, and the Juniper documentation on this subject is incorrect. So what happens is, the announcing router knows it wants to announce a prefix, but it has no label stack for it, won't allocate one, and instead it just puts in label 1048575, or 2^20-1. This label is not in the LFIB, so when that router receives packets with that label, it doesn't pop the label and do a layer-3 look-up. Instead, it just discards the packets. Worse than that, the announcing router's `show route advertising-protocol bgp ` output is incorrect. It shows no label, even though it really is sending a label stack with 2^20-1. You have to go over to the receiving router to find this out. So this combination of documentation bugs and ridiculous Junos ability to announce labeled BGP routes that it knows for sure are invalid, is quite foolish, to say nothing of the fact that it won't just use FECs you already created using LDP. :/ Anyway, if you ever get labeled BGP routes with label 2^20-1, this might be why. Hopefully some kind Juniper folks will be willing to file some bugs on this for me, because I don't have a week to fight with JTAC about it. It is, however, very easy to reproduce the problem. :-) Thanks -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MLD snooping and IPv6 ND
Could any of the Juniper folks mail me off-list regarding some MLD snooping and IPv6 ND interactions? Thanks -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Debugging mysterious packet loss on J2350 under stress
On Sat, Dec 29, 2012 at 3:18 PM, 叶雨飞 wrote: > InterfaceLink Input packets(pps) Output packets (pps) > ge-0/0/0 Up11772104571 (24744) 11662868938 (161012) > *ge-0/0/3* Up 3405764281 (*148559*) 6036903599 (12097) > > traffic is routed from ge-0/0/3 to ge-0/0/0. *ge-0/0/3 is 100M* link, > which is not being used in full, ge-0/0/0 is 1G link: That link is full. A 100Mb Ethernet circuit can't carry more than 148Kpps. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 4 byte as mixed with 2 byte recieving problem
On Tue, Dec 11, 2012 at 6:04 AM, moki wrote: > The customer have 4byte as and requested we add prepend (with our > as) to Loop detection is preventing your RR from accepting the path. Do you actually need the prepend behavior to influence best-path selection inside of your network, or does the customer really want you to prepend your AS when you EXPORT the route to your EBGP NEIGHBORS? I think what you need is a mechanism for prepending upon export. Normally this is implemented by assigning a BGP community and doing the prepend in your export policy. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] small multitenant datacenter
On Mon, Dec 3, 2012 at 11:06 PM, Ryan Goldberg wrote: > Do you see an issue with blowing up ex4200s with all this ospf and vrrp? I'm > labbing tomorrow and will try to get the boxes to thrash. I'm interested to know your thoughts on RE performance after you have labbed this scenario. I've read the EX4200 supports 256 VRF-Lite instances, but like you, I imagine the control-plane may become sluggish before it gets to that point. I noticed you include the EX3300 in your design. I also considered this switch and decided against it once I read the feature table. I would like to use them once additional features are working, but right now, it lacks critical items like storm-control. https://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html Also, you mention both EX4200 virtual-chassis, and VRRP. I think it is unusual to choose BOTH V-C and STP+VRRP as redundancy mechanisms, because you get "the worst of both worlds" in terms of potential failure modes. For example, you get the unknown-unicast problems associated with ingress traffic arriving on the VRRP non-master and potentially being flooded out many ports of that switch, because it may never learn MAC addresses of downstream servers while it is the non-master. You also get any problems that you might encounter with virtual-chassis, meaning, bugs. I think you should pick one: V-C or STP+VRRP, depending on which technology you are most comfortable with. Mixing the two is IMO not smart, not because of any unique problems that arise from this combination, but simply because you have decided to expose yourself to two sets of gotchas without necessarily gaining anything. My experience with EX4200 virtual-chassis has been extremely good since Junos 10.4. Before then, we had problems with file system corruption on the EX4200, but this was fixed in 10.4. I have not had any serious stacking-specific bugs since about Junos 9.5. I rely totally on EX4200 virtual-chassis for redundancy in many environments, and am very pleased with the results. Good luck with your project. I hope my comments are constructive and helpful! -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Set weight (BGP attribute) in JunOS
On Sun, Nov 25, 2012 at 6:29 PM, Ali Sumsam wrote: > Actually I am working on migration from Cisco to Juniper. > On Cisco router weight attribute is used and have to set same preference > same on Juniper. > > Thats where I found that there is no weight in Juniper. > Good to know some thing :). I think you mis-understood the information you read in the documentation that Ytti referenced. Please see my earlier post on this thread. I will expand on it since you must not have gotten it clearly. On IOS, Weight is an attribute you can use to basically override the whole BGP bestpath selection process, and pick a path you want. This is a double-edged sword. If you use Preference1 on Junos to get the same effect you will sometimes have results that are different than you expect. Like I mentioned before, Preference1 on Junos is the same concept as Administrative Distance on IOS. You usually use it to make one routing protocol, or type of route, have better bestpath selection than another. For example, if you configure "distance" under "router bgp ASNXX." This matters because if you were to pick Preference1 = 100 for a route, and the rest of the configuration was basically the default, that route would be selected in favor of OSPF type E routes, which normally have Preference1 = 150. You might use such routes for learning 0/0 inside your network, etc. I think this is important for you to know before you finish your project. Otherwise, it may cause confusion later that you are not equipped to troubleshoot! -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Set weight (BGP attribute) in JunOS
On Sun, Nov 25, 2012 at 4:56 AM, Mihai wrote: > Weight is a Cisco proprietary thing and cannot be used with a Juniper > device. Maybe you could use preference (not local-preference). "preference" in JUNOS is like administrative distance on IOS. It's probably a good idea to mention this when suggesting its use as a substitute for "weight" because it is conceptually different. Like weight, though, it is possible to make your iBGP domain produce unusual results if you fool around with preference. Unlike local-preference, these changes are not signaled to iBGP neighbors. In a network like: A---B---C If you alter preference on router B, it is possible that router A will send packets for a prefix which it thinks will exit the network at router C, but in fact, router B has made a different bestpath selection and picked its own neighbor as the egress for that prefix. This may make the network confusing to troubleshoot. If you had BGP customers who weren't stupid, it would anger them. If you have labeled-unicast it would not happen though. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX110 and Cisco2970 MSTP issue
On Mon, Nov 19, 2012 at 6:04 PM, Ali Sumsam wrote: > If I try to set the priority on one of the SRX110 to become root bridge, > MSTP seems to be converged but there are huge packet losses in the network. > I removed the priority and one of the cisco2970 became root and then > everything seems to be fine. No packet loss after that. Just taking a wild guess here, but does the SRX110 have enough forwarding performance, and enough port speed, to switch all of the traffic between your 2970s? Check the CPU usage and link headroom when the SRX is root. Unless you manipulate your port costs, the configuration you suggested would have traffic going 2970#1---SRX110---2970#2. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX - DWDM no link
On Wed, Nov 7, 2012 at 2:37 AM, Luca Salvatore wrote: > This might seem silly but when I look into the XPF in the router I don't see > any red lights coming from inside the XPF. Normally when you look into a XFP > or SFP you can see the red laser inside it. I'm not seeing that with the XFP > in the MX. Should I be able to see a light? > > Any suggestions? I have configured the wavelengths on each side and the > interface is just configured as a simple inet interface. don't look into laser with remaining good eye! The light coming from that XFP is not within the visible spectrum. You can't see it BUT IT CAN DAMAGE YOUR EYE. Do not look into it! To be honest, I'm not sure your post isn't a troll! However, there are plenty of things that could be wrong with your installation. The Tx/Rx fibers could be reversed. You may be using the wrong wavelength for the underlying DWDM system. The fiber span may not be good enough for 10G -- are there other 10G waves working on it? 1G/2.5G waves? You might need amplification or chromatic dispersion correction equipment. Your XFPs could be bad. Maybe it's vendor fiber and it is not patched correctly? Perhaps you have in-building cross-connects which are not completed or are of poor quality? Who really knows? You have done zero basic troubleshooting steps. The reason why is (assuming you aren't a troll) you don't understand what you are doing. I think your project will be more successful if you find a local contractor to help you. This may sound rude, but you are not even working SAFELY at this point, let alone effectively. Get yourself some assistance so you can get the job done without damaging your eyesight or delaying your work. You probably need someone local to you, because there is a very big knowledge gap between what you've got (in this specific context) and what you might need to troubleshoot quickly and SAFELY. The mailing list can hand-hold you through it if you post more information and do a bunch of troubleshooting steps, but I wouldn't want to be on the phone with my dark fiber vendor going, "well, some guys on juniper-nsp told me to rent a light meter and I used it and can't see any signal from my other POP..." :-/ $0.02. Again, I apologize if my response seems rude, but you are going to harm your eyes! -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
On Fri, Oct 26, 2012 at 2:46 PM, Morgan McLean wrote: > fault tolerance. How reliable is VC? I've really done my best to avoid it I can't speak to EX3300 specifically, but on EX4200 the VC works very well. I have many stacks running for many years, and have had no stacking-related problems since before Junos 10.4R. We configure no-split-detection on VCs of two units (like TOR) based on our guess that it is much more likely one unit will fail completely, than the likelihood of split-brain happening where both switches are still working. If it did happen we would have a fast time-to-repair, and we think good MTTR is too often overlooked. -- Jeff S Wheeler +1 502-523-6989 Mobile Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Switch EX4200 doing broadcast for all ports from multicast traffic
On Fri, Oct 19, 2012 at 9:36 PM, Giuliano Medalha wrote: > We have 4 x EX4200 (4200-24F and EX4200-48T) running 12.1R3.5 code > connected using Virtual Chassis configuration. That's brave. Perhaps you should consider running a version of Junos that is less disasterous. JTAC would recommend 11.4R5.5 as of this week. We have yet to have good results from any 12.x release on EX3200/EX4200. http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476&actp=RSS -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How are max routes calculated on an SRX
On Wed, Oct 17, 2012 at 8:38 PM, Ben Dale wrote: > Table Tot Paths Act Paths SuppressedHistory Damp State > Pending > inet.0 1056579 354871 0 0 0 > 0 ... > Data plane memory576 MB Max 420 MB used ( 73 percent) <--- > FIB sits here It's probably worth applying some simple arithmetic. The DFZ today is 20% larger than in Ben's snapshot, above. Data-plane memory use obviously doesn't scale linearly with the number of routes, but it it did, his memory use today would be ~88%. Now add the IPv6 DFZ, which is still in its infancy at 10k routes today, but requires more memory per route (a lot more, depending on implementation.) You just ran out of memory. Today. Not with IPv6 growth in the future, or IPv4 growth in the future, but just by taking the current IPv4 and IPv6 DFZ. If I had that box deployed today, I would plan to upgrade it when needed. If I deployed it as a new device today, I would expect to be fired. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500-48S4Q-ACR
On Thu, Sep 27, 2012 at 9:15 PM, Julien Goodwin wrote: >> some hard-coded CoPP "accept" rules that you cannot override by > I know Trident+ (which this uses) has some weird limitations around this > area, any idea if this actually is one? No, I believe it is a choice by Juniper not to change it, because they think it will give customers "too much rope." I really doubt the chip is hard-wired to punt all BGP packets but that's basically what happens. Also the ACL TCAM is relatively small and CoPP rules use up a lot of TCAM rows. There are some Juniper KB entries on this. So if you configure say, like this: interface lo0.0 family inet filter input [ MYCOPP ] interface xe24.0 family inet filter input [ CUSTOMER1FILTER ] interface xe25.0 family inet filter input [ CUSTOMER2FILTER ] and MYCOPP uses up 30 TCAM rows (easily possible) then it will actually use 30, then 30 more (on top of whatever CUSTOMER1FILTER needs) for xe24, and yet 30 more for xe25 (plus that customer's filter rows.) So you can exhaust your available ACL TCAM rather quickly if you are doing much on it. >> I think QFabric is brain-damaged and doubt we will ever try it. > > Really? Any reasons why? (other than the whole locked optics thing) I think their whole concept for the control-plane is bad and unreliable. If you are considering QFabric I think you should buy enough hardware for testing and reboot the control-plane switches a few times and watch how long it takes to start working right again. They say they will/have fix the optics lock-in but I have not tested this recently. Just my $0.02 but I think QFX is good for L2, not so good for other things at this time. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] mx-class units now advertisement management interface networks in BGP
On Thu, Sep 27, 2012 at 1:49 PM, Jo Rhett wrote: > I don't know when Juniper broke this Hey, Jo, I remember Junos working like this since forever. I'm 100% sure it has worked like this since way before MX80 existed. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500-48S4Q-ACR
On Thu, Sep 27, 2012 at 7:13 PM, Dave Peters - Terabit Systems wrote: > We are considering deploying these for a customer's TOR, but I don't have any > experience with them. > > Anybody out there have experience or comments good/bad on these? Anything I > should know going in? We have several QFX in production in clients' networks, doing L2, and are mostly satisfied. We are recently working on a problem with high amount of unknown-unicast or multicast traffic but we are not sure the problem is the switch. If this is our only gripe, I'd say that is an indicator the switch works well. We haven't done any L3 or QFabric. The reason for no L3 is there are some hard-coded CoPP "accept" rules that you cannot override by configuration which make the switch unusually vulnerable to a DoS attack. Juniper says they will not address this, so we don't have hopes of using them for L3 in the future. I think QFabric is brain-damaged and doubt we will ever try it. Also, if you run software before 12.2, you should apply a fix suggested by JTAC to stop the switch from hanging when you plug/unplug the serial port, or send it a break. The PR# is finally un-hidden (now that they have fixed it, go figure) and is available below. You just need to modify /etc/rc.conf.platform or upgrade to 12.2. https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR769146 This is the worst problem we had with the QFX and it took us a lot of time to realize what was going on. Hopefully it will save you some trouble! Overall, I continue to recommend QFX to my clients for layer-2 where commit/rollback is beneficial. Outside of that, I believe it has limited application at this time due to the CoPP problems; but Juniper could decide to fix that if they think some customers will buy the switch because of fixing it. My $0.02 -- Jeff S Wheeler +1 502-523-6989 Mobile Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 bridge-domain QinQ question
On Sun, Sep 23, 2012 at 6:28 AM, Robert Hass wrote: > Could you paste working configuration here if you find solution ? As > I'm also interested in same configuration. Sorry, Robert (and others who might find this thread in The Google) small update: The previous configuration I pasted did not work because we need to manipulate the VLAN tags. On my EX-facing interface we had to make the following config: root@CR3.1250RL# show interfaces xe-0/0/3.423 description "CUSTXP xxx Internet"; encapsulation vlan-bridge; vlan-id 423; input-vlan-map { push; vlan-id 1428; } output-vlan-map pop-swap; family bridge; Notice above I am adding input-vlan-map and output-vlan-map. We tested this today and it works. I am not sure if we can do a swap-swap or similar in order to connect to more CE that have different outer-tags, though. :/ -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Config help for basic MPLS setup
On Mon, Sep 24, 2012 at 6:55 PM, Caillin Bathern wrote: > On point 2 there, the ex can only process one label at a time but there could > be a larger label stack than that so it can be a P router. I've been told the EX4200 will actually drop frames with more than one MPLS label. If you are able to get your proposed configuration working, please post a follow-up. I would like to know if it will indeed function as a P box. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 bridge-domain QinQ question
On Sun, Sep 23, 2012 at 6:28 AM, Robert Hass wrote: > On Thu, Sep 20, 2012 at 8:39 PM, Doug Hanks wrote: > [...] >> You'll just need to define each CTAG as you have been doing. > > Hi Jeff > Could you paste working configuration here if you find solution ? As > I'm also interested in same configuration. Hey, Robert, I have just configured a bridge-domain and associated LIFs per each CVLAN. It works just like this: root@CR3.1250RL> show configuration bridge-domains vl423 { description "CUSTXP xxx public"; interface xe-0/0/3.423; interface ge-1/1/8.14281; } vl424 { description "CUSTXP xxx LAN"; interface xe-0/0/3.424; interface ge-1/1/8.14282; } root@CR3.1250RL> show configuration interfaces ge-1/1/8.14281 description "CUSTXP xxx public"; encapsulation vlan-bridge; vlan-tags outer 1428 inner 423; family bridge; root@CR3.1250RL> show configuration interfaces ge-1/1/8.14282 description "CUSTXP xxx LAN"; encapsulation vlan-bridge; vlan-tags outer 1428 inner 424; family bridge; root@CR3.1250RL> show configuration interfaces xe-0/0/3.423 description "CUSTXP xxx public"; encapsulation vlan-bridge; vlan-id 423; family bridge; root@CR3.1250RL> show configuration interfaces xe-0/0/3.424 description "CUSTXP xxx LAN"; encapsulation vlan-bridge; vlan-id 424; family bridge; Basically, if we needed to haul a lot of CVLANs into the bridge-domain(s) for connection to several other sites, we would have to push an outer-tag onto the CVLANs using the EX4200 in the datacenter network, and pop them back off at their office CEs. That would allow doing it without b-d and LIFs per every CVLAN. We don't want to do the push on the EX4200 though, because in this instance, the customer only has one port on the datacenter network for mixed use. If the customer asked for a bunch more CVLANs to be hauled around for them we would ask them to take another switch port to simplify things. For only two CVLANs the above is pretty sane and better for us than making the customer take more ports. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 bridge-domain QinQ question
On Wed, Sep 19, 2012 at 4:07 PM, Doug Hanks wrote: > Use a SP-style IFL using 802.1ad for telco. Use a SP-style IFL using > 802.1q for the EX4200. The BD will automatically pop and push tags for > you. Could you give an example? I searched high and low in the KB and elsewhere. What I am doing now is below. The physical interfaces obviously have many other things connected and are setup with flexible-vlan-tagging and encap flexible-ethernet-services. interface ge-1/1/8.14281 { description "customer office via telco network"; encapsulation vlan-bridge; vlan-tags outer 1428 inner 423; family bridge; } interface xe-0/0/3.423 { description "customer servers via EX4200"; encapsulation vlan-bridge; vlan-id 423; family bridge; } bridge-domain vl423 { interface ge-1/1/8.14281; interface xe-0/0/3.423; } The above configuration works. Unfortunately, I must duplicate the above stanzas for each CVLAN. If I try to use vlan-id-list [ 423 424 ] on the EX4200-facing port, the IFL sees 0 packets. For example: interface xe-0/0/3.423 { description "customer servers via EX4200"; encapsulation vlan-bridge; vlan-id-list [ 423 424 ]; family bridge; } That commits but xe-0/0/3.423 never sees any packets arrive, and the BD never learns any MACs from it. Certainly it doesn't work as I thought it might. Using interface-mode trunk and configuring a vlan-id-list in the BD is not possible, as far as I can understand, because I can't work out how to configure the telco-facing IFL to push/pop as needed to get the outer-tag on it. It seems I can't use input/output-vlan-mapping in concert with a BD configured with a vlan-id-list in order to utilize mode trunk. Thanks -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX80 bridge-domain QinQ question
Dear List, I am having trouble figuring out how to configure a bridge-domain setup for customer traffic with QinQ outer-tags on some interfaces, but not all. My topology is as follows: CE---telco network---MX80---EX4200---CE In this case, the vlans between MX80 and EX4200 are single-tagged; but an outer-tag must be pushed toward the telco to direct them to the customer site. This is possible by creating a distinct bridge-domain, and logical interfaces, per each CVLAN. However, it will not work with vlan-id-lists or similar, which may allow me to avoid all that extra config per CVLAN. Various restrictions on when input/output-vlan-map can be used, etc. prevent me from configuring it. Obviously the savvy thing to do is simply push an outer tag using the EX4200, which then may be swapped as needed; but is it possible to configure this as I want, without distinct bridge-domain and logical units per each CVLAN? The restriction against doing push/pop operations on outer tags when vlan-id-list is in use seem to be stopping me. FYI I have tried on 10.4 and 11.4 boxes, so I do have interface-mode trunk; but it is unhelpful given the push/pop limits. Thanks -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP setup question, advertise-peer-as?
On Sat, Aug 25, 2012 at 7:26 AM, Morgan McLean wrote: > My main issue is I can't seem to get the advertised routes from firewall A > to be shared between the border routers. I know the nature of iBGP will > block this, so I tried enabling advertise-peer-as for just the border to I've read your posts to date. I do not clearly understand if you have a full iBGP mesh or not. If you do, ASBR-B does not need to learn FW-A's routes from ASBR-A. ASBR-B will already be learning FW-A's routes directly. If you want ASBR-A to re-advertise FW-A's routes to ASBR-B then you must use route reflection or similar. The advertise-peer-as feature is unrelated to what's going on here. I hope the above gives you a starting place. I think if you re-read the rules for when routers will re-advertise a route to an iBGP neighbor, you will quickly feel silly and wonder why you didn't figure this out yesterday :) -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF Forwarding Address
On Thu, Aug 2, 2012 at 7:59 AM, Benny Amorsen wrote: > If I replace router1 with a VRF on a Cisco 7600, Forwarding Address > is set to 10.10.200.1 and everything works as I expected. This is > obviously not my preferred solution :) Do router2 and router1 have an OSPF adjacency on the /27? This is required for forwarding-address to be set. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vmember limits in EX series stack
On Mon, Apr 30, 2012 at 11:15 PM, Naveen Nathan wrote: > I'm attempting to retire a cisco 6509 setup, replacing it with an EX4200 > virtual chassis configuration (8 linecards). I've run into a warning > when committing the configuration: I found your problem. You are attempting to retire a Cisco 6509 by replacing it with a closet full of stackables. That is a pretty foolish thing to do. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper SFP's
On Tue, Apr 24, 2012 at 9:02 PM, Skeeve Stevens wrote: > Juniper are really pissing me off in regards to their SFP's. Agreed. > Is there ANY actual difference between these SFP's? They are all the same > price from the distributor but they all have different availability - see > number above for example from one of my disties. Yes. The QFX3500 actually requires QFX-specific SFP/SFP+ and even the Juniper OEM ones for other Juniper products will not function in a QFX3500, at least as of 11.3. A little bird told me that they will remove the optics lock-in sometime this year. The sooner this happens, the better. I, too, am not willing to wait for Juniper to supply me with SFPs, especially since Juniper is honestly pretty bad at supply chain / logistics, and does not even offer colored SFPs for some of these products. Cost is not the overriding concern here, it is AVAILABILITY. We literally shipped a QFX3500 to a third-party optics vendor's lab and had them figure out how to re-flash generic optics so they would work in it. This because our SE gave us an incorrect answer about whether or not it would work with generics -- turns out it doesn't. One of my clients was so angry about this that they returned some of their QFX3500s and got their money back over this, and bought another manufacturer's product instead. I can only guess that the reason Juniper has different SKUs for the optics for different product families is that this is the mechanism they use to credit the optics revenue to the correct product group, and this must be why the QFX won't work with Juniper optics from other product lines. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] redistribute iBGP learned routes
On Sun, Apr 22, 2012 at 1:53 PM, Matthias Brumm wrote: > Thanks for your insight. I would like to clean up our structure a bit, > so I will go with route-reflection. If you are not very knowledgeable about BGP, you should probably avoid doing route-reflection (or confederating) until you have a more thorough understanding of how things work and your various options / caveats. You may not be aware that you do not need a direct circuit (or VLAN, etc) to establish an iBGP session from your access router to your edge router. Establishing iBGP sessions among all of your routers is the normal way of deploying a small BGP network. Route-reflection and confederating are good tools for scaling up, but in this case, you are using a complicated tool that has non-trivial caveats, because you do not understand some very basic things about how BGP works. This is not good for you or your BGP customer. :-/ -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JunOS 10.4R8.5 on MX5? Am I forced to run 11.4+?
2012/3/22 Timh Bergström : > I recently bought a MX5-T (Instead of the MX80-5G) and I'm running > 10.4R8.5 on my other MX80s and would naturally like to run the same > codebase on all my MX-series hardware. However when I try to install > the 10.4R8.5 release on the MX5-T it says that the platform is not > supported, I thought the MX5/10/40 was the same hardware as the MX80 > (it surely looks the same, side-by-side)? I just got an MX80 that won't boot 10.4 software. Like you, I did not want to upgrade to newer software yet, as my existing MX80s are all running 10.4R4.5 and we are satisfied with it. FYI my Midplane is REV 09, PEMs REV 04, QXM REV 06. All part numbers are identical to my existing MX80 routers in this network, the only difference is the hardware revision numbers, and the fact that this device doesn't seem to want to run 10.4. I guess I won't plan on deploying any new MX80s until I have time to test 11.2 or newer. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] default Junos on EX4200s currently shipping
I am resurrecting this old thread because we are still receiving new EX4200s from the distribution channel with Junos 11.2R1.2 on them. This version is so unstable on the 4200 it is pathetic. Juniper guys, please talk to whoever in the company decides what software ships on new products, and make a change for these switches. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] configure MAC address on MX logical unit?
I have a somewhat unusual network topology where it would really benefit me to be able to change the MAC address used on a given AE interface logical unit. This does not seem possible in 10.4 on the MX series. Is it available in any later release? For example, I wish to configure: interface ae0 { unit 40 { family inet { address ...; } } unit 50 { mac-address 02:02:02:04:04:04; /* different MAC for this unit */ family inet { address ...; } } } The "mac-address" statement above is imaginary, it does not exist in 10.4, but if something similar is available in a later release, it will compel me to upgrade eventually. I have tried tricking the router into doing this using VRRP, but I need to establish an eBGP session from this unit 50, and the router still transmits the BGP session packets with the hardware MAC address, not the VRRP address. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Set MED in BGP to IGP metric for iBGP NEXT-HOP router
On Tue, Feb 21, 2012 at 7:25 PM, Paul Zugnoni wrote: > I'm looking to set the MED on routes exported to eBGP peers to reflect the > IGP metric to the BGP protocol next-hop I did not see any replies to your question. Apologies if you already figured this out yourself. set metric igp already does what you describe. You will also want to read the documentation on `set metric minimum-igp` which is often what folks really want. Keep in mind that the MED will be set to the IGP metric to the protocol next-hop, NOT "the address of the router it learned the route from." You used both phrasings in your post. So for example, if you have a route reflector in your AS, a route may be learned from an RR but the metric will obviously not be based on the path to the RR, but the path to the next-hop. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-UM-2X4SFP- 2-port 10G SFP+ / 4-port 1G SFP Uplink Module
On Tue, Feb 21, 2012 at 3:05 AM, Skeeve Stevens wrote: > The common thought was that you could use EITHER the 2 x 10Gb OR the 4 x > 1Gb. You are correct. It will not operate in a mixed mode. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PVLAN for tagged VLANs on EX4200
On Fri, Jan 27, 2012 at 12:37 PM, Shane Short wrote: > I'm currently trying to figure out how I can deploy either PLVAN or some kind > of local ethernet isolation on my network. > I currently have a bunch of customers on /30 interconnects which are trunked > back to our EX4200 for aggregation. I'd like to somehow shift those customers > into a larger (say, /25) range, while forcing all the traffic through the > aggregation switch. I initially thought that PVLAN would do what I want, but > it seems to baulk I try and add one of the tagged VLANs into the mix. Basic > diagram is below (forgive my horrible ASCII art) Also note that the EX4200 does not support l3-interface on a private vlan. In this role it is useful for L2 but not a mix of L2 and L3, for private vlans. The 4200 might not be able to do what you have planned. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 missing ARP entry work-around
We have decided on a better work-around for our missing ARP entry problems on the EX4200 and friends. As you may recall, the EX4200 will sometimes have an ARP entry in the control-plane, but it will not be present in the data-plane. You can investigate by checking your destination IP address with the command `show halp-rt route ip rtt-index 0 prefix 192.0.2.2 prefix-length 32` which will produce output like this: PFEM0(vty)# show halp-rt route ip rtt-index 0 prefix 192.0.2.2 prefix-length 32 RouteType Paths RtIdx Rpf SipSa Row:Col:Row:Col - - --- - --- 192.0.2.2 ECMP 0 2037 No No439:0:0:0 Dev0 (RtIdx:2037) - Command : Route CpuCode: 3 AppSpCpuCodeEn: 0 UcSipFiltEna : 0 TtlDecEna : 1 TtlOptChkBypass: 0 IngressMirror : 0 QoSProfileEn : 0 QoSProfileIndex : 0 QoSPrecedence : 1 ModifyUp : 2 ModifyDscp : 0 CounterSet: 2 ArpBc2Cpu : 0 SipAccessLevel: 0 DipAccessLevel : 0 IcmpRedirExpnMirr : 0 MtuProfileIdx : 2 Ipv6ScopeCheckEn : 0 Ipv6DstSiteId : 0 NhTnnl: 0 NhTnnlIdx : 0 NhVlan: 6 NhIf : VIDX4095 NhArpIdx : 138 Device: 0 ArpEntry Idx 138 : 00:2b:f0:19:87:01 Hit/Miss : N Notice above a reference to NhArpIdx 138. In order for forwarding to work correctly, there must be an entry # 138 in the `halp-nh arp-table.` Since there isn't one, the NhIf shown is VIDX4095, not a port. However, if you want to verify that there is no NhArpIdx 138 in the hardware, you can examine the table with `show halp-nh arp-table` and scroll down to where # 138 should be. You won't find it! PFEM0(vty)# show halp-nh arp-table Device: 0 ... lots of scrolling ... ArpEntry Idx 136 : 00:18:8b:f8:b6:6e ArpEntry Idx 137 : 00:0e:b6:2d:01:a0 ArpEntry Idx 139 : 00:19:b9:f9:24:2a ArpEntry Idx 140 : 78:2b:cb:3c:91:60 How do you get the switch to populate that entry? Well, since `clear arp` on the EX4200 doesn't actually do what it is supposed to do, what we have been doing in the past is deleting whole subnets, impacting potentially many machines, and then re-adding them. This is not good but it does work. Our new solution is much better. We just add a bogus static arp entry for 192.0.2.2, pointing to some made-up MAC address, and then we commit, roll back, and commit again. Like magic, the ARP entry will re-populate correctly. Almost as if you really did have a `clear arp` command on the EX4200, one that worked right! After adding and then deleting the bogus static ARP for 192.0.2.2 you can re-examine the PFE and see the results. Also, your customer's Internets will begin working correctly again. I hope this helps. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
On Sat, Jan 7, 2012 at 8:48 PM, OBrien, Will wrote: > I'd make darn sure that Juniper knows that this is an issue for you. In fact, we've let them know that the competing vendor is getting 60% more money for a comparable product; but that large price premium is worth it given the obvious logistical issues with stocking vendor-coded optics. Juniper could give me optics for free and it still wouldn't be acceptable. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] QFX3500 optics lock?
We just received our first QFX3500s, and contrary to what the Juniper SE told us, they will not work with non-Juniper optics. Is there some clever, undocumented means of using third-party optics in these switches? JTAC says it will "never" be compatible with non-Juniper SFP+. Right now it looks like we will be sending them all back and going with another vendor. Glad I wasted my time doing Q&A with the sales engineer.. :/ -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX3200 proxy-arp behavior
I'd like to describe proxy-arp behavior I am observing on the EX3200. I am not sure it is really doing the right thing. It certainly isn't ideal for my topology. I have an ISP who is unable or unwilling to route additional subnets to my client via routing protocols or static routes. They simply add secondary interfaces to their router for everything. I would like nothing more than to abandon these jokers, but in the mean time... allocation A 192.0.2.1/29 my EX3200, .7 ISP router allocation B 203.0.113.128/25, .254 is their secondary interface, but I split this subnet into various /30s and similar, and 203.0.113.254/31 is not utilized (so goes to default route, 192.0.2.7) allocation C 198.51.100.96/27, .126 is their secondary interface, and I have the whole /27 configured on one of my downstream interfaces So my ISP uplink port looks like this: > show configuration interfaces ge-0/0/23.0 arp-resp unrestricted; proxy-arp unrestricted; family inet { address 192.0.2.1/29 { primary; preferred; } address 198.51.100.125/30; } Notice the additional 198.51.100.125/30 subnet configured on my ISP-facing interface. This was required because the EX3200 receives the ISP's ARP WHO-HAS from 198.51.100.126 and, without this /30 configured, it either fails to respond to them or sends them out the wrong interface (not sure which.) As you may imagine, the ISP also sends me WHO-HAS sourced from 203.0.113.254, but because I do not have a route for that, the ARP behavior is "correct" without anything hackish, for that allocation. Obviously the solution to this is "don't design the network stupidly" and maybe it wouldn't operate stupidly, but I found the behavior described above surprising. I think the EX3200 should simply respond to the ISP gateway's WHO-HAS based on the L2 address of the request and ignore the "tell 198.51.100.126" entirely. That is not what happens. I do not think there is a standard behavior defined since all this proxy arp garbage is evil anyway. Insights or comparisons with other vendors' behavior appreciated -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] TASK_OS_MEMHIGH on ex2200
On Mon, Jan 2, 2012 at 11:44 PM, Maciej Jan Broniarz wrote: > Today my switch started dropping traffic and in logs it says: > > Jan 3 05:30:49 ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of > memory, 100 percent of available > Jan 3 05:31:49 ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of > memory, 100 percent of available > Jan 3 05:32:49 ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of > memory, 100 percent of available It looks like vccpd has leaked a lot of memory. You may drop to the shell and kill off vccpd, hoping that the switch returns to a working condition momentarily, rather than freaking out and requiring a reboot. Personally, if I were you, I would just reboot it anyway. If you expect multi-year trouble-free uptimes from your switches you made a bad purchase with the EX-series, and I say that as someone who does advocate using them for certain things. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Issue related to ARP learning
On Fri, Dec 30, 2011 at 3:05 AM, Sachin Rai wrote: > The thing is when I ping the IP 192.168.1.2 from EX4200 and run command 'show > arp' then it displays 192.168.1.1 and 192.168.1.2 binded with > aa:aa:aa:aa:aa:aa, and after this the IP 192.168.1.2 is pingable from > external network. > > I want to know why EX4200 is not displaying all the IPs configured on the > interface binded with MAC aa:aa:aa:aa:aa:aa. Can anyone help me on this > situation or explain me what is happening. Sachin, could you post what JUNOS version you are using? If I were you I would investigate in more detail, by using tcpdump or similar on the server, and verify that the EX4200 is not sending ARP WHO-HAS to the LAN when you try to ping 192.168.1.2 from the external network. With the information you supplied so far, I think the most likely explanation is that your servers are somehow mis-configured. I would be the first to say ARP on EX4200 is bug-ridden and needs serious attention, but with the limited details you supplied so far, I do not think the EX4200 is malfunctioning. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] default Junos on EX4200s currently shipping
On Wed, Dec 14, 2011 at 5:14 PM, Chuck Anderson wrote: > Are these the old EX4200-48P, or the new PoE+ EX4200-48PX models? The > new models require 11.2 (but they should have loaded a later R). This is the vanilla EX4200-48T. I can't imagine why it is shipping with 11.2R1.2. I just got these last week. My last batch had 10.something and at least weren't crashing right out of the box. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] default Junos on EX4200s currently shipping
Dear List, and Juniper lurkers! The EX4200s we have been purchasing lately are coming with Junos 11.2R1.2 installed from the factory. That version is totally unusable. Various processes crash at the most trivial operations, commits, and the CLI even crashes when editing the config (before making any commit) in some cases. Yes, we change the software before we deploy the switches, but I would hate to be an unsophisticated customer who just expects the switch to mostly work right out of the box. It's a PITA even for me to get software onto the things when they are drop-shipped to POPs with connectivity and serial consoles waiting. Perhaps putting a Junos on the switches that is remotely stable when shipping them out from the factory would be a good idea. I'm sure this is obvious, but maybe the Juniper folks on the list could communicate this obvious idea to the people who decide what version ships on new units. Merry Christmas! -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX as BRAS / demux
On Thu, Nov 17, 2011 at 12:32 PM, Bjørn Tore wrote: > interfaces { > demux0 { > no-gratuitous-arp-request; On other types of interfaces, you would also need no-gratuitous-arp-reply, but it can't be configured there. :-/ Perhaps there is an ER#? -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] TCAM full on EX8200?
On Sat, Oct 22, 2011 at 12:19 PM, Pavel Lunin wrote: > As far as I understand, it's not really correct to compare difficulty of > these two operations, since they are performed by two different units inside "I don't think you should compare difficulty of building a birdhouse to building a doghouse, because a doghouse requires more materials." You could use that argument over and over again, and as long as people actually believed it made sense, they may agree with you. Except it doesn't. Some things are harder than others. > router. Hashing ALU's life is not a peace of cake either. Say, EX series PFE > use only 6-bit seeds to construct hash on them. In case you want to push a > whole 20-bit label to the hash seed, I'm afraid, you'll need more bits in > ALU registers, more cycles or something else. Do you realize that the source and destination IP address, TCP ports, MAC addresses, and so on, are all larger than 20 bits? If the thing can figure out how to hash on those parameters, it could also figure out how to hash on labels. > I've heard (please correct me if I'm wrong), that the $1 per bucket ASICs, > used in switches, are VLIW, which is hard to reprogram. While the more > expensive ones, custom developed for routers, are rather sort of more > flexible tiny MIMD computers with asynchronously working units inside. To focus just on the instruction format is a bit myopic, but again, if a chip can do Ethernet switching and IPv4 / IPv6 routing, it can also easily be made to do label switching. Push/pop/swap is no more difficult than dealing with a mixture of native and 802.1q ports. The hardware side of things can seem very complex until you understand it thoroughly. Then you realize what Richard keeps saying: the secret sauce is really the control-plane software. Hardware is basically a commodity now. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] TCAM full on EX8200?
On Fri, Oct 21, 2011 at 6:24 AM, Pavel Lunin wrote: >> http://tools.ietf.org/html/draft-ietf-mpls-entropy-label-00 > > Keeping in mind what we discussed in the next thread, it's way too > complicated for the cheap ASICs, used in ethernet switches. Most of them, as > far as I understand, are just hardcoded to extract bits with given offsets > and that's all. In addition, looks like they have a limited-size memory > cells (registers or whatever), on which they can do xor/mod/cmp/etc for the > hash-key calculations and hash-key->next-hop mapping. Size of one MPLS header: 4 octets Size of one IPv6 header (w/o TCP, etc.) 40 octets Since many of these devices have IPv6 routing capability (with a limited FIB size) it is certain that they can look far enough into the packet to see as many labels as any reasonable design will require. Whether or not they have the ability to understand those labels is another matter; but if a chip can route IPv6 it can sure see as many labels as you are likely to require. On Fri, Oct 21, 2011 at 7:21 AM, Pavel Lunin wrote: > BTW, this is why I'm quite sceptically looking at the Juniper's marketing of > Express Chip simplicity and corresponded benefits. Lower number of I share your skeptical view of the PTX. The power requirements they have published (estimates, I imagine) are relatively high and FCS density is not terribly exciting. I hear the price is also not going to be very exciting. They have not said how much buffer it will have, which would contribute to energy consumption. As far as how they have decided to implement PTX, I guess if you are a big enough customer, you can just ask them. The forwarding look-up itself is trivial and, assuming packets are arriving at a rate of 300MHz (two 100GbE interfaces) you could do it without any off-die memory at all, which means you save pins and power by eliminating off-chip memory banks. The internal buffering / queuing across the system fabric is probably more complicated than the destination look-up. QoS is another complexity. i doubt it is quite as simple as "install less SRAM and rate the ALUs for more Mpps because they are doing less work per packet," but certainly one area of the process does get much less complicated. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] TCAM full on EX8200?
On Sun, Oct 16, 2011 at 10:02 AM, Julien Goodwin wrote: > Arista is the one company that seems poised to actually take this on and > keep coming out with good hardware, at a decent price, with a powerful, > open control plane. Their kit isn't Openflow interoperable yet that I > know of, but that should be doable. Every time I speak to Arista, I say, "you know, if your software had MPLS features at this price-point, we and everyone else would like to buy a lot more of them..." but they do not seem to understand the size of the market that is available to them. I'm sure they are doing a lot of good business in 10Gb ToR / End-of-Row, and are clearly quite good at it. The large amount of R&D needed to be an MPLS P box is, in their mind, not worth the potential business. I hope all of you guys say the same thing to your Arista rep whenever you order their kit for more ordinary uses. I agree that the biggest threat to Juniper and Cisco is Arista, but I don't think Arista knows it! :-) -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] TCAM full on EX8200?
On Sat, Oct 15, 2011 at 6:04 AM, Phil Mayers wrote: > ...whereas because ACLs are variable length, determined by customers and > possibly large, performance of a RAM-based ACL algorithm is hard to predict, > and people want predictable performance, and usually line-rate performance. It's not so much that it's hard to predict -- it isn't. It's hard to market. Customers can't understand that the 100 line ACL in front of their server farm is spending too much time walking a structure (or executing instructions) read from RAM. They can understand if the vendor says "wire speed" and that's what is marketable. The trade-off is flexibility, which you mention below... > Having said that - personally I might be willing to trade line-rate > performance for (say) an ACL mechanism with near line-rate for simple ACLs, > the option of a "jump" opcode, and some way of knowing what the exact > performance (range) of a given ACL/interface combo would be. Most customers find that their Juniper boxes still operate at wire rate even when they load up some ugly filters. On some boxes in some cases, however, that is not true. But to generalize, M/MX does everything with RAM, provides the operator with more flexibility, but also gives him a little more rope with which to hang himself. > Do I take it that non-destination-based routing (policy routing, filter > based forwarding) are therefore implemented differently on boxes that use > RAM-based forwarding? "There's more than one way to do it," but to use M/MX as an example again, this still happens using RAM. In a box designed for routing tables (or MAC/ARP/MPLS/etc) the size of what M/MX delivers, CAM is not the most effective solution. Could they glue some on for the purpose of accelerating large ACLs? It depends on the match terms. CAM still cannot implement the fancy operations you can do with Juniper firewall filters in one operation; all it can potentially do is accelerate the types of filters that optimize better into TCAM matches than ALU+RAM searches. I doubt Juniper has ignored the possibility of grafting some CAM onto their "router" boxes for certain operations, but when you already have the ALU+RAM method R&D'd and you can simply scale it up a little bit, this is probably more sensible than adding a power-hungry CAM and all the guts necessary to interface to it, and then do more R&D to have the control-plane figure out how to take advantage of it, and *then* still live with the fact that Juniper firewall filters *still* give you the flexibility to make that operation not perform at wire rate also. > Hehe. "Tag switching will make core routers really cheap, you'll have a few > really big PE routers only". Wasn't that the line we were sold with TDP? I see Richard has covered this in his follow-up. I'm sure you eventually will get those cheap LSRs, but there is no reason for Cisco or Juniper to be the first to market these devices. Either one of them could decide to spin up that product, glue it all together from their existing technology, and ship it in no time; but why would they when that would take away from big iron product segments? -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] TCAM full on EX8200?
On Fri, Oct 14, 2011 at 3:52 AM, Michele Bergonzoni wrote: > can only be done with TCAM. For those who want more info on this issue, this > is the very interesting reference that I received in a private email: > > http://www.firstpr.com.au/ip/sram-ip-forwarding/ I wouldn't use that particular document as a "reference." On Fri, Oct 14, 2011 at 6:08 AM, Phil Mayers wrote: > On that topic; I'm familiar with how TCAM can be used to accelerate routing > lookups, but less so with SRAM. Is the SRAM used to implement a "simple" A CAM electronically searches all of its rows for matches at the same time. It is relatively expensive in terms of power/heat. It has never been a particularly smart way of doing many kinds of look-up operations. It is useful is when the data set is small, the size of the rows / number of bits to search is fairly large, and distribution of keys is basically random. This is why CAM is used for Ethernet switching, TLB in microprocessors, etc. When your data set grows, like the DFZ, it is less expensive to have an ordinary RAM and search algorithm. Which particular kind of RAM is in use is not all that exciting, but in routers that use some kind of tree search, you can find all manner of SRAM and DRAM. There has been some mention about TCAM being good at ACL matching. It can take a whole lot of ALU operations and RAM accessing to figure out if a given packet should pass an ACL or not, and this is especially true if you have those long ACLs blocking or allowing a ton of TCP ports, etc. At some point, it still becomes cheaper to implement ACL with an ALU and RAM than with a TCAM. The reason vendors do not want to do this is the TCAM can evaluate a very large ACL in one step, while a ALU+RAM might be more power-efficient, if you have a ACL with hundreds of entries, it will take a long time to process packets, and you will not have wire speed performance anymore, on packets trying to compare against that big ACL. Predictable performance is important and it is a lot easier to predict the performance of a CAM/TCAM (because it is simple) than of other methods. From the operator's perspective, you don't want to hear that you might lose wire speed forwarding if you have more than 17 ACL entries unless the optimizer figures out a clever way to install them into the memory in which case 80 entries might work just fine. You just want your ACLs to work. Of course, Juniper does do ACL with ALU+RAM in most boxes, and so you can indeed create this problem for yourself. This is often not obvious until you have a few millions PPS passing through a filter that it cannot optimize into anything clever. It is nice to understand how your routers work at a deeper level. More often than not, though, all it will do is make you wonder how a given product ever shipped or make you angry that you can't just get an MPLS P box for the same price as an Ethernet switch. :-) -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] what happens in JUNOS when interface is disabled/enabled
On Sun, Oct 2, 2011 at 9:56 PM, Tim Harman wrote: > Reminded me of the old days (or maybe still modern times, I wouldn't know) > on a Cisco box where "no ip cef ip cef" would usually fix these sorts > of problems. It feels like we are having progressively more "CEF problems" with Juniper boxes. It would be really great if Juniper provided some commands with the intent of bringing the PFE back into sync with what the control-plane says should be in it, in a low-impact manner that does not involve bringing interfaces down and up, bouncing fabric modules, literally or effectively rebooting, etc. Of course I would like to have fewer malfunctions / bugs, but I can live with them more easily if getting the box back to a correctly-functioning state is a low-impact operation. I don't think Juniper really gets this. Bugs happen, that's life; but if the vendor provides a relatively pain-free way to remedy the situation, it can save us from tough choices like, do we reboot a box at 2pm to restore correct function, or live with some serious headache and customer gripe until 2am when a reload will cause less collateral damage to unaffected customers or services? -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M10i JUNOS Upgrade
On Wed, Sep 28, 2011 at 2:43 PM, Jake Jake <2012j...@gmail.com> wrote: > I am looking at upgrading the JUNOS on our M10i router. Current JUNOS > platform is 6.3R1.3 . The router has redundant routing Engine RE-5.0 with > 512MB DRAM . Also there is no compact flash on board only *ad1s1*. Can any > one suggest on if I can upgrade the router to 11.1R5.4 with the current > hardware specification . Please advise on if a direct upgrade can be done > as well from 6.3 to 11.1. If you have DFZ routes you should upgrade the RAM to 768MB, or alternatively, replace the router or buy more modern routing engines. There is a big jump in memory usage in 8.x and if you have only 512MB and are carrying "Internet" BGP routes, you will be using the swap and the RE will perform badly. No, you cannot do a direct upgrade from 6.3 to 11.1. You'll be going through quite a few intermediate software versions to do that. It will be easier to simply reinstall Junos from an 11.1 install-media disk and then load your configuration. > Plus as I understand M10i has 3 DRAM slots. Is there any way of knowing the > combination of RAM used ..i.e 256+256MB or a single 512MB RAM. I don't think the RE-5.0 will recognize more than 256MB per slot. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Interesting EX4200 gotcha and "resolution"
On Mon, Sep 26, 2011 at 1:39 PM, Brent Jones wrote: > Did you observe any strange entries in /var/log/shadow when these events > occur? > I've had similar issues, where some EX4200's in a VC lose the ARP > table, and traffic cannot transit the switch to another switch (if the > traffic must go through that VCP). > JTAC was unable to find any root cause, but there were number errors > in /var/log/shadow about the ASIC forwarding table didn't match what > was in software/memory No, the only entries present in /var/log/shadow.log are the mysterious "Non RTG error" messages that it logs every ~5.5 minutes. In this instance, the VC contains two EX4200-48T and both switches have identical halp-nh arp-table data, with both missing the same entries. What the root cause is, who knows; but if Juniper wanted to provide me with a "fix" they could make "clear arp" actually clear the arp entries. This happens so rarely that it's only a problem because the obvious fix that NOC guys try before escalating does not work. I am hoping a future instance of this problem will get escalated to me so I can try installing a static ARP entry with a different MAC and then removing it, which should correct the problem without impacting other machines on the subnet. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Interesting EX4200 gotcha and "resolution"
A colleague pointed out recently that some of the gotchas and fixes we run into are interesting to others, so in that spirit, I have another one to share with you today. In this case, a malfunctioning EX4200 (10.4R4.5) appears to have valid ARP entries for a few boxes, but when you try to ping them, etc. the boxes do not get any traffic. In fact, they receive nothing from the switch except ARP who-has. They respond, and upon clearing the ARP entries from the EX4200, that process repeats. Upon investigating the PFE data, I found that the halp-nh arp-table was missing these ARP entries, even though they were present in the Junos CLI and indeed the correct MAC address is referenced in the PFE route table. See below: PFEM0(vty)# show route ip prefix 192.0.2.39 detail IPv4 Route Table 0, default.0, 0x0: Destination NH IP Addr Type NH ID Interface --- - - 192.0.2.39 192.0.2.39 Unicast 2933 RT-ifl 197 vlan.1122 ifl 197 RT flags: 0x, Ignore: 0x, COS index: 0 DCU id: 0, SCU id: 0, RPF ifl list id: 0 PFEM0(vty)# show nh id 2933 detail ID Type InterfaceNext Hop AddrProtocol Encap MTU Flags PFE internal Flags - - --- -- -- 2933 Unicast vlan.1122 192.0.2.39IPv4 Ethernet 0 0x 0x Flags: 2 nh_idx: 3 CMD: Route Arp Idx: 1341 MTU Idx: 2 Num Tags:0 Upd Cnt: 1 Tun Strt:False Chain_nh 3484: Hw install:1 Mac: 00 0e 0c a2 2d dc PFEM0(vty)# show halp-nh arp-table Device: 0 ...hundreds and hundreds of lines... ArpEntry Idx 1340 : 00:15:17:6b:a9:7c ArpEntry Idx 1342 : 00:25:90:2c:41:e5 ...hundreds more, but where is Idx 1341?! Our "fix" is to remove 192.0.2.1/27 from the vlan.1122 configuration, commit, and then rollback. This is obviously not good. I would like to have tried installing a different ARP entry (by configuring this IP address on another machine) but I have not had an opportunity to test this yet. The reason this is happening is the ASIC vendor format ARP table in the PFE memory is abstracted from the "Juniper ARP table," as I understand. It appears that simply refreshing the Juniper ARP table with an identical entry does not cause a missing entry to be put into the forwarding table. I would love to be able to reproduce this, but with hundreds to a few thousand machines each on many EX4200 stacks, it happens very rarely. I only mention it because "clear arp" from the CLI does not work, so this problem gets escalated until it reaches someone brave enough to temporarily break some unaffected boxes to fix a broken one. It would be nice, though, if "clear arp" actually worked right. If you encounter this problem and do something different, I would be very interested to hear from you! -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
On Wed, Aug 31, 2011 at 2:04 AM, Dale Shaw wrote: > On Wed, Aug 31, 2011 at 3:49 PM, Chris Kawchuk wrote: I don't want to make a giant vlan and put all the devices loopbacks in it, one for scalability issues but also for broadcast related issues. > > But is it really an unscalable solution? > Is it really going to suffer from "broadcast related issues"? My argument against that design is simple: spanning-tree. Why expose yourself to one more thing that can, and sometimes does, malfunction? We live in a world where multi-vendor L3VPN works pretty good, but spanning-tree is apparently really hard to figure out, especially for some vendors who are particularly good at routing and not so experienced at Ethernet bridging. There are plenty of other good reasons not to do a big vlan for all the routers in that area, but the reason above should be good enough for anyone. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RE-600 SOLID STATE DRIVE NOT RECOGNIZED
On Thu, Aug 25, 2011 at 3:00 PM, Mario Andres Rueda Jaimes wrote: > I'm trying to install a 8GB SSD in a RE-600 with compact flash of 2G but > > Anybody has performed this before or has suggestions ? We use this model drive, a 16GB with old-style parallel IDE connector: http://www.amazon.com/gp/product/B000T9S52W/ref=oss_product -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M20 SSB E Memory seller required
On Wed, Aug 10, 2011 at 2:03 PM, Chris Cappuccio wrote: > (Of course if I installed an M20 with an SSB-E, i'd put 128MB of DRAM in it > just on principle) Unless I was very budget-constrained or needed a lot of P-type slots for terminating DS3/OC3/OC12 interfaces, I would try pretty hard to get a new router instead of throw more time and money at an M20. I thought this might be worth mentioning, as the platform is certainly dated. If you have enough routes in PFE that you need the SSB-E-16, your control-plane is probably not very fast. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Junos Pulse / SRX240 problems
I have a very simple VPN configuration for a non-uptime-critical service, with an SRX240H and Dynamic VPN client licenses. This worked fine with Junos 10.4R4.5 (JTAC recommended release) and the Juniper Access Manager client. However, Dynamic VPN sessions were becoming "stuck," and hours or days after a user had disconnected, they would still appear in `show security ike ...` and still consume Dynamic VPN licenses as reported by `show system licenses`. The same users were shown many times, etc. I have tried 11.1R3.5 and it has solved the stuck IKE associations / license exhaustion issue, but the Junos Pulse client is not working well. JAM does work fine, but the web front-end installs Pulse for end-users now. From my test machine, I can sometimes connect the VPN on the first or second try, but usually have to enter login credentials at least twice. Where it gets problematic is if I disconnect and later attempt to reconnect, I might enter my login and click continue 50 times before the VPN session is established, if it ever works at all. Restarting Pulse does not seem helpful, but rebooting the PC does. I have not tried rebooting the SRX, but I find no entries cleared when issuing `clear security dynamic-vpn all` and that does not appear to influence the problem. Before someone asks, since this works perfectly with the JAM client, I do not think the SRX configuration is any issue. This config is as simple as can be, without even a RADIUS server yet. My impression right now is that the Pulse client is too buggy to deploy and I should downgrade back to 10.4R4.5 so users will receive Juniper Access Manager instead. I have read a few similar opinions on the Juniper forums. I would appreciate any thoughts you guys have. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Back-reference in JunOS regular expressions
On Thu, Jul 14, 2011 at 3:00 AM, Jonathan Lassoff wrote: > Honestly, what's the use case of a backreference for an AS path? If you have that feature, you can detect as-path prepends and use that to influence your path selection. http://juniper.cluepon.net/ER_Detect_AS-PATH_prepends -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] bgp to ospf
On Thu, Jun 16, 2011 at 12:48 PM, Payam Chychi wrote: > Were you able to figure this out? I don't have lab gear to test this correctly, so please take my post with a grain of salt. Please excuse the use of gmail "Rich Text" to get a fixed-width typeface in my composer: /\ || ASBR1ABR5---ASBR3 ABR5 redistributes 192.0.2.0/24 into iBGP, but not into OSPF. ASBR3 redistributes same /24 from BGP into OSPF as an E2 with "set next-hop" to ABR5 loopback in the routing policy. ASBR1 learns the E2 route and its RIB (and FIB) show a next-hop directly to ABR5 However, in ASBR1 "show ospf database external" CLI output, the Fwd Adr is 0, not the ABR5 next-hop. I am really not surprised by this, because the purpose of OSPF Forwarding Address is, as expressly documented in relevant RFCs, for situations where several routers are using a multi-access or broadcast media (frame-relay, Ethernet, etc.) to reach an external neighbor, yet not all of these routers have routing protocol sessions to same neighbor. For example: AS16631 | == || ASBR1ASBR2 || AR3 AR4 In this stick-figure, === might be Ethernet, ATM, Frame, smoke signals, whatever. What matters is you will have eBGP from ASBR1 to the external neighbor AS16631, but not to ASBR2. However, if you want ASBR2 to be capable of routing traffic directly to AS16631 without sending it through ASBR1, you can use OSPF External routes with Fwd Adr set to the next-hop address of AS16631 (imagine that ASBR2 just doesn't have the capability of speaking BGP.) In fact, on Cisco IOS, the router will not let you accidentally send Fwd Adr if you send these External routes also to AR3. It will omit Fwd Adr and so AR3 will utilize ASBR1 to reach the neighbor. So Fwd Adr is only set on LSAs flooded to the === interface. Further, I do not believe ASBR2 would preserve Fwd Adr when sending LSA to AR4. As I mentioned, take my post with a grain of salt. I may be incorrect here about the actual functioning, as I have never, ever had reason to utilize this in a practical network. But if you do some reading, the intended purpose of Fwd Adr is expressed above. The original poster should not be using it for what he wants to do (I don't think it will work), and should instead utilize BGP or change his topology. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX loopback filter and monitor traffic
On Thu, Jun 16, 2011 at 10:53 AM, Clarke Morledge wrote: > However, if I do a "monitor traffic" on the loopback interface itself, I see > nothing: I like to think of "monitor traffic" as something which is nice when it works the way I hope it will, but isn't something to really get concerned about when it doesn't behave as expected. If you really need detailed information to debug a problem, mirroring traffic to an interface (or a GRE tunnel, etc.) and doing packet capture on a PC is more reliable than betting on the output of "monitor traffic." -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SSH/Telnet session hanging
On Wed, Jun 1, 2011 at 8:49 PM, Richard A Steenbergen wrote: > Well first off I hope you actually meant "something LOWER than 1500 > bytes", since tcp-mss doesn't include the headers that go into making up > the 1500 byte IP packet. At a minimum you're looking at 20 bytes of IP + > 20 bytes of TCP, so an mss of 1460, but don't forget to leave room for > things like TCP MD5. I used to be confused about this, because RFC 879 and RFC 2385 (and a host of others) do not agree. Once I spent a week fighting with an IOS bug whereby the router sends packets/frames which are 20 octets too big when TCP MD5 is enabled (going so far as to actually send them out interfaces and cause the Giant counter on the remote side to increment a few times every time the BGP session flapped) I decided to take this conservative approach. I believe that IOS now does what RFC 2385 suggests (but older IOS is just badly broken) and I think JUNOS follows RFC 879, and deals with TCP Options by stuffing less payload into segments, interpreting the MSS as including Options and payload, but not the earlier things in the TCP header. At least, this is what it did when I spent the better part of a week on this problem. > But more importantly, the maximum packet size for BGP is limited to 4096 > anyways, so the 9000 vs 9192 path mtu really doesn't make any difference > at all. :) I suppose I could also take this opportunity to gripe about It is important not to confuse BGP Message size as being directly related to MSS or MTU in some way. It isn't. I have written some posts on the IETF IDR list recently on this subject. A larger MSS than the BGP Message size certainly can be taken advantage of by a BGP speaker. To observe this, all you must do is disconnect an iBGP neighbor from an IOS box that is simply sending routine keep-alives, and then cause it to send an update. The keep-alive will go out, fail to be ACK'd, and perhaps the same thing will happen to the update. Either way, when it is time to retransmit the keep-alive, the IOS BGP Router will not just re-send the same segment with only the keep-alive Message -- it will add the extra payload of the subsequent update Messages and retransmit as a larger segment. Also, a normal TCP stack has a transmit buffer in the kernel, plus it has a TCP Window to deal with as well. It can accept more data into its transmit buffer than it is allowed to have in-flight over the wire before receiving ACKs. This will cause some Messages to be buffered in the kernel and be transmitted together as bigger segments once the TCP Window advances a bit. > an ongoing bug where Juniper's TCP stack occasionally thinks that the > mss is ~64k, resulting in blackholing of the tcp packets and endlessly > flapping sessions, but if I get started bitching about new junos bugs > that are making my life hell right now I might not be able to stop. :( This probably wouldn't happen if the perfectly-good TCP stack in the kernel was left alone to do its job. :-/ -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SSH/Telnet session hanging
On Wed, Jun 1, 2011 at 12:14 PM, Mark Tinka wrote: > It's probably time to break out the 'tcp-mss' option for > BGP. This is exactly the reason that BGP implementations used to default to MSS 536 for all iBGP sessions. The change in default behavior has happened over the past five years or so, and it is not without peril. Customers and vendors have thought that raising the MSS will improve convergence speed, and they are correct that it has shown to result in some improvement; however the same improvement could be had with larger TCP windows and less stupidity with respect to TCP inside BGP daemons. This has been a "pet peeve" of mine for many years. The reason 536 used to be the default is it is based on the minimum allowable MTU of 576 for IP. There should never be any router or link used for IP that cannot forward a 576 octet packet, or in the absence of extra IP options, a 536 octet TCP segment. So no matter how the IGP path within the network changes, you always knew that an iBGP session using 536 MSS would work correctly. Path MTU detection was not needed but it was not left out of iBGP by accident -- the implementors knew that one part of your backbone might support 9000 MTU and another part might support 1500 MTU, and that an IGP topology change could cause an already-established iBGP session to swing from a path supporting 9000 MTU to one supporing a smaller size, causing BGP session failure. eBGP differs in this regard because (in the absence of eBGP multihop or loopback peering) the correct MTU will be known and stable. The path taken by the eBGP TCP session can't change from one path to another with potentially different MTU. This is the reason that eBGP sessions often did not use 536 MSS and instead calculated the MSS based on the interface MTU toward the eBGP neighbor. I believe that vendors have made a mistake by changing this default, but it is inconsequential to most networks because they have a consistent MTU across their whole backbone. If you don't, you should base the iBGP TCP MSS on the smallest value which is safe for your network, and not use Path MTU Detection. You can decide to figure this on a per-session basis, but this simply produces complexity for minimal gain in convergence time. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] some bugs to avoid
We have had our first instance of serious filesystem corruption on an EX4200 running 10.3R1.9. I am hopeful that the new-fangled stuff in 10.4 will stop these incidents from causing switches to reboot into an un-usable state requiring a reinstall from USB. :-/ In other news, we also observed an M160 with two REs (one in the process of upgrading from JUNOS 6.2) exhibit an interesting new failure mode. The second RE incorrectly reported its CPU Temperature as about 800 million degrees, which caused the master RE's chassisd to spawn children emitting warnings about 3 times each minute. Unfortunately, chassisd was not wait(2)ing on these children after they exited. This produced additional console warnings about the maximum number of processes for uid 0. After about 15 minutes, there were enough children of chassisd that the kernel process table was full, resulting in a kernel panic and automatic reboot. We had to remove the second routing engine to prevent it from happening a second time. IRB on MX80 10.4R4.5 appears badly broken, too. Configuring a bridge-domain with one untagged/"access" interface and one dot1q-tagged sub-interface, plus an IRB interface for layer-3, is a pretty good way to waste a couple hours troubleshooting the router. It works fine most of the time, and all looks well in the PFE console; but a few times per hour the Bridge-Domain simply stops forwarding any traffic, while the IRB loses its ARP entries. This fault sometimes lasts long enough for BGP to drop. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Code upgrade to 10.4R4.5
On Wed, May 11, 2011 at 3:11 PM, Cyn D. wrote: > Will this be a none (no config loaded at all) and all (if loaded then it is > intact) situation? What I don't want to see is configuration loaded > partially and the lines that are not compatible are missing. When you go I have encountered quite a few upgrade problems where only part of the configuration loaded. "Verify" is by no means a fool-proof check, and the "fool" in this case is not you, it's the developers. For example, an upgrade from EX4200 9.2(?) to 9.3(?) or there-abouts will break if you have virtual-chassis { pre-provisioned; } configured, because the syntax changes to "preprovisioned" (no hyphen), yet this is not caught by "verify." The box will be unusable after it upgrades. EX boxes, and their spectacular upgrade failures, have justified my OOB facilities many times over in the past couple of years. Always have a "rain plan." OOB network, remote hands, let router be down until you can dispatch an employee, whatever. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 LLDP issue with vlan-tagging
I find that EX4200 with interfaces configured with vlan-tagging and layer-3 sub-interfaces, as opposed to family ethernet-switching and routed VLAN interfaces, transmit LLDP frames differently. I do not think this is the correct behavior, but I would appreciate comments. The interfaces configured as follows: interface xe-1/1/1 { vlan-tagging; unit 3911 { vlan-id 3911; family inet { address 192.0.2.1/24; } } } produces LLDP frames that appear like this: 08:39:23.892264 Out 00:19:e2:51:86:99 > 01:80:c2:00:00:0e, ethertype 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype LLDP, LLDP,0 Notice the outer-ethertype 0x8100 rather than 0x88CC. Surely this is not correct. Changing the configuration to something like: interface xe-1/1/1 { unit 0 { family ethernet-switching { port-mode trunk; vlan { members 3911; } } } } interface vlan.3911 { family inet { address 192.0.2.1/24; } } vlan v3911 { vlan-id 3911; l3-interface vlan.3911; } produces LLDP frames which appear normal: 08:50:01.121422 Out 00:19:e2:51:86:bf > 01:80:c2:00:00:0e, ethertype LLDP (0x88cc), length 74: LLDP, name J3K3.1250RL, length 60 In the first case, my neighboring devices are dropping the LLDP frames, and thus they do not learn about the advertising device. In the later case, everything works as expected. With both configurations, the EX4200 itself does detect the neighboring LLDP-speakers correctly. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp