Consider custom lines when your application needs to route different users through different network paths, or when critical business operations need to bypass congested lines. Custom lines utilize system routing policies to control the flow of data packets. This allows users to manage network traffic more precisely.

The core of custom lines is selecting different network exits or paths for data packets based on factors such as source, destination, and protocol type. This differs from simply setting a default gateway, which is a single exit point for all traffic. Custom lines allow multiple exit points to coexist and intelligently distribute traffic according to rules. For example, office traffic can use a stable dedicated line, video conferencing can use a low-latency line, and download tasks can use a high-bandwidth line.

The first step in implementing custom lines is to understand your system's infrastructure. You need to know how many network cards your system has and what networks they are connected to. The `ip addr` command lists all network interfaces, showing names like eth0 and eth1 and their assigned IP addresses. The `ip route` command displays the current routing table, typically showing entries like "default via 192.168.1.1 dev eth0," indicating that traffic defaults to exiting from eth0. This is the baseline state; you need to add new rules based on it.

A common method for setting up custom routes is policy routing. While regular routing selects a route based solely on the destination address, policy routing allows for more conditions such as source address and service type. In Linux, policy routing is primarily implemented using the `ip rule` and `ip route` commands. First, create a new routing table. Edit the `/etc/iproute2/rt_tables` file and add a line such as "100 custom1". This creates a new routing table with the number 100 and the name "custom1". This table is initially empty and needs to be populated with specific routes.

Next, add routing rules to the new routing table. Assume you have two outgoing lines: eth0 connects to broadband (gateway 192.168.1.1), and eth1 connects to a 4G network (gateway 10.0.0.1). Set a default route in the `custom1` table: `ip route add default via 10.0.0.1 dev eth1 table custom1`. Now the `custom1` table has its own default route and will not interfere with the main routing table.

A routing table alone is not enough; rules are needed to determine which traffic uses this table. Create a rule specifying the source IP range to use the `custom1` table:

ip rule add from 192.168.1.100/30 table custom1 priority 1000

This rule means: traffic from 192.168.1.100 to 192.168.1.103 will have its path determined by querying the `custom1` routing table. `priority` indicates the routing order; the smaller the number, the higher the priority. The system matches rules according to priority; only traffic that doesn't match will be routed through the main routing table.

Rules can be more granular. Besides source IP, traffic can also be routed by destination IP, service port, and packet tags. For example, to direct traffic to a specific server via a designated route:

`ip rule add to 203.0.113.50 table custom1 priority 990`

Or to direct SSH traffic (port 22) via a more secure route:

ip rule add ipproto tcp dport 22 table custom1 priority 980

More complex scenarios require combining iptables or nftables for marking and then using policy-based routing. For example, identifying video stream traffic and marking it as 100, then directing traffic marked 100 via a specific routing table:

iptables -t mangle -A OUTPUT -p udp --dport 5000:5010 -j MARK --set-mark 100

ip rule add fwmark 100 table custom1 priority 970

This achieves application-type-based routing.

These command settings are temporary and will disappear upon reboot. To make them permanent, the configuration needs to be written into the startup script. Different systems require different methods. Rules can be written to `/etc/rc.local` (execute permissions required), or used with the systemd service unit, or in the network configuration directory such as `/etc/network/interfaces.d/`.

In actual deployment, testing and verification are crucial. After setting rules, use `ip rule list` to view all rules and `ip route show table custom1` to view the contents of a specific routing table. When testing connectivity, use `ping -I eth1 8.8.8.8` to specify pinging from the eth1 interface, or use `traceroute` to observe the actual path. For tag-based traffic splitting, you can see packet matching and tagging status in `iptables -t mangle -L`.

Dynamic lines require more advanced solutions. When a line fails, traffic should be automatically switched. This can be achieved through routing protocols such as BGP, or by using tools like keepalived to monitor link status and trigger switching scripts. Simple monitoring can periodically ping critical gateways; if this fails, execute `ip rule del` and `ip rule add` to switch rule priorities and transfer traffic to backup lines.

Maintaining configuration consistency in a multi-server environment is challenging. Configuration management tools like Ansible and Puppet can be used to deploy routing policies in batches. Rules can be written as templates, with different parameters populated based on server roles (e.g., web server, database server) to ensure servers with the same role have the same routing policy, reducing manual configuration errors.

Typical use cases for custom lines include: directing internal access via China Telecom and external access via China Unicom when enterprises have multiple network interfaces; configuring multiple network interface cards (NICs) on cloud servers to differentiate between management and business traffic; CDN edge nodes selecting the optimal uplink based on user origin; and intelligent switching between Wi-Fi and cellular networks for IoT devices.

In advanced applications, BGP can be used to achieve more intelligent dynamic routing. With your own AS number and IP range, routes can be advertised to multiple operators via BGP, and AS path attributes can be adjusted based on real-time network conditions to guide inbound traffic. This requires routers to support BGP and to establish peering sessions with operators.

No matter how complex the solution, start with simplicity. First, verify in a test environment, recording all steps and commands. Implement in phases. For example, first set up traffic splitting based on source IP, and then add port-based rules after it stabilizes. Back up the current configuration before each change:

ip rule save > backup_rules.txt

This saves rules.

ip route save > backup_routes.txt

This saves routes.

Monitoring and maintenance are equally important. Log the number of rule matches:

ptables -t mangle -L -v

This command displays the packet count. Monitor bandwidth usage on each line to prevent overloading of any single line. Regularly audit rules, clean up unnecessary entries, and keep the configuration simple.

Mastering custom line settings allows you to design network traffic paths based on actual needs, rather than relying solely on device defaults. This requires understanding network layering principles, familiarity with the system's network stack configuration, and continuous adjustments in practice. Start with simple strategies and gradually build a network architecture that meets business needs.