Specifications

Page 102 /148
3.2.9 IP Tunneling
JUNOS supports configuration for a Tunnel Physical Interface Card (PIC) for the
Mxxx routers. The Tunnel PIC is a single-wide PIC (that is, occupies one of four
PIC slots on an FPC) and provides an OC-12/STM4’s worth of tunneling
bandwidth. The Tunnel PIC provides a loopback function that allows packets to
be encapsulated and decapsulated. Thus, the PIC has no physical interface.
A number of applications for the Mxxx require quick encapsulation and
decapsulation of packets. The Tunnel PIC supports this requirement by providing
a loopback function to allow packets to be encapsulated. JUNOS supports :
§ encapsulation of PIM sparse mode multicast traffic within unicast packets,
§ encapsulation of IP traffic within IP packets,
§ encapsulation of GRE traffic within IP unicast packets (RFC 1701).
The diagram below shows the flow on IP multicast packets through the Tunnel
PIC.
3.2.10 Load sharing on parallel links
JUNOS offers optional per packet and per flow load balancing, therefore can
share traffic for equal cost routes on any outgoing interface.
JUNOS also offers more controlled methods of balancing traffic using it’s MPLS
based traffic engineering approach. Traffic in this model can be directed across
network interface as required, independently of the IGP shortest path
calculations. This makes for extremely efficient use of bandwidth in unequal
networks.
JUNOS’ treatment of parallel links and paths are the same in the case of traffic
engineering and normal IP forwarding. There are two ways that Junos can
handle parallel paths.
In the first approach, the routing software detects multiple equal-cost paths to a
given next hop and randomizes the prefixes pointing to that next hop among the
multiple paths. In other words, imagine an ingress and an egress router I and E,
respectively. Now imagine that two paths, P1 and P2, exist between I and E. If I
were to receive 500 routes via I-BGP for prefixes behind E, then I would install
roughly 250 entries pointing down path P1 and roughly 250 entries pointing down
P2. The result is a probabilistic load sharing among paths going towards that
next hop, though a given IP prefix takes exactly one path. The advantage of this
approach is that good load sharing happens, but packet reordering does not.
Note that when the number of equal-cost paths changes (e.g., one paths fails or
another one appears), the routing software re-randomizes the paths taken to
ensure continued load sharing.
In the second approach, an IP prefix points to multiple next hops in the actual
forwarding path. When a packet is forwarded, a random number is chosen that is
used to select one of the multiple paths. This approach may result in slightly
better load sharing, but it introduces the possibility of packet reordering. The
system is configurable for which approach to use.
Some attention should be paid to MPLS in this context. A given Label-Switched
Path (LSP) goes along exactly one path in the network, meaning that for a single
Route Route
LookupLookup
PIC
I/O
Manager
ASIC
FPC
I/O
Manager
ASIC
FPC
Internet
Processor II
Mcast packet
arrives for
encapsulation
Next hop:
Tunnel PIC
Next hop determined for
tunnel tail-end address
Unicast packet
forwarded through
tunnel
PIC
PIC
PIC
Tunnel
PIC
PIC
PIC
PIC
L2 rewrite adds
appropriate
unicast header
Packet is looped
back for second
lookup