[j-nsp] Questions about EX4550 switches
Good day everyone. Just recently subscribed so I'm sorry if I break any rule here. But I'd like to post some questions about EX4550 we recently got. Our network mostly run cisco but with a couple of old Juniper M5 and I have experience but I am not really familiar with Juniper. So I'm running to this list hoping guys here can clarify some things. 1. Configuring firewall gives me "Warning: statement ignored: unsupported platform (ex4550-32f)" when including "except". I'm trying to filter ALL traffic except from some IP but except is not working. 2. All the box have 13.2X51-D35.3 (Junos 13.2??) but juniper site says 12.3R12 is suggested as of the moment. JunOS 15 and 16 is available for the box (I think) but I am not sure what to follow. 3. Not really technical but if someone can help. I just signed up for an account on their site so I can download checkout the firmware(s) but I haven't got a response from them. Thank you! -- Rod ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QoS when there is no congestion
I think this is where I was misunderstood. Firstly, "proper" user *shouldn't* (see points about policers) hurt, but "proper" requires research into your whole network. The point I was making was based on the OP's initial statement that there is no congestion in the network, QoS will not help anything, because as long as the packet is not being buffered (queued), it won't have a chance to be reordered by QoS, but rather will go straight to the tx ring. Again, I can't state this enough: the OP explicitly stated lack of congestion *anywhere in the network*. The rest are assumptions made that OP simply doesn't realize that there is congestion on the network. So put it simply, if there is no congestion *anywhere* QoS is a lot of effort with very little to no payback and new risks coming from potential for improper configuration and additional complexity. If there is congestion, then by all means, make the business case that additional complexity and configuration management costs are lower than simply increasing the size of the pipe where congestion is. Hence YMMV note. At the end it all comes down to $$$. If you can demonstrate that tinkering with QoS is cheaper than not, I agree, go with QoS. --Andrey On Tue, Nov 15, 2016 at 2:44 AM, wrote: > > Of Andrey Khomyakov > > Sent: Monday, November 14, 2016 4:56 PM > > > > OP explicitly stated that there is not congestion. I think we can all > agree that > > QoS only works if there is congestion on the egress line. In cases where > > egress rate is lower than line rate, QoS will simply hurt more than help > since > > you'll be potentially limiting any given class with police or shape (I > know this is > > juniper list, but I don't know junos equivalents) statements to below > the line > > rate. > > > Hey buddy, > First of all I suggest you get some reading on QOS to get the basics > right, how on earth can proper use of policing and shaping hurt? > > My experience is that OP is probably unaware of all the congestion points > (including congestion points within devices themselves) because 99% of > folks I talk to are not, unfortunately. > No, I don't agree that QOS works only if there is congestion on an egress > line, see above. > > > adam > > > netconsultings.com > ::carrier-class solutions for the telecommunications industry:: > > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX: Proxy ARP and ARP cache
Hey! I am in the process of migrating from one setup to another and I need the MX to proxy some ARP requests in the process. I can't use "proxy-arp unrestricted" as it would attract far too much traffic, so I am trying to stick with "proxy-arp restricted". The documentation says: The router or switch responds to ARP requests in which the physical networks of the source and target are different and does not respond if the source and target IP addresses are in the same subnet. The router or switch must also have a route to the target IP address. This totally matches my case. However, I have noticed that when there is an entry for the target IP in the ARP cache, there is no answer. This is quite inconvenient for me. For example, assume that the MX is 192.0.2.1/24 and we have two hosts, 192.0.2.14 and 192.0.2.15, which are connected to some interface to the MX. Therefore, the MX has the following entries in its cache: 06:ea:3c:00:00:62 192.0.2.14ae0.90 none 06:ea:3c:00:00:63 192.0.2.15ae0.90 none Then, 192.0.2.14 moves to another equipment and the MX receives a route to let it know how to contact it: 192.0.2.14/32 *[BGP/170] 00:11:52, localpref 100 AS path: 65002 65004 I > to 198.51.0.14 via ae1.180 The ARP cache entry is left intact. The MX has no problem to ping 192.0.2.14 from now on. It uses the route, not the ARP cache entry. However, on ae0.90, the MX is also configured with "proxy-arp unrestricted". The idea is that 192.0.2.15 should be able to contact 192.0.2.14. The MX should fake an ARP answer and route the traffic. However, as long as the 192.0.2.14 entry stays in the ARP cache, the MX won't answer the ARP request. Once the entry is expired, this works as expected. The JTAC has been unhelpful on this case as they consider that something that never worked is out of their scope. Any tip on how to make this kind of setup works would be helpful. Thanks! -- One of the most striking differences between a cat and a lie is that a cat has only nine lives. -- Mark Twain, "Pudd'nhead Wilson's Calendar" ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QoS when there is no congestion
> Of Andrey Khomyakov > Sent: Monday, November 14, 2016 4:56 PM > > OP explicitly stated that there is not congestion. I think we can all agree > that > QoS only works if there is congestion on the egress line. In cases where > egress rate is lower than line rate, QoS will simply hurt more than help since > you'll be potentially limiting any given class with police or shape (I know > this is > juniper list, but I don't know junos equivalents) statements to below the line > rate. > Hey buddy, First of all I suggest you get some reading on QOS to get the basics right, how on earth can proper use of policing and shaping hurt? My experience is that OP is probably unaware of all the congestion points (including congestion points within devices themselves) because 99% of folks I talk to are not, unfortunately. No, I don't agree that QOS works only if there is congestion on an egress line, see above. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
