:. AMS-IX .: Amsterdam Internet Exchange
Contact us || Site-Map || Home || Connect to AMS-IX || Services & pricing || Technical || Member list || FAQ
» Main » Technical » Configuration Guide
Juniper Configuration Hints

9. Juniper Configuration Hints

For Juniper routers, there isn't much to disable. The Juniper Documents from qOrbit Technologies contain useful hints on how to set up your Juniper router.

CautionIGMP Bug (PR/20343) in JunOS versions 5.3R4
 

There's a bug in JunOS versions up to 5.3R4, that will cause a Juniper router to emit IGMP packets on all its interfaces, even when IGMP is disabled. The only way to stop your router from transmitting IGMP is to configure outgoing packet filters on your AMS-IX interface(s).

9.1. Unicast BGP Configuration

Make sure to exchange only unicast routes in the unicast ISP peering LAN by explicitly adding the following statement to all neighbors, groups and prefix-limits:

set family inet unicast

CautionBe thorough with family inet unicast
 

If even one of the neighbors, groups or prefix-limits is defined with a family inet “any”, you'll enable multicast and turn on MBGP.

9.2. IPv4 ARP Cache Timeout

Juniper's default ARP cache timeout is 20 minutes (by comparision: Cisco's default ARP cache timeout is 4 hours which fits AMS-IX's relatively static environment much better).

To reduce the amount of unnecessary broadcast traffic, we recommend setting the ARP cache timeout on Juniper routers to 4 hours. A recipe for this follows:

> configure
Entering configuration mode

[edit]
you@juniper# edit system arp

[edit system arp]
you@juniper# set aging-timer 240

[edit system arp]
you@juniper# show | compare
[edit system arp]
+ aging-timer 240;

[edit system arp]
you@juniper# commit and-quit
commit complete
Exiting configuration mode

9.3. Juniper Aggregated Links

9.3.1. M-Series

We have encountered no issues with aggregated links and JunOS (M40, M160, T320). JUNOS releases prior to 6.0 required VLAN tagging on aggregated interfaces. This limitation has since been removed. An example configuration follows:

---
[edit]
niels@junix# show chassis
aggregated-devices {
    ethernet {
        device-count 1;
    }
}
---
[edit]
niels@junix# show interfaces ge-2/1/0
gigether-options {
    802.3ad ae0;
}

[edit]
niels@junix# show interfaces ge-3/1/0
gigether-options {
   802.3ad ae0;
}
---
[edit]
niels@junix# show interfaces ae0
description "AMS-IX";
unit 0 {
   family inet {
       filter {
           input AMSIX-in;
           output AMSIX-out;
       }
       address 195.69.14x.y/23;
   }
   family inet6 {
       address 2001:07F8:1::A50a:bcde:1/64;
   }
}
---

Additionally and optionally you can configure more granular load balancing:

#

---
routing-options {
    autonomous-system abcde;
    forwarding-table {
        export [ load-balance ];
    }
}
policy-options {
    policy-statement load-balance {
        then {
            load-balance per-packet;
        }
    }
}
forwarding-options {
    hash-key {
        family inet {
            layer-3;
            layer-4;
        }
    }
}
---

In case that is not granular enough, you can modify the hash-key algorithm with some undocumented options in JunOS 7.x and up:

---
hash-key {
    family inet {
        layer-3 {
            destination-address;
            protocol;
            source-address;
        }
        layer-4 {
            destination-port;
            source-port;
            type-of-service;
        }
    }
}
---

Also, you can set your aggregated min-links to a value that will cause the bundle to drop in the event that your links can no longer support the amount of traffic you plan on shoving down the pipe. Thus, 2-port aggregated link, pushing 1.2 Gbps sustained across, drop bundle if n == 1;

---
aggregated-ether-options {
    minimum-links 2;
    link-speed 1g;
}
---

In a situation with load-balancing over multiple IP interfaces (not AMS-IX), the final statement will make traceroute more confusing to novices as packets may seem to "bounce" between interfaces by also including TCP/UDP port numbers and ICMP checksums in the algorithm.

On an IP1 load-balance per-packet really means per-packet; on an IP2 it actually works per flow, which is preferable.