13-自动配置
本章节下载: 13-自动配置 (231.02 KB)
目 录
自动配置功能是指没有配置文件的设备在启动时自动获取并执行配置文件。
自动配置的典型组网环境如图1-1所示。设备需要在DHCP服务器、HTTP服务器、TFTP服务器和DNS服务器的配合下,实现自动配置:
· DHCP服务器:用来为执行自动配置的设备分配IP地址、配置文件名或远程启动文件的HTTP形式的URL、TFTP服务器参数和DNS服务器IP地址等信息。DHCP服务器的详细介绍,请参见“三层技术-IP业务配置指导”中的“DHCP服务器”。
· HTTP服务器:用来为执行自动配置的设备分配需要的文件,如设备的配置文件信息。
· TFTP服务器:用来保存自动配置过程中设备需要的文件,如保存主机IP地址和主机名映射关系的主机名文件和设备的配置文件等。TFTP服务器的详细介绍,请参见“基础配置指导”中的“TFTP”。配置文件和主机名文件的详细介绍,请参见“1.2.2 2. 获取配置文件”。
· DNS服务器:用来提供IP地址和主机名的对应关系。执行自动配置的设备可以通过DNS服务器将自己的IP地址解析为主机名,以便从TFTP服务器获取名为“主机名.cfg”的配置文件;如果设备从DHCP应答报文中获取到TFTP服务器的域名,设备还可以通过DNS服务器将TFTP服务器的域名解析为TFTP服务器的IP地址。DNS服务器的详细介绍,请参见“三层技术-IP业务配置指导”中的“域名解析”。
如果HTTP服务器、DHCP服务器、TFTP服务器和DNS服务器与执行自动配置的设备不在同一个网段,自动配置的设备需要增加网关,并且网关得配置DHCP中继功能,并配置路由协议,使得各个服务器和设备之间路由可达。
以广播方式向TFTP服务器发送请求消息时,由于广播报文只能在本网段内传播,如果执行自动配置的设备与TFTP服务器不在同一个网段,则需要在网关设备上配置UDP Helper功能,将广播报文转换为单播报文,转发给指定的TFTP服务器。有关UDP Helper功能的详细介绍,请参见“三层技术-IP业务配置指导”中的“UDP Helper”。
· 用户可以在TFTP服务器或HTTP服务器上创建配置文件,定义配置文件名时,为方便辨识文件名,尽量不要使用带空格的配置文件名。
· 自动配置支持的配置文件包括文件和Python脚本两种形式。通过Python脚本可以实现自动更新版本、下发配置等功能。关于Python脚本的详细介绍,请参见“基础配置指导”中的“Python”。
(1) 设备在空配置启动时,系统按照如下规则选取符合条件的接口:
a. 若有处于链路状态UP的管理以太网接口,则优先选取管理以太网接口;
b. 若没有处于链路状态UP的管理以太网接口,有处于链路状态UP的二层以太网接口,则选取默认VLAN对应的VLAN虚接口;
c. 若没有处于链路状态UP的二层以太网接口,则按照接口类型字典序、接口编号从小到大的顺序依次选择处于链路状态UP的三层以太网接口。
(2) 系统获取到符合条件的第一个接口后,系统配置该接口通过DHCP方式获取如下信息:配置文件名、TFTP服务器域名、TFTP服务器IP地址和DNS服务器地址等信息。
(3) 设备成功地从DHCP服务器获取到该接口的IP地址及后续获取配置文件所需要的信息后,根据信息内容选择获取配置文件的形式:
¡ 如果从DHCP服务器获取的信息中,包括配置文件名为合法的HTTP形式的URL,自动配置会选择HTTP方式下载配置文件。
¡ 如果从DHCP服务器获取的信息中,包括与TFTP下载相关的信息,自动配置会根据上述信息获取配置文件名,并从TFTP服务器下载该配置文件。
(4) 如果下载配置文件成功,执行配置文件,自动配置过程结束;否则按照步骤(1)的规则开始获取下一个符合条件的接口,重复步骤(2)和(3)。
(5) 当获取配置文件失败时,设备会不断重复自动配置过程,直到成功获取配置文件为止。如果获取配置文件失败,则在30秒后开始下次自动配置过程,或用户通过<CTRL+D>手工终止自动配置操作。
(6) 成功获得配置文件后,执行获取到的配置文件。在自动配置过程中,不论通过当前接口下载配置文件成功与否,自动配置都会恢复该接口的缺省配置。
(7) 如果执行配置文件成功,则整个自动配置流程结束;如果执行配置文件失败,设备会在30秒后开始执行下次自动配置流程,或用户通过<CTRL+D>手工终止自动配置操作。
· 如需使用自动配置功能,建议在设备开启前,只将自动配置时需要使用的接口连入网络,以便加快自动配置速度。
· 自动配置执行成功获取到配置文件后,如果配置文件中某些配置和获取该配置文件的接口当前配置有冲突,则配置文件中的配置可能下发失败。例如配置文件中包含设备某接口的IP地址和获取该配置文件的接口IP地址是同一网段时,该接口的IP地址配置会下发失败。请用户尽量避免在准备配置文件时添加与接口当前配置冲突的内容。
· 通过自动配置获取到的配置文件执行完成后,该文件将被删除,不会在设备上保存。建议配置文件执行完成后,在设备上通过save命令保存配置,否则,设备重启后还需重新执行自动配置功能。save命令的详细介绍请参见“基础配置命令参考”中的“配置文件管理”。
· 通过自动配置功能获取到的配置文件,不支持下发端口一分四的配置,必须先将获取到的配置文件设置为下次主用启动配置文件,然后重启设备才能使该配置重新生效。
DHCP请求报文除获取IP地址以外,报文中的Option 55选项指明设备需要从DHCP服务器获得哪些信息(如配置文件名或远程启动文件的HTTP形式的URL、TFTP服务器域名、TFTP服务器IP地址和DNS服务器IP地址等信息)。
通过DHCP成功获取到IP地址后,设备将解析DHCP服务器应答报文中的如下字段:
· Option 67或file字段:用来获取配置文件名或远程启动文件的HTTP形式的URL。设备首先解析Option 67,如果该选项包括配置文件名或远程启动文件的HTTP形式的URL,则不再解析file字段;否则,继续解析file字段。
· Option 66:用来获取TFTP服务器域名。
· Option 150:用来获取TFTP服务器IP地址。
· Option 6:用来获取DNS服务器IP地址。
DHCP的详细工作过程请参见“三层技术-IP业务配置指导”中的“DHCP概述”。
用户可以根据自动配置功能的需要,在DHCP服务器上选择相应类型的地址管理方式:
· 不同设备的配置文件都相同时,可以在DHCP服务器上配置动态选择IP地址的方式,通过地址池为设备动态分配IP地址的同时,还为这些设备分配一样的网络配置参数(如配置文件名)。如果采用这种方式,则配置文件中只能包含这些设备共有的配置,每个设备特有的配置还需要采用其他方式完成。例如,通过自动配置获取的配置文件中指定在所有设备上开启Telnet服务,并创建本地用户,以便管理员通过Telnet方式登录这些设备,完成对每个设备特有的配置(如配置各个接口的IP地址)。
· 每个设备的配置文件都不相同时,需要在DHCP服务器上配置静态绑定IP地址的方式,以保证为特定的客户端分配固定的IP地址和其他网络配置参数。通过这种方式可以为每个设备指定不同的配置文件,实现对设备的完全配置,无需再通过其他方式配置设备。
设备作为DHCP客户端时,采用客户端ID作为标识,在DHCP服务器上配置静态绑定IP地址时,需要指定静态绑定的客户端ID。客户端ID的获取方法为:启动执行自动配置的设备,使执行自动配置的接口通过DHCP获取IP地址,IP地址获取成功后,在DHCP服务器上通过display dhcp server ip-in-use命令显示地址绑定信息,从中可以获取设备的客户端ID。
设备根据对DHCP应答报文中TFTP服务器域名和TFTP服务器IP地址信息的解析结果,选择TFTP请求消息的发送方式:
(1) 如果应答报文中包括TFTP服务器IP地址信息,且IP地址值合法,设备将以单播方式向TFTP服务器发送请求消息,并不再解析TFTP服务器的域名信息。否则,继续解析应答报文中的TFTP服务器域名信息。
(2) 如果应答报文中包括TFTP服务器的域名信息,且域名合法,则通过DNS服务器解析TFTP服务器的IP地址。IP地址解析成功后,以单播方式向TFTP服务器发送请求消息。如果IP地址解析不成功,则以广播方式向TFTP服务器发送请求消息。
(3) 如果应答报文中不包括TFTP服务器IP地址和域名信息,或TFTP服务器IP地址和域名信息不合法,设备将以广播方式向TFTP服务器发送请求消息。
以广播方式向TFTP服务器发送请求消息时,设备只会从第一个响应的TFTP服务器获取配置文件。
包含指定设备启动的配置信息,保存在TFTP服务器上,由DHCP应答报文中Option 67或file字段指定 如果配置文件是python脚本形式,那么配置文件内容中不能含有fips mode enable命令,否则设备将不能成功完成自动配置 |
|
保存IP地址与主机名称的映射关系,文件由管理员设定,上传到TFTP服务器 |
|
缺省配置文件包含一般设备启动的公用配置信息,保存在TFTP服务器上 如果缺省配置文件是python脚本形式,那么配置文件内容中不能含有fips mode enable命令,否则设备将不能成功完成自动配置 |
如图1-3所示,设备根据对DHCP应答报文中配置文件名信息的解析结果,确定从TFTP服务器上获取哪个配置文件:
(1) 如果应答报文中包括配置文件名信息,则向TFTP服务器请求指定的配置文件。
(2) 如果应答报文中不包括配置文件名信息,则需要先获得设备的主机名,再向TFTP服务器请求与主机名对应的配置文件。设备通过如下几种方式获得主机名:
¡ 从TFTP服务器上获取主机名文件,在主机名文件中查找设备的IP地址对应的主机名;
¡ 如果在主机名文件中没有找到设备的主机名,则以单播方式向DNS服务器发送请求消息,以获取设备IP地址对应的主机名,如果单播方式失败,则以广播方式查询。
(3) 如果上述过程失败,则向TFTP服务器请求缺省配置文件。
如果DHCP服务器应答报文中包含的配置文件名为合法的HTTP形式的URL,那么客户端会以HTTP方式下载配置文件。客户端根据DHCP应答报文中HTTP形式的URL信息,向其指定的HTTP服务器请求配置文件。
如果配置文件是python脚本形式,那么配置文件内容中不能含有fips mode enable命令,否则设备将不能成功完成自动配置。
IRF零配置是指设备启动时从指定的存储介质自动获取并执行建立IRF相关配置的过程。本案例要通过设备从HTTP服务器上自动获取并执行Python脚本来实现多台设备之间自动组成IRF的操作。
如图1-4所示,Switch A和Switch B通过管理以太网口分别与HTTP 服务器和Router A相连。Router A上开启DHCP服务。为网络中的设备动态分配192.168.1.0/24网段的IP地址。
现要求通过自动配置实现Switch A和Switch B通过DHCP服务器下发的HTTP服务器地址,到HTTP服务器上下载Python脚本,根据脚本自动执行IRF配置的相关命令。然后再连接Switch A和Switch B之间的线缆,完成IRF的建立。
在进行自动配置之前请用户准备如下文件:
(1) Python脚本:Python脚本是设备进行IRF零配置操作的主要文件,需要用户自行准备并保存在HTTP服务器上。脚本的编写可以根据具体需求进行调整,关于Python的详细介绍请参见“基础配置指导”中的“Python配置”。Python脚本需要完成以下操作:
· 设备判断flash是否存在足够的存储空间(可选)
· 设备从HTTP服务器下载配置文件
· 设备从HTTP服务器下载启动软件包(可选)
· 设备从HTTP服务器下载sn.txt文件
· 配置设备的启动软件包(可选)
· 解析sn.txt文件并修改设备的IRF成员编号
· 配置设备下次启动时使用的配置文件
· 设备重新启动
(2) 配置文件:配置文件包含了所有设备进行IRF堆叠的相关命令,用户可以在已经成功创建IRF的设备上,将配置文件导出并修改然后保存在HTTP服务器上,供需要创建类似拓扑IRF的设备下载使用。关于IRF配置的详细信息请参见“IRF配置指导”中的“IRF配置”。
配置文件内容中不能含有fips mode enable命令,否则设备将不能成功完成自动配置。
(3) sn.txt文件:每个设备都有唯一的设备序列号,sn.txt文件根据设备的序列号来指定设备在IRF组中的成员编码。设备通过运行Python脚本来解析sn.txt文件,然后修改设备的IRF成员编号,并根据自身的成员编号来完成相应的IRF配置。
(4) 软件启动包:软件启动包是设备启动、运行的必备软件,需保存在HTTP服务器上。如果现有设备(包括主用主控板和备用主控板)的启动软件包全部一致且不需要升级软件版本,可不需要准备该文件。
(5) 确保设备进入自动配置的条件:如果设备首次使用,当设备上电后会进入自动配置流程;如果设备不是首次使用,请执行undo startup saved-configuration命令设置设备以出厂配置启动并重启设备。
(1) 如图1-4所示,利用线缆完成Switch A和Switch B分别与HTTP 服务器和Router A的连接。
(2) 配置DHCP服务器
# 启动DHCP服务,创建名称为1的DHCP地址池,配置地址池动态分配IP地址的网段为192.168.1.0/24。
<RouterA> system-view
[RouterA] dhcp enable
[RouterA] dhcp server ip-pool 1
[RouterA-dhcp-pool-1] network 192.168.1.0 24
# 配置DHCP客户端远程启动文件为HTTP形式的URL。
[RouterA-dhcp-pool-1] bootfile-name http://192.168.1.40/device.py
(3) 配置HTTP服务器,保证Switch A和Switch B可以从HTTP服务器成功下载Python脚本device.py。
(4) 进入自动配置流程,设备下载并执行Python脚本,完成来多台设备之间自动组成IRF的操作。
(5) 连接Switch A和Switch B之间的线缆,连接好线缆以后设备进行IRF选举,选举失败的一台设备会自动重启。设备自动重启后,Switch A和Switch B成功组成IRF。
下面以Switch A为例验证设备是否成功组成IRF,Switch B和Switch A类似,不再赘述。
# 显示IRF中所有成员设备的相关信息。
<Switch A>display irf
MemberID Slot Role Priority CPU-Mac Description
1 1 Standby 1 00e0-fc0f-8c02 ---
*+2 1 Master 30 00e0-fc0f-8c14 ---
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.
The Bridge MAC of the IRF is: 000c-1000-1111
Auto upgrade : yes
Mac persistent : always
Domain ID : 0
Auto merge : yes
以上显示信息表明IRF已经成功建立。
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!