Re: [j-nsp] Netconf namespaces
I've looked at the PyEZ and ncclient code, and basically they seem to take the approach of just throwing away all namespace information. This seems icky to me, and make me wonder if Netconf is going to be another SOAP - so many implementation errors that interop ends up being a mess of special casing and workarounds. Do you really need the namespaces? If different vendors use the same tags for different things you’ll still have to write code to deal with it whether you have a namespace to warn you or not. Maybe I’m missing something. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netconf namespaces
On Jun 17, 2014, at 10:01 AM, Phil Mayers p.may...@imperial.ac.uk wrote: On 17/06/14 14:49, Keegan Holley wrote: I've looked at the PyEZ and ncclient code, and basically they seem to take the approach of just throwing away all namespace information. This seems icky to me, and make me wonder if Netconf is going to be another SOAP - so many implementation errors that interop ends up being a mess of special casing and workarounds. Do you really need the namespaces? If different vendors use the same tags for different things you’ll still have to write code to deal with it whether you have a namespace to warn you or not. Maybe I’m missing something. It's not really a matter of need. They're mandatory per the Netconf spec. It's not some optional thing you can dispense with if you don't like it, or because your COBOL libraries don't do them properly or some other reason. If vendors are generating XML without required namespace declarations, you can't validate the returned XML against the schema for the protocol, or for example against their published Yang data model. If you can't do that, you can't be sure it's well-formed semantically. You end up embedding all kinds of turn your head and squint workarounds, and we're back to being only slightly better off than parsing Cisco IOS configs by looking at the indent and using regexps… That’s my point. Even if there are conflicts between namespaces you’ll end up having to implement workarounds. Either you find them in the namespace (which no one reads.. Go for it http://tools.ietf.org/html/rfc6241) or you’ll find them when you’re debugging your code. (I exaggerate here...) Obviously disposing of the namespace info is possible. But it might surprise you how complicated that makes certain things. For example, one thing I've found myself doing is pulling the config as XML from JunOS, annotating and mutating the document locally according to template and database info, then sending it back in the other direction. If I've thrown away namespaced tags and attributes, I might have received this: junos:commentLink to provider/junos:comment interface namege-0/0/0/name ... /interface ...but I send back: commentLink to provider/junos:comment interface namege-0/0/0/name ... /interface ...which is invalid. The comments are a big caveat and are handled poorly. Most of the JunOS XML I’ve parsed I’ve used standard libraries and I haven’t run into any problems yet, but I normally don’t deal with comments either. That being said either way you’re going to have to write code to replace the ns's until juniper fixes their kit. Everything else is just a rant. I’m with you in spirit, but I usually do my ranting on Nanog. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IBGP via EBGP Default
You shouldn’t be learning routes via an eBGP peering if they already have your AS number in the path. Beyond your bouncing peer that could cause a routing loop if the eBGP route took over while the iBGP route was still valid. That being said, the juniper kit doesn’t treat iBGP routes differently than eBGP routes beyond the normal route selection process. Technically there is no such thing. If you think about it your peer’s AS number doesn’t suddenly create two different routing protocols. It was just an easy way to differentiate between one’s domain and the rest of the internet in the docs. I could think of a few places where what you saw could be valid behavior. There are networks using eBGP within a single datacenter for example with no IGP protocol. Juniper tends not to try and predict how you will use it’s routers when it writes the code. Some vendors will introduce features that make life easier for most but become cumbersome if presented with a corner case. That being said juniper router will give you enough freedom to seriously break things if you’re not careful. On Mar 17, 2014, at 1:55 PM, Christopher Costa cco...@gaikai.com wrote: We observe on EX and QFX platforms that their IBGP session is maintained (and reestablishes when bouncing the session) when the interconnect between them goes down; following an EBGP learned default route to reach the peer address. Juniper says this is expected behavior, although my understanding is that the IBGP session should not be maintained when the underlying route is known via EBGP. Am I mistaken about that? Thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Do the old M-series fixed optic SONET/SDH PICs wear out?
On Mar 14, 2014, at 5:06 PM, Will Orton w...@loopfree.net wrote: I have a couple P(E)-4OC3-SON-SMIR that I purchased used and successfully ran in a production network in the 2007-2009 timeframe. Then, about 5 years ago the OC3 links were taken out of service and the PICs sat in their routers (an M10 and an M20) for 4-5 more years doing nothing. The ports were set disable but the PIC was online, so I believe the optical transmitters were still active. Could just be dust/debris even if someone put the boots back on, which sometimes doesn’t happen. SMIR is very sensitive dirt. Now I'm trying to reussurect them for lab use and I cannot for the life of me get them to link up back-to-back. Only one port out of eight will even go green when looped to itself with a 1m patch cable. None will link port-to-port. LOL clears and I get PLL lock, but then either LOS or LOF, AIS, BERR, etc on both sides. I've tried: -multiple patch cables (yes they're SMF) -cleaning the cables' SC connector with tissue/alcohol This is a bad idea. You could replace tiny dust particles with giant tissue fibers twice as big but still too small to see. A proper fiber cleaner is about $100. If you don’t have access to one you should just replace cables. -blowing canned air into the ports on the PIC Bad idea as well. You’re actually more likely to blow things into the connectors than away from them. -5 10db optical attenuators in case it was rx overload even though that shouldn't matter I’ve never had to attenuate in a lab even with SMIR optics and 1-2m cables, but YMMV. To quote my old SE, “Juniper likes it hot!”. -verifying tx/rx strands and swapping just in case -every combination of clocking,enable/disable scrambling, crc16/32, etc -JUNOS 10, 11, and 12 in both M10 and M20 with FPC-E are you sure the new code is compatible with those cards? Are the optics swappable? I can’t remember for that card. I’d try new ones or at least try known good ones in all the non-working ports. Unfortunately I don't have a light meter. But I'm starting to think the transmitters might just be toast and not pushing enough light to present a usable signal to the other end even with only a 1m patch. You do actually have a moderately accurate light meter. There’s a command that will show you light levels from the perspective of the PIC IIRC. I can’t guarantee that it is supported on hardware this old though so YMMV. I believe it’s under the show interfaces physical hierarchy. It should tell you what it’s transmitting, what it’s receiving and the minimum light level to establish a link. Over the years, I’ve also taken to simply taking the known good port and cable and plugging it into all the stuff that didn’t work. I would sometimes end up with cables pulled through racks and other dodgy places temporarily, but I always ended up invalidating some of my deductions. http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-network-interfaces/id-12763130.html says: To extend the life of the laser, when a SONET/SDH PIC is not being actively used with any valid links, take the PIC offline until you are ready to establish a link to another device. To do this, issue the request chassis pic offline fpc-slot slot-number pic-slot slot-number operational mode command Is this a real thing? Is 10-15 years in the expected usable lifetime of a circa-2001 1310nm laser? Yes. no. maybe. probably. definitely. sometimes… I’ve seen gear used well beyond it’s expected lifetime and I’ve seen things come out of the depot completely unusable. Everything breaks. Stuff is either broken or not broken yet. That’s why hardware lifecycle’s were invented. If there’s no current in the components they will last longer at least according to the laws of physics. That doesn’t mean that leaving one on for 5 years will definitely fry it. -Will Orton ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Do the old M-series fixed optic SONET/SDH PICs wear out?
Maybe enough have come out of service that people just trash them without comment. This is definitely the case. Most of this stuff is probably being recycled into raspberry pi servers and iPhones at this point. There are probably some still in use. ISP’s in remote areas for example have to squeeze every useable minute out of their gear so I wouldn’t be surprised to see some of it still out there. It’s hard to finance a 6 figure equipment refresh if you only have 1000 subscribers. -Will ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] eBGP neighbor link failure detection
That would be one hell of a coincidence to have the same bug across different implementations of NSR/NSF across two different vendors. That said, stranger things literally have happened. There are a bunch of other possible causes though. What happened in the rest of the network? Was all traffic black-holed for 3min even though the other border router was able to reach the internet? The juniper gear doesn’t prefer eBGP over iBGP by default so AS path will win unless you’re using local preference internally. Are your other routers using BGP to reach the edge or another protocol? Could be IGP or VRRP misconfiguration if you’re not using iBGP or even a bad static route. Have you checked to make sure you’re return routes failed over? Assuming you have an ASN and are advertising the same routes to both providers in an active/passive fashion (a big assumption). If there are advertisement issues one provider could have continued to draw traffic towards the down link. On Mar 14, 2014, at 11:40 AM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: Hi Payam, yes the logs clearly show that the failures start after the link goes down. We have external monitors set up via a 3rd party monitoring ASP that watch our various services. Some, but not all, of them reported connection issues for about 4 minutes. We also run 'rpm' probes from the MX80s toward 4 different destinations. The MX80 that had the peer go down logged all 4 of these probes failing for 2m 48s. The probes are set with a test-interval of 60, probe-count of 10 and a total-loss threshold of 1. Our 2nd MX80 did not have any rpm probes fail. It is an eBGP peer with another provider taking full routes and an iBGP peer with the other MX80. Here is the sequence of events (fictional time starting at 0s) 0m0s - MX80 A logs interface toward neighbor is down - tfeb0 UPDN msg to kernel for ifd:xe-x/x/x, flag:2, speed: 0, duplex:0 0m0s - MX80 A logs BGP neighbor state change - rpd[1344]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer x.x.x.x (External AS Y) changed state from Established to Idle (event Stop) 0m2s - First rpm icmp probe logs failure - rmopd[1348]: PING_PROBE_FAILED: pingCtlOwnerIndex = ICMP-Probe, pingCtlTestName = our-probe-name 0m2s - 3m48s - all icmp probes fail 3m48s - First rpm icmp probe succeeds mopd[1348]: PING_TEST_COMPLETED: pingCtlOwnerIndex = ICMP-Probe, pingCtlTestName = our-probe-name 12m12s - MX80 A logs interface toward neighbor is up - tfeb0 UPDN msg to kernel for ifd:xe-x/x/x, flag:1, speed: 0, duplex:0 12m15s - MX80 A logs BGP neighbor state change to Established - rpd[1344]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer x.x.x.x (External AS Y) changed state from OpenConfirm to Established (event RecvKeepAlive) -andy On Thu, Mar 13, 2014 at 5:17 PM, Payam Chychi pchy...@gmail.com wrote: Are you sure? Ive never seen an update to remove routes take 3min. Andy, are you sure the 3min outage was after the link hard down and not just prior? Guessing this is easy to find due to time stamps. Ive seen this due to line protocol down and everything blackholes until bgp fails but never a 3mim wait for route withdraw (unless this is a peering router with dozens of peers and full routes on each) Hope you fins root cause -- Payam Chychi Network Engineer / Security Specialist On Thursday, March 13, 2014 at 4:50 PM, Andy Litzinger wrote: Hi Chris, yes, i am taking full routes from this neighbor. is there any way to reduce the time it takes to handle the updates? if i wanted to test this behavior in my lab, what would i want to watch? (logs/traceoptions) i don't think I've seen this behavior during scheduled maintenance- for example during times when i've deactivated the neighbor config. Am I correct in thinking this is because in this scenario even though the RE is taking awhile to remove the routes from the FIB the actual next hop router is still available and thus the routes are still valid? -andy On Thu, Mar 13, 2014 at 3:54 PM, Chris Adams c...@cmadams.net wrote: Once upon a time, Andy Litzinger andy.litzinger.li...@gmail.com said: what surprised me is that it looks like routes toward that provider were not immediately removed from my routing table. Instead i see evidence of blackholing for almost 3 minutes. Are you taking full routes from this neighbor? It takes a while for the routing engine to send updates to remove/replace 200k+ prefixes to the forwarding engine. -- Chris Adams c...@cmadams.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list
Re: [j-nsp] Multicast/Broadcast Packets going to EX CPU
This is normal unless the firewall filters don’t work. MDNS/Bonjour is sent to 224.0.0.251 which is in the link local range and is at least read off the wire by everything with an IP stack. 100pps would equate to about 64kbps worst case. Still it’s best practice to have a FF on every box to prevent things like this. I doubt this is a bug though. Keegan On Mar 10, 2014, at 5:12 PM, Clarke Morledge chm...@wm.edu wrote: -- Sebastian, We are using a combination of storm-control and firewall filters, just to throttle the multicast back. Nothing special. Since we are not officially supporting multicast applications, this has not really hurt us yet. Clarke * Clarke Morledge chm...@wm.edu [2014-03-06 16:42]: Sebastian, No, you are not alone on this issue. For a little more context, I have seen the same type of behavior associated with Apple Bonjour traffic related to Multicast DNS reported on this thread in November, 2013: http://www.gossamer-threads.com/lists/nsp/juniper/48269?do=post_view_flat#48269 Currently, we are implementing ways of limiting multicast. I am aware that this is more of a bandaid approach, but I have never heard a completely satisfactory explanation or solution for this behavior on the EX platform. Thank you for your reply, can you share a bit more about what countermeasures you are implementing? storm-control? firewall filters? If anyone comes up with some good answers, please inform the list. +1 Regards Sebastian ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Large JunOS Space Deployments
Seems like there are several people interested in the responses to this thread. I’ll check with anyone who responds and post a summary of the information if allowed by the responders. That being said I haven’t received many responses at all. My gut says this is as much a product of Space being new as the general skeptcisim most router-jockeys have towards GUI/WebUI based management tools. On Mar 3, 2014, at 10:30 AM, Keegan Holley no.s...@comcast.net wrote: Curious if anyone is using JunOS Space in an SP network. I’m most interested in the automation features for services provisioning, network management and security management as well as the Service Now module. Just some basic opinions. Do you love it? Hate it? Caveats? Bugs? That sort of thing. off-list is fine. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multicast/Broadcast Packets going to EX CPU
I agree. It’s more likely that you had an increase in packets that the switch would process normally than the switch getting bored and suddenly deciding to read packets off the wire. If there is an IP interface on the network that the broadcast/multicast packets traverse, the switch must read them just like every other IP enabled host. This will even happen for tagged frames if there is a VLAN interface that matches the tag. On Mar 5, 2014, at 6:52 AM, Chris Evans chrisccnpsp...@gmail.com wrote: low TTL on the multicast frames will cause this.. Also the multicast destination addresses will do this too if they're in 224.0.0.0/24 On Wed, Mar 5, 2014 at 8:49 AM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: Hello, I'm currently looking at an EX4500 setup that had a few problems related to multicast/broadcast packets going to the CPU (and sometimes preventing required packets like LACP reaching the CPU) of the switch. I assume this was because the queue between PFE and CPU was full (is there a way to check?). I noticed that multicast and broadcast packets in all VLANs are sent to the CPU. My question is why? IGMP snooping and VSTP is not enabled on the switch and apart from that I don't see an apparent reason why it should do this for tagged frames. Example of packets being sent to the CPU includes VRRP packets from attached routers (DMAC 01:00:5e:00:00:12) and BOOTP/DHCP (DMAC ff:ff:ff:ff:ff:ff) packets. Would an lo0 firewall filter help? Is this applied before or after the packets are sent over the PFE-CPU link? Perhaps you could share your ideas on how this could be prevented and what you're doing to protect the CPU on these EX boxes. Regards Seastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] router-jockeys and gui tools
I agree. I could even add a few. A big one is control. I had a supervisor once who now works for juniper ironically say he didn’t like tools because he didn’t want to start forgetting the commands. I asked if he was ok with all of engineering using prod routers as a practice ground. He just shrugged... It definitely depends on the work to be done though. Repetitive tasks or large scale changes are easier and less prone to error when done by a computer of some sort. Upgrading JunOS on more than one router at a time. deploying VRF’s, or LSP’s, modifying routing policies across a bunch of routers. I usually subscribe to the skepticism, but as with everything the devil is in the details. Sometimes it’s annoying when engineers disparage a tool when it is clearly better for the task at hand. Good post though, Keegan On Mar 5, 2014, at 10:32 AM, Phil Shafer p...@juniper.net wrote: [hijacking part of a thread from Keegan] Keegan Holley writes: My gut says this is as much a product of Space being new as the general skeptcisim most router-jockeys have towards GUI/WebUI based management tools. As the on-box CLI developer, this has always been an area of interest to me. My gut says the router-jockey/gui repulsion is powered by: a) completeness Everything one can do with a router is available in the CLI, where GUIs tend to carry a subset and will have a time lag WRT availability. Part of this is driven by the tool-makers view of how their particular customer set works, and part is driven by the need to attack the biggest and most visible problems. b) text/email friendly Pasting config into email and using show | compare allow simple obvious differences. Diffing the output of two HTML divs is, well, difficult. c) power tools If you want to repeat a command, ^P is blindingly fast. Add in bindings like ESC-. and ESC-/ (and ^R) and you can get many jobs done faster at a CLI than in a GUI. d) trust If I say set interfaces xe-0/0/0 family inet filter output foo, then I know exacly what I did and how it will work. When the GUI has a field/drop-down and I select foo, I'm trusting the app to do the right thing, and to let me know when it cannot. e) inertia I completely understand inertia. I'm writing this email using vi under mh, chiefly because no one can pull the procmail needle from my arm. Tools are addictive. If they work, you use them more. If they don't, you use them less. Even in the face of these factors, there's definitely movement in the GUI arena. As tools evolve and are able to show more data and as the volume of data demands tools that let you explore (not just view) data, we need to find ways to keep the valuable portions of the CLI world, while allowing data access for web tools. Visualization is becoming more important, and as someone who tried to make Sparklines in ascii for op script output, I can definitely say that the tty-based CLI is very limiting. In JUNOS, we've had our XML APIs for 13 years, and the tight binding between the CLI and the API ensure that feature parity is constant and consistent. We're working to find ways to expand on this, and while I don't have anything to share yet, I'd love to hear back (on or off list) regarding the items listed above and any additional factors that keep you committed to the CLI with a loyalty that would do Charlton Heston proud. Thanks, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Large JunOS Space Deployments
Curious if anyone is using JunOS Space in an SP network. I’m most interested in the automation features for services provisioning, network management and security management as well as the Service Now module. Just some basic opinions. Do you love it? Hate it? Caveats? Bugs? That sort of thing. off-list is fine. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M20 issues installing Junos 10
Are you sure that RE supports 10.0 code? 2012/5/30 Juan C. Crespo R. jcre...@ifxnw.com.ve Hi Guys I've been trying to install the Junos 10 into one M20 with Routing Engine 3.0 (with one SSD of 8GB) and I getting this error Adding jbase... gzip: stdin: invalid compressed data--format violated tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now Any idea? Thanks __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] traffic drops to 8 Gb/s when a firewall filter is applied
What version of JunOS were you running? Any interesting logs/stats from the DPC itself? 2012/5/30 Matjaž Straus Istenič juni...@arnes.si Hi list, no, this is not a joke ;-) -- our problem disappeared when FPC was _power-cycled_ after almost a year uptime. JTAC and the local Juniper partner were very helpful in the troubleshooting and they even supplied a new FPC for a test. We replicated the same behaviour on two MXs. We still don't know what caused the problem. Hope new FPCs with a higher revision number are immune to this kind of behaviour. Thank you all for your feedback, Regards, Matjaž On 15. dec. 2011, at 03:04, Keegan Holley wrote: I 2011/12/14 Richard A Steenbergen r...@e-gerbil.net On Fri, Dec 09, 2011 at 01:19:54PM -0500, Keegan Holley wrote: Yea but it should have enough silicon to do simple policing in hardware unless you have every single other feature on the box enabled. If a policer with no queueing, and no marking etc, caused throughput to decrease by 20% across the board I'd inquire about their return policy. Hopefully, it's the policer config. Most of my 10G interfaces do not require policers, but I've got 1G interfaces with hundreds of logicals each with a unique policer. Unfortunately not... There are all kinds of ways to make I-chip cards not deliever line rate performance even with relatively simple firewall rules, and it's very poorly logged when this does happen. Admittedly I've never seen a simple then accept push it over the edge, but maybe it was RIGHT on the edge before... Try looking for some discards, such as WAN_DROP_CNTR, on the *INGRESS* interface (i.e. not the one where you added the egress filter). For xe-x/y/0 do: start shell pfe network fpcx show ichip y iif stat example: Traffic stats: Counter NameTotal Rate Peak Rate -- -- -- GFAB_BCNTR 4229125816477883 949530 1276098290 KA_PCNTR0 0 0 KA_BCNTR0 0 0 Discard counters: Counter NameTotal Rate Peak Rate -- -- -- WAN_DROP_CNTR 298 0 82 FAB_DROP_CNTR 1511 0419 KA_DROP_CNTR0 0 0 HOST_DROP_CNTR0 0 0 -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) I see your point, but I'd still be surprised if a defaulted box with a then accept filter would drop by this much. You could see the be queue discarding packets in the sh int output. The be queue is given 95% of the buffer in the default schedule map which still leaves 1G plus unaccounted for. Maybe it's a little bit of both. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] what would you put in this PoP
I don't mean to offend, but I never understood these design via commitee threads. The OP never lists enough info to allow anyone to give a completely accurate answer. Then the answers and information provided are so varied that the only way to be sure of what you're reading is to do same research you could have done in lieu of posting to a news group. MX80, MX240 or T320? hmmm.. How about an ASR? 9K or 1K? Is ATM really always 155Mbps? I have answers for all those, but I wouldn't come anywhere near a news group if I were designing a resi POP (real or fake) Just my opinion I suppose, Keegan 2012/5/23 Tom Storey t...@snnap.net Assuming space were not an issue, is there a reason why you might avoid something like an M320, or maybe a T320, being the traditional multi-protocol boxes? Im just a curious bystander, trying to learn. :-) On 23 May 2012 10:33, Per Granath per.gran...@gcc.com.cy wrote: MX240, with redundant REs, with two MPC1, two 2XE MIC, one ATM MIC, one 20GE MIC. For the Business connections, do a VC of two EX4200, uplinks to the available XE ports. If you have space, go for the MX480 which does not really cost much more. You need to figure out if you can use MPC1E (reduce scale L3) or MPC1-3D-R-B (full scale L3), depending on your services (L3VPN?). -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of MKS Sent: Wednesday, May 23, 2012 1:32 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] what would you put in this PoP Hi Imagine a town of 15.000-20.000 people. What type of device/devices and size would you put into this town, given the following requirements Residential triple play (HSI, VoD, Multicast) 8 IP dslams (GigE) Vod servers (4 GigE pors) Business connections (L3VPN) 10 Business connections on GigE 30-40 Business connections 10-100 mb AToM ATMoMPLS port mode, 4 STM1 ports needed. Uplinks on 10GbE in a ring based structure, current traffic levels 2-3 gigs total BNG termination (pppoe) is not a requirement Spare parts are located 4-5 hours away. 1) If you where given a clean slate, what would you put in? 2) What do you put normally, given your normal capex level. Regards MKS ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Update on 10.4R9 stability for MX?
The answer is pretty much the same with every code version. You can query the list for what others think are relevant bugs, but it's largely subjective. Depends on the size of your network, the services you use and where you're upgrading from. If you're already in the 10.4 train upgrading to a new release is (some list members may differ) supposed to provide bug fixes only and no new features or bugs. If you are coming from a much older code you may see new bugs that weren't there before as well as changes in features or syntax. Generally, speaking I haven't come across many bugs in 10.4 although we're running an older release. According to their software lifecycle policy there shouldn't be any bugs in 10.4R9 that aren't in earlier versions of 10.4. As I said earlier though YMMV considerably. 2012/5/9 Clarke Morledge chm...@wm.edu It has been a couple of months since the JTAC recommended Junos software versions has been updated for the MX. As of February, the recommendation was to use 10.4R8.5 for the MX, except that there is an issue related to BFD configurations on the DPC line cards. Supposedly, the fix is in 10.4R9. In looking at the release notes, there are some issues that have been resolved in the 11.x series but nothing noted yet for any future 10.4.x releases. Perhaps there are future 10.4.x versions planned to carry forward these fixes? I am curious to know about anyone's experience with 10.4R9 over the past few months. I have DPC only currently; i.e. no MPC hardware -- and no MultiServices. Thanks. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Document Update - EX Features
I kind of agree with the OP on this one. As customers it wasn't our choice to include a re-branded switch in the portfolio. It's simpler to be able to get all the info in one spot, especially if all the other switches in the family are listed there. Just my $0.02. 2012/5/10 Aviva Garrett av...@juniper.net Hi Skeeve, Here is the reason it's not included: the EX2500 does not run Junos software. I see that the doc web pages are not clear about this, and I am following up with the PLM and writing teams to see what we might want to do about this. Aviva In message 20120507182021.cff8111...@eng-mail01.juniper.netyou write: Hi Skeeve, The writer for that topic is on paternity leave. I'll ask around and see if I can find out why it's not included in the software features overview topic. Aviva In message caeufugn94esgjx8u7sty8b_34aleigfg4k7oee+u7z-gymq...@mail.gmail.co m you write: Hey, Does anyone know who we hassle to get a document updated? Specifically: http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/conc = ept/ex-series-software-features-overview.html With the EX2500's in it. *Skeeve Stevens, CEO* eintellego Pty Ltd ske...@eintellego.net ; www.eintellego.net http://www.eintellego.net.au Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco =96 IBM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper SFP's
+1 :) I'm willing to give them the benefit of the doubt, but are they different enough to warrant all the different part numbers? How about a universal SFP that works across similar products. I can't comment on the others but I've seen the EX and MX/M SFP's interchanged. More often than not it happens by accident. Juniper adds to the fun by not printing the part number on most of them. 2012/4/24 Skeeve Stevens skeeve+juniper...@eintellego.net Hey all, rant Juniper are really pissing me off in regards to their SFP's. As an example: CTP-SFP-1GE-SX (0) EX-SFP-1GE-SX (163) JX-SFP-1GE-SX (2) QFX-SFP-1GE-SX (5) SRX-SFP-1GE-SX (4) 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. I recently deployed some MX80, EX4200 and SRX240 and had to order different SFP's for them all.. and the SRX one took ages... There is likely to be no difference, but will JTAC tell me to get lost if I use an EX one in an SRX or MX or vice versa? *Frustrated* Does anyone have experience with the compatibility of the generics? Agilestair or so on? I really am happy to sell genuine Juniper SFP's, but why the hell are there different codes for each one? Why am I waiting for stock for 3 weeks for an SRX one when they have 163 EX ones. /rant Have a nice day ;-) *Skeeve Stevens, CEO* eintellego Pty Ltd ske...@eintellego.net ; www.eintellego.net http://www.eintellego.net.au Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] redistributing label between rsvp and ldp
Labels aren't like routes per se. They only point to a next hop and not a destination so you don't have to exchange labels between two routing protocols in the same way you would routes. You only have to configure the routers at the edge of each topology so that it runs both protocols. That being said RSVP adds a caveat. If you try to form a RSVP LSP that traverses a router that isn't running RSVP it will either fail to form or re-route. LDP does not have this constraint and just advertises labels to directly connected peers. To bridge between the two protocols I would configure p3 (and every router at the edge of your RSVP domain) as a PE running both LDP and RSVP. You can terminate the RSVP LSP's there. Since it's a PE it should be able to match the L3VPN information advertised by pe2 via BGP with the LDP labels it's advertising. You could also turn on LDP on all of your routers. Any IP that doesn't have an RSVP next hop failover to LDP and vise versa. This is easier to manage since it will be obvious which paths use LDP and which ones use RSVP. The ultimate solution is probably to run only one label protocol though. 2012/4/29 Uzi Be go...@live.com hi, I was just testing out to swap labels between two different signaling protocols (ldp and rsvp). lets say we have two different network, one is running ldp and the other one is running rsvp (same AS, so no inter-as options). ce - pe1 - p1 - p2 - p3 -p4 -pe2 - ce so pe1 - p1 - p2 -p3 are running rsvp and p4-pe2 are running ldp, and edge ce's are using l3vpn. what are the options to have a labeled path from pe2 to pe1 (considering that pe1 is not going to run ldp protocol, and pe2 can't use rsvp so ldp tunneling is not an option here). thanks in advance for your comments. Andrew ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] mx240 vs asr 9006
Go with the 480 if you go juniper. The cost difference between chassis is negligible even if you won't use the extra slots for some time. Haven't played with the cisco option much so I can't vouch for the 9k. Your environment matters as well. What your engineers are comfortable with, what your automation and backend systems suport, etc. The boxes also differ in terms of horsepower, number of routes supported,port density. Are any of these limits important to you? If they are really interchangeable in your environment I'd probably go with the cheaper of the two. 2012/4/24 Peter piotr.1...@interia.pl Hi I have to upgrade my bgp routers, i have budget for two options: 1. - bundle: MX240BASE-AC-HIGH, MPC1-3D-R-B, MIC-3D-20XGE-SFP, MIC-3D-2XGE-XFP; configurable RE, SCB, and PEM - better routing engine RE-S-1800X2-8G-UPG-BB + jflow license ( netflow v9 or ipfix) S-ACCT-JFLOW-IN or 2. asr 9006 - A9K-RSP-4G - A9K-MOD80-TR, 80G Modular Linecard, Packet Transport Optimized - license for l3 vpn the price is almost the same. I need: - ports: from 4x10G line to max 8x10G, line rate - 3 virtual routers with full ip routing table v4 - 10 virtual routers with ca 10k prefix in routing table v4 - v6 - up to 12 full bgp feed - netflow v9 or ipfix, sampling max 100/s - define counters on logical and physical interfaces, count many times to the same counter, one packet could be count to different counters in next term - access to counters via snmp - independent control plane and data plane - and few others things on bgp edge which model will be better ? thanks for some advice regards Peter ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Ethernet OAM, specifically CFM
CFM just performs a continuity check so I'm not sure it will help you here. In other words it just checks if the CFM instance on the switch can talk to the CFM instance on the router. If I understand your question correctly you're trying to verify an access point leading to a customer and not your MX. If there is only one access port per VLAN interface can you move it down to the switch? 2012/4/20 chip chip.g...@gmail.com Hi folks, I'm trying to figure out if I can create a connectivity-fault-management instance between a vlan sub interface on an MX and the access port in the same vlan on a down stream switch. Possibly this will help: http://imgur.com/MMrZm Ultimately my goal is to detect an outage on the access port and take down the layer-3 interface on the MX so I won't blackhole traffic. Since that interface won't go down if the access port on the downstream switch does. Or maybe there's a better solution. Either way, if someone has this setup and can supply some example configs I would be ever so grateful. I can't quite seem to work it out. Thanks all! --chip -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Ethernet OAM, specifically CFM
CFM wouldn't monitor a link with no MEP on the other end of it. So you can't have a router a switch and then a link from the switch to a customer and monitor a link to a customer where the customer isn't running CFM on their equipment. 2012/4/20 Humair Ali humair.s@gmail.com Actually CFM would be appropriate with what Chip is trying to achieve, CFM monitor a maintenance session end to end and works a vlan or link level. Why not monitor Cust Rtr interface to MX1 accross the bridge network via CFM and have an action profile assign to it ? or monitor Cust Rtr 1 to remote end Cust Rtr 2 CFM , since usually you would want to use CFM to guarantee a service. On 20 April 2012 18:20, Keegan Holley keegan.hol...@sungard.com wrote: CFM just performs a continuity check so I'm not sure it will help you here. In other words it just checks if the CFM instance on the switch can talk to the CFM instance on the router. If I understand your question correctly you're trying to verify an access point leading to a customer and not your MX. If there is only one access port per VLAN interface can you move it down to the switch? 2012/4/20 chip chip.g...@gmail.com Hi folks, I'm trying to figure out if I can create a connectivity-fault-management instance between a vlan sub interface on an MX and the access port in the same vlan on a down stream switch. Possibly this will help: http://imgur.com/MMrZm Ultimately my goal is to detect an outage on the access port and take down the layer-3 interface on the MX so I won't blackhole traffic. Since that interface won't go down if the access port on the downstream switch does. Or maybe there's a better solution. Either way, if someone has this setup and can supply some example configs I would be ever so grateful. I can't quite seem to work it out. Thanks all! --chip -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Humair ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Frustrations (Juniper - Cisco)
Tagging isn't supported with the encapsulation you're using. That was the
only thing I found wrong with your config. Is yourT-LDP session ok? Do
you have a lab router you can use to try this on? What code are you
running? If a vanilla VPLS config weren't working in a particular version
of JunOS that should be in release notes somewhere. Did they verify your
T-LDP and mention your encapsulation? Not that JTAC has ever come up with
the wrong answer for me, mind you.
2012/3/27 Ben Boyd b...@sinatranetwork.com
The CE's can tag or not tag, they want freedom to do whatever they wish.
There is no BGP. It's all LDP signaled. That's why an L2VPN isn't
possible and VPLS is our only way.
I'm trying to accomplish Q-in-Q or more exactly possiblyQ-in-Q.
JTAC thinks this is a bug as the Juniper is sending STP traffic and
tagging correctly, but it isn't decapsulating the STP traffic coming back.
---
Ben Boyd
b...@sinatranetwork.com
http://about.me/benboyd
On Mar 22, 2012, at 4:48 PM, Keegan Holley wrote:
Try changing your encapsulation to flexible ethernet services. It's been
a while since I set this up from scratch, but I've never seen a vpls
neighbor defined only site-id's and site ranges. That may not be your
problem though. Are your CE's tagging? encap vpls only supports untagged
packets from the CE. vlan-vpls or flexible is required to pass dot1q
tags. You should think about doing q-in-q to isolate your topology from
the customers. What does your BGP look like? Both L2VPN and VPLS are
actually BGP signalled so your (MP)BGP config is important too.
2012/3/22 Ben Boyd b...@sinatranetwork.com
A straight l2 circuit wouldn't work because of a switched-network between
a PE and the CE.
L2VPN wouldn't work because BGP isn't used as MPLS transport mechanism.
Updated Setup:
CE switch #1 (untagged/tagged) MX240 (11.4R1.14) P
router Cisco PE (tagged) Switched Network CE
switch #2 (untagged/tagged)
---
Ben Boyd
b...@sinatranetwork.com
http://about.me/benboyd
On Mar 22, 2012, at 11:34 AM, Ben Boyd wrote:
All,
I'm running into VPLS frustrations in an MX. I'd like to create a VPLS
instance in which a customer can plug in a device on any port in our
network and we'll pass the traffic no matter what type of traffic it is
(we're just a wire). For example, they can plug in a switch/router where
the interface is tagging traffic or not tagging traffic.
This particular example is one CE-switch to another CE-Switch, but
we'll eventually add several additional switches and routers in the same
VPLS instance.
Right now, I am seeing BPDU's received from one CE switch to another CE
switch, but I'm not seeing any coming back.
I'm also not able to ping from CE to CE on any VLAN.
Here is the Setup:
CE switch #1 (untagged/tagged) MX240 (11.4R1.14) P
router Cisco PE CE switch #2 (untagged/tagged)
CE switch #2 is receiving BPDUs from CE switch #1, however CE switch #1
isn't receiving BPDU's from CE switch #2
Relevant MX240 config:
admin@interop-MX240# show interfaces ge-2/1/0
mtu 9192;
encapsulation ethernet-vpls;
unit 0 {
family vpls;
}
admin@interop-MX240# show routing-instances VPLS2001
instance-type vpls;
vlan-id all;
interface ge-2/1/0.0;
protocols {
vpls {
no-tunnel-services;
vpls-id 100;
mtu 9216;
neighbor 172.16.0.11;
}
}
admin@interop-MX240# show protocols layer2-control
mac-rewrite {
interface ge-2/1/0 {
protocol {
stp;
vtp;
cdp;
}
}
}
The VPLS VC is up from MX240 to Cisco PE.
admin@interop-MX240# run show vpls connections
Instance: VPLS2001
VPLS-id: 100
Neighbor Type St Time last up # Up
trans
172.16.0.11(vpls-id 100) rmt Up Mar 22 11:13:33 2012
1
Remote PE: 172.16.0.11, Negotiated control-word: No
Incoming label: 262151, Outgoing label: 119
Negotiated PW status TLV: No
Local interface: lsi.1052423, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls VPLS2001 neighbor 172.16.0.11 vpls-id
100
Cisco_PE#show mpls l2transport vc
Local intf Local circuit Dest addressVC ID
Status
- -- --- --
--
VFI vpls1 VFI172.16.0.12 100UP
If anyone has some config advice, i'm open to it!
---
Ben Boyd
b...@sinatranetwork.com
http://about.me/benboyd
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Frustrations (Juniper - Cisco)
Try changing your encapsulation to flexible ethernet services. It's been a
while since I set this up from scratch, but I've never seen a vpls neighbor
defined only site-id's and site ranges. That may not be your problem
though. Are your CE's tagging? encap vpls only supports untagged packets
from the CE. vlan-vpls or flexible is required to pass dot1q tags. You
should think about doing q-in-q to isolate your topology from the
customers. What does your BGP look like? Both L2VPN and VPLS are actually
BGP signalled so your (MP)BGP config is important too.
2012/3/22 Ben Boyd b...@sinatranetwork.com
A straight l2 circuit wouldn't work because of a switched-network between
a PE and the CE.
L2VPN wouldn't work because BGP isn't used as MPLS transport mechanism.
Updated Setup:
CE switch #1 (untagged/tagged) MX240 (11.4R1.14) P
router Cisco PE (tagged) Switched Network CE
switch #2 (untagged/tagged)
---
Ben Boyd
b...@sinatranetwork.com
http://about.me/benboyd
On Mar 22, 2012, at 11:34 AM, Ben Boyd wrote:
All,
I'm running into VPLS frustrations in an MX. I'd like to create a VPLS
instance in which a customer can plug in a device on any port in our
network and we'll pass the traffic no matter what type of traffic it is
(we're just a wire). For example, they can plug in a switch/router where
the interface is tagging traffic or not tagging traffic.
This particular example is one CE-switch to another CE-Switch, but we'll
eventually add several additional switches and routers in the same VPLS
instance.
Right now, I am seeing BPDU's received from one CE switch to another CE
switch, but I'm not seeing any coming back.
I'm also not able to ping from CE to CE on any VLAN.
Here is the Setup:
CE switch #1 (untagged/tagged) MX240 (11.4R1.14) P
router Cisco PE CE switch #2 (untagged/tagged)
CE switch #2 is receiving BPDUs from CE switch #1, however CE switch #1
isn't receiving BPDU's from CE switch #2
Relevant MX240 config:
admin@interop-MX240# show interfaces ge-2/1/0
mtu 9192;
encapsulation ethernet-vpls;
unit 0 {
family vpls;
}
admin@interop-MX240# show routing-instances VPLS2001
instance-type vpls;
vlan-id all;
interface ge-2/1/0.0;
protocols {
vpls {
no-tunnel-services;
vpls-id 100;
mtu 9216;
neighbor 172.16.0.11;
}
}
admin@interop-MX240# show protocols layer2-control
mac-rewrite {
interface ge-2/1/0 {
protocol {
stp;
vtp;
cdp;
}
}
}
The VPLS VC is up from MX240 to Cisco PE.
admin@interop-MX240# run show vpls connections
Instance: VPLS2001
VPLS-id: 100
Neighbor Type St Time last up # Up
trans
172.16.0.11(vpls-id 100) rmt Up Mar 22 11:13:33 2012
1
Remote PE: 172.16.0.11, Negotiated control-word: No
Incoming label: 262151, Outgoing label: 119
Negotiated PW status TLV: No
Local interface: lsi.1052423, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls VPLS2001 neighbor 172.16.0.11 vpls-id
100
Cisco_PE#show mpls l2transport vc
Local intf Local circuit Dest addressVC ID
Status
- -- --- --
--
VFI vpls1 VFI172.16.0.12 100UP
If anyone has some config advice, i'm open to it!
---
Ben Boyd
b...@sinatranetwork.com
http://about.me/benboyd
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Recommend JUNOS version for M7i with RE400
Juniper publishes their recommended code so you may want to check there first. Problem reports vary with different use cases so list member opinions will vary. You may also want to verify that your RE's have the required 1GB of flash. Some of the older RE-400 bundles do not have enough flash to run 10.4. You can order flash separately and upgrade if you do not have enough. 2012/3/18 Chen Jiang iloveb...@gmail.com HI! Is there any experience in JUNOS 10.4R -- BR! James Chen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Stacking cable sizes
The juniper website doesn't seem to have exact lengths or part numbers for the small, medium and large stacking cables described in the hardware guides. Just wondering if anyone on the list knew the length of each cable. I was also curious if the cable that comes with the switch is small or medium. Thanks! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX Error Entry
I've never seen those particular errors but they look like fabric errors. Have you checked your pfe counters and such? 2012/2/1 Paul Stewart p...@paulstewart.org Has anyone seen these errors before and can shed some light on whether they are serious or not? Feb 1 06:29:19 dis1.bridgenorth1 tfeb0 MQ(0): pio_handle(0x437b3668); pio_read_u64() failed: 1(generic failure)! addr=02253808 Feb 1 06:29:19 dis1.bridgenorth1 tfeb0 mqchip_dstat_update_q_stats - MQCHIP(0) q_num is 280, i is 1 Feb 1 06:29:21 dis1.bridgenorth1 tfeb0 trinity_pio: 1 PIO errors occurred Feb 1 06:29:21 dis1.bridgenorth1 tfeb0 trinity_pio: Last error: 5 MQ Trinity PCI 0xe97881ca Read PCIe 0 2 5 6 This is a Juniper MX80 running [11.2R3.3] Thanks, Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
2012/1/26 Mark Tinka mti...@globaltransit.net: On Friday, January 27, 2012 02:30:35 AM Keegan Holley wrote: I agree... I think. MPLS has a better forwarding paradigm and the IGP only core of P routers is a plus. Well, I'm not so sure MPLS has a better forwarding paradigm per se. If you're talking about raw forwarding performance, hardware forwarding these days makes that a non-issue, but you already knew that :-). I guess I just meant the fact that there are fewer lookups and fewer operations on the actual packet with MPLS. All the switching decisions are done ahead of time. This is obviously what makes things like FRR and backup LSP's possible as failover methods. It's true that hardware performance, and better proc/mem speed up non-MPLS based paths enough to make it mostly academic. In theory though MPLS is stll the better way to do things. We like running it for Internet traffic because we can remove BGP (for v4) from the core. That's all. On the application side, we like running it because we can offer those cool services like IPTv, l2vpn and them. Why not FRR everything? The control plane hit is negligable even if your internet users wouldn't notice, care about, or even understand the improvements. We have a large-ish network, particularly in the Access (lots of Metro-E switches that are IP/MPLS-aware). Trying to run RSVP everywhere isn't feasible, when your customers are demanding lower and lower prices. Makes sense. I'm still straddling the line between large enterprise and small service provider so I haven't felt the resource bite from RSVP everywhere. Interesting to hear that perspective though. I've seen RSVP work in a T-series/CRS based large network though so I guess platform choice ($$) and design play a role as well. Given the amount of effort required for this, we relegate RSVP-TE to: o Multicast for IPTv services (we'll be using mLDP for data-based Multicast services). We run FRR here too. o Unequal cost routing within the core, so we don't have idle links when others are full. Keeping it in the core only reduces state. o Specific requests from customers who want their traffic to take a specific path, or failover within a very short time (note I don't say 50ms). This we charge expensively to discourage customers from buying it, as it's hectic to maintain, and overall, the differences in latency across several points in the country is very, very negligible. Moreover, we've found failover times for BFD + our tuned IS-IS to be reasonable for most applications. All RSVP instances run Refresh Reduction for scaling, even if state is relatively low due to the above. Makes sense. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
Well NC (network control) is a completely different queue than EF (expedited forwarding). This could be normal. Several things such as routing protocol updates are set to NC by default because it is network control traffic or part of the network control plane. Such traffic should be prioritized during congestion to keep the paths stable. I wouldn't use the NC queue for other traffic if you can avoid it and I wouldn't make this traffic best effort without figuring out what it is. Is it possible that it's just a control protocol? I know most routing protocols mark their hello's as NC. Spanning tree BPDU's might do the same but I can't remember off the top of my head. 2012/1/26 Gökhan Gümüş ggu...@gmail.com: Dear Saku, Thanks for the reply. I checked the queues on the interface as seen below; LON show class-of-service interface ge-2/0/4 Physical interface: ge-2/0/4, Index: 158 Queues supported: 8, Queues in use: 4 Scheduler map: default, Index: 2 Logical interface: ge-2/0/4.0, Index: 216 How can i use %100 BE by changing my config in Juniper? Thanks and regards, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
2012/1/26 Mark Tinka mti...@globaltransit.net: On Sunday, January 22, 2012 08:55:07 AM Derick Winkworth wrote: http://packetpushers.net/internet-as-a-service-in-an-mpls -cloud/ We also want to avoid putting too much reliance on MPLS for basic services like Internet access. We relegate MPLS-based services to those that MUST have it to work, e.g., BGP- MVPN's, l2vpn's, l3vpn's, VPLS, e.t.c. Anything else that doesn't really need MPLS lives on its own, e.g., IPv6 (no need for 6PE), Internet access, e.t.c. What do you use for signaling? It seems like overkill to keep one kind of traffic from using the MPLS operations if there are already LSP's between the source and the destination and L3/L2vpn traffic flowing between them. You also give up some of the MPLS knobs such as FRR and link/node protection. What do you gain by doing this? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
2012/1/26 Saku Ytti s...@ytti.fi: On (2012-01-26 10:52 -0500), Keegan Holley wrote: stable. I wouldn't use the NC queue for other traffic if you can avoid it and I wouldn't make this traffic best effort without figuring Yet in INET facing router, jnpr default 95/5 split causes just that, any user in Internet can get special 5% of privileged capacity from your network. Which is strictly different from csco default, which is 100% BE. That's not exactly accurate. Cisco's kit also has some queuing setup by default. The details vary by platform. Every cisco router I've worked with defaults to trusting incoming markings rather then rewriting them to best effort. So the cisco default is vaguely similar. Also, in order for someone to take advantage of this queue they would have to get across you're upstreams which means they are doing the same thing. It would then be your fault for not remarking traffic on ingress. It looked like only 832 packets came in as network control so I doubt someone is being malicious. They look like periodic hello's from something which is why I cautioned against flattening the network. I would still hesitate to do a way with queueing all together on the interface. The NC queue doesn't use any bw when it's empty and it may save you from problems if there is congestion in the future. Admittedly, this practice was started when the world had much lower bandwidth links. Now one could argue, that if you care about QoS enough to change the config, more planned approach than jnpr or csco default should be pursued. But at very least you'd probably want to to guarantee that transit and peering interfaces cannot inject arbitrary amount of traffic to your !BE queue. I can't see this being a huge risk. Most of your upstreams will remark on ingress and not hand you traffic tagged with NC. If you are large enough not to have upstreams then you shouldn't be getting your QOS policy from a news group. I think marking most traffic down to BE and leaving the default queues would be fine for most networks unless you have a specific plan. Most networks should have a specific plan here, but ymmv. I would hesitate to flatten everything to BE though for the reasons stated above. Given that I'd need to implement QoS strategy from scratch, and that I'd want to use only 8 values, so I can carry my QoS in EXP/801.1p, I'd do something like this in core (SP focused): 0 - normal INET (e.g. transit customer traffic) 1 - worse than normal (e.g. offsite tape backup) 2 - important INET (e.g. traffic to own ASN, instead of transit customer) 3 - normal VPN (e.g. 0 received from CPE is reset to 2) 4 - preferred (e.g. software required to work at office) 5 - priority (e.g. voice+video, [5 is default in many phones]) 6 - high demand (e.g. internal pstn trunks etc) 7 - network control (e.g. IGP, LDP, iBGP, MGMT) 0 received from INET customer CPE is reset to 2 0 received from VPN/ customer CPE is reset to 3 7,6 received from INET/VPN customer is reset to 5 2,3 received from iNET/VPN customer is reset to 4 This is good for some, but it's hard to recommend a queuing policy to someone without understanding what they do with their network. I've made due in the past with only 4 queues, especially when juniper pic's only had 4. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
You said this is a ccc interface. Is the customer connecting to this device through this interface or is this part of a L2 circuit that traverses this interface. If it is the latter, they could be running a protocol over the circuit that is being placed in your NC queue. Also, how long did it take to increment? If it only logged 832 packets in a few hours or days I'd ignore it. Reconfiguring qos without understanding the traffic flows may be worse. 2012/1/26 Gökhan Gümüş ggu...@gmail.com: Thanks for the replies. I do not have any CoS configuration on my router. There is no Spanning-Tree is running between my device and customer device. I have no idea what is causing an increment in the network-control queue. Any ideas would be appreciated. Thanks and regards, Gokhan On Thu, Jan 26, 2012 at 4:52 PM, Keegan Holley keegan.hol...@sungard.com wrote: Well NC (network control) is a completely different queue than EF (expedited forwarding). This could be normal. Several things such as routing protocol updates are set to NC by default because it is network control traffic or part of the network control plane. Such traffic should be prioritized during congestion to keep the paths stable. I wouldn't use the NC queue for other traffic if you can avoid it and I wouldn't make this traffic best effort without figuring out what it is. Is it possible that it's just a control protocol? I know most routing protocols mark their hello's as NC. Spanning tree BPDU's might do the same but I can't remember off the top of my head. 2012/1/26 Gökhan Gümüş ggu...@gmail.com: Dear Saku, Thanks for the reply. I checked the queues on the interface as seen below; LON show class-of-service interface ge-2/0/4 Physical interface: ge-2/0/4, Index: 158 Queues supported: 8, Queues in use: 4 Scheduler map: default, Index: 2 Logical interface: ge-2/0/4.0, Index: 216 How can i use %100 BE by changing my config in Juniper? Thanks and regards, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
2012/1/26 Mark Tinka mti...@globaltransit.net: On Friday, January 27, 2012 12:36:50 AM Keegan Holley wrote: What do you use for signaling? It seems like overkill to keep one kind of traffic from using the MPLS operations if there are already LSP's between the source and the destination and L3/L2vpn traffic flowing between them. You also give up some of the MPLS knobs such as FRR and link/node protection. What do you gain by doing this? We signal mostly by LDP, and scarcely by RSVP. One of the main reasons we allow Internet traffic to be forwarded by MPLS through the network is to enjoy a BGP-free core for IPv4. That's the only relation the global table has with MPLS. Otherwise, MPLS is used strictly for MPLS-based applications. I agree... I think. MPLS has a better forwarding paradigm and the IGP only core of P routers is a plus. We only use RSVP for p2mp LSP's for our BGP-MVPN Multicast (IPTv) services, and also for focused TE requirements, e.g., unequal cost paths within the core. As the TE is mostly for Internet traffic, we don't turn on FRR for that. We only enable FRR for the p2mp RSVP-based LSP's, and those are dedicated to IPTv. Why not FRR everything? The control plane hit is negligable even if your internet users wouldn't notice, care about, or even understand the improvements. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
That's not exactly accurate. Cisco's kit also has some queuing setup by default. The details vary by platform. Every cisco router I've worked with defaults to trusting incoming markings rather then rewriting them to best effort. So the cisco default is vaguely similar. Also, in order for someone to take advantage of this queue No cisco router does this to my understanding, some cisco routers use TOS values in punt path by default in attempt for rudimentary CoPP. But no Cisco that I know or have tested has different transit scheduling per class The 6509 and the other L3 switch platforms (not sure about the nexus) come to mind here. Not sure about the CRS and ASR-9k though. network control so I doubt someone is being malicious. They look like periodic hello's from something which is why I cautioned against flattening the network. Either you control who can congest this class, or you shouldn't use it. As if it is not used, then dossing the service relying on the 5% NC is trivial, compared to all traffic being BE. I agree it's best practice to control it. I was just saying it's not much of an attack vector. I can't see this being a huge risk. Most of your upstreams will remark on ingress and not hand you traffic tagged with NC. If you are I know that we don't do it, we never touch or trust TOS, we view it as customer property and cleanly pass it over INET (maybe customer wants to use them inside their LAN and signal it still over INET). You can't not touch and not trust traffic at the same time. You trust it, in which case you're doing the same thing you suggest the OP avoid, in that you can't control who's putting what traffic in your queues. If you don't trust then you have to remark to control what queues each type of traffic is placed in. You can also map all markings to a single queue but that would defeat the purpose of marking traffic in the first place. If you run MPLS network this is easy, if you don't have labeled forwarding, there is no option but to reset incoming TOS value in peering/transit, if you are doing any Qos (which in case of JNPR default you are). You can always re-write the QOS bits incoming no matter what protocol you use. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
2012/1/26 Pavel Lunin plu...@senetsy.ru: Why not FRR everything? The control plane hit is negligable even if your internet users wouldn't notice, care about, or even understand the improvements. FRRed traffic can follow very fancy routes eating bandwidth on the way. FRR for high loads is like sending trucks from a speedway to a narrow detour path through a village 10 miles away. Only effect is getting it jammed. The Internet users will also not notice a well-tuned IGP reroute or a head-end switchover to a pre-signaled backup LSP. I can see this happening in some corner cases, but generally speaking why would FRR LSP's take a route different than what the IGP would converge to. CSPF is roughly SPF over a different set of values. I'm asking because I've never seen this in the wild, but I'm usually switching from one speedway to another without the burden of narrow villages. What the VRF-based Internet users will definitely notice is (looks like RAS is tired of telling this story) is ICMP tunneling and consequent hard to interpret delay values. People are very suspicious to the numbers. This is almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. Hey kitty photos are serious business especially if you are facebook stalking the aforementioned kitty. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
2012/1/26 Pavel Lunin plu...@senetsy.ru: why would FRR LSP's take a route different than what the IGP would converge to. Because FRR uses a path from a different entry (PLP) to probably a different exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated) is a path from head-end to tail-end. Whether this happens often or rare, the need to care how your detours are calculated is itself a big enough headache. That's not how FRR works at least for RSVP. It pretty much just re-runs cspf with something removed. So it's the same route your IGP would choose if said thing went dark. I don't have many obscure paths where I wouldn't want traffic to go so I can't really comment on your earlier idea. That being said I've never seen FRR choose a path worse than the path the IGP would choose. It's just preselects that path and pre-signals it. I'm sure there are failure scenarios though. What the VRF-based Internet users will definitely notice is (looks like RAS is tired of telling this story) is ICMP tunneling and consequent hard to interpret delay values. People are very suspicious to the numbers. This is almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. Hey kitty photos are serious business especially if you are facebook stalking the aforementioned kitty. Absolutely. This is why in case of issues you should not waste time for explaining why your core router is 200ms away from the previous hop. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Whitebox 10Gb/s capture challenge
Not to ruin the fun but there are appliances and hardware taps that are purpose built for this. An appliance is probably going to be easier to manage than an actual server. It also scales much better and provides better fault tolerance. 2012/1/12 Drew Weaver drew.wea...@thenap.com Everyone pointed out really good notes here as well but as far as I know and this may have changed recently but if you do the 10Gbps / smallest possible packet size you'll crush the CPU before it ever gets anywhere near the disks. I was trying to figure out a way to use iptables to do simple firewalling at full line rate 10Gbps and it ate a bowl of fail big time (and that was without any disk/io capturing). I'm assuming perhaps newer PCI Express version 3 10G NICs will be released that may be able to get you over that hump but for now it's really tricky to do this on a single box. Which is why vendors charge $50k for those ASIC based capturing boxes =) Thanks, -Drew -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto: juniper-nsp-boun...@puck.nether.net] On Behalf Of Phil Bedard Sent: Monday, January 09, 2012 2:13 PM To: OBrien, Will Cc: J NSP Subject: Re: [j-nsp] Whitebox 10Gb/s capture challenge How much traffic is actually on the boxes? A full 10G or some fraction? Are they in the same datacenter? There are muxing boxes from onpath,apcon, anue, net optics, etc. which might let you get away with less actual capture devices. Keep in mind some of those solutions are fairly expensive themselves... Phil On Jan 9, 2012,s at 11:05 AM, OBrien, Will obri...@missouri.edu wrote: I'm pondering the idea of trying to build a relatively inexpensive 10Gb capture box. The simple solution is a dell R710 with 10Gb nics. I have some, they work, but I'd have to spend $50k to get enough of them. So, my challenge is keeping the price point is something around $1000-$1500 - basically the 10Gb version of a 1u gigE capture system. In general, I probably don't need to ever write 10Gb/s to disk, but it would be nice load the dice for success. My thoughts are a reasonable performance motherboard with 10Gb PCIe nics or a white box mobo with onboard SFP+ ports. Anyone gone this route? Will O'Brien University of Missouri, DoIT DNPS Network Systems Analyst - Redacted obri...@missouri.edu ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] traffic drops to 8 Gb/s when a firewall filter is applied
I 2011/12/14 Richard A Steenbergen r...@e-gerbil.net On Fri, Dec 09, 2011 at 01:19:54PM -0500, Keegan Holley wrote: Yea but it should have enough silicon to do simple policing in hardware unless you have every single other feature on the box enabled. If a policer with no queueing, and no marking etc, caused throughput to decrease by 20% across the board I'd inquire about their return policy. Hopefully, it's the policer config. Most of my 10G interfaces do not require policers, but I've got 1G interfaces with hundreds of logicals each with a unique policer. Unfortunately not... There are all kinds of ways to make I-chip cards not deliever line rate performance even with relatively simple firewall rules, and it's very poorly logged when this does happen. Admittedly I've never seen a simple then accept push it over the edge, but maybe it was RIGHT on the edge before... Try looking for some discards, such as WAN_DROP_CNTR, on the *INGRESS* interface (i.e. not the one where you added the egress filter). For xe-x/y/0 do: start shell pfe network fpcx show ichip y iif stat example: Traffic stats: Counter NameTotal Rate Peak Rate -- -- -- GFAB_BCNTR 4229125816477883 949530 1276098290 KA_PCNTR0 0 0 KA_BCNTR0 0 0 Discard counters: Counter NameTotal Rate Peak Rate -- -- -- WAN_DROP_CNTR 298 0 82 FAB_DROP_CNTR 1511 0419 KA_DROP_CNTR0 0 0 HOST_DROP_CNTR0 0 0 -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) I see your point, but I'd still be surprised if a defaulted box with a then accept filter would drop by this much. You could see the be queue discarding packets in the sh int output. The be queue is given 95% of the buffer in the default schedule map which still leaves 1G plus unaccounted for. Maybe it's a little bit of both. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Difference MX DPC-R / DPCE-R
You can find the details on the juniper website. Off the top of my head I know there are fewer queues and you can't do layer-2 and layer-3 services on the same blade. There's a DPC-S that is layer 2 only. In general you should consider the non-e legacy. I believe they might even be end of life by now. The DPC-E's are eventually going to be superseded by the MPC because of the trio chipsets, but there will be several years before they are dropped, if ever. 2011/12/12 Nicolaj Kamensek n...@accelerated.de Hello list, can anyone name the major differences between those modules? DPC are becoming available in the used market for small money and I am wondering if a DPC non-E is good enough for a classical access router environment with 30.000+ ARP entries and a growing number of IPv6 neighbours but nothing fancy overall. Since it's hard to find any facts about this: - does it matter memory-wise if the requirements above are applied to just one routed port or to multiple switched/routed ports? - do bundled links still double the amount of memory required? Thanks! __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Difference MX DPC-R / DPCE-R
Many thanks. It's been a while since I had to research them. I guess my memory isn't what I thought it was. 2011/12/12 Jonas Frey (Probe Networks) j...@probe-networks.de Keegan, all of the DPC- cards are EOL since long time (05/31/2009). Some of the DPCE- cards are also EOL already. For details here is a list (public): http://www.juniper.net/support/eol/mseries_hw.html Of course juniper wants to move customers to MPC hardware so more and more of the remaining DPCE- cards will go EOL soon. You probably also mixed up DPC-S and DPCE-X, which is the layer2 card. Best regards, Jonas Am Montag, den 12.12.2011, 11:42 -0500 schrieb Keegan Holley: You can find the details on the juniper website. Off the top of my head I know there are fewer queues and you can't do layer-2 and layer-3 services on the same blade. There's a DPC-S that is layer 2 only. In general you should consider the non-e legacy. I believe they might even be end of life by now. The DPC-E's are eventually going to be superseded by the MPC because of the trio chipsets, but there will be several years before they are dropped, if ever. 2011/12/12 Nicolaj Kamensek n...@accelerated.de Hello list, can anyone name the major differences between those modules? DPC are becoming available in the used market for small money and I am wondering if a DPC non-E is good enough for a classical access router environment with 30.000+ ARP entries and a growing number of IPv6 neighbours but nothing fancy overall. Since it's hard to find any facts about this: - does it matter memory-wise if the requirements above are applied to just one routed port or to multiple switched/routed ports? - do bundled links still double the amount of memory required? Thanks! __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsp https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] traffic drops to 8 Gb/s when a firewall filter is applied
Can you post the filter and a sh int extensive? You might have the burst rate too small. What kind of load are you generation? Do you see the ff counters incrementing? 2011/12/9 Gabriel Blanchard g...@teksavvy.ca We have simple filters configured on our 10Gbps as well on our DPCs and can definitely push more than 8gbps. Though mostly in one direction. Are you saying it's limited to 8gbps in both directions? I'm curious to know which Junos version you are running. Gabriel Blanchard Director, Information Technology TekSavvy Solutions On 11-12-09 10:09 AM, Matjaž Straus Istenič wrote: Hi list, we've tested the throughput of a 10G interface on a DPCE 4x10GE R running in MX960. We've loaded the interface with almost 10 Gb/s of traffic in both directions and it work fine with no loss until an output filter was activated on the interface. Then the traffic dropped to 8 Gb/s flat. A filter that caused that could be as simple as a single accept term. Input filter doesn't have any impact, only output filter does. Only one logical interface was involved in the tests. Traffic flows in and out through the same interface. We have a JTAC case opened on this (since september 2011). Latest news from them: we tested this on 1 gig interface and it works fine (!?). Nice, it might work on 100 meg also ;-). Has anybody on the list run into something similar (not talking about the support, but the effect of the outbound firewall filter on a 10 GE interface ;-))? Kind regards, Matjaž --- Matjaž Straus Istenič, Arnes http://www.arnes.si Tel: +386 1 4798-877 Fax: +386 1 4798-878 matjaz.str...@arnes.si MS6745-RIPE PGP 490F3B4F 2009-10-21 Fingerprint = 6172 7BF8 B0B7 1F09 47B3 AFA3 0946 1701 490F 3B4F __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] root@re1 as root: cmd='/sbin/sysctl net.inet.ip_control_plane messages
10.4R5.5 on 1G and 10G DPE-E's. Our MPC hardware doesn't seem to log this message either. Thanks. 2011/12/5 Mark Tinka mti...@globaltransit.net On Monday, December 05, 2011 12:39:54 AM Keegan Holley wrote: I'm seeing these come in once every few seconds after upgrading some M/MX boxes to 10.4. Has anyone else run into this problem? I don't personally agree with it but we log any any right now and filter on the syslog servers. I'll probably open a JTAC case on monday, just wondering if anyone else had run into this and solved it. Which flavour of 10.4? We've been running 10.4R4.5 since it started shipping. We've come across all sorts of logs, but not this one. We're looking at moving to 10.4R8.5 as it's now out. Is that what you're on? Anyone else had any experience with it? MX480 with MPC2 3D cards here. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] root@re1 as root: cmd='/sbin/sysctl net.inet.ip_control_plane messages
I'm seeing these come in once every few seconds after upgrading some M/MX boxes to 10.4. Has anyone else run into this problem? I don't personally agree with it but we log any any right now and filter on the syslog servers. I'll probably open a JTAC case on monday, just wondering if anyone else had run into this and solved it. Thanks, Keegan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Does a L3VPN RR require routing-instance for each VRF?
Do you have family inet-VPN configured in the group stanza? All the routes are reflected from the bgp.l3vpn.0 table. You don't have to define each vrf. If you already configured the address family it sounds like it doesn't like your ext. communities for some reason. Sent from my iPhone On Nov 29, 2011, at 7:37 AM, Phil Mayers p.may...@imperial.ac.uk wrote: As per subject line: if we want to use a JunOS box (M7i, running 10.4) as a route-reflector, it seems to reject inet-vpn routes with: bgp_rcv_nlri: 129.x.x.0:4:193.x.x.0/92 rejected due to the lack of a valid target community I was hoping we could avoid the hassle of defining the VRF on the RRs if possible, but I guess that is required - am I missing some obvious / subtle point why that is the case, or some way of making it work? Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VLAN-CCC over GRE extended to GE interface
+1 GRE between loopbacks. Why not just use RSVP for labeling and do L2vpn or pseudowire. Both work though. 2011/11/3 Jack Bates jba...@brightok.net On 11/3/2011 1:45 PM, Terry Jones wrote: Simple enough using a vlan-ccc. The problem is that I have to setup the vlan-ccc over a GRE tunnel. Now the question I have is how to make it layer 2 to the GE interface? Since I can using a vlan-ccc, vlan-ccc and family inet cannot be configured on the same vlan-id, so I cannot terminate the GREs on the same endpoints (GE) that I need to configure the vlan-ccc. I would think the GRE is between loopbacks on each router, and then l2circuit over tldp over rsvp (or perhaps just ldp) over GRE? Are you saying that you need a layer 2 crossconnect and layer 3 services on the same vlan? Jack __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vpls loop avoidance
A spanning tree TCN would do it as well. It would be nice if configuring STP at the edge caused the box to TCN when it gives up mastership. I haven't tried it but I'm pretty sure it doesn't. 2011/10/20 David Ball davidtb...@gmail.com On 20 October 2011 14:00, William Cooper wcoope...@gmail.com wrote: I might be confused... but wouldn't the switches learn the MAC to port association dynamically based on traffic flows? In the absence of gratuitous ARP (used, for example, by VRRP), no. The switch will learn it once, cache it, and that MAC-to-port entry will remain until it times out and is relearned (unless the switch port goes down, in which case the switch will flush MACs learned on that port). This is where an earlier poster's idea of shortening the MAC aging timeout on the switch could help a little, though some folks might prefer faster failover than is afforded by MAC timeouts on a dead (yet still admin/oper UP) port. You can typically flush the MAC table manually on the switch, but that's certainly not a viable solution for speeding up automated failover. David ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vpls loop avoidance
Interesting. It's a stack. I guess I'll have to use multihoming. Just for fun I'm going to see if I can get it to pass the untagged BPDUs. Thanks, Keegan 2011/10/12 Phil Bedard phil...@gmail.com Standards-based STP BPDUs are sent untagged, which might be an issue if the links to your CE switches are tagged only. Cisco PVST+ sends the BPDUs with a VLAN tag. I remember seeing some blurb about not connecting two CE devices to each other if they are connected to two different PEs with the same site-id. Is this one switch or two? Phil On 10/11/11 4:14 PM, Keegan Holley keegan.hol...@sungard.com wrote: 2011/10/11 Humair Ali humair.s@gmail.com Hi Keegan As far as I know , in VPLS, it uses split horizon as loop avoidance mechanism , and you should not see any loop occurring in a VPLS setup,(pending the rest of config is correct) Yes it is BGP signaled so that will solve the loops on the core facing interfaces. The only way you could have a loop in VPLS is when you start having your CE dual homed , where in that case you need to either configure STP , or you could use the primary/backup knob to define which PE is the primary and which is the back up. STP doesn't seem to work here. Only cisco PVST which doesn't help me on an EX4200. Primary/backup has to do with multihoming which works as well. I'd like to know why this works when the site-id's are the same and why the l2forwarding instance doesn't work. I'm also curious why cisco pvst works and none of the standards based protocols. On 11 October 2011 20:19, Keegan Holley keegan.hol...@sungard.com wrote: I'm trying to get my handle on vpls loop avoidance and I can't remember the default behavior regarding site-id's and node-id's. I remember reading about it in one config guide or another but I can't seem to find it now. I'm trying to remember if broadcast, multicast and unknown unicast is flooded between PE router interfaces with the same site id's and maybe just some general guidelines on their behavior. I'm trying to understand best practices for loop avoidance. It seems to loop with any standards based STP protocol if two or more interfaces are connected to routers configured with the same site-id. The behavior I see seems to be the opposite of what the website says. http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/vpn-confi guring-ethernet-switch-as-the-ce-device.html ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Humair ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] vpls loop avoidance
I'm trying to get my handle on vpls loop avoidance and I can't remember the default behavior regarding site-id's and node-id's. I remember reading about it in one config guide or another but I can't seem to find it now. I'm trying to remember if broadcast, multicast and unknown unicast is flooded between PE router interfaces with the same site id's and maybe just some general guidelines on their behavior. I'm trying to understand best practices for loop avoidance. It seems to loop with any standards based STP protocol if two or more interfaces are connected to routers configured with the same site-id. The behavior I see seems to be the opposite of what the website says. http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/vpn-configuring-ethernet-switch-as-the-ce-device.html ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vpls loop avoidance
2011/10/11 Humair Ali humair.s@gmail.com Hi Keegan As far as I know , in VPLS, it uses split horizon as loop avoidance mechanism , and you should not see any loop occurring in a VPLS setup,(pending the rest of config is correct) Yes it is BGP signaled so that will solve the loops on the core facing interfaces. The only way you could have a loop in VPLS is when you start having your CE dual homed , where in that case you need to either configure STP , or you could use the primary/backup knob to define which PE is the primary and which is the back up. STP doesn't seem to work here. Only cisco PVST which doesn't help me on an EX4200. Primary/backup has to do with multihoming which works as well. I'd like to know why this works when the site-id's are the same and why the l2forwarding instance doesn't work. I'm also curious why cisco pvst works and none of the standards based protocols. On 11 October 2011 20:19, Keegan Holley keegan.hol...@sungard.com wrote: I'm trying to get my handle on vpls loop avoidance and I can't remember the default behavior regarding site-id's and node-id's. I remember reading about it in one config guide or another but I can't seem to find it now. I'm trying to remember if broadcast, multicast and unknown unicast is flooded between PE router interfaces with the same site id's and maybe just some general guidelines on their behavior. I'm trying to understand best practices for loop avoidance. It seems to loop with any standards based STP protocol if two or more interfaces are connected to routers configured with the same site-id. The behavior I see seems to be the opposite of what the website says. http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/vpn-configuring-ethernet-switch-as-the-ce-device.html ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Humair ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Fan Tray Failure in JM20
If they all go at the same time it may indicate that the chassis connections to it is bad. Can you try the same fans in a different chassis? 2011/10/10 Jon Helman j...@ic2net.net Graham, Previously, I was only receiving a syslog report that the upper fan tray had failed. I went to the router site and replaced the upper left fan assembly. After that they all reported failure. I placed my hand over the side of the JM20 and I feel no air being pushed out from the unit. The unit has ample A/C directly blowing on it. Is there some type of fuse that powers all of the fan tray units? Thanks for your assistance, Jon Helman Owner 714-970-5011 Phone ext 2260 714-660-2260 Direct 714-970-5449 Fax j...@ic2net.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] commit scripts
To juniper: If you are going to include syntax checking please include line numbers like other things that check other types of syntax. The following does not constitute a valid error message: re0: configuration check succeeds re1: *error: syntax error: ;* error: remote load-configuration failed on re1 Thank you, A customer ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Hardware Not present
We are using the following to dedicate fpc bandwidth instead of disabling
tunnel services. I've been told it's faster but disables a gig interface to
cannibalize the asics. It however requires a fpc restart. I suppose a RTM
is in order. Thanks all for the input.
set chassis fpc 0 pic 0 tunnel-services bandwidth 1g
2011/9/30 Keegan Holley keegan.hol...@sungard.com
Ok, I'm stumped. Configuring vpls and everything seems to be working but
the local router interfaces. They come up as NP or hardware not present.
The DPC and pic are up and working fine and I've tried it with tunnel
bandwidth 1g configured under the chassis stanza as well as no tunnel
services under vpls protocols. I have a pretty good grasp of vpls
configuration, but I'm sensing a juniper nuance that I don't remember. Does
this ring any bells for anyone?
Thanks,
Keegan
root@mx480 show vpls connections
Layer-2 VPN connections:
Legend for connection status (St)
EI -- encapsulation invalid NC -- interface encapsulation not
CCC/TCC/VPLS
EM -- encapsulation mismatch WE -- interface and instance encaps not
same
VC-Dn -- Virtual circuit downNP -- interface hardware not present
CM -- control-word mismatch - -- only outbound connection is up
CN -- circuit not provisioned- -- only inbound connection is up
OR -- out of range Up -- operational
OL -- no outgoing label Dn -- down
LD -- local site signaled down CF -- call admission control failure
RD -- remote site signaled down SC -- local and remote site ID collision
LN -- local site not designated LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum
designated
XX -- unknown connection status IL -- no incoming label
MM -- MTU mismatch
Legend for interface status
Up -- operational
Dn -- down
Instance: vplsA
Local site: mx480-vplsA (6)
connection-site Type St Time last up # Up trans
5 rmt NP
9 rmt NP
10rmt NP
{master}
root@mx480
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...
2011/9/27 Gert Doering g...@greenie.muc.de Hi, On Mon, Sep 26, 2011 at 01:18:05PM -0700, Derick Winkworth wrote: I'm trying to find an archived discussion or presentation discussing why exactly the industry generally settled on having a separate FIB table for each VRF vs having one FIB table with a column that identifies the VRF instance? I'm not finding it, but I'm guessing its because of performance issues? Lookup would fail for overlapping address space if you lookup address first, VRF second. How do you find the right entry if you have 10.0.0.0/8 vrf red 10.0.0.0/16 vrf green 10.0.1.0/24 vrf blue and try to look up 10.0.0.1 in vrf red? You'll find the /24 entry, which is tagged vrf blue. Alternatively, you'd need to explode the /8 entry for vrf red if *another* VRF adds a more specific for that /8. I'm not claiming to understand why equipment manufacturers chose one method over another. However, if the vrf's all have separate tables in the real world then that should require the table lookup to come before the prefix lookup. If not there would be no way to figure out which fib to search. If you apply the same logic to routes in the same FIB it works, at least in theory. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...
Now in dcef mode With a separate FIB+Adjacency tables per vrf You could copy only subset of FIB and Adjacency tables to the linecard based on which vrfs the interfaces on the particular line-card are asociated with -to save up some memory (than a proces would be needed to request FIB resend from the RP when interface on a line-card would be asociated with a new vrf) This would also work with a single FIB as well as long as the routes were marked with what vrf they belong in. Maybe we're missing the obvious. It's possible that there is no real reason why it separate FIBs were used. It's possible that this decision was made before vrf and L3VPN were common technologies and it was considered safer to have separate FIBs. Also, in the event of a forwarding bug or even a security hole it's alot easier to maintain the integrity of a VRF if it's forwarding entries are separate from the others. adam -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: Tuesday, September 27, 2011 9:58 AM To: Derick Winkworth Cc: juniper-nsp@puck.nether.net; cisco-...@puck.nether.net Subject: Re: [c-nsp] general question on VRFs and FIBs... Hi, On Mon, Sep 26, 2011 at 01:18:05PM -0700, Derick Winkworth wrote: I'm trying to find an archived discussion or presentation discussing why exactly the industry generally settled on having a separate FIB table for each VRF vs having one FIB table with a column that identifies the VRF instance? I'm not finding it, but I'm guessing its because of performance issues? Lookup would fail for overlapping address space if you lookup address first, VRF second. How do you find the right entry if you have 10.0.0.0/8 vrf red 10.0.0.0/16 vrf green 10.0.1.0/24 vrf blue and try to look up 10.0.0.1 in vrf red? You'll find the /24 entry, which is tagged vrf blue. Alternatively, you'd need to explode the /8 entry for vrf red if *another* VRF adds a more specific for that /8. gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ http://www.muc.de/%7Egert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...
2011/9/27 Robert Raszuk rob...@raszuk.net Hi Keegan, over another. However, if the vrf's all have separate tables in the real world then that should require the table lookup to come before the prefix lookup. If not there would be no way to figure out which fib to search. For packets coming from customer (CE) there is no need for any additional lookup as switching vectors of the interfaces (logical/physical) are already locked to a given VRF. /* One exception of the above is Policy Based VRF selection where you are choosing VRF dynamically based on preconfigured policy or even remote radius lookup. in this configuration interfaces are not bounded to any VRF. */ For packets coming from the core to a PE the VPN label directly points to the right VRF (per vrf label/aggregate label case). For per CE or per prefix labels no IP lookup is necessary in the VRFs at all for packets going to the CE. I think you misunderstood. This is all part of the same lookup. The first is matched by the interface, the second by policy and the third by mpls tag. My point is that it is the same operation across multiple FIBs or a single FIB. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] full table?
Is it always necessary to take in a full table? Why or why not? In light of the Saudi Telekom fiasco I'm curious what others thing. This question is understandably subjective. We have datacenters with no more than three upstreams. We would obviously have to have a few copies of the table for customers that want to receive it from us, but I'm curious if it is still necessary to have a full table advertised from every peering. Several ISP's will allow you to filter everything longer than say /20 and then receive a default. Just curious what others think and if anyone is doing this. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] full table?
2011/9/20 Mark Tinka mti...@globaltransit.net On Wednesday, September 21, 2011 01:26:07 AM Keegan Holley wrote: Is it always necessary to take in a full table? Why or why not? In light of the Saudi Telekom fiasco I'm curious what others thing. This question is understandably subjective. We have datacenters with no more than three upstreams. We would obviously have to have a few copies of the table for customers that want to receive it from us, but I'm curious if it is still necessary to have a full table advertised from every peering. Several ISP's will allow you to filter everything longer than say /20 and then receive a default. Just curious what others think and if anyone is doing this. Well, if you're connected to a single provider, you tend to have less use for a full table. 0/0 or ::/0 will do just fine. I wish :) If you're multi-homed and need to get full use of those links, while taking a full feed isn't absolutely necessary, it does help. Folks have gotten by with default, or default + partial, or even eBGP Multi-Hop + Loopback peering if multi-homed to the same ISP. If your customers want a full table from you (and you're multi-homed), then a full table likely makes sense. I thought about partials for the data center links and having a separate router that carries the full table for the customers that wish to peer with us. This makes me uneasy though. Thoughts of routing loops or the default leaking into the side with the full table. Just wondering what others have done. Maybe this is the right way. If you want to implement very fine control of your routing and traffic flow, and perhaps, offer that capability to your customers through BGP communities, a full table may make sense. We offer that as well as do our upstreams. It's always been easier to use a full table for everything. My thought was to develop a lower tier of internet service based on smaller devices and manipulate the next hops so that the traffic from the full table customers can still traverse a feed where we may not be receiving a full table. I'm prone to strange ideas though... If you're modeling the routing table for research, traffic engineering studies or some such work, a full table may make sense. I wish :) If you're suffering from old hardware that you don't have the cash to upgrade as you run out of FIB slots, having a full table is probably the least of your problems, and you may consider just default, partial routes, or default + a skinny full table. I've inherited alot of old hardware from mergers. The main problem is that there aren't enough hands to type the request software adds and install the MX's. My idea was a skinny table for most users and a system of route reflectors for those that need a full table. As always, it depends, and YMMV :-). Indeed. Thanks! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] full table?
2011/9/20 Pavel Lunin plu...@senetsy.ru Is it always necessary to take in a full table? Why or why not? In light of the Saudi Telekom fiasco I'm curious what others thing. This question is understandably subjective. We have datacenters with no more than three upstreams. We would obviously have to have a few copies of the table for customers that want to receive it from us, but I'm curious if it is still necessary to have a full table advertised from every peering. Several ISP's will allow you to filter everything longer than say /20 and then receive a default. Just curious what others think and if anyone is doing this. 1. If you have downstream ASes, than full table is [most probably] needed to be not just received but also used for forwarding (this is by default, but you can alter, see below). Otherwise loops/blackholes are possible in specific scenarios (split customer's AS, etc). Workarounds exist for this, but they are rather too complicated to maintain and make everyone in NOC to remember how it works. Some folks (especially DCs) don't care and just send full table to customers, not having it in data plane. For DCs with just few customers with their own ASes, this approach works well almost always (until something breaks). When issues arise, they troubleshot it and rewrite policies to accept additional routes. Not very good, but I saw this many times. This is very insightful and probably the biggest hurdle to overcome. I definitely have downstreams that require the full table. The combination of full tables and skinny tables opens the possibility for routing loops, suboptimal paths and confusion. Then there's the NOC factor. 2. You must remember (people forget these basics surprisingly often), that full table, you receive from upstreams or IX-peer, is used to _send_ traffic. So when you think it's useful to have full table to analyze or somehow intellectually influence traffic balancing across uplinks, you must remember that it only relates to traffic going _out_ your AS. Every couple of weeks I talk to someone who believes, he needs to receive full table, since he wants to balance traffic. When I ask them, how much traffic they send out, it usually turns out to be not more than 10% of a single link capacity, and they don't experience any problem with it at all. And yes, most of them need to balance incoming traffic, but full table has nothing to do with this. I often field this question myself. 6. If, after checking rules 1-5, you are still not sure if you need full table -- you definitely don't. Having this said, I'd say, full table is needed because of the downstream ASes. Playing the games described above does not worth it. Wishful thinking I suppose. Thanks all for humoring me. __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What does AS path attribute problem mean?
I'm hearing this may not be fixed until 10.3 and later. I'm still waiting
for confirmation from juniper though. I'm not sure if I would consider this
a bug or a misinterpretation of the RFC. That message is for malformed
routes/updates not for routes/updates with things we don't like in them.
Either way it needs to go.
2011/9/9 Andrew Parnell and...@parnell.ca
Completely agree, the real fix is to update the old/buggy software,
however this does solve the immediate problem of my BGP sessions
flapping spontaneously. We're already planning to do a batch of code
upgrades soon, so unless this becomes more than just a one-off
incident, I'd rather not rush into software updates on this particular
Friday.
Andrew
On Fri, Sep 9, 2011 at 1:07 PM, Jared Mauch ja...@puck.nether.net wrote:
Well, the update is well formatted and proper, the handling in
JunOS is buggy. You don't want to just blackhole unkown items like this as
you can
create a significant problem for others similar to the bogon problems
that exist.
This type of a fix is ONLY a short term fix to workaround your
buggy
software.
- Jared
On Fri, Sep 09, 2011 at 12:58:36PM -0400, Andrew Parnell wrote:
We noticed this as well on a couple of our M7i running 9.x series
code, but not on others running 10.x. This is being caused by a
particular prefix (212.118.142.0/24):
rpd[5239]: xx.xx.253.192 (Internal AS xx) Received BAD update for
family inet-unicast(1), prefix 212.118.142.0/24
The easy solution is to simply filter out the offending prefix. There
are many ways this can be done, but the following did the trick for
us:
policy-options {
prefix-list bad-prefixes {
212.118.142.0/24;
}
policy-statement BGP-Import {
term block-bad-prefixes {
from {
prefix-list bad-prefixes;
}
then reject;
}
}
Apply something like this to your BGP import and/or export policy as
appropriate and you should be fine.
Andrew
On Fri, Sep 9, 2011 at 11:41 AM, Markus unive...@truemetal.org wrote:
All of a sudden without changing anything in the config I'm getting
the
following on a M7i running 8.0R2.8:
rpd[3019]: bgp_read_v4_update: NOTIFICATION sent to 89.146.xx.49
(External
AS ): code 3 (Update Message Error) subcode 11 (AS path attribute
problem)
The other end (Cisco) is getting:
%BGP-3-NOTIFICATION: received from neighbor 89.146.xx.50 3/11 (invalid
or
corrupt AS path) 0 bytes
This is causing the BGP session to flap. It happens at arbitrary
intervals,
sometimes once a minute, sometimes just once in an hour. CFEB and RE
CPU are
at steady 100% when it happens.
What can I do about this and what could be the cause? Help! :)
Thanks!
Markus
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Jared Mauch | pgp key available via finger from ja...@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only
mine.
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What does AS path attribute problem mean?
You can't filter it because the operation that causes the flap happens
before the route filters are evaluated.
2011/9/9 Clay Haynes chay...@centracomm.net
On Fri, Sep 9, 2011 at 1:07 PM, Jared Mauch ja...@puck.nether.net wrote:
Well, the update is well formatted and proper, the handling in
JunOS
is buggy. You don't want to just blackhole unkown items like this as you
can
create a significant problem for others similar to the bogon problems
that exist.
This type of a fix is ONLY a short term fix to workaround your
buggy
software.
- Jared
On Fri, Sep 09, 2011 at 12:58:36PM -0400, Andrew Parnell wrote:
We noticed this as well on a couple of our M7i running 9.x series
code, but not on others running 10.x. This is being caused by a
particular prefix (212.118.142.0/24):
rpd[5239]: xx.xx.253.192 (Internal AS xx) Received BAD update for
family inet-unicast(1), prefix 212.118.142.0/24
The easy solution is to simply filter out the offending prefix. There
are many ways this can be done, but the following did the trick for
us:
policy-options {
prefix-list bad-prefixes {
212.118.142.0/24;
}
policy-statement BGP-Import {
term block-bad-prefixes {
from {
prefix-list bad-prefixes;
}
then reject;
}
}
Apply something like this to your BGP import and/or export policy as
appropriate and you should be fine.
Andrew
On Fri, Sep 9, 2011 at 11:41 AM, Markus unive...@truemetal.org
wrote:
All of a sudden without changing anything in the config I'm getting
the
following on a M7i running 8.0R2.8:
rpd[3019]: bgp_read_v4_update: NOTIFICATION sent to 89.146.xx.49
(External
AS ): code 3 (Update Message Error) subcode 11 (AS path attribute
problem)
The other end (Cisco) is getting:
%BGP-3-NOTIFICATION: received from neighbor 89.146.xx.50 3/11
(invalid
or
corrupt AS path) 0 bytes
This is causing the BGP session to flap. It happens at arbitrary
intervals,
sometimes once a minute, sometimes just once in an hour. CFEB and RE
CPU are
at steady 100% when it happens.
What can I do about this and what could be the cause? Help! :)
Thanks!
Markus
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Jared Mauch | pgp key available via finger from ja...@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only
mine.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
I have a case open with TAC on this. They recommended temporarily filtering
out the bad prefix (as others have mentioned in this thread), and upgrading
to JUNOS 10.2 or later which doesn't appear to have the issue. In the
meantime they're looking for the root cause of the flap and seeing if
there's a different way to fix it for older supported versions of JUNOS.
Regards,
Clay
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What does AS path attribute problem mean?
That's good to know. I thought it was fixed in 9.X code until a 9.6R2.11 router started having issues. 2011/9/9 Mark Tinka mti...@globaltransit.net On Saturday, September 10, 2011 03:20:34 AM Chris Adams wrote: I've got an M10i running JUNOS 9.3R4.4 that is logging the same error about that prefix, but it does not cause the BGP session to flap. I'm not seeing any unusual behavior beyond the log message itself. Junos 9.3R2.8 is affected. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4200 vlan problem
where are you pinging from? inside the vlan or outside of it? Check for mac-addresses. If you are learning the devices mac addresses on both ports in the correct vlans it's not the switch or the config. Have you tried another device in the same port or swapping the two devices? Can you post the config as well? 2011/8/26 Pappas, AJ apap...@ottawaregional.org I am have a ex4200 that is configured for a particular vlan vlan 244. This vlan is configured on 2 ports. I can reach one device fine, the other I am unable to ping the second device ge-4/0/16. I can ping from it but not to it. AJ Pappas | Network Administrator www.ottawaregional.org http://www.ottawaregional.org/ | apap...@ottawaregional.org mailto:apap...@ottawaregional.org phone: 815.431.5180 | mobile line: 815.993.8522 1100 East Norris Drive, Ottawa, IL 61350 USA ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Questions
2011/8/25 Brendan Regan brendan.bre...@gmail.com Hi, I was wondering if anyone knew how to calculate how many routes can be taken in on an MX80 with 2 Full EBGP peers and 1 IBGP peer? I dont' think this is something you can calculate. Most vendors do extensive testing and come up with a number that they are willing to support. There are alot of variables and just because you may be able to stuff a box full of routes without it crashing doesn't mean that it's safe to do so. It's probably best to just work with the numbers put out by juniper. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper RPM Monitoring
2011/8/25 Saku Ytti s...@ytti.fi On (2011-08-25 10:36 +0100), Danny Vernals wrote: Using it to monitor availability worked fine but if you're planning on monitoring latency and jitter then my findings were to do this you'd need an MS-DPC. With an MS-DPC the service can use two-way time stamping, without one you can only do one-way timestamping and you're reliant on the RE so results are subject to variance when the router is busy with RPD etc. There was a significant difference between latency / jitter measured on external probes compared to results based on RPM. I'd really want to see RPM timestamping implemented in trio. With accurate clock source to the router and hardware timestamping RPM could be produce much better than millisecond accurate measurements regardless of RE related latencies. I recall hearing prior to EX launch that they would timestamp RPM in hardware, but later someone I know who I know suspected this not to be true due to results he was seeing. According to the 10.0 release notes RPM timestamping in hardware can be enabled with a specific command. I'm checking to make sure this is on all cards and not just the Trio stuff. I'll post whatever answers I get. Thanks everyone for responding. ■ RPM timestamping extension (MX Series routers)—Adds support for timestamping of RPM probes in the Packet Forwarding Engine host processer. On MX Series routers only, you can enable this feature by including the hardware-timestamp statement at the [edit services rpm probe probe-name test test-name] hierarchy level. ■ Failure of the Packet Forwarding Engine-based RPM feature with stateful firewall rules—The Packet Forwarding Engine-based RPM feature does not support any stateful firewall configurations. If you need to combine RPM timestamping with stateful firewall, you should use the interface-based RPM timestamping service. Multiservices DPCs support stateful firewall processing as well as RPM timestamping. Keegan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 32-Bit JunOS on the 64-Bit Routing Engines
2011/8/25 Daniel Roesen d...@cluenet.de On Wed, Aug 24, 2011 at 07:52:54PM -0400, Keegan Holley wrote: They are saying that the new 16G RE's can handle 250M routes. How is this possible if none of the daemons are 64bit? Multiple logical-system instances (== multiple rpd processes)? :-) lol. a) try splitting your table between multiple routers virtual or otherwise and let me know how that works out. b) So someone shows up and pitches a router where the specs are based on the power of a single logical router x the number of logical routers I can create. If my response is to purchase said contraption and put it in my network, whatever happens then is my fault. c) It would be extremely ironic if the EOL'd the 16G RE and release one with a bigger proc before the extra ram becomes useful like they did with the first 2G RE. -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 32-Bit JunOS on the 64-Bit Routing Engines
Interestingly enough my SE told us this is possible at lease on our Mx480 and MX960 boxes. Our lab boxes are otherwise engaged at the moment so we havent tested. One note regarding general computing though. The processor can only address 4G (3.8 or so actually) of ram with a 32 bit word size. So even if you get the re's running the 32 bit code they will only register 4G of the precious 16G. Sent from my iPhone On Aug 24, 2011, at 3:12 AM, Thomas Eichhorn t...@te3networks.de wrote: Hi all, I just discussed the following with my SE: I wanted to get new 64Bit REs with some new gear, but run the 32-Bit JunOS on them - he denied that this is possible. I tried to research that, but have not yet found something in the docs - does anybody here have some clue about that? As the REs are 'only' standard PCs, I do not see any reason for them to be not capable of running 'legacy' 32Bit JunOS. I would be really glad if someone has some clue about that and could unearth the truth. Thanks, Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 32-Bit JunOS on the 64-Bit Routing Engines
Sent from my iPhone On Aug 24, 2011, at 9:13 AM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Keegan Holley keegan.hol...@sungard.com said: Interestingly enough my SE told us this is possible at lease on our Mx480 and MX960 boxes. Our lab boxes are otherwise engaged at the moment so we havent tested. One note regarding general computing though. The processor can only address 4G (3.8 or so actually) of ram with a 32 bit word size. So even if you get the re's running the 32 bit code they will only register 4G of the precious 16G. Well, that isn't entirely true. Intel added the Physical Address Extension to the Pentium Pro many years ago (and virtually everything claiming to be i686 compatible has PAE). PAE allows the OS kernel to address up to 36 bits of RAM (64G), just not all at once. I've never heard of this actually being used though. Maybe I'm wrong though. Most people just modified their code to support 64 bit and stopped there. I also haven't seen any boards RE's or regular Mobo's with 32 bit procs and support for more that the 4G of RAM. In general, a given program can still only see 32 bits, unless it does special bank switching. I don't know about PAE support on FreeBSD or JUNOS, but it does exist in all x86 Juniper hardware. Interesting. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Juniper RPM Monitoring
Does anyone have any experiences with RPM on MX boxes? I'm a bit leary of monitoring daemons and probes running directly on routes. Then there's the recent bug circus with the 9 and 10 code trains. I also can't remember coming across it anywhere in the wild. Just wondering if anyone has had any experience with it positive or negative. http://www.juniper.net/us/en/local/pdf/app-notes/3500145-en.pdf ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 32-Bit JunOS on the 64-Bit Routing Engines
As Robert pointed out, 32/64 bit use the same codebase and at the current point in time only the kernel is enabled to handle the additional memory. Therefore some of the memory maps/footprints changed slightly. No other daemons have moved to 64bit. They are saying that the new 16G RE's can handle 250M routes. How is this possible if none of the daemons are 64bit? -- Weitergeleitete Nachricht Von: Thomas Eichhorn t...@te3networks.de Datum: Wed, 24 Aug 2011 13:27:14 +0100 An: Keegan Holley keegan.hol...@sungard.com Cc: juniper-nsp@puck.nether.net Betreff: Re: [j-nsp] 32-Bit JunOS on the 64-Bit Routing Engines Yeah, that is clear - my original point is: I do not trust the 64bit software - I have more faith in the 32bit software. As per now, it has equal cost to order an MX960 with 32b-4G-RE or 64b-16G-RE. So of course I would order the bigger RE but only if I can use the the matured software... Tom Am 24.08.2011 14:19, schrieb Keegan Holley: Interestingly enough my SE told us this is possible at lease on our Mx480 and MX960 boxes. Our lab boxes are otherwise engaged at the moment so we havent tested. One note regarding general computing though. The processor can only address 4G (3.8 or so actually) of ram with a 32 bit word size. So even if you get the re's running the 32 bit code they will only register 4G of the precious 16G. Sent from my iPhone On Aug 24, 2011, at 3:12 AM, Thomas Eichhornt...@te3networks.de wrote: Hi all, I just discussed the following with my SE: I wanted to get new 64Bit REs with some new gear, but run the 32-Bit JunOS on them - he denied that this is possible. I tried to research that, but have not yet found something in the docs - does anybody here have some clue about that? As the REs are 'only' standard PCs, I do not see any reason for them to be not capable of running 'legacy' 32Bit JunOS. I would be really glad if someone has some clue about that and could unearth the truth. Thanks, Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Ende der weitergeleiteten Nachricht ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] load balancing in Route reflector scenario
Not sure if others will have a better answer, but I don't think this is possible. As far as I know BGP doesn't support multi-pathing so there isn't a way to have two next hops used for the same prefix. You might be able to peer with a loopback address and use your IGP to create equal cost routes to the BGP loopback address. If you run mpls that obviously complicates things a bit. 2011/8/10 biwa net biwa...@gmail.com Dear All I have a setup where I need to load balancing routes received from 2 RR in IPV4 environment (not VPN-IPV4) I have my PE (let's called PE1) connected to 2 RR (cluster), my destination subnet eg: 10.1.1.1/24 is behind 2 PE (PE-2 and PE3) which are also client of the same 2RR PE-2 and PE3 are sending the same route 10.1.1.1/24 to the RR , which as per normal behavior is selecting the best route to PE1 , My issue is that RR is always advertising the route 10.1.1.1/24 through PE2 (due to lower router id) as best path and I would like to load balanced it through PE2 and PE3 Anyone can recommend a way to load balance ? Unfortunately I dont have a lab to test any solution and there are live traffic on this ,so all I can do is guessing is whether the below 2 option would work or not. 2 option I have 1.So here I am trying to thinking about testing the multipath command under the RR configuration to see if I am receiving routes from both PE or not , 2. try to put all devices them in routing instance VRF , with the BGP configuration under it (both RR and client) , and RD configured in the VRF (but not putting any vpn family under bgp) so that it stays IPV4 routes , maybe I could cheat the RR to believe these are 2 differentes routes due to the RD, but dont know if this works or not . anyone has had similar issue and found a workaround ? does the 2 option above actually work or not ? thanks for any input ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] load balancing in Route reflector scenario
I thought advertise inactive just configured the routers to advertise the entire BGP RIB instead of only advertising the routes in the routing-table. How would you configure multipathing once the routes were there? 2011/8/10 Stefan Fouant sfou...@shortestpathfirst.net Have you tried the advertise-inactive knob on the RR? I can't guarantee that this will work but it just might also advertise the route towards PE3 as well. Of course, if this works, then you would need to enable multipathing on PE1 accordingly. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 10, 2011, at 2:44 PM, biwa net biwa...@gmail.com wrote: Dear All I have a setup where I need to load balancing routes received from 2 RR in IPV4 environment (not VPN-IPV4) I have my PE (let's called PE1) connected to 2 RR (cluster), my destination subnet eg: 10.1.1.1/24 is behind 2 PE (PE-2 and PE3) which are also client of the same 2RR PE-2 and PE3 are sending the same route 10.1.1.1/24 to the RR , which as per normal behavior is selecting the best route to PE1 , My issue is that RR is always advertising the route 10.1.1.1/24 through PE2 (due to lower router id) as best path and I would like to load balanced it through PE2 and PE3 Anyone can recommend a way to load balance ? Unfortunately I dont have a lab to test any solution and there are live traffic on this ,so all I can do is guessing is whether the below 2 option would work or not. 2 option I have 1.So here I am trying to thinking about testing the multipath command under the RR configuration to see if I am receiving routes from both PE or not , 2. try to put all devices them in routing instance VRF , with the BGP configuration under it (both RR and client) , and RD configured in the VRF (but not putting any vpn family under bgp) so that it stays IPV4 routes , maybe I could cheat the RR to believe these are 2 differentes routes due to the RD, but dont know if this works or not . anyone has had similar issue and found a workaround ? does the 2 option above actually work or not ? thanks for any input ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] load balancing in Route reflector scenario
2011/8/10 Humair Ali humair.s@gmail.com just to clarify , you have : PE2 with 2 link , 1 to RR1 (let's call it link 1) and 1 to RR2 (link 2) PE3 with 2 link , 1 to RR1 (let's call it Link 3) and 1 to RR2 (link4) you could set local pref to link to PE2 to 150 (RR1 to PE2 will be preferred), and link 2 (PE2 to RR2) as standard 100 then set link 3 standard 100 (PE3 to RR1) but set link 4 with 150 (RR2 to PE3 will be preferred) local pref isn't link specific and neither are the BGP peerings. In other words if you have two links to the same RR you would normally only have one peering. If you had multiple, you would still only choose a single route advertised by a single route reflector even though you are changing the local pref several times. then RR1 has prefered path via PE2 (via link 1 high local pref), RR2 have prefered path via PE3( via link 4 high local pref) , Each RR may advertise both route to PE1 The route reflector isn't in the forwarding path most of the time. So the PE's learn each other's routes through the route reflectors but forward directly to each other or to other P routers. On 10 August 2011 21:06, Stefan Fouant sfou...@shortestpathfirst.netwrote: Have you tried the advertise-inactive knob on the RR? I can't guarantee that this will work but it just might also advertise the route towards PE3 as well. Of course, if this works, then you would need to enable multipathing on PE1 accordingly. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 10, 2011, at 2:44 PM, biwa net biwa...@gmail.com wrote: Dear All I have a setup where I need to load balancing routes received from 2 RR in IPV4 environment (not VPN-IPV4) I have my PE (let's called PE1) connected to 2 RR (cluster), my destination subnet eg: 10.1.1.1/24 is behind 2 PE (PE-2 and PE3) which are also client of the same 2RR PE-2 and PE3 are sending the same route 10.1.1.1/24 to the RR , which as per normal behavior is selecting the best route to PE1 , My issue is that RR is always advertising the route 10.1.1.1/24through PE2 (due to lower router id) as best path and I would like to load balanced it through PE2 and PE3 Anyone can recommend a way to load balance ? Unfortunately I dont have a lab to test any solution and there are live traffic on this ,so all I can do is guessing is whether the below 2 option would work or not. 2 option I have 1.So here I am trying to thinking about testing the multipath command under the RR configuration to see if I am receiving routes from both PE or not , 2. try to put all devices them in routing instance VRF , with the BGP configuration under it (both RR and client) , and RD configured in the VRF (but not putting any vpn family under bgp) so that it stays IPV4 routes , maybe I could cheat the RR to believe these are 2 differentes routes due to the RD, but dont know if this works or not . anyone has had similar issue and found a workaround ? does the 2 option above actually work or not ? thanks for any input ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Humair ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] load balancing in Route reflector scenario
I think the advertise inactive knob turns that off, but I don't know for sure because I've never tried it. I know it's not supported on cisco routers. The reason for it is the size of the BGP table. So if the table is 400k routes and you have 5 different ISP's and you advertise every route that would be 2M routes in the table. Since BGP doesn't allow multiple version of the same route in the routing table (separate from the BGP table where incoming routes are stored) you would still only use the original 400K the other 1.8M routes would just go unused unless you manipulated them some how. 2011/8/10 Ivan Ivanov ivanov.i...@gmail.com Hello, On this link http://goo.gl/6FgnZ from Cisco site you can find the below quote: Route Reflector Limitation When multiple iBGP paths installed in a routing table, a route reflector will advertise only one paths (next hop). If a router is behind a route reflector, all routers that are connected to multihomed sites will not be advertised unless a different route distinguisher is configured for each VRF. To be honest I don't why is like this, but I think that with 'multipath' it won't work. HTH On Wed, Aug 10, 2011 at 23:32, Humair Ali humair.s@gmail.com wrote: just to clarify , you have : PE2 with 2 link , 1 to RR1 (let's call it link 1) and 1 to RR2 (link 2) PE3 with 2 link , 1 to RR1 (let's call it Link 3) and 1 to RR2 (link4) you could set local pref to link to PE2 to 150 (RR1 to PE2 will be preferred), and link 2 (PE2 to RR2) as standard 100 then set link 3 standard 100 (PE3 to RR1) but set link 4 with 150 (RR2 to PE3 will be preferred) then RR1 has prefered path via PE2 (via link 1 high local pref), RR2 have prefered path via PE3( via link 4 high local pref) , Each RR may advertise both route to PE1 then on PE1 , u need load balancing configured , I can't guarantee either , but need to be tested. On 10 August 2011 21:06, Stefan Fouant sfou...@shortestpathfirst.net wrote: Have you tried the advertise-inactive knob on the RR? I can't guarantee that this will work but it just might also advertise the route towards PE3 as well. Of course, if this works, then you would need to enable multipathing on PE1 accordingly. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 10, 2011, at 2:44 PM, biwa net biwa...@gmail.com wrote: Dear All I have a setup where I need to load balancing routes received from 2 RR in IPV4 environment (not VPN-IPV4) I have my PE (let's called PE1) connected to 2 RR (cluster), my destination subnet eg: 10.1.1.1/24 is behind 2 PE (PE-2 and PE3) which are also client of the same 2RR PE-2 and PE3 are sending the same route 10.1.1.1/24 to the RR , which as per normal behavior is selecting the best route to PE1 , My issue is that RR is always advertising the route 10.1.1.1/24through PE2 (due to lower router id) as best path and I would like to load balanced it through PE2 and PE3 Anyone can recommend a way to load balance ? Unfortunately I dont have a lab to test any solution and there are live traffic on this ,so all I can do is guessing is whether the below 2 option would work or not. 2 option I have 1.So here I am trying to thinking about testing the multipath command under the RR configuration to see if I am receiving routes from both PE or not , 2. try to put all devices them in routing instance VRF , with the BGP configuration under it (both RR and client) , and RD configured in the VRF (but not putting any vpn family under bgp) so that it stays IPV4 routes , maybe I could cheat the RR to believe these are 2 differentes routes due to the RD, but dont know if this works or not . anyone has had similar issue and found a workaround ? does the 2 option above actually work or not ? thanks for any input ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Humair ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net
Re: [j-nsp] load balancing in Route reflector scenario
2011/8/10 Robert Raszuk rob...@raszuk.net Hi Keegan, I think the advertise inactive knob turns that off, but I don't know for sure because I've never tried it. I know it's not supported on cisco routers. The reason for it is the size of the BGP table. So if the table is 400k routes and you have 5 different ISP's and you advertise every route that would be 2M routes in the table. Since BGP doesn't allow multiple version of the same route in the routing table (separate from the BGP table where incoming routes are stored) you would still only use the original 400K the other 1.8M routes would just go unused unless you manipulated them some how. Advertise inactive is not about what get's advertised - it is about if the best path is advertised or not. And if is decided based on the check if the BGP path to be advertised is inserted in the RIB/FIB or not. Oh I see. I have never used that command so thanks. Most of the above example was what would happen if BGP advertised everything it learned instead of just the best path or the path in the routing table btw. By default Junos and IOS-XR advertise only those best path in BGP which actually are installed into forwarding. Advertising inactive knob will overwrite it. Wouldn't this lead to traffic being blackholed? If all the routes for a given destination are inactive would this still cause BGP to advertise a route for them? IOS classic/XE (for historical reasons) advertises all best paths from BGP table and to enforce it not to advertise what has not been installed into RIB/FIB there is knob called suppress inactive. Cheers, R. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] load balancing in Route reflector scenario
2011/8/10 Robert Raszuk rob...@raszuk.net Hi Keegan, By default Junos and IOS-XR advertise only those best path in BGP which actually are installed into forwarding. Advertising inactive knob will overwrite it. Wouldn't this lead to traffic being blackholed? If all the routes for a given destination are inactive would this still cause BGP to advertise a route for them? Nope ... there can be other producers of the same route (OSPF, ISIS, STATIC) which will be in the RIB. If not there is always next step - less specific route to be used. I suppose there's a use for this or the feature wouldn't exist, but why would you have a route in the IGP that's not in BGP but still needs to receive traffic from routers running an IGP and BGP but not learning the route from the IGP. Why not just import the route(s) into BGP. It just seems like this command may cause unexpected behavior to add features that can be configured in a more graceful manner. So there are some valid cases where you may want to attract by BGP all traffic, but switch it according by your own policy and not by BGP decision. Cheers, R. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] acceptable/good laser receive power in case of different interfaces
2011/8/7 Martin T m4rtn...@gmail.com Lane, while browsing the specifications of the optical modules listed in this Optical Interface Support—EX 3200 and EX 4200 Switches.pdf file: http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/optical-interface-support-ex-series.pdf ..all the modules have minimum and maximum launch power which differ from each other quite a lot. What does this mean? Shouldn't the launch power be consistent? Not at all. As I said each type of transceiver will have a different rating. So a 1310nm single mode sfp with a max distance of 10km will be much more powerful than an 850nm multimode sfp with a max distance of 500m. It takes more power to push light 10km than it takes to push it 500m. Also the multimode optics are led based and the single mode ones are laser, so they aren't even the same type of light. In addition, what is a Maximum Receiver Sensitivity? This one I'm not 100% sure about. It sounds like the lowest the rx can go before the switches considers the interface down, but that's just a guess. David, Keegan, thank you for explanation! In addition, there isn't some sort of connection between Rx power and Tx power, is there? I mean for example in case the received signal is low, the transmit signal of the SFP/XFP is increased automatically? As far as I know and as Lane confirmed, the Tx signal should be always consistent.. The devices don't communicate signal strength so the transmitting device has no way of knowing what the other device is receiving if anything at all. In general the path is either good or bad. The signal will vary from one second to the next but not because of any attempt at boosting the signal. 2011/8/3 Keegan Holley keegan.hol...@sungard.com: 2011/8/2 Joel Jaeggli joe...@bogus.com if these are sr multimode optics, the -15 number is low the -7 number is marginal and everything else is decent. either the -15 one is quite long ( for sr) or needs to be replugged/cleaned/reterminated Yea I agree. The -15 is a bit low unless it's is at the end of a really long, low-quality fiber run I'd clean it and or replace the XFP. It's blasting out at +1 and receiving much less, there could also be a mismatch of some sort. There are lots of ways to mismatch optics and cabling and still get link. On Aug 2, 2011, at 2:53 PM, chip wrote: Depending on whose optics you're using there should be a data sheet that shows the acceptable Tx/Rx levels for each type available from your vendor. I can't seem to locate a document for Juniper at the moment. But I assume they shouldn't be that far off from Cisco stuff. For example, here's a data sheet for the XENPAK module: http://www.cisco.com/en/US/prod/collateral/modules/ps2797/ps5138/product_data_sheet09186a008007cd00_ps5455_Products_Data_Sheet.html Check Table-2. As far as I know, an optic will output power within a specified range as according to what type it is, SR, LR, ER, ZR, etc... Hope that helps a bit. On Tue, Aug 2, 2011 at 5:26 PM, Martin T m4rtn...@gmail.com wrote: What is the acceptable Rx power in case of SFP/XFP? For example, here are XFP Tx and Rx signals from six FXP's: 1: Laser output power: 1.2920 mW / 1.11 dBm Laser rx power: 0.0285 mW / -15.45 dBm 2: Laser output power: 0.6420 mW / -1.92 dBm Laser rx power: 0.3054 mW / -5.15 dBm 3: Laser output power: 0.4230 mW / -3.74 dBm Laser rx power: 0.5092 mW / -2.93 dBm 4: Laser output power: 0.4180 mW / -3.79 dBm Laser rx power: 0.4208 mW / -3.76 dBm 5: Laser output power: 1.0920 mW / 0.38 dBm Laser rx power: 0.1801 mW / -7.44 dBm 6: Laser output power: 0.7680 mW / -1.15 dBm Laser rx power: 0.3337 mW / -4.77 dBm Is there some sort of pattern? It looks like if the Rx signal is lower, the Tx is higher? And what can one consider a decent Rx laser power level? regards, martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] acceptable/good laser receive power in case of different interfaces
2011/8/2 Martin T m4rtn...@gmail.com What is the acceptable Rx power in case of SFP/XFP? For example, here are XFP Tx and Rx signals from six FXP's: 1: Laser output power: 1.2920 mW / 1.11 dBm Laser rx power: 0.0285 mW / -15.45 dBm 2: Laser output power: 0.6420 mW / -1.92 dBm Laser rx power: 0.3054 mW / -5.15 dBm 3: Laser output power: 0.4230 mW / -3.74 dBm Laser rx power: 0.5092 mW / -2.93 dBm 4: Laser output power: 0.4180 mW / -3.79 dBm Laser rx power: 0.4208 mW / -3.76 dBm 5: Laser output power: 1.0920 mW / 0.38 dBm Laser rx power: 0.1801 mW / -7.44 dBm 6: Laser output power: 0.7680 mW / -1.15 dBm Laser rx power: 0.3337 mW / -4.77 dBm Is there some sort of pattern? It looks like if the Rx signal is lower, the Tx is higher? And what can one consider a decent Rx laser power level? I don't think anyone explained this explicitly but the output power is just that. The power of the output laser or led in the sfp local to the box, unhindered by cabling distances, attenuation or anything else. They should be high compared to the the receive number and relatively constant across like sfp's (usually). They will vary based on sfp type single-mode vs. multi-mode, and distance rating LR, ER, SR etc. There really isn't a perfect number for every application. For example if you take two sets of single-mode LX optics and plug one set into a 5km dark fiber run and the other into a 3m jumper your receive number will be higher on the shorter cable because less of the signal is lost to fiber distances. Vendors will publish what is acceptable for their equipment, but even then variation within those numbers could be a cause for concern. For example if you come across a link that was -2 or -3dbm one day and suddenly jumps to -6. -6 might be within the acceptable range for the vendor and sfp, but chances are the fiber is dirty and taking errors. Someone may have been walking around with your new jumper (true story) in their pocket unprotected and then installed it without cleaning or caring. Light levels are truly relative, however low light levels will usually be accompanied by other problems such as errors and/or upset customers. HTH, Keegan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] acceptable/good laser receive power in case of different interfaces
2011/8/2 Joel Jaeggli joe...@bogus.com if these are sr multimode optics, the -15 number is low the -7 number is marginal and everything else is decent. either the -15 one is quite long ( for sr) or needs to be replugged/cleaned/reterminated Yea I agree. The -15 is a bit low unless it's is at the end of a really long, low-quality fiber run I'd clean it and or replace the XFP. It's blasting out at +1 and receiving much less, there could also be a mismatch of some sort. There are lots of ways to mismatch optics and cabling and still get link. On Aug 2, 2011, at 2:53 PM, chip wrote: Depending on whose optics you're using there should be a data sheet that shows the acceptable Tx/Rx levels for each type available from your vendor. I can't seem to locate a document for Juniper at the moment. But I assume they shouldn't be that far off from Cisco stuff. For example, here's a data sheet for the XENPAK module: http://www.cisco.com/en/US/prod/collateral/modules/ps2797/ps5138/product_data_sheet09186a008007cd00_ps5455_Products_Data_Sheet.html Check Table-2. As far as I know, an optic will output power within a specified range as according to what type it is, SR, LR, ER, ZR, etc... Hope that helps a bit. On Tue, Aug 2, 2011 at 5:26 PM, Martin T m4rtn...@gmail.com wrote: What is the acceptable Rx power in case of SFP/XFP? For example, here are XFP Tx and Rx signals from six FXP's: 1: Laser output power: 1.2920 mW / 1.11 dBm Laser rx power: 0.0285 mW / -15.45 dBm 2: Laser output power: 0.6420 mW / -1.92 dBm Laser rx power: 0.3054 mW / -5.15 dBm 3: Laser output power: 0.4230 mW / -3.74 dBm Laser rx power: 0.5092 mW / -2.93 dBm 4: Laser output power: 0.4180 mW / -3.79 dBm Laser rx power: 0.4208 mW / -3.76 dBm 5: Laser output power: 1.0920 mW / 0.38 dBm Laser rx power: 0.1801 mW / -7.44 dBm 6: Laser output power: 0.7680 mW / -1.15 dBm Laser rx power: 0.3337 mW / -4.77 dBm Is there some sort of pattern? It looks like if the Rx signal is lower, the Tx is higher? And what can one consider a decent Rx laser power level? regards, martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] dot1q CCC/MPLS on EX4200 series switches
You can create a ccc based on port and just everything that comes in the port to the other end regardless of vlan or encapsulation. There is also no mac learning to worry about. This in my experience is easier to manage than q-in-q which requires mac learning and spanning-tree. The down side is that each port requires a dedicated LSP, so 48 ports would create 48 new LSP's between the two devices. I'm not sure what the LSP limitations are but I would assume it's pretty high. 2011/7/17 Matthew S. Crocker matt...@crocker.com Hello, I have a customer handing me a GigE with dot1q tags to my EX4200 switch. I need to carry the GigE/dot1q over a couple other EX4200s and terminate on a GigE port of my MX80. I've read through the docs for building MPLS/ccc circuits between the two devices. It isn't clear to me if I need to establish a ccc for each vlan (i.e. I will need to know the VLANs the customer is sending me). Or, can I create one CCC that will catch all tags and transport them across my MPLS and dump them out the MX80. I would prefer not having to know the VLANs my customer is sending me. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] External routes in OSPF database
2011/7/9 Alex D. listensamm...@gmx.de Thanks for the replies. Are you sure that it is all the BGP routes? I didn't examine all routes in detail, but the quantity brought me to that conclusion. Should be easy to confirm from where the externals are originating through its router-id. Your probably learning them from the customer The CPE router is also under my control and only advertise it's local networks. There's only redistribute connected under router ospf 1 configured. The externals originate from the PE-routers itself and i don't find a reason why they appear only when adjacency is up. The PE routers facing the customers or the PE routers facing your upstreams? You only show 14k external LSA's in the database which is much smaller than a full BGP feed. Are the above snippets from the PE router that is originating the external LSA's? Have you confirmed that the next hop on that PE router is actually learned from BGP and not from static or aggregate? Could there be inherited config from something else? If you wish *only* a default and type 1/2 lsas (and a type 3 for the default) you may consider setting as a totally stubby network (which should not be area 0) Hmm, is it possible to configure OSPF only with e.g. area 0.0.0.1 without having an area 0.0.0.0 ? I didn't try that before and thought that area 0.0.0.0 is always needed. You can have only an area 1 but it would be isolated from other areas and not ideal. It would be better to have your network and edge routers in area 0 and customers in different areas. The trade-off would be keeping your customer interfaces out of the backbone flooding domain vs. scaling and the number of areas you'd have to create. You could also use routing-instances but that would be equally as messy. As most others have said the best thing would be to require BGP or static routes. Regards, Alex __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] External routes in OSPF database
2011/7/9 Alex D. listensamm...@gmx.de
Hello,
we have a MPLS enabled backbone with about 30 routers. IS-IS is used as
IGP. All routers have iBGP sessions with our two route-reflectors and get
BGP full-feed from them.
Now i try to setup OSPF with area 0.0.0.0 for connecting customers to one
of our PE routers (running JUNOS 7.5R2.8).
You should upgrade as soon as possible if your hardware supports it.
Customer should get only a default route via OSPF.
Are you providing internet to your customers? If you you should use BGP or
static routes. OSPF neighbors tax resources. It's also not a good idea to
have all the customer routers and network routers in the same area.
Topology changes will propogate throughout the entire network which could
cause resource issues at scale.
Now i have the problem that all BGP routes appear as external routes in
OSPF database, but only when adjacency to the neighbor router, a Cisco 1841,
is up.
Are you sure that it is all the BGP routes? If you redistributed the whole
table into OSPF and then advertised it to all 30 routers the network would
probably melt down. (I'm about 85% sure of that) What is the next-hop/router
ID in the routes? Your probably learning them from the customer. Also if
the routers weren't coming from the customer they would probably still be
there when you shut down the ospf neighbor with them. This is another
problem with OSPF it's difficult to filter incoming routes from the
database. If you plan to use ospf with customers you should implement some
kind of database filter to protect your routers.
Without an adjacency, OSPF database looks like:
router# run show ospf database summary
Area 0.0.0.0:
2 Router LSAs
Externals:
3 Extern LSAs
Interface ge-0/1/0.22:
When adjacency is up, it looks like:
router# run show ospf database summary
Area 0.0.0.0:
2 Router LSAs
Externals:
14396 Extern LSAs -- after a while, there appear all BGP routes
Interface ge-0/1/0.22:
Now my questions:
- Is that the default behaviour of a Juniper router ?
- Why appear all BGP routes in OSPF database as external routes not before
adjacency is up ?
- How can i avoid appearence of these routes in OSPF database ?
- How do i achieve that *only* default-route is announced to customer ?
My corresponding OSPF specidic configuration looks as follows:
routing-options {
static {
route 0.0.0.0/0 discard;
}
router-id removed;
}
policy-options {
policy-statement RM_DEFAULT_ROUTE_TO_OSPF {
term default-route {
from {
protocol static;
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term explicit-deny {
then reject;
}
}
}
protocols {
ospf {
traceoptions {
file ospf size 50 files 5;
flag state;
}
export RM_DEFAULT_ROUTE_TO_OSPF;
area 0.0.0.0 {
interface ge-0/1/0.22 {
authentication {
simple-password removed;
}
}
interface all {
disable;
}
}
}
}
Thanks in advance for your help...
Regards,
Alex
__**_
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Firewalls as-a-service in an MPLS infrastructure...
I never said it's not possible, just that I've rarely seen it done correctly. Not everyone has your level of skill. Just for arguments sake how did you handle shared bandwidth? In other words how did you keep a DDOS attack on one customers's segment from using up all available bandwidth in some shared segment upstream from the firewall. 2011/7/8 Stefan Fouant sfou...@shortestpathfirst.net On 7/8/2011 12:28 AM, Keegan Holley wrote: Could be interesting. I've rarely seen firewall as a service done right though. It's hard to keep, cpu, memory usage, DDOS attacks, misconfiguration, etc. of one customers from affecting the other customers that share hardware. That being said there are better platforms to run the firewall instances on that are available now, checkpoint VSX comes to mind. Years ago when I had to develop a Network Based Firewall solution for a particular ISP in order to comply with the Federal Government's NetworX bid, we chose Juniper's NS-5400 for precisely this reason. In ScreenOS you have the concept of resource profiles with which you can limit the amount of CPU, Sessions, Policies, MIPs and DIPs (used for NAT), and other user defined objects such as address book entries, etc. that each VSYS can avail. These are essential elements of any multi-tenant firewall solution and evaluated platforms should likewise have similar offerings to contain resource usage for individual customers. Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.**net http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Firewalls as-a-service in an MPLS infrastructure...
Could be interesting. I've rarely seen firewall as a service done right though. It's hard to keep, cpu, memory usage, DDOS attacks, misconfiguration, etc. of one customers from affecting the other customers that share hardware. That being said there are better platforms to run the firewall instances on that are available now, checkpoint VSX comes to mind. 2011/7/6 Derick Winkworth dwinkwo...@att.net Thoughts on this blog entry? I wonder if Cisco will support BGP on ASA soon.. I know people have been asking for it. It would be nice if it had something Netconf on it too... The new ASA blade is coming out for Nexus I hear, anyone know how many virtual-firewalls it will support? Juniper's SRX will do LSYS soon.. 32 per box. That seems like a low number. Fortinet does thousands of thier VDOMs (virtual-firewalls) on a single unit... ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How does multihop eBGP work?
Can you elaborate? This isn't really much info to go on. multi-hop BGP is pretty simple though. In fact it's pretty much identical to the way most configure iBGP (sans mpls). You peer based on an address that is not directly connected to you. Once that is established you start receiving routes with a next hop of that not-so-directly-connected address that you are peered with. When you begin to send packets to that peer AS may need to traverse routers that do not have the BGP routes from the remote peer so you will need to use an IGP, static routes or PFM to tell the intermediate routers how to reach the prefixes advertised from the multi-hop peer. The cleanest way may be to use iBGP or simply redistribute the routes into your IGP if it is a small enough number. 2011/6/24 Mike Williams mike.willi...@comodo.com Hey guys, I've got a situation I think I need multihop bgp for (logical-systems and bridge-domains). However it bugs me deeply that I don't get multihop BGP. My biggest bugbear is if my multihop-ebgp peer tells me he know the best way to x.x.x.x, the packets I send towards him must be routed by intermediaries, will those intermediaries use their tables and hijack my packets down their bits of wet string through 15 other ASs and to the moon and back? Thanks -- Mike Williams ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] BGP MTU Mismatch
Does anyone know why a BGP session would constantly flap because of an MTU mismatch. I'm sure it's MTU since that is what fixed the problem. The peering is between a cisco and a juniper and both support PMTU discovery. I would assume any mismatches would be settled by the TCP MSS negotiation or fragmentation (admittedly bad). The peering flapped almost every three minutes on the mark so it never made it past the first dead timer interval. Just curious if someone out there had ever gotten to the bottom of this problem. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP MTU Mismatch
:) I found the MTU issue and fixed it because it was an obvious error. I don't see anything saying that BGP should care about MTU sizes though. I'm just curious to see if anyone else ran into this type of behavior and figured out the root cause. 2011/6/22 Abhi vyaaghrah-...@yahoo.com Hi Keegan how did u solve the problem of bgp flap in first place. Regards Abhijeet.C - Original Message - From: Keegan Holley keegan.hol...@sungard.com To: juniper-nsp juniper-nsp@puck.nether.net Cc: Sent: Wednesday, June 22, 2011 2:08 PM Subject: [j-nsp] BGP MTU Mismatch Does anyone know why a BGP session would constantly flap because of an MTU mismatch. I'm sure it's MTU since that is what fixed the problem. The peering is between a cisco and a juniper and both support PMTU discovery. I would assume any mismatches would be settled by the TCP MSS negotiation or fragmentation (admittedly bad). The peering flapped almost every three minutes on the mark so it never made it past the first dead timer interval. Just curious if someone out there had ever gotten to the bottom of this problem. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RE : MX80 MIC won't come online
2011/6/21 Chris Evans chrisccnpsp...@gmail.com Just making sure. A lot of folks rely on others in forums vs the vendor. We pay them for support and how will they know of problems when they aren't reported. Not only that but there would be alot more consulting income around if this forum didn't exist That being said did anyone ask if the OP had the proper licenses? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
And then there was vyatta... Sent from my iPhone On Jun 2, 2011, at 10:10 PM, Richard A Steenbergen r...@e-gerbil.net wrote: On Thu, Jun 02, 2011 at 09:59:15PM -0400, jnprb...@gmail.com wrote: Although expensive, you can buy the JCS1200 with 64-bit Junos to run as a standalone RR. It's probably more economical if you could also benefit from VPNv4 RRs for MPLS VPN deployments. Price aside, anyone who wants a 12U RE needs to have their head examined. :) How freaking hard can it be to take an off-the-shelf 1U PC, slap a Juniper logo on the front, mark it up 20x like everything else, and sell it to us as a fully supported RR? I'm still confused how this has managed to escape their attention. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
10.4R4 seems usable on MX960 with mixed DPC/MPC. There is a packet discard bug on MX80 though - it randomly mistakes non-first fragments as L2TP packets and as no L2TP service is configured, discards those packets. Would you happen to have the PR for this? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
2011/6/2 Richard A Steenbergen r...@e-gerbil.net On Thu, Jun 02, 2011 at 09:59:15PM -0400, jnprb...@gmail.com wrote: Although expensive, you can buy the JCS1200 with 64-bit Junos to run as a standalone RR. It's probably more economical if you could also benefit from VPNv4 RRs for MPLS VPN deployments. Price aside, anyone who wants a 12U RE needs to have their head examined. :) How freaking hard can it be to take an off-the-shelf 1U PC, slap a Juniper logo on the front, mark it up 20x like everything else, and sell it to us as a fully supported RR? I'm still confused how this has managed to escape their attention. And then there was Vyatta ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] mpls question
The EX doesn't support L3VPN/VRF. You'd have to use an MX80 at the least. You could do pseudowires per customer though. On Thu, May 12, 2011 at 7:31 AM, Johan Borch johan.bo...@gmail.com wrote: Hi, I have a question regarding MPLS on ex-series. I have a situation where i need to connect several data centers together. I have never worked with MPLS before but my idea is to use MPLS to transport VLANs between the data centers. An example: a customer is located in it's own VRF and we use VLAN/RVI for servers and client networks, now I wan't to connect my core in DC1 to my core in DC2, is MPLS the right way to go? The data centers will be connected with multiple connections. I read somewhere that I can't use family ccc if the vlan has an RVI, is that correct? Regards Johan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] mpls question
The EX doesn't support vpls either. The implementation described in the pdf also uses an MX for the mpls vpn portion. On Thu, May 12, 2011 at 9:34 AM, Cristiano Monteiro crmont...@gmail.comwrote: Hi, Maybe this link helps you http://www.juniper.net/us/en/local/pdf/implementation-guides/8010050-en.pdf Best Regards, Cristiano Monteiro 2011/5/12 Johan Borch johan.bo...@gmail.com Hi, I have a question regarding MPLS on ex-series. I have a situation where i need to connect several data centers together. I have never worked with MPLS before but my idea is to use MPLS to transport VLANs between the data centers. An example: a customer is located in it's own VRF and we use VLAN/RVI for servers and client networks, now I wan't to connect my core in DC1 to my core in DC2, is MPLS the right way to go? The data centers will be connected with multiple connections. I read somewhere that I can't use family ccc if the vlan has an RVI, is that correct? Regards Johan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] (no subject)
the first one is going to a IP next hop and packets require an IP look up. Either it's not using mpls or is only using the inner (vpn) label for that hop. The second is taking a real-live lsp and does not perform an IP lookup, so no IP next hop is needed, just an LSP and a label to push. On Fri, Apr 29, 2011 at 8:18 AM, Chuck Anderson c...@wpi.edu wrote: On Fri, Apr 29, 2011 at 01:12:22PM +0100, ibariouen khalid wrote: show route : 10.41.2.32/30 *[OSPF/10] 18:49:01, metric 4 *to 10.41.144.6* via ge-1/1/0.0 via so-1/3/1.0 show route table GG_jk 10.160.31.10/32*[BGP/170] 6d 01:17:54, localpref 100, from 10.41.0.1 AS path: I via so-1/3/1.0, label-switched-path fes22cr2-to-cascr1 Question : would someone tell me why i have in the first one to X.X.X.X and not for other routes ?? The second table looks like a l3vpn routing-instance with MPLS LSPs for next-hops. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RES: Trying to get OSPF to work across IPsec for Redundancy
I don't think OSPF carries multicast. I know cisco routers have a neighbor statement that will force it to unicast hello's I've never tried it on a juniper. I think if you do GRE over IPSEC (not to be confused with IPSEC over GRE) the multicast will work as well. It depends on your endpoints though, I don't think firewalls will do GRE. On Thu, Apr 28, 2011 at 3:59 PM, Leonardo Gama Souza leonardo.so...@nec.com.br wrote: Hello All: I'm trying to get OSPF up over IPsec. We have two IPsec tunnels, a primary and a secondary that our spoke router can use. We want to have the spoke router run OSPF across both and then in case of a failure of the primary hub router (where the primary IPsec tunnel terminates) OSPF will direct traffic over the backup tunnel to the backup hub. So far I have seen OSPF on the spoke router come up just a couple of times but only to one or the other peer. It never has come up to both peers. Here are my configurations for OSPF and the services interfaces below. Also BGP is up on all routers and all routers are reachable via BGP. If anyeone can guide me in the right direction to get OSPF working over IPsec that would be most apprectiated! As far as I know IPSec solely is not able to carry Multicast traffic. Are you using GRE over IPSec? If not, you may want to try unicast hellos. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RES: Trying to get OSPF to work across IPsec for Redundancy
sorry I meant IPSEC doesn't carry multicast. OSPF technically doesn't carry anything. On Thu, Apr 28, 2011 at 11:28 PM, Keegan Holley keegan.hol...@sungard.comwrote: I don't think OSPF carries multicast. I know cisco routers have a neighbor statement that will force it to unicast hello's I've never tried it on a juniper. I think if you do GRE over IPSEC (not to be confused with IPSEC over GRE) the multicast will work as well. It depends on your endpoints though, I don't think firewalls will do GRE. On Thu, Apr 28, 2011 at 3:59 PM, Leonardo Gama Souza leonardo.so...@nec.com.br wrote: Hello All: I'm trying to get OSPF up over IPsec. We have two IPsec tunnels, a primary and a secondary that our spoke router can use. We want to have the spoke router run OSPF across both and then in case of a failure of the primary hub router (where the primary IPsec tunnel terminates) OSPF will direct traffic over the backup tunnel to the backup hub. So far I have seen OSPF on the spoke router come up just a couple of times but only to one or the other peer. It never has come up to both peers. Here are my configurations for OSPF and the services interfaces below. Also BGP is up on all routers and all routers are reachable via BGP. If anyeone can guide me in the right direction to get OSPF working over IPsec that would be most apprectiated! As far as I know IPSec solely is not able to carry Multicast traffic. Are you using GRE over IPSec? If not, you may want to try unicast hellos. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper firewall policer inner workings
What does your policer config look like? I've seen some links have problems with large packet sizes if the burst was set too low. Also, I think the iperf packet loss calculation also counts some kind of internal buffering loss. I'm couldn't find it on google but I remember reading something a few years ago on another group. Try increasing your you're buffer space on iperf both server server and client side. Also, make sure you have 1M or more of burst since you are sending 1470B packets. On Mon, Apr 4, 2011 at 5:41 AM, Martin T m4rtn...@gmail.com wrote: I made a following setup: http://img690.imageshack.us/img690/3162/iperftest.png In a laptop, an Iperf server is listening like this: iperf -s -u -fm. In a workstation, an Iperf client is executed like this: iperf -c 192.168.2.1 -u -fm -t60 -d -b 10m. This will execute simultaneous 10Mbps UDP traffic flood between 192.168.1.1 and 192.168.2.1 for 1 minute. Results are always like this: [root@ ~]# iperf -c 192.168.2.1 -u -fm -t60 -d -b 10m Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 0.04 MByte (default) Client connecting to 192.168.2.1, UDP port 5001 Sending 1470 byte datagrams UDP buffer size: 0.01 MByte (default) [ 4] local 192.168.1.1 port 32284 connected with 192.168.2.1 port 5001 [ 3] local 192.168.1.1 port 5001 connected with 192.168.2.1 port 52428 [ ID] Interval Transfer Bandwidth [ 4] 0.0-60.0 sec 71.5 MBytes 10.0 Mbits/sec [ 4] Sent 51021 datagrams [ 4] Server Report: [ 4] 0.0-59.9 sec 69.8 MBytes 9.77 Mbits/sec 0.112 ms 1259/51020 (2.5%) [ 4] 0.0-59.9 sec 1 datagrams received out-of-order [ 3] 0.0-60.0 sec 69.8 MBytes 9.77 Mbits/sec 0.030 ms 1200/51021 (2.4%) [ 3] 0.0-60.0 sec 1 datagrams received out-of-order [root@ ~]# As you can see, there is a ~2.5% packet loss. This packet loss is due to the fact, that router bw-10Mbps policer drops small percentage of packages in input direction(I can check the amount of dropped packets with show policer command). For example if I increase the policer bandwidth-limit to 11m, there will be no packet loss. In both machines(192.168.1.1 and 192.168.2.1) Iperf sends packets with 1470 byte payload. In addition, there is a 8 byte UDP header and 20 byte IPv4 header. So according to tcpdump the whole IPv4 packet is 1498 bytes: [root@ ~]# tcpdump -i fxp0 -c 4 -v tcpdump: listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes 11:49:18.961405 IP (tos 0x0, ttl 63, id 44836, offset 0, flags [DF], proto UDP (17), length 1498) 192.168.2.1.52428 192.168.1.1.commplex-link: UDP, length 1470 11:49:18.961459 IP (tos 0x0, ttl 64, id 37052, offset 0, flags [none], proto UDP (17), length 1498) 192.168.1.1.32284 192.168.2.1.commplex-link: UDP, length 1470 11:49:18.961473 IP (tos 0x0, ttl 64, id 37053, offset 0, flags [none], proto UDP (17), length 1498) 192.168.1.1.32284 192.168.2.1.commplex-link: UDP, length 1470 11:49:18.961485 IP (tos 0x0, ttl 64, id 37054, offset 0, flags [none], proto UDP (17), length 1498) 192.168.1.1.32284 192.168.2.1.commplex-link: UDP, length 1470 4 packets captured 284 packets received by filter 0 packets dropped by kernel [root@ ~]# Whole frame size is 1512 bytes. Does JUNOS include UDP(or L3 header in general) header to this bandwidth-limit 10m? If it does, shouldn't there be 0.5% packet loss instead of 2.5%? Or if bandwidth-limit 10m includes IPv4 header as well, the packet loss for Iperf should be 1498 - 100% 28 - x% ..1.9% not ~2.5%. Are my calculations wrong or how does JUNOS policer bandwidth-limit calculate this 10m bits? regards, martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480 - BGP Session Not Coming Up
We migrated a trunk connection from Cisco 7206 to MX480. All the BGP session was up for a while goes down. The following is the error message in MX480 (10.2R2.11): rpd[1358]: task_connect: task BGP_remoteAS.a.b.c.d.14+179 addr a.b.c.d+179: Operation not permitted rpd[1358]: bgp_connect_start: connect a.b.c.d (External remote AS): Operation not permitted What messages do you get from the cisco box? The operation not permitted message seems out of place if no changes were made. Does the peering come right back up after the error happens? Any interface flaps in the logs? Can you telnet to port 179 from both routers? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco ACL converter
Have you thought about doing it manually? Neither type of filter (assuming you're not talking about route-maps or QOS policies) is that complex. It would probably take you longer to find a tool and use it than it would to look up route-filters on the juniper website. On Thu, Mar 31, 2011 at 4:50 AM, Nick Ryce nick.r...@lumison.net wrote: Hi, This has probably been covered before but my google foo is letting me down. Is there a tool ( apart for the ios2junos translator ) that converts cisco ACLs to juniper? The ios2junos translator has no concept of object groups and is unable to convert an acl line that has more than one port specified. I have a about 150 customer ACLS each with about 40 lines of code which I really don't want to do manually. Thanks. -- Nick Ryce Network Engineer Lumison t: 0845 1199 900 d: +44 131 514 4049 P.S. Fancy some light reading? Clouds to networks, download a Lumison whitepaper now at http://www.lumison.net/why-lumison/whitepapers -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco ACL converter
Have you thought about doing it manually? Neither type of filter (assuming you're not talking about route-maps or QOS policies) is that complex. It would probably take you longer to find a tool and use it than it would to look up route-filters on the juniper website. +1 | A script could do this in no time... Agree, but it depends on how good you are at scripting. :) I still think I'd spend more time Q/A'ing the script or at least it's output than just doing it the low-tech way. I'd probably try to use sed or one of those text editors that support regex though. That way I could Q/A as I go. Good point nonetheless. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] about 10.4R3 on EX
On Tue, Mar 22, 2011 at 4:15 PM, TiM t...@muppetz.com wrote: On Wed, March 23, 2011 8:54 am, Kaj Niemi wrote: Hi, sarcasm To whomever who decided to introduce new features in a R3 release, thanks ;-( Specifically installing jloader separately is highly appreciated. /sarcasm You'll probably be thanking them when your switch loses power* and when you restore it, you find your bootable filesystem isn't corrupted. At least I'm _hoping_ that's what this 4th partition is designed to fix. Context: http://www.gossamer-threads.com/lists/nsp/juniper/25513 Just to be fair.. The original point was to highlight the fact that they add features in the maintenance releases which is still bad software engineering. These are supposed to be dot releases so that people know when there is a potential for new bugs. So instead of 10.4R3 there should be something like 10.4.0R3 with normal partitioning and 10.4.1R3 with the new features. What if you're only upgrading to fix a PR only to find out that ISSU is impossible and reboots will take longer? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tower top switch/router recommendation..
So, I'm looking for some form of stacking router/switch solution that could handle BGP/OSPF/~75 MIR and CIR rules per interface with enforcement by customer subnet (they are all on the same interface and vlan)/and tcpdump for easy debug of customer connectivity problems.. Possible with Juniper? Is so, what device, and what QOS rules? The EX4200 is the obvious choice. It supports BGP/OSPF and advanced QOS features. Other candidates would be the MX and EX8200's. There are also other vendors that make equipment suitable for such an environment. Overall it depends on the size of your routing table, what feature you need (MPLS, security, etc) and what kind of queueing you want to do (ingress, egress, both, number of schedules, number of policers). Peter Kranz Founder/CEO - Unwired Ltd www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207- pkr...@unwiredltd.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
