So after doing a lab test between a Ex and QFX using a traffic genarator we noted that traffic flow went over one member interface and returned over the other.

We did the same test but the result looks defrent on the MX routers. Seems like the traffic transmit and recieve over the same link. This is now with default AE configuration on both scenarios. So my question then is do the MX by default do symetric laodbalcing where as the switches needs to be configured. It would be nice if this is actaully documented or perhaps it is just a coincidence that the traffic flow seemed this way perhaps not enough sessions generated etc. Do anyone know the facts or done something similar as it quite import for a soltuion i am working on.

Hi,

On MX, can you try configuring load-balancing per-packet configuration? It says per-packet, but it really is per-flow load-balancing in implementation.

[edit routing-options forwarding-table]

export load-balancing-policy;

[edit policy-options]

policy-statement

load-balancing-policy

{   

   then

{        load-balance per-packet;    }}

To answer some of the questions you had posed - 

 - Load-balancing across AE member links is performed based on a hashing funtion. Hash computation is performed in hardware on ingress PFE's lookup chip with a combination of several functions. The output of this operation is generation of several

You can also try per-family load-balancing. For example, if you plan to configure load balancing for IPv4 transit traffic, you may configure lb using keys dervied from L3 and L4 headers.

For verification, you may use the following operational mode command - 

request pfe execute target fpc<FPC NUMBER FOR INGRESS PORT> command "show jnh lb"

[...]            IIF-V4: Yes          SPORT-V4: Yes          DPORT-V4: Yes               TOS: No       GTP-TEID-V4: No           

                  IIF-V6: Yes          SPORT-V6: Yes          DPORT-V6: Yes     TRAFFIC_CLASS: No       GTP-TEID-V6: No         

                 IIF-MPLS: Yes      MPLS_PAYLOAD: Yes          ETHER_PW: Yes          MPLS_EXP: No        CW_PRESENT: No[...]

Some options for family inet load-balancing - 

{master}[edit]jnpr@R1-RE0# set forwarding-options enhanced-hash-key family inet ?

Possible completions:

+ apply-groups         Groups from which to inherit configuration data

+ apply-groups-except  Don't inherit configuration data from these groups 

gtp-tunnel-endpoint-identifier  Include TEID in the hash key for GTP-U packets 

incoming-interface-index  Include incoming interface index in the hash key 

no-destination-port  Omit IP destination port in the hash key 

no-source-port       Omit IP source port in the hash key 

type-of-service     Include TOS byte in the hash key

As @pranavs stated, what occurs in Juniper products, and most all other products is based on flows, not packets.  Plus, no one really does load-balancing, it is really load-sharing.  Based upon randomness of MAC/IP address/UDP or TCP port numbers, the idea is to get a close to equal load-balancing as possible.  Load-balancing can only occur with per-packet algorthims, but per packet are generally not used as out-of-sequence could occur.  This is why almost everyone uses flow-based algorthims, not packet based.

So if in your test you only use 1 flow (same MAC/IP SA and DA, etc.) then no load-sharing should occur.  For real test results you should use 100s or better yet 1000s of different flows.  Depending upon Juniper product, there maybe options for different hash algorthims to determine how flows are distrubted across an AE/LAG.  For any one product, the determination should be the same, if configured the same.  What does this all lead to?  For MX to MX one should expect (with same config) any specific flow to be always associated with the same link within the AE/LAG bundle always.  For connection between 2 different products, in your case EX/QFX [not sure which exact models] there is the potential for different algorthims to be in use, and therefore by default one might send on link A, while the other sends the same reverse flow, down link B.

This could well explain the behavior you saw as very normal.  The reason for more advanced and configurable hash algorthims for how AE/LAG links are associated with any flow, is due to fact that even with randomness of flows, all flows could actually choose the same link, and therefore no other links within the AE/LAG would be used.

Hopefully this may help you, and/or others.

Did you try to 1) delete the whole config but the root password 2) apply your own preprovisioned VC configuration with this single switch defined as member ID 0  and routing-engine role (you will have to use P6893-C if this is true for that switch, as its serial-number, as the shorter SN that is printed on its label will not work) 3) commit and reboot 4) give it some minutes after reboot.

