4.2. Routing to Locally Connected Networks

本文介绍了如何通过IP地址和子网掩码定义网络,并详细解析了CIDR和传统子网掩码表示法。通过实例展示了如何确定本地连接网络的可达范围,并使用路由表确认本地网络内的直接可达性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

4.2. Routing to Locally Connected Networks

 

Any IP network is defined by two sets of numbers: network address and netmask. By convention, there are two ways to represent these two numbers. Netmask notation is the convention and tradition in IP networking although the more succinct CIDR notation is gaining popularity.

In the example network, isolde has IP address 192.168.100.17. In CIDR notation, isolde's address is 192.168.100.17/24, and in traditional netmask notation, 192.168.100.17/255.255.255.0. Any of the IP calculators, confirms that the first usable IP address is 192.168.100.1 and the last usable IP address is 192.168.100.254. Importantly, the IP network address, 192.168.100.0/24, is reachable through the directly connected Ethernet interface (refer to classification 2). Therefore, isolde should be able to reach any IP address in this range directly on the locally connected Ethernet segment.

Below is the routing table for isolde, first shown with the conventional route -n output [16] and then with the ip route show [17] command. Each of these tools conveys the same routing table and operates on the same kernel routing table. For more on the routing table displayed in Example 4.3, “Identifying the locally connected networks with route”, consult Section 4.8.3, “The Main Routing Table”.

Example 4.3. Identifying the locally connected networks with route

[root@isolde]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.100.254 0.0.0.0         UG    0      0        0 eth0
[root@isolde]# ip route show
192.168.100.0/24 dev eth0  scope link 
127.0.0.0/8 dev lo  scope link 
default via 192.168.100.254 dev eth0
      

In the above example, the locally reachable destination is 192.168.100.0/255.255.255.0 which can also be written 192.168.100.0/24 as in ip route show. In classful networking terms, the network to which isolde is directly connected is called a class C sized network.

When a process on isolde needs to send a packet to another machine on the locally connected network, packets will be sent from 192.168.100.17 (isolde's IP). The kernel will consult the routing table to determine the route and the source address to use when sending this packet. Assuming the destination is 192.168.100.32, the kernel will find that 192.168.100.32 falls inside the IP address range 192.168.100.0/24 and will select this route for the outbound packet. For further details on source address selection, see Section 4.6, “Source Address Selection”. The source address on the outbound packet conveys vital information to the host receiving the packet. In order for the packet to be able to return, isolde has to use an IP address that is locally available, 192.168.100.32 has to have a route to isolde and neither host must block the packet.

The packet will be sent to the locally connected network segment directly, because isolde interprets from the routing table that 192.168.100.32 is directly reachable through the physical network connection on eth0.

Occasionally, a machine will be directly connected to two different IP networks on the same device. The routing table will show that both networks are reachable through the same physical device. For more on this topic, see Section 9.2, “Multiple IP Networks on one Ethernet Segment”. Similarly, multi-homed hosts will have routes for all locally connected networks through the locally-connected network interface. For more on this sort of configuration, see Section 9.6, “Multihomed Hosts”.

This covers the classification of IP destinations which are available on a locally connected network. This highlights the importance of an accurate netmask and network address. The next section will cover IP ranges which are neither locally hosted nor fall in the range of the locally reachable networks. These destinations must be reached through a router.



[16] The route -n output can also be produced with netstat -rn and is commonly used by admininstrators who rely on platform independent behaviour across heterogeneous Unix and Unix-like systems. This traditional routing table output uses conventional netmask notation to denote network size.

[17] Refer to the ip route section for a fuller discussion of this linux specific tool. The routing table output from ip route uses exclusively CIDR notation.

### Docker Bridge Network Mode and Gateway Configuration In Docker's bridge network mode, each container connected to a bridge network is assigned an IP address from the subnet associated with that particular bridge. The Docker engine configures this automatically when setting up the bridge network; however, specific configurations such as customizing the gateway might be necessary depending on use cases or requirements. For most typical scenarios involving standalone containers running within default bridge networks created by Docker (not user-defined), no explicit configuration of gateways is required because Docker sets these parameters internally during creation[^1]. When launching services through `docker run`, unless specified otherwise via options like `--network` followed by a pre-configured network name, containers will attach themselves to the default bridge (`bridge`) which already has its own internal settings including DHCP server providing addresses along with routing rules set up properly so traffic can flow between host machine interfaces and attached containers without additional intervention. However, for more complex setups—such as multi-host deployments where communication across hosts needs consideration—it may become essential to define bridges manually alongside specifying their respective subnets and possibly even static routes/gateways outside what Docker provides out-of-the-box. This level of customization allows greater control over how packets traverse different segments but requires deeper knowledge about networking principles and tools provided either natively under Linux distributions used as base OSes hosting Docker instances or third-party solutions integrated into CI/CD pipelines managing infrastructure resources dynamically at scale[^2]. When working specifically with Redis clusters inside Docker environments, ensuring proper connectivity among nodes often involves adjusting security-related directives present since version 3.2 due to introduction of protected mode being enabled by default. While configuring external access points towards individual members forming part of distributed systems built around key-value stores similar to Redis, attention should also focus on disabling protection mechanisms temporarily while testing locally before moving onto production stages where hardened configurations must apply strictly according to best practices recommended officially[^3]. ```bash # Example command showing basic usage of connecting container to existing overlay network. $ docker network connect overlay_network_name container_name_or_id ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值