- play_arrow Overview
- play_arrow Collecting Traffic Samples for Network Monitoring
- Traffic Sampling Configuration
- Minimum Traffic Sampling Configuration
- Configuring Traffic Sampling
- Disabling Traffic Sampling
- Collecting Traffic Sampling Output in a File
- Directing Traffic Sampling Output to a Server Running the cflowd Application
- Collecting Traffic Sampling Output in the Cisco Systems NetFlow Services Export Version 9 Format
- Example: Sampling a Single SONET/SDH Interface
- Example: Sampling All Traffic from a Single IP Address
- Example: Sampling All FTP Traffic
- Tracing Traffic-Sampling Operations
- play_arrow Configuring Traffic Forwarding for Network Monitoring
- Configuring Traffic Forwarding and Monitoring
- Configuring IPv4 and IPv6 Accounting
- Configuring Discard Accounting
- Configuring Active Flow Monitoring on PTX Series Packet Transport Routers
- Configuring Passive Flow Monitoring
- Configuring Port Mirroring
- Example: Configuring Local Port Mirroring on PTX Routers
- Example: Configuring Remote Port Mirroring on PTX Routers
- Configuring Next-Hop Groups to Use Multiple Interfaces to Forward Packets Used in Port Mirroring
- Defining a Port-Mirroring Firewall Filter
- Defining a Next-Hop Group on MX Series Routers for Port Mirroring
- play_arrow Configuring Forwarding Table Filters to Efficiently Route Traffic
- play_arrow Configuring Other Forwarding Options
- Configuring Routers, Switches, and Interfaces as DHCP and BOOTP Relay Agents
- Configuring DNS and TFTP Packet Forwarding
- Configuring Port-based LAN Broadcast Packet Forwarding
- Preventing DHCP Spoofing on MX Series 5G Universal Routing Platforms
- Understanding the Hyper Mode Feature on Enhanced MPCs for MX Series Routers and EX9200 Switches
- Configuring Hyper Mode on Enhanced MPCs to Speed Up Packet Processing
- Unsupported Features and CLI Commands When Hyper Mode Is Enabled
- play_arrow Configuration Statements and Operational Commands
Understanding Load Balancing for BGP Traffic with Unequal Bandwidth Allocated to the Paths
The multipath option removes the tiebreakers from the active route decision process, thereby allowing otherwise equal cost BGP routes learned from multiple sources to be installed into the forwarding table. However, when the available paths are not equal cost, you may wish to load balance the traffic asymmetrically.
Once multiple next hops are installed in the forwarding table, a specific forwarding next hop is selected by the Junos OS per-prefix load-balancing algorithm. This process hashes against a packet’s source and destination addresses to deterministically map the prefix pairing onto one of the available next hops. Per-prefix mapping works best when the hash function is presented with a large number of prefixes, such as might occur on an Internet peering exchange, and it serves to prevent packet reordering among pairs of communicating nodes.
An enterprise network normally wants to alter the default behavior to evoke a per-packet load-balancing algorithm. Per-packet is emphasized here because its use is a misnomer that stems from the historic behavior of the original Internet Processor ASIC. In reality, current Juniper Networks routers support per-prefix (default) and per-flow load balancing. The latter involves hashing against various Layer 3 and Layer 4 headers, including portions of the source address, destination address, transport protocol, incoming interface, and application ports. The effect is that now individual flows are hashed to a specific next hop, resulting in a more even distribution across available next hops, especially when routing between fewer source and destination pairs.
With per-packet load balancing, packets comprising a communication stream between two endpoints might be resequenced, but packets within individual flows maintain correct sequencing. Whether you opt for per-prefix or per-packet load balancing, asymmetry of access links can present a technical challenge. Either way, the prefixes or flows that are mapped to, for example, a T1 link will exhibit degraded performance when compared to those flows that map to, for example, a Fast Ethernet access link. Worse yet, with heavy traffic loads, any attempt at equal load balancing is likely to result in total saturation of the T1 link and session disruption stemming from packet loss.
Fortunately, the Juniper Networks BGP implementation supports the notion of a bandwidth community. This extended community encodes the bandwidth of a given next hop, and when combined with multipath, the load-balancing algorithm distributes flows across the set of next hops proportional to their relative bandwidths. Put another way, if you have a 10-Mbps and a 1-Mbps next hop, on average nine flows will map to the high-speed next hop for every one that uses the low speed.
Use of BGP bandwidth community is supported only with per-packet load balancing.
The configuration task has two parts:
Configure the external BGP (EBGP) peering sessions, enable multipath, and define an import policy to tag routes with a bandwidth community that reflects link speed.
Enable per-packet (really per-flow) load balancing for optimal distribution of traffic.