Once it has this applied you could further try to use 'request virtual-chassis reactivate' to make this one become master and active.

Thansk for your replies really appriciate. However i think i didnt post my question in the right context. I understand the loadbalacing mechanism per AE from a single device point of view. My question was more around the return traffic. As i said on the switch i could see by default sometimes the north direction of the flow will go via member interface 1 and the return traffic for that same flow will be via member interface 2. Sometimes it chooses the excact same physcial member for both directions of the flow.

On the MX on the other hand we did these same test, both directions of the flow kept on the same physical member, after the several test resets we can see the flow even moved to the secondary member and also the retun traffic moved to the second member. So during these test we could observe asymetric traffic whereas with the MX it kept on being symetrical. This is actaully what i need to know. I will be putting a transparent device on the links and need to know what go out on member must return on the same member interface.

Hope this sense regarding the symatric

See attached what i am trying to achieve. I will be deploying a cache solution, but instead of using the more complex and cumbersome PBR with firewall filter etc. i want do add the devices in the network without making any major changes on the routing, making it simple and still scalabe. So i was thinking to deploy the units in transparent mode on each physcal member. Therefore making use of the build in load balancing mechanism of EA (no need for dedicated LB) and also make use of the build in redudndacny of AE.

In this deployment LACP can not be used because the links arent directly connected between the switches so lL3 microBFD on the AE can be enabled between the routers and interfaces. So should a cache unit stop operating the BDF will take the coresponding members down from the bundle. Should the entire AE0 go down the bypass link will be used by means of IGP.

So with the above all should work fine, unless there are asymetric traffic on the AE links it wont, as northbound traffic can go via one cache and return via another. Let me know what you think.

@Spuluka

NO, intravlan traffic which is locally switched in my opinion does not really affect the Performance numbers given in IMIX or large packets, or....

So it needs NOT to be included in the performance evaluation as long as you are not overflowing the etherswitch capacity or an output port

regards

alexander

Hi,

We have Cisco 6506 switch at H.O. and Juniper Ex switches (4300, 4200) at branch location. We are planning to connect both office with 2 point to point link. If one link goes down second link will transfer all the traffic(vlan)

please suggest how can we do that(i.e. LACP, any kind of routing(dynamic) or if any)

Thank you..

Hello,

Easiest way would be to use either

1/ Flex Link on CSCO side https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3550/software/release/12-2_25_see/configuration/guide/swflink.html

or

2/ Redundant Trunk Group (RTG) on Juniper side

https://www.juniper.net/documentation/en_US/junos/topics/example/cfm-ex-series-redundant-trunk-groups.html

https://www.juniper.net/documentation/en_US/junos/topics/example/cfm-ex-series-redundant-trunk-groups-els.html

But not both at the same time.

HTH

Thx
Alex

Fo SRX1400 ISSU cluster upgrade I am getting below error:

Any suggestion to resolve the issue?

root@SDBRONRS04W> ...unos-srx1k3k-12.3X48-D50.6-domestic.tgz
Checking compatibility with configuration
Initializing...
cp: /etc/iri_ipsec_key.db: No such file or directory
Using /var/tmp/junos-srx1k3k-12.3X48-D50.6-domestic.tgz
chroot: /bin/sh: No such file or directory
ERROR: validate-config: junos/+REQUIRE fails
WARNING: Current configuration not compatible with /var/tmp/junos-srx1k3k-12.3X48-D50.6-domestic.tgz

I am upgrading the code from 12.1X46-D40.2 to  12.3X48

Intra vlan is the traffic between the same vlan/subnet. This should be linerate speed because I have created switch/L2 ports and for this scenario the SRX acts as a regular switch (it doesn’t apply any security checks to this traffic as a regular switch will do).

Inter vlan traffic is the traffic from one vlan/subnet to another one. This traffic has to be routed by the SRX between its different L3 interfaces (ge-6/0/1, ge-6/0/0, vlan.10, vlan.20, vlan .30 and vlan.40) and security checks have to be performed for this traffic (security-zones/security-policies/NAT, etc) like a regular firewall will do.

