经过前面漫长的铺垫，相信各位大佬已经对网络有了一个基本的概念。接下来的日子里，我们将正式在网络之路拾级而上，我将以H3C系列认证课程为蓝本，以HCL为主要工具，以VMware、NFV等其他环境为辅助工具，从基础技术入手，逐步深入，助力各位新手逐步成长为一名网络工程师，体验网络技术带来的巨大快感！
6、基础网络实验
本章节，主要通过在HCL中配置一些简单实验来了解相关的网络技术。
6.1、简单网络环境搭建与测试
在我们日常接触的网络中，一般是分层的网络架构，即使是普通的家庭宽带网络，一般也有光猫和路由器，内网终端一般也有2个以上。以我的家庭网络为例，有路由器、交换机、服务器、电脑、手机等网络设备，用HCL模拟一下，大概的网络结构如下所示：
这个环境还是有点特殊的，与常规组网相比，有以下几点不同：
1、因为服务器和NAS离光猫有点远，所以HUB2的作用主要是为了降低网线的成本；
2、HUB不支持VLAN划分，两个HUB下的设备属于同一个冲突域，所以在未做限制的情况，内网终端可以从光猫、路由器1或者路由器2获取到IP地址，为了保证地址获取无冲突，仅开启了路由器1的DHCP功能；
3、还有一个很少见的配置，那就是路由器1和路由器2的WAN口在同一个网段，LAN口也在同一个网段。因为路由器2支持配置L2TP VPN，所以它是用来将服务器发布到公网用的（成本增加了100块，内网服务器上公网解决方案2.0重磅来袭！）。
那如果移除掉这些不规范的地方，普通的网络应该长下面这样：
内网所有的终端（手机、电脑、服务器、NAS等）都通过无线路由器上网，HUB交换机的作用主要是扩展网络接口；因为光猫的性能比较差，所以仅承担PPPoE拨号的功能。
当我们使用HCL模拟器时，要模拟PC主机，可以使用3种方式，分别为Host、PC和VPCS。
Host用于通过主机网卡和宿主机进行连接，可以选择宿主机中处于启用或连接状态的硬件网卡和VirtualBox网卡。
当我们配置连线时，我们可以看到有两个可选的网卡，分别是电脑的有线网卡和VirtualBox虚拟网卡。而实际上，我电脑中有7张网卡，其中2张硬件网卡（LAN+WLAN）、1张VirtualBox虚拟网卡、2张VMware虚拟网卡和2张VPN虚拟网卡。
将网线连接到VirtualBox虚拟网卡之后，HCL中的其他设备就可以与主机进行通信了。
我们先看一下网卡的IP地址信息。
然后我们配置PC类型的虚拟主机，右击设备图标选择“配置”，首先“启用”接口，然后配置使用DHCP获取IPv4地址，或者使用静态IPv4地址，最后点击“启用”使配置生效。
双机设备图标或者右击选择“启动命令行终端”进入设备命令行，这是一个精简的命令行系统，仅能执行一些简单的操作命令。
然后我们使用ping命令测试一下宿主机的连通性。
接下来，我们配置VPCS类型的虚拟主机。还是右击设备图标选择“配置”，接口默认启用，然后配置使用DHCP获取IPv4地址，或者使用静态IPv4地址，最后点击“启用”使配置生效。
VPCS的系统应该是通过Linux系统改的，支持一些简单的命令，但是不能通过“TAB键”进行补全，可以使用“？键”查看可用命令，但是需要回车确认。像配置时提到的，建议通过命令行配置VPCS设备，使用上面的页面进行配置时，设备会发生重启。
重启之后检查设备的IP地址配置。
与宿主机通信正常，并且可以查看到宿主机的ARP信息。
再测试一下PC设备，可以看到通信正常，并且ARP学习正常。
终端之间互访的流量，我们可以在线路上抓包查看。操作方法为在线路上右击，选择“开启抓包”，然后选择要抓包的接口。
开启抓包时，会提示操作将导致相关设备的接口震荡，一定要选择“是”，否则无法开始抓包。
如果要查看抓包信息，请在“设置”的“工具”页签中配置好WireShark的路径，和命令行终端的配置在同一个界面。
在“抓包接口列表”视图中，我们可以右击开启了转包的接口，选择对应的操作，包括停止（全部）抓包、启动WireShark、导出抓包文件等操作。
我们选择“启动WireShark”，查看抓包信息。
可以看到，报文的交互过程为ARP请求和ARP应答、ICMP请求和ICMP应答，对应设备的操作如下：
从下面的ARP信息中，我们可以看到，这条ARP记录将在113秒之后超期，变成上面的ARP表项为空的情况。ARP（Address Resolution Protoco，地址解析协议）是一种在网络层协议中用于将IP地址解析为物理地址的协议，用于在两台计算机之间传递地址解析请求和响应。此时，因为设备中没有ARP表项，两台主机无法通信，所以VPCS会在广播域内先发送一个ARP广播请求来寻找另一台主机192.168.56.11。ARP请求包中包含目标计算机的IP地址，物理地址以全F的广播地址进行代替。
当192.168.56.11收到ARP请求包后，会向VPCS回复一个ARP单播报文，将自己的IP地址和物理地址告诉VPCS。
然后，双方就都有了对方的IP地址和MAC物理地址的记录，并在以后使用该地址来发送数据。
而ping探测使用的是ICMP协议，请求报文是type-8的Echo request报文。
响应报文是type-0的Echo reply报文。
按照协议规定（Internet控制消息协议ICMP报文详解），每个节点必须实现ICMP Echo响应功能，该功能接收Echo请求并发送相应的Echo回复。出于诊断目的，节点还应实现用于发送回显请求和接收回显回复的应用层接口。与此同时，响应单播回显请求消息而发送的回显回复的源地址必须与该回显请求的目标地址相同，且ICMP Echo请求消息中接收到的数据必须在ICMP Echo回复消息中完全返回且未修改。
这样，通过ARP协议和ICMP协议，我们就实现了简单的主机间通信。
6.2、网络设备基本连接与调试
可能很多人跟我一样，接触的第一台网络设备就是家用路由器，有可能大多数人迄今为止都没接触过交换机。确实，我家里自2011年安装了第一台无线路由器，到现在已经有12年了，但在2020年才因为扩展端口的原因安装了第一台HUB集线器，不支持任何管理操作；而且2012年我对办公室的交换机的理解，也是扩展端口，这应该是符合大多数人的认知的。
所以，直接向大家介绍交换机肯定是比较晦涩的，我们还是沿着路由表的逻辑继续介绍路由器设备（网络之路2：初识路由表）。
我们上次测试了局域网中主机间的通信，这也是网络中最基础的网络通信，它所依赖的协议是ARP（Address Resolution Protocol，地址解析协议）（ARP：以太网地址解析协议），主要用于实现在网络层协议中用于将IP地址解析为物理地址的协议，用于在两台计算机之间传递地址解析请求和响应，这是所有主机间通信的基础。
但是因为网络规模的原因，将所有主机都接在一台大的HUB集线器下面是不现实的，我们已经知道ARP的请求报文是广播报文，需要发送给网络中所有的主机；我们假设网络中只有6万台主机，一个ARP广播包的大小是64字节，那这个广播的总流量就是64*6000=3.84 MB，至少需要占用31 Mbps的带宽，1 Gbps的链路也只能支持33台主机同时广播，主机间的通信势必受到极大影响。
这就像我们日常生活中一样，办公室内的通信可以是面对面的，但是跨城市的交通一般都是采用集中交付的模式，比如快递中转站、汽车站、火车站等等。
而在网络中承担这个中转角色的设备一般就是路由器，我们可以将其称为“按路由表转发的设备”。我们现在已经知道，路由表是网络设备中存储的表格，包含了该设备可到达其他网络的信息和如何到达这些网络的路径。路由表中的每一条记录称为路由项（或路由记录），它指示了到达某个目标网络的下一跳路由器或直接连接的接口，并指定了到达目标网络的路由协议和距离等信息。
还是在这个拓扑里面，我们将PC的地址配置为192.168.56.11/24，将路由器的IP地址配置为192.168.56.1/24，这样PC和路由器就可以通信了。
现在我们在宿主机上进行测试，发现主机可以访问路由器的接口地址192.168.56.1，但是无法访问192.168.0.2这个地址。
此时，因为192.168.0.0/24和192.168.56.0/24属于跨网段了，我们就要考虑路由表的问题了。
我们首先查看路由器的路由表，命令为：
display ip routing-table
可以看到，去往192.168.0.0/24和192.168.56.0/24的路由表都在路由表中，而且都是设备的接口地址。
然后我们查看主机的路由表，命令为：
route print -4
可以看到，路由表中没有去往该网段的明细路由，按照最长匹配原则，会匹配0.0.0.0/0的默认路由从接口192.168.1.110进行转发，而这个接口下连的网络中是没有192.168.0.2这个地址的，导致访问失败。
此时，我们就要添加一条明细路由来指导去往192.168.0.0/24这个网段的流量的转发，命令如下：
route add 192.168.0.0/24 192.168.56.1
此时，主机上就有了去往192.168.0.0/24这个网段的路由表项了，然后我们再测试一下。
可以看到，现在已经可以访问路由器上的192.168.0.2地址了，但是还无法访问光猫的192.168.0.1地址。
我们主机上不是已经填加了路由表项了吗？为什么还是无法访问？
这里就要考虑一个双向通信的原因，当主机要访问光猫时，主机上有路由表项，会将报文转发给下一跳路由器；路由器收到报文之后，也会查路由表从接口G0/1转发出去。
光猫也可以正常收到请求报文，但在发送时却犯了难，我们看到光猫对报文的处理方式为Discarding（丢弃），原因是Destination is unreachable（目的地不可达）。
此时我们看一下光猫的路由表。
可以看到，光猫上只有一个接口直连的路由表，没有其他路由表项了，这就导致查询去往192.168.56.2的路由表项失败，只能丢弃报文。
解决方法和电脑主机一样，也是增加一条路由表项就可以了，命令为：
ip route-static 192.168.56.0 24 192.168.0.2
现在再测试，主机就可以成功访问到光猫了。
但是当我们追踪到光猫的路径时，却发现无法显示中间的路由器设备。这是因为H3C设备的ICMP超时报文发送功能和ICMP目的不可达报文发送功能默认处于关闭状态，需要手工开启，命令如下：
ip ttl-expires enable ip unreachables enable
需要注意的是，两条命令一般建议是同时开启的，但两者的实际功能存在差异。
开启ICMP超时报文发送功能之后，设备收到IP数据报文后，如果报文的目的地不是本地且报文的TTL字段是1，则发送ICMP差错报文“TTL超时”；设备收到目的地址为本地的IP数据报文的第一个分片后，启动定时器，如果所有分片报文到达之前定时器超时，则会发送ICMP差错报文“重组超时”。
而ICMP目的不可达报文发送功能开启之后，当符合以下条件时会发送目的不可达报文：
1、设备在转发报文时，如果在路由表中未找到对应的转发路由，且路由表中没有缺省路由，则给源端发送ICMP差错报文“网络不可达”；
2、设备收到目的地址为本地的数据报文时，如果设备不支持数据报文采用的传输层协议，则给源端发送ICMP差错报文“协议不可达”；
3、设备收到目的地址为本地、传输层协议为UDP的数据报文时，如果报文的端口号与正在使用的进程不匹配，则给源端发送ICMP差错报文“端口不可达”；
4、源端如果采用“严格的源路由选择”发送报文，当中间设备发现源路由所指定的下一个设备不在其直接连接的网络上，则给源端发送的ICMP差错报文“源站路由失败”；
5、设备在转发报文时，如果转发接口的MTU小于报文的长度，但报文被设置了不可分片，则给源端发送ICMP差错报文“需要进行分片但设置了不分片位”。
如果是在Linux系统中，我们也可以使用MTR命令进行相关探测（MTR网络诊断工具），获取相关转发路径或报错信息。
还要介绍一个Windows系统和网络设备一个不同的逻辑，那就是带源地址的相关操作。
如果我们查看Windows中ping命令的相关操作，可以发现有一条-S参数，它的解释是指定“要使用的源地址”。
但是当我们操作时，发现路由器没有收到报文。
你是不是在想缺少路由的问题？
看，路由器上是有路由的，说明这个“要使用的源地址”的更准确描述应该为“要使用的出接口”。
因为我们抓包来看，这个ICMP请求报文还是从192.168.1.110这个网卡发出去了。
那网络设备的命令是怎样的呢？
H3C设备是使用-a命令来指定“要使用的源地址”，我们测试一下。
可以看到，请求报文所使用的源地址为192.168.56.1，而转发确实查路由表从接口GigabitEthernet0/1进行转发的。
本节涉及命令：
#显示路由表信息 display ip routing-table #添加、配置静态路由 ip route-static 192.168.56.0 24 192.168.0.2 #开启ICMP超时报文发送功能 ip ttl-expires enable #开启ICMP目的不可达报文发送功能 ip unreachables enable #指定ping报文的源IP地址，该地址必须是设备上已配置的IP地址 ping -a #指定ICMP回显请求报文的发送次数，缺省值为5 ping -c
现在，我们了解了基本的二层ARP通信和三层网关通信，这两个的转发基础，一个是ARP协议，另一个是路由表。那跨网段通信一定需要配置路由表吗？也不一定，接下来，让我们走进ARP再看一下。
6.3、ARP配置
ARP（Address Resolution Protocol，地址解析协议）是将IP地址解析为以太网MAC地址（或称物理地址）的协议，他的RFC标准是（ARP：以太网地址解析协议）。在网络中，当主机或其它网络设备有数据要发送给另一个主机或设备时，它必须知道对方的网络层地址（即IP地址），由于IP数据报必须封装成帧才能通过物理网络发送，因此还需要知道对方的物理地址，而ARP就是在设备上建立从IP地址到物理地址的映射关系的协议。对应的，还有一个通过物理地址查询IP地址的协议，就是RARP（Reverse Address Resolution Protocol，反向地址解析协议），想了解的可以参考（RARP：反向地址解析协议），不做过多介绍。
前面我们了解了主机间通信的ARP交互过程。在初始状态，源设备中没有目的设备的ARP表项，两台主机无法通信，所以VPCS会在广播域内先发送一个ARP广播请求来寻找另一台主机192.168.56.11。ARP请求包中包含目标计算机的IP地址，物理地址以全F的广播地址进行代替。
当192.168.56.11收到ARP请求包后，会向VPCS回复一个ARP单播报文，将自己的IP地址和物理地址告诉VPCS。
如果我们在Windows系统中，可以在CMD或PowerShell中使用命令arp -a显示ARP表项。
而此时我们在交换机上是无法查看ARP表项的。想想为什么？ARP是从IP地址到MAC地址的映射关系，交换机上此时没有配置任何IP地址，所以无法响应ARP请求。
但是，交换机作为二层设备，可以查看到各个接口的MAC地址信息。
而路由器就不一样了，它自身是配置了网关IP地址的，所以它可以查看ARP表项信息。
注意看后面的Type选项，表示此ARP表项是动态学习到的，还有Aging选项，对应的数字表示此表项还有多少分钟到期，到期之后，此表项将被设备删除，直到下次学习被再次添加。
所以，与动态学习相对应的是静态添加，也就是在设备上手工添加ARP表项。比如我们将192.168.56.2的ARP表项手工添加到设备上，可以使用命令：
arp static 192.168.56.2 0a00-2700-001b
配置过程中，可以使用命令查看可用选项及其含义。配置完成之后，我们看到192.168.56.2对应的ARP表项中，Type为S表示ARP表项类型为静态；Aging老化时间不显示了，表示手工添加的静态ARP表项永不老化。
这样，当网关路由器需要和主机通信时，就省略了一个ARP请求的过程，能够提高通信效率。
但是，如果我们不小心把ARP表项配错了呢？
我们将对应的MAC地址修改为0a00-2700-0000，试一下。
首先使用undo命令删除掉对应的表项。
此时，设备上已经没有192.168.56.2对应的ARP表项了，我们添加一条错误的记录看看。
试一下从路由器访问主机192.168.56.2。
可以看到，已经无法访问了，说明配置静态ARP表项可以影响主机的通信。静态ARP表项可以限制和指定IP地址的设备通信时只使用指定的MAC地址，如果有有攻击报文，也无法修改此表项的IP地址和MAC地址的映射关系，从而保护了本设备和指定设备间的正常通信，增加了通信的安全性。
然后我们移除错误表项对比一下。
接下来，就是代理ARP（Proxy ARP）功能。
正常来讲，对于跨网段通信，需要沿途所有设备上都有相关路由表项。以本场景中PC终端要和光猫通信为例，PC和光猫同时连接了路由器设备，但是不在同一个广播域中，PC和光猫都要有去往对端的路由表项。但是如果使用了代理ARP，就可以不用路由表了。
代理ARP功能屏蔽了分离的物理网络这一事实，使用户使用起来，好像在同一个物理网络上。代理ARP分为普通代理ARP和本地代理ARP，二者的应用场景有所区别：
1、普通代理ARP：想要互通的主机分别连接到设备的不同三层接口上，且这些主机不在同一个广播域中。
2、本地代理ARP：想要互通的主机连接到设备的同一个三层接口上，且这些主机不在同一个广播域中。
此时，我们符合普通代理ARP的场景，需要在连接终端的接口上都开启普通代理ARP功能。
然后，我们在光猫设备上删掉到PC网段的路由。
让后测试到PC的跨网段访问。
可以看到，两台设备可以互通，并且跨设备学习到了对方的ARP表项。
当然，我们可以看到，此时的ARP请求是从一个网络的主机发往同一网段却不在同一物理网络上的另一台主机，也就是说光猫（192.168.0.1/16）和PC（192.168.56.2/16）互相认为处于同一子网，但实际却被路由器分在两个不同的子网192.168.0.0/24和192.168.56.0/24。
虽然手工配置静态IP地址的方式用起来比较安全，但是对于日常使用略显繁琐，所以日常使用比较多的还是DHCP协议。
6.4、DHCP报文交互过程
DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）的协议规范是RFC2131（DHCP：动态主机配置协议详解），它提供了一个框架，用于将配置信息传递给TCP/IP网络上的主机。DHCP基于引导协议（Bootstrap Protocol，BOOTP）（Bootstrap 协议的说明和扩展），增加了自动分配可重用网络地址和附加配置选项的能力，DHCP 具有捕获 BOOTP 中继代理的行为，并且 DHCP 参与者可以与 BOOTP 参与者进行互操作。
我们之前学习过如何通过WireShark查看报文的封装结构（WireShark抓包报文结构分析），今天就用比较基础且典型的DHCP再来简单介绍一下。
DHCP采用客户端/服务器的C/S模式，由服务器为网络设备动态地分配IP地址等网络配置参数。
在这个简单的拓扑里面，正常应该是设备MSR36是DHCP服务器，主机是客户端。但是主机的虚拟网卡默认开启了DHCP服务器功能，而MSR36设备默认开启了客户端模式。但是不影响报文交互，MSR36开机后的报文交互如下：
这个过程和设备自动配置的过程是一致的，只不过没有拿到配置，但是从这个过程中可以看出每次请求初始化配置的循环过程。
而且从上图中可以看到DHCP请求地址的4个过程，但是如果我们进行筛选，会发现多出一个环节。
首先看正常的，DHCP客户端从DHCP服务器获取IP地址，主要通过四个阶段进行：
1、发现阶段：客户端以广播方式发送DHCP-DISCOVER报文。
2、提供阶段：服务器接收到客户端的DHCP-DISCOVER报文后，根据IP地址分配的优先次序选出一个IP地址，与其他参数一起通过DHCP-OFFER报文发送给客户端。
3、选择阶段：客户端选择IP地址的阶段。如果有多台DHCP服务器向该客户端发来DHCP-OFFER报文，客户端只接受第一个收到的DHCP-OFFER报文，然后以广播方式发送DHCP-REQUEST报文，该报文中包含DHCP服务器在DHCP-OFFER报文中分配的IP地址。
4、确认阶段：服务器收到客户端发来的DHCP-REQUEST报文后，只有DHCP客户端选择的服务器进行回复，如果确认将地址分配给该客户端，则返回DHCP-ACK报文；否则返回DHCP-NAK报文，表明地址不能分配给该客户端。
我们可以看出，这是一个四次握手的过程，那多余的一个DHCP-RELEASE呢？就是客户端通过向服务器发送DHCP-RELEASE消息来选择放弃对网络地址的租用，通知服务器释放该地址租约，对，是通知，单向的。
再梳理一下，就是下面这样的：
这个过程就好像是一个大学生去找工作（如果按照找工作来理解DHCP，那就简单明了了）：
1、DHCP Discover：快毕业了，谁能给我一份工作啊。大学生开始在网络或者招聘会上大量发送简历。
2、DHCP Offer：有3家公司A、B、C看了一下，自己公司有空缺，都像大学生给出了Offer。你看，Offer和Offer是一样的。
3、DHCP Request：和实际情况有些不一样，或许是这个大学生比较着急，因为C公司是最快发送Offer的，所以大学生就接受了C公司的Offer。
4、DHCP ACK/NAK：C公司收到反馈之后，检查公司岗位情况，如果这个岗位仍然空缺，那就回复ACK允许该大学生入职，万事大吉；如果不巧，这个岗位因为某些原因已经分配给其他人了，那就回复NAK给大学生，让他另谋高就。这个时候，他就要从新开始找工作了。
5、DHCP Request和DHCP ACK/NAK，续签合同：正式入职后，大学生会在合同期到一半的时候，向公司发起续签。如果公司感觉没有问题，那就继续续签，当然，除非手工配置，DHCP协议中不会出现无限期的合同；如果碰巧公司这个岗位又被安排出去了，那就会发送NAK和大学生解约，他就要从新开始找工作了。
6、DHCP Release：当然，如果大学生工作了一些年后，赚得盆满钵满，不再需要这份工作了，那他就直接裸辞了。当然，他也可能是用这种方式换份更加体面的工作，不同的是，他不需要离职交接，不需要离职证明，也不需要签署竞业协议。
我们先来看一下DHCP Discover报文：
最外层可以看到请求的源MAC地址是设备接口的MAC地址，目的MAC地址是全1的广播地址（FF:FF:FF:FF:FF:FF）。
网络层是IPv4协议，源地址因为还没有地址，所以是0.0.0.0，同样目的地址也是全1的广播地址（255.255.255.255）。
传输层是UDP协议，源端口是68，目的端口是67，表明这是一个DHCP协议报文。
解析DHCP协议内容，可以看到消息类型是Boot Request，不要怀疑，DHCP Discover、Offer、ACK、NAK等等这些是消息，消息类型（或者称消息操作码）只有Request（1）和Reply（2）两个。
Transaction ID，事务ID，这个是客户端选择的随机数，客户端和服务器使用它来关联客户端和服务器之间的消息和响应，在一次DHCP过程中，这个数值始终保持一致。
后面是DHCP的IP地址信息，当然，还没有分配具体的地址。
最后是6个option选项，其中option 55中还包含着12个option。参考RFC（【先码后看】DHCP 扩展选项大全），我们都能找到对应的解释。当然，如果从设备自动配置的角度来看，我们可能需要额外关注列表中12个option。
再看DHCP Offer，就好理解了。这个是DHCP服务器192.168.56.100发出的广播报文。传输层的UDP源端口68、目的端口67，表示这还是一个DHCP协议报文。
消息类型是2，表示是Reply。
这里服务器给的Offer地址是192.168.56.101，掩码是255.255.255.0，租期是20分钟。其他相关的option选项服务器只回应了4个。option 255不算，这个是用来表示结束的。
来到Offer接收阶段的DHCP Request，我们看到这个时候客户端还是自由身，他仍然以空地址0.0.0.0进行广播。只不过DHCP消息中增加了option 54和Option 50两个选项，表明自己准备接受192.168.56.100这个服务器，自己请求使用的地址为192.168.56.101。
对比Offer和ACK来看，其实差别不大，主要差别在于Option 53表明这是一个ACK报文，同时多了一个option 56，你看消息内容：Ok, ok, here it is。大概意思是说，好的，好的，在这呢！
最后的Release多么简洁，这是一个不需要Reply的Request，多么潇洒啊！
总结一下：我们常说的报文交互过程的消息类型是包含在DHCP消息的option 53中的，该选项共有8个合法值，具体如下：
在MSR36上配置地址租期时发现一条新命令：
除了正常配置的有期限（1秒-2年）和无期限（实际上系统限定约为136年）之外，还多了一个allow-hint，解释为：允许服务器考虑客户端建议的租用时间，目前官网手册还没有正式解释，不过配置之后效果如下：
默认是1天。要是参考DHCPv6的说明，那这个应该是尽量满足客户端的期望租期。
6.5、DHCP基础实验
本次实验，我们主要介绍HCL中的MSR3620设备作为DHCP服务器的实验配置，同时简单介绍MSR3620设备作为DHCP客户的配置方法。
实验拓扑如上图所示，其中PC为连接电脑的VB网卡，SW作为二层交换机使用。
在最简单的使用场景下，会将路由器的下联口作为内网的网关使用，所以我们首先给服务器的下联口配置一个IP地址。
# interface GigabitEthernet0/0 ip address 10.1.1.1 255.255.255.0
然后我们将VB网卡的IPv4配置修改为“自动获得IP地址”和“自动获得DNS服务器地址”。
修改完之后，在没有开启DHCP服务器的情况下，我们查看主机网卡的状态，可以看到网卡仍然获取到了一个169.254.56.107的IP地址。
我们在之前的文章中介绍过（IPv4 地址冲突检测），如果DHCP客户端未能从任何DHCP服务器获得响应，它将简单地组成一个包含随机169.254.x.x的虚假响应地址。如果ARP模块报告了该地址的冲突，则DHCP客户端将再次尝试，根据需要多次组成一个新的随机169.254.x.x地址，直到成功。简言之，网络中缺少DHCP服务的服务器，网卡获取IP地址失败。
然后我们在服务器上简单配置一个DHCP服务器，在DHCP地址池视图下的可用配置如下：
常用命令是address、dns-list、gateway-list和network，其中network和address都用来指定地址池内的地址。network命令比较常用，可以直接配置DHCP地址池动态分配的IP地址网段，命令如下：
# dhcp server ip-pool h4c network 10.1.1.0 mask 255.255.255.0
需要注意的是，每个DHCP地址池中只能配置一个主网段，所以我们一般要考虑掩码的长度是否满足使用需求。当地址池耗尽时，需要改小掩码或增加从网段；但是从网段也涉及掩码和网关的问题，日常使用较少。
现在，我们只要再开启路由器的DHCP服务就可以了。
# dhcp enable
然后检查网卡获取网卡是否成功。
可以看到，电脑成功获取到了10.1.1.2的IP地址，下面还显示了DHCP服务器地址是10.1.1.1，还有获得租约以及租约过期的时间，租约为1天。
对应的，设备上看到的debug信息如下：
通过我们前面对路由表的了解，没有默认网关是无法访问外部网络的，所以我们还要为其指定一个网关地址，命令如下：
# dhcp server ip-pool h4c gateway-list 10.1.1.1 network 10.1.1.0 mask 255.255.255.0
此时客户端就可以获取到IPv4默认网关了。
同样的，我们还可以为其配置DNS（Domain Name Server，域名服务器）服务器和WINS（Windows Internet Name Service，Windows网络名称服务）服务器信息。当然，一般用户很少用的WINS服务器，使用标准域的企业用户才用的到。
# dhcp server ip-pool h4c gateway-list 10.1.1.1 network 10.1.1.0 mask 255.255.255.0 dns-list 223.5.5.5 nbns-list 10.1.1.254
此时客户端的网络连接详细信息显示就全了。
回过头来，我们刚刚介绍还有一个address命令平时也会用到。但address需要跟range命令一块使用，用来配置地址池动态分配的IP地址范围；如果未通过address range命令配置地址池动态分配的IP地址范围，则地址池下network命令指定的网段地址都可以分配给DHCP客户端；如果通过address range命令配置了地址池动态分配的IP地址范围，则只能从本命令指定的IP地址范围内选择地址分配给客户端。
比如我们指定仅分配10.1.1.100-10.1.1.200的地址给客户端，则命令如下：
# dhcp server ip-pool h4c gateway-list 10.1.1.1 network 10.1.1.0 mask 255.255.255.0 address range 10.1.1.100 10.1.1.200 dns-list 223.5.5.5 nbns-list 10.1.1.254
当客户端再次上线时，他还是先请求的之前的IP地址，但是被服务器拒绝了，之后客户端才接受了10.1.1.100这个IP地址。
查看debug过程如下：
注意：address range命令指定的地址范围应该在network命令指定的网段范围内，网段范围外的地址将无法被分配；并且在配置address range命令后，不能再通过network secondary命令在地址池中配置从网段。
而如果我们想给客户端分配固定的IP地址时，我们还可以通过static-bind命令来实现，通过客户端ID或硬件地址来为指定的客户端分配DHCP地址池中固定的IP地址。
例如，我们现在想给客户端指定10.1.1.163的IP地址，我们需要记录客户端的MAC地址，格式为aabb-cccc-dddd。例如我的网卡的格式就需要调整为0a00-2700-0006，则配置命令如下：
# dhcp server ip-pool h4c static-bind ip-address 10.1.1.163 hardware-address 0a00-2700-0006
此时再次让客户端重新获取IP地址。
虽然客户端对10.1.1.2这个IP地址表示了浓厚的兴趣，但是最终仍然获得了10.1.1.163这个IP地址。不过需要注意的是，因为我们没有为其指定IP地址的掩码，导致其直接按照地址大类分配了255.0.0.0的掩码；所以，在实际使用中，建议配置mask参数，以保证正确配置掩码。如下所示
# dhcp server ip-pool h4c static-bind ip-address 10.1.1.163 mask 255.255.255.0 hardware-address 0a00-2700-0006
看完了PC客户端的配置，那网络设备的IP地址何如通过DHCP获取呢？
其实也很简单，只需要将IP地址配置为通过DHCP动态获取就可以了，命令如下：
# interface GigabitEthernet0/0 ip address dhcp-alloc
然后检查地址是否获取成功：
同样，还有DNS信息和网关信息。
注意看，这里默认路由的优先级是70，如果是手工配置的优先级会更高一些，为60，也就是说，手工配置的默认路由会优于自动获取的默认路由。
此时，如果我们不想给客户端分配10.1.1.101这个IP地址呢？可以使用forbidden-ip或forbidden-ip-range命令，forbidden-ip命令用来配置地址池中不参与自动分配的IP地址，而forbidden-ip-range命令用来配置DHCP地址池中不参与自动分配的IP地址段。命令如下：
# dhcp server ip-pool h4c forbidden-ip 10.1.1.101 forbidden-ip-range 10.1.1.102 10.1.1.105
然后我们让MSR3620再次获取IP地址，看获取到的是不是10.1.1.106。
而查看debug过程，我们可以发现，网络设备对IP地址就没有操作系统那么执着。
配置完成之后，我们还可以从设备上查看DHCP服务器的相关信息。
查看DHCP地址池的信息。
display dhcp server pool
查看DHCP地址分配/绑定信息。
display dhcp server ip-in-use
查看DHCP地址池的空闲地址信息。
display dhcp server free-ip
查看DHCP服务器的统计信息。
display dhcp server statistics
理论上讲，学到这里，90%以上的DHCP配置都能满足了。但是，有时我们还是会遇到一些复杂的场景，比如装在Windows Server上的DHCP服务器等等（配置Windows Server 2016作为DHCP服务器），所以有兴趣的小伙伴可以把业务场景覆盖率提升到98%。
6.6、DHCP进阶实验
首先回顾一下，DHCP请求报文是什么类型的报文？是不是广播报文？广播报文能否跨三层转发？
第一个问题，如何在设备上开启多个DHCP地址池。
当然，这个拓扑不太合理，但是在没接触三层交换机之前，我们先大概借此模型认识一下。假设2个客户端都需要从DHCP服务器获取IP地址，我们一般是要配置2个DHCP地址池的，分别对应到两个互联接口所在的网段，配置如下：
# dhcp enable # dhcp server ip-pool h4c0 gateway-list 10.1.0.1 network 10.1.0.0 mask 255.255.255.0 # dhcp server ip-pool h4c1 gateway-list 10.1.1.1 network 10.1.1.0 mask 255.255.255.0 # interface GigabitEthernet0/0 ip address 10.1.0.1 255.255.255.0 # interface GigabitEthernet0/1 ip address 10.1.1.1 255.255.255.0
然后我们查看客户端地址的获取情况。
客户端1获取到了10.1.0.2/24的IP地址。
客户端2获取到了10.1.1.2/24的IP地址。
那有没有可能两个主机使用一个地址池内的地址呢？正好10.1.0.0/24和10.1.1.0/24可以聚合为10.1.0.0/23，试一下。
# dhcp server ip-pool h4c2 gateway-list 10.1.1.1 10.1.0.1 network 10.1.0.0 mask 255.255.254.0
此时客户端1获取到的IP地址还是正常的，但是网关却不响应请求了。
而到了客户端2这边，也是同样的情况。
这就导致了虽然能学到ARP信息，但是无法通信。
所以，正如我们上次实验所提到的，如果我们想扩容地址池，还是要考虑掩码长度和网关的配置问题，如果不匹配，可能就会出现上面这种情况。
那如何配置多个DHCP地址池呢？
上面这种模型明显不太合理，所以这个时候一般会将地址池配置到三层交换机上，为每个VLAN配置单独的DHCP地址池，像下面这样：
# vlan 10 # vlan 20 # vlan 30 # vlan 40 # dhcp server ip-pool h4c10 gateway-list 10.1.10.254 network 10.1.10.0 mask 255.255.255.0 # dhcp server ip-pool h4c20 gateway-list 10.1.20.254 network 10.1.20.0 mask 255.255.255.0 # dhcp server ip-pool h4c30 gateway-list 10.1.30.254 network 10.1.30.0 mask 255.255.255.0 # dhcp server ip-pool h4c40 gateway-list 10.1.40.254 network 10.0.0.0 mask 255.0.0.0 # interface Vlan-interface10 ip address 10.1.10.254 255.255.255.0 # interface Vlan-interface20 ip address 10.1.20.254 255.255.255.0 # interface Vlan-interface30 ip address 10.1.30.254 255.255.255.0 # interface Vlan-interface40 ip address 10.1.40.254 255.255.255.0
这样，配合VLAN终结就可以实现不同VLAN获取不同的地址段了，这也是目前用的比较多的方案。
当然，还有一种情况，那就是有单独的DHCP服务器的情况，此时一般结合DHCP中继来使用（DHCP 中继代理信息选项）。DHCP中继用于DHCP客户端和DHCP服务器处于不同物理网段的情况，客户端可以通过DHCP中继与DHCP服务器通信，获取IP地址及其他配置信息。
此时，我们需要在中继设备连接终端的接口下配置DHCP中继，并且保证服务器和中继设备的接口地址可以通信，此时终端就可以获取到IP地址了。中继设备的配置如下：
# dhcp enable # interface GigabitEthernet0/0 port link-mode route combo enable copper ip address 10.1.0.1 255.255.255.0 dhcp select relay dhcp relay server-address 10.1.2.2
终端获取到的地址信息如下：
这里还有时间相关的信息，具体的介绍可以参考协议规范（DHCP：动态主机配置协议详解），其中Allocated lease指租约时长，86400秒指1天，可以通过expired命令进行修改，如设置为6天7小时8分9秒的命令如下：
# dhcp server ip-pool h4c1 expired day 6 hour 7 minute 8 second 9
另外的两个，T1指DHCP客户端的一半左右租约时间（以秒为单位），是个随机值；T2为DHCP客户端的7/8租约时间（以秒为单位），是精确值。
还有一些DHCP option参数（【先码后看】DHCP 扩展选项大全），常用的有Option 43和Option 60子选项，一般用来指定服务提供商的标识子选项，客户端和服务器使用此选项来交换特定于厂商的消息，比如Option 43子选项为供应商指定信息（Vendor-Specific Information，VSI），可以来配置AC的IP地址，当AP收到DHCP Offer报文时，就可以记录AC的IP地址；而option 60子选项为供应商类标识符（Vendor Class Identifier，VCI），可以唯一地标识供应商设备的类型，这个参数一般携带在AP发送的DHCP Discover报文中，用来标识自己的厂商和型号等信息。现在的配置比之前也人性化多了，可以直接使用IP地址了，之前还要手工转换为二进制字符串。
我们查看一下AP发送的DHCP Discover报文：
可以看到，携带的option 60信息为H3C. H3C WA6320-HCL，也就是设备型号，跟在设备命令行看到的一致。
再看一下DHCP服务器响应的DHCP Offer报文：
可以看到此处的值为0a010101，对应点分十进制的10.1.1.1，就是我们配置的AC的IP地址。
如果配置多个IP地址的话，此处的长度就会增加。
DHCP还有一种安全特性，叫做DHCP Snooping，用于保证客户端从合法的服务器获取IP地址，并记录DHCP客户端IP地址与MAC地址的对应关系。一般需要结合信任端口来使用，仅从信任端口正常转发接收到的DHCP报文，而丢弃非信任端口接收到DHCP服务器响应的DHCP-ACK和DHCP-OFFER报文，避免假冒DHCP服务器的影响。
如果我们想开启DHCP Snooping表项功能，一般使用如下配置：
# dhcp snooping enable # interface GigabitEthernet1/0/1 dhcp snooping trust # interface GigabitEthernet1/0/2 dhcp snooping binding record
通过在连接DHCP服务器的接口配置信任端口，在连接客户端的接口启用DHCP Snooping表项功能，来实现记录信息。
当然，这个命令在三层口下不被支持，需要使用交换机验证。
6.7、VLAN基础实验
我们平时所接触到的家用路由器（网络之路3：认识家用路由器），一定程度上也可以称为路由交换一体机。家用路由器一般由1个WAN口，多个LAN口，这些LAN口下联的终端同属于一个网段，如果单独看这些LAN接口的话，一度程度上可以把他们视为一个小的傻瓜二层交换机。
试想这样一个场景，我们将6台终端接入到一个交换机上，交换机不做任何配置，所有终端可以直接通信。
最简单的模型，我们可以将6台设备配置到同一个网段，比如6台设备的互联地址分别配置为10.1.1.1-10.1.1.6，他们是可以直接通信的，这一点无需验证。
再作进一步考虑，如果我们想让上面3台相互通信、让下面3台相互通信，上线的设备彼此不能通信，在没有VLAN的情况下，我们可以将6台主机分别配置到两个网段，比如10.1.1.0/24和10.1.2.0/24。
现在，我们在RT3上测试一下终端间是否可以互访。
可以看到，同网段之间可以互访，不同网段之间不能互访。注意看，我这里没有测试RT3和RT6之间的联通性，那我在RT6的接口上抓包能看到报文吗？
可以看到，虽然RT6未参与任何通信，但是他的网卡一直在接收数据，而报文类型大部分都是广播类型的报文，而且还夹杂着不是本网段的业务流量，RT6根本不关心这些业务。
我抓取了6分钟的流量，一共捕获了57KB的报文流量，因为没有业务相关的操作，对RT6而言，都可以理解为是垃圾流量，这些流量换算下来，大概是1.3 kbps的流量，如果网络规模足够大，比如有60000台设备都接在一台巨大的交换机上，那单台设备接口收到的垃圾流量将高达13 Mbps。
然后我们在交换机上配置DHCP，为6台设备分配IP地址，但是我们地址池内仅设置2个可用地址，地址租期设置为5秒，我们再看一下。
# interface Vlan-interface1 ip address 10.1.1.1 255.255.255.0 # dhcp server ip-pool h4c network 10.1.1.0 mask 255.255.255.0 address range 10.1.1.2 10.1.1.3 expired day 0 hour 0 minute 0 second 5
接下来，我们将6台终端的地址都修改为通过DHCP自动获取，同时开启抓包。
很快，2个地址就分配完成了。
然后我们查看抓包情况，发现网络里都是DHCP报文信息。
这次，在不到3分钟的时间里，我们捕获了2440个报文，总大小为239 KB，这些流量换算下来，大概是11 kbps的流量，还是假设60000台设备都接在一台巨大的交换机上的情况，在没有业务收发的情况下，单台设备接口收到的垃圾流量将高达110 Mbps。
在实际使用中，还有一种环路的情况，大概像上图这样，多台设备首尾相连，此时广播报文就会在几台设备之间不断传播，在传播的同时又在生成新的报文。如果以前面的流量模型计算，在这种网络中，过不了多久，网络里的流量就达到设备的性能瓶颈了，出现性能显著下降，甚至网络不可用等问题，影响正常业务报文的转发；这种情况，我们一般称之为“广播风暴”。
为了提高网络和设备利用率，我们可以把一个物理LAN划分成多个逻辑LAN——VLAN（Virtual Local Area Network，虚拟局域网）。这样，我们就将局域网中的一个冲突域（广播域）划分成了多个冲突域（广播域），有效减少了广播报文等垃圾流量无限制转发、冲突严重等问题。使用VLAN之后，处于同一VLAN的主机能直接互通，而处于不同VLAN的主机则不能直接互通；广播报文被限制在同一个VLAN内，即每个VLAN是一个广播域。
比如我们将这6个终端分别划分到VLAN10和VLAN20两个VLAN。
配置方式有两种，一种是在接口下配置VLAN。
# vlan 10 # interface GigabitEthernet1/0/1 port access vlan 10
另一种是在VLAN下配置接口。
[SW]vlan 20 [SW-vlan20]port GigabitEthernet 1/0/2 [SW-vlan20]dis vlan 20 VLAN ID: 20 VLAN type: Static Route interface: Not configured Description: VLAN 0020 Name: VLAN 0020 Tagged ports: None Untagged ports: GigabitEthernet1/0/2
最终的配置都是显示在接口下面的。
# vlan 10 # vlan 20 # interface GigabitEthernet1/0/1 port access vlan 10 # interface GigabitEthernet1/0/2 port access vlan 20 # interface GigabitEthernet1/0/3 port access vlan 10 # interface GigabitEthernet1/0/4 port access vlan 20 # interface GigabitEthernet1/0/5 port access vlan 10 # interface GigabitEthernet1/0/6 port access vlan 20
然后我们为编号为奇数的终端和编号为偶数的终端配置相同的IP地址，然后测试访问情况。
首先是RT1访问RT3和RT5。
然后是RT2访问RT4和RT6。
可以看到，虽然6台终端的IP地址两两重叠，但是彼此的通信互不影响。
我们看一下VLAN的相关信息。
观察输出的信息，我们发现几个地方：
1、VLAN ID就是我们手工创建的VLAN，当没有额外操作时，设备上仅存在VLAN 1，所有接口都在VLAN 1下面，像下面这样：
2、VLAN type为Static，即静态VLAN，与之对应的还有动态VLAN，一般和接入认证配合使用，等后面遇到了再进行介绍；
3、Route interface为未配置状态，指的是是否存在VLAN虚接口，用于终结本VLAN内需要二层流量。只要创建了vlan-interface就会显示为已配置状态，而不会关心是否配置了IP地址。
4、Description描述字段默认显示的VLAN+VLAN编号，正常配置中是看不到的，如果我们有需求，可以进行更改。
5、Name处为VLAN的名称，和Description一样，默认显示的也是VLAN+编号，如果我们有需求，可以进行更改，这个名称是在brief概要信息中可以展示的。
6、Tagged ports和Untagged ports是指在对应的接口收发报文时是否需要携带Tag标记，这是因为，在默认情况下，VLAN标识仅在本地有效；如果要将VLAN传递到其他设备上，则需要在转发报文时为报文携带Tag标记，也就是VLAN编号。
根据端口在转发报文时对VLAN Tag的不同处理方式，可将端口的链路类型分为Access、Trunk和Hybrid三种：
1、Access：端口只能发送一个VLAN的报文，发出去的报文不带VLAN Tag。一般用于和不能识别VLAN Tag的用户终端设备相连，或者不需要区分不同VLAN成员时使用。Access端口的缺省VLAN就是它所在的VLAN。
2、Trunk：端口能发送多个VLAN的报文，且能够配置端口缺省VLAN，除匹配端口缺省VLAN的报文不带VLAN Tag之外，其他VLAN的报文都必须带VLAN Tag。通常用于网络传输设备之间的互连。
3、Hybrid：端口能发送多个VLAN的报文，也能够配置端口缺省VLAN，端口发出去的报文可根据需要配置某些VLAN的报文带VLAN Tag，某些VLAN的报文不带VLAN Tag。
用最简单的组网拓扑来看一下，两台交换机设备直连，通过VLAN20进行通信，我们配置互联接口为Trunk链路类型，默认VLAN使用VLAN10，SW1的配置如下：
# vlan 1 # vlan 10 # vlan 20 # interface Vlan-interface20 ip address 20.1.1.1 255.255.255.0 # interface GigabitEthernet1/0/1 port link-type trunk port trunk permit vlan 1 10 20 port trunk pvid vlan 10
SW2只有VLAN虚接口的IP地址有差异：
# vlan 1 # vlan 10 # vlan 20 # interface Vlan-interface20 ip address 20.1.1.2 255.255.255.0 # interface GigabitEthernet1/0/1 port link-type trunk port trunk permit vlan 1 10 20 port trunk pvid vlan 10
然后我们查看VLAN信息：
可以看到，同一接口对不同VLAN的打标签策略是不一样的，而且在接口配置了路由接口之后，还可以显示IP地址和掩码信息。
最后，我们抓包看一下报文。
观察报文中的802.1Q封装，我们可以看到前3位为Priority，用来表示报文的802.1p优先级，和QoS相关；第4位为DEI，也被称为CFI，用来表示MAC地址在不同的传输介质中是否以标准格式进行封装，在以太网中，取值均为0；后面12位为VLAN ID，用来表示该报文所属VLAN的编号，对应0-4095共4096个VLAN，由于0和4095为协议保留取值，所以VLAN ID的取值范围为1～4094。此处携带的VLAN ID为20。
