Category Archives: junos

Junos per packet load balancing

If you have two multiple equal cost paths to the same destination, JunOS behavior is to pick up one of the next-hops and use that one. For example in the following scenario, Junos keeps sending the packets via the ge-0/0/0.41 interface.

but you can change this behavior ;

1) Write a policy statement

Continue reading

Effect of MRU setting on EX Switch

MRU (Maximum Receive Unit) has a close relation to MTU but as far as I can see it has different effects in various active devices.
For example setting an MTU value of 1000 on an Ethernet interface of a Linux machine or an SRX box doesn’t prevent the larger packet from being accepted. However if the very same interface tries to return a similar size packet then it has to be fragmented. However on EX switch I saw something else. Let me explain;

I connected two PCs to my ex2200 test switch’s ge-0/0/8 and 9 port and assigned to the same vlan. Then I pinged from the PC connected to the port 8 to PC on 9. port with size 1000bytes and it worked. Then I set the interface MTU of port 8 to 900bytes and checked the MRU value.

As it can be seen MRU is 908 since Junos adds 8 bytes to calculate this value. After this setting I again tried to send a ping with 1000 size but no success. Here is the point because it is a switch and also it is MRU but not MTU your sender won’t get notified by any ICMP message even if you have PMTU discovery is turned on. You can literally beat the air if you have a small MRU setting on the switch this is my humble opinion:)

MTU and PMTU on JunOS

I would like to talk about couple of things in this post about MTU on JunOS;

  • Why do we have two different MTU settings i.e at interface and logical level?
  • What is the meaning of path mtu discovery on a junos box
  • How MTU is important for OSPF?

Actually all started with my OSPF tests in my lab. I was connected to one SRX device in my home network and playing with MTU settings at interface level and unit level to see the differences and all of a sudden I lost my connection. To be honest I like doing non-destructive mistakes as they teach me a lot. Now I recall again how MTU is an important piece in OSPF messages. Lets start from beginning again;

Continue reading

GRE tunnel configuration in SRX

I will configure GRE (Generic Routing Encapsulation) between two Juniper SRX firewal devices. If you want to learn more about the protocol see RFC2784. I will just demonstrate how two networks can be connected to each other via a tunnel. I will also show how SRX security policy should be configured in order to pass the traffic through. Here is my topology;

srx-gre-tunnel-topology

1) Configure GRE interfaces on both sides

Interface configuration is pretty obvious if you have a look at my topology.
source address is the real interface address facing towards the remote device.
destination address is the real interface address accepting the packets.

Documentation says that gre interface IP address e.g 10.10.10.1 isn’t mandatory i.e unnumbered GRE is possible but what I have seen is that if you leave it unassigned, routes that you forward to this interface as next-hop won’t be installed into the routing table.

Note: According to feedback from blog reader kroozo, setting “family inet” is sufficient for route to be installed.

Continue reading

SRX reset button for factory/rescue configuration

I will briefly write about Branch SRX alarm led and reset button in this post.

1) Alarm led

Today when I deleted my rescue configuration via;

> request system configuration rescue delete

command, then minutes later I noticed that alarm led on the front panel turned to amber.
First I couldn’t guess that alarm is raised because of rescue config. Then I checked chassis and
system alarms

It seems alarm can also be raised with Minor category for a non-existing rescue configuration.
Once the rescue config is set;

>request system configuration rescue save

Alarm is cleared. Good to learn this feature.

2) Reset button

What I used to know was that reset button returns the config to factory default config now I know that it can also return to rescue config.
If you have rescue config saved and press the reset button and then release it immediately ;

SRX commits the rescue configuration which is really a handy feature.

If you press the button more than 15 seconds, then you return to the factory default configuration.

Good thing is that you can also change this behavior via the configuration mode command;

monitor traffic doesn’t show any icmp traffic

If you want to capture some icmp traffic destined for a Junos router by using “monitor traffic“, you must re-think what you are doing. For example you issued the following command and you started ping from another host towards this Junos router.

Unfortunately you won’t get any icmp request on this capture. The underlying reason that I know is that ICMP responses are handled by the data plane (PFE) instead of the control plane. In other words, you don’t really receive this traffic and PFE responds to this ICMP.

What I do usually is to create a sample TCP traffic (e.g SSH request) towards the RE to see some packet traffic.

Archiving junos configurations

There is a very handy feature in junos which you may find very useful if you have lots of junos devices. JunOS can send your active configuration after every commit to a configured remote destination server by using scp,http or ftp protocols. A small configuration is sufficient to achieve this. For example with the configuration below, my SRX device’s configuration is sent to 192.168.103.20 within the specified interval.

If you list the files on the remote server you will see the files transferred after commit;