I am running a regular online speed test with Verizon and it seems like Juniler 2-3 ms behind. I am also noticing slower browsing speed or it could just be me or unluck  with the test.

Regarding some of the comments posted:

------------------------------------------------------------------------------------------------------------

“The difference will be with intra vlan traffic between hosts in the same subnet that is currently passing on your switch.  Most switches these days are line rate or pretty close to it so lots of host to host traffic is no problem.  But a firewall runs a packet inspect process on everthing so the capacity is a lot lower than line rate.  You will need to see if the specs on the srx650 will work for your intra vlan traffic.”

The above statement is false, the SRX is acting as a regular switch for the intra-vlan traffic and is not performing any security checks on that traffic. Actually this other comment is more accurate:

As long as you keep all access ports in the SRX650 XPIM module, you should have linerate switching performance within the same vlan.

And can be complemented with tis other one:

without having exact performance data the switch-part in my experience is a normal ethernet switch, with adequate wirespeed throughput, and does not at all affect the L3-firewall performance

------------------------------------------------------------------------------------------------------------

I am not aware of the following limitation and it shouldn’t be a problem for our implementation because we have all L2 interfaces in the same module:

Switching from the XPIM module to another module or the onboard ports are not supported. These can only be routed.

Minus there will be lower switching capacity and less switching features as other have mentioned.  If you don't need these then it is not an issue at all.

In my case, I am not using any special switching features.

Any further advice is greatly appreciated...

Hello readers,
When rsvp and mpls are added to port configuration rpd process allocate much more memory then expexted and in time it would use all remaining memory and freeze the box. 

Without rsvp and mpls: 
xyz@fmPCi-bb-jsw01> show system processes extensive 
last pid: 61749; load averages: 0.34, 0.31, 0.26 up 253+20:20:30 09:58:34 
130 processes: 4 running, 104 sleeping, 1 zombie, 21 waiting 

Mem: 513M Active, 62M Inact, 103M Wired, 226M Cache, 109M Buf, 73M Free 
Swap: 


PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 
10 root 1 155 52 0K 16K RUN 4292.3 66.26% idle 
1196 root 1 48 0 95464K 14672K RUN 419.5H 6.01% chassism 
61744 remote 1 40 0 47264K 37012K select 0:01 5.62% cli 
61727 root 1 8 0 12036K 6292K nanslp 0:05 4.79% cscript 
1199 root 1 8 0 87392K 28016K nanslp 339.9H 2.29% pfem 
61741 root 1 40 0 8928K 3780K select 0:00 1.62% sshd 
61728 root 1 43 0 39108K 21348K select 0:02 0.93% mgd 
1261 root 1 42 0 29724K 22296K select 75.7H 0.93% snmpd 
1262 root 1 40 0 36476K 18512K select 89.7H 0.63% mib2d 
1197 root 2 -52 -52 73144K 18100K select 135.5H 0.10% sfid 
895 root 1 40 0 16320K 9408K select 533:07 0.05% eventd 
1269 root 1 40 0 19784K 11968K select 57.1H 0.00% ppmd 
11 root 1 -36 -139 0K 16K RUN 34.8H 0.00% swi7: clock 
1265 root 1 40 0 56504K 24528K select 33.1H 0.00% pfed 
23 root 1 -68 -171 0K 16K WAIT 27.2H 0.00% irq43: i2c0 i2c1 
1263 root 1 4 0 93440K 34228K kqread 22.8H 0.00% rpd —> allocation OK. 

With rsvp and mpls: 
xyz@fmPCi-bb-jsw01> show system processes extensive 
last pid: 61865; load averages: 0.35, 0.35, 0.29 up 253+20:25:02 10:03:06 
129 processes: 4 running, 104 sleeping, 21 waiting 

Mem: 531M Active, 64M Inact, 104M Wired, 226M Cache, 109M Buf, 53M Free 
Swap: 


PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 
10 root 1 155 52 0K 16K RUN 4292.4 67.04% idle 
1196 root 1 48 0 95464K 14684K RUN 419.5H 5.91% chassism 
61824 root 1 8 0 11968K 6224K nanslp 0:04 3.43% cscript 
1199 root 1 8 0 87392K 28032K nanslp 339.9H 1.86% pfem 
1263 root 1 4 0 115M 55100K kqread 22.8H 0.93% rpd —> much more allocated memory 


Commands used: 
rsvp { 
interface xe-0/1/0.0; 
} 
mpls { 
interface xe-0/1/0.0; 
} 

We are running two EX4200 together on Junos  15.1R6-S4 as we tried to upgrade from 15.1R6.7 where we had same issue.

Any idea what is going on? Problem with RAM allocation would lead to box freeze and physical restart is needed.

Hello,

I see You haven't actually read the links I supplied. No probs, it happens all the time 

CSCO says

Flex Links are a pair of a Layer 2 interfaces (switch ports or port channels) 

Same for Juniper. The documentation does not spell in clearly but this wording is important

If the active link either goes down or is disabled administratively, it broadcasts a list of 
its known MAC addresses for data traffic; the other link immediately picks up and adds the 
MAC addresses to its address table, becomes active, and begins forwarding traffic.

So You can deduce that the primary link needs to learn MACs for the JNPR RTG to function. And to learn MACs, the link needs to be enabled with "family ethernet-switching". I also verified it in the lab by enabling RTG for et-0/0/15 and et-0/0/16, I also removed "family ethernet-switching" from et-0/0/15|16 and added "family inet" as below:

[edit interfaces et-0/0/15 unit 0]
+      family inet {
+          address 203.0.113.129/30;
+      }
-      family ethernet-switching {
-          vlan {
-              members default;
-          }
-          storm-control default;
-      }
[edit interfaces et-0/0/16 unit 0]
+      family inet {
+          address 203.0.113.133/30;
+      }
-      family ethernet-switching {
-          vlan {
-              members default;
-          }
-          storm-control default;
-      }
[edit protocols rstp]
+   disable;
[edit]
+  switch-options {
+      redundant-trunk-group {
+          group rtg0 {
+              preempt-cutover-timer 60;
+              interface et-0/0/15.0 {
+                  primary;
+              }
+              interface et-0/0/16.0;   
+          }
+      }
+  }

The result is

{master:0}[edit]
ccl@qfx5200# commit ch
01 Feb 2018 10:25:02 UTCeck 
[edit switch-options redundant-trunk-group group rtg0]
  'interface et-0/0/15.0'
    L2ALD rtg : Interface et-0/0/15.0 is not enabled for Ethernet Switching
error: configuration check-out failed

So the conclusion is that You cannot use JNPR RTG as both L2 and L3, only as L2 with "family ethernet-switching". But this does not prevent You from configuring a stub vlan with SVI (IRB or vlan.XYZ L3 interface) and having a L3 connectivity across said link on that stub VLAN.

HTH

Thx
Alex

I didn't believe that security flow would not apply on SRX ports in ethernet mode so I ran that same test in my own lab and was surprised to see you cannot apply security policies to switched traffic and there is no flow processing for local switching.

I'm suprised because the documentation sure implies to me that we can secure mixed layer 2 and 3 traffic on the SRX but that is not the case.  Only the layer 3 traffic hits the flow processor in mixed mode.

So clearly there won't be as large a hit to move switching to the SRX as I thought.  But I still stand by that the SRX will not have the same full line rate availabe on a modern switch.  We would need a full line rate test to verify what the capacity actually is.

I was running into this same (or very similar) problem with an ex3300 runing Junos 15.1R6-S2.1. It is a l2 switch with a management vlan (the only interface with family inet is vlan.100). vlan.100 is configured with address 10.0.100.10/28, and I wanted that to change to /24.

Example showing the interfaces and the vlans stanzas in my lab switch

interfaces {
    vlan {
        unit 100 {
            description "management vlan";
            family inet {
                address 10.0.100.10/28;
            }
        }
    }
}
vlans {
    vlan-mgmt {
        description "management vlan";
        vlan-id 100;
        l3-interface vlan.100;
    }
}

I should be able to delete the address, and add it back with the new netmask:

root@sw-lab-ex3300# show | compare
[edit interfaces vlan unit 100 family inet]
+       address 10.0.100.10/24;
-       address 10.0.100.10/28;

root@sw-lab-ex3300# commit check
error: Overlapping subnet is configred under vlan
[edit interfaces vlan unit 100 family inet]
  'address 10.0.100.10/24'
     Overlapping subnet is configured
error: DCD Configuration check FAILED.
error: configuration check-out failed

{master:0}[edit]
root@sw-lab-ex3300# rollback
load complete

{master:0}[edit]
root@sw-lab-ex3300#

Uh-oh, that's not good. I rolled back to the running configuration and decided to research more. I followed some of the examples in this thread, and began testing in my lab. Testing in lab confirmed that I can change the netmask if I delete the l3-interface's inet address, reboot, then add the address with new netmask. This isn't a great solution, so how do I do this without a reboot? I have done it before without issue. What was different then!?

I decided to do some more lab testing with some other ex3300's that I was using. These already had other vlans and multiple l3-interfaces. I added vlan-mgmt, and the l3-interface configured with a /28 netmask, etc. Committed - no errors.

I then hen tried changing the netmask to /24 as above, and it committed with no errors this time!?

Why? It looks like this problem only appears if you only have one irb/vlan l3-interface configured on the switch. So I go back to my problem switch and I added a temporary vlan with a temporary l3-interface (this is all temporary, so doesn't matter too much what values you use - make sure it doesn't conflict with anything else, or maybe you can put it in a separate routing-instance). I do not attempt to change the management vlan netmask yet!

root@sw-lab-ex3300# show | compare
[edit interfaces vlan]
+    unit 3000 {
+        description "temporary vlan";
+        family inet {
+            address 10.255.255.254/32;
+        }
+    }
[edit vlans]
+   vlan-temp {
+       description "temporary vlan";
+       vlan-id 3000;
+       l3-interface vlan.3000;
+   }

{master:0}[edit]
root@sw-lab-ex3300# commit check
configuration check succeeds

{master:0}[edit]
root@sw-lab-ex3300# commit
configuration check succeeds
commit complete

{master:0}[edit]

So far so good!

Now I can attempt to update the management vlan's netmask:

root@sw-lab-ex3300# show | compare
[edit interfaces vlan unit 100 family inet]
+ address 10.0.100.10/24;
- address 10.0.100.10/28;

{master:0}[edit]
root@sw-lab-ex3300# commit check
configuration check succeeds

{master:0}[edit]
root@sw-lab-ex3300# commit
configuration check succeeds
commit complete

{master:0}[edit]
root@sw-lab-ex3300#

Weird quirk! I know this tread is several months old now, but I figured I would add another documented workaround for the next person that runs into this (and doesn't want to reboot their device).

I just ran into this problem, and wrote up a way to work around it (without having to remove the l3-interface, reboot, and re-add the interface to change the netmask) in this thread: https://forums.juniper.net/t5/Ethernet-Switching/Overlapping-subnet-is-configured-under-irb-ERROR/m-p/310863.

Hopefully this helps anyone else who runs into this quirk, and finds these threads in the future!

Hi guys,

I need help with a certian configuration setup I'm having trouble with.

Here is my physical setup:

I have 3 switches - Switch-A, Switch-B and Switch-C.

Switch-A is the user switch and Switches-B/C are aggregation switches (Switches-B/C are located in different subnets).

I have a l3 vlan on Switch-A which is configured with 2 IP addresses, one for "B" environment and one for "C" environment (vlan-id is the same for both of them).

Switch-A can be connected either to B or to C (never to both of them).

How can I configure some kind of mechanism that will alternate my defualt static route so it will route to the GW of "B" or "C"?

I know that theres an IP SLA mechanism in Cisco swtiches, is there anything like this in Juniper?

Yes, I know.

Does RPM need a special license? Will RPM help me in this specific scenario? Could you provide configuration examples?