No.001 Simple Case

 Nov 7th 21  PNETLab 17 minutes read (About 2613 words)
This is an article that was created 1047 days ago, and the information may have evolved or changed.

上文提到要 po 一篇文，现在发表一下自己的思路和配置。原文:【有点儿意思系列 06】一个看起来简单的案例，再上图。

Request and Solution

  1. PC1、PC2 分属 VLAN10 和 VLAN20；DHCP 服务器属 VLAN30 ，PC1 和 PC2 从 DHCP 服务器自动获取地址。

    S：根据上下文需求，确定 R3 和 R4 是热备组网。R3 和 R4 上配置子接口，配置 VRRP ；业务地址段和 DHCPServer 不在同一网段，所以需要在业务网段的网关上配置 DHCP 中继。实验中使用一台路由器模拟 DHCPServer，上面配置分配给 VLAN10,VLAN20 的地址池。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    ! --- DHCPServer 配置
    !
    ip dhcp excluded-address 10.1.10.252 10.1.10.254
    ip dhcp excluded-address 10.1.20.252 10.1.20.254
    !
    ip dhcp pool vlan10
     network 10.1.10.0 255.255.255.0
     default-router 10.1.10.254 
    !
    ip dhcp pool vlan20
     network 10.1.20.0 255.255.255.0
     default-router 10.1.20.254 
    !
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    ! --- R3 配置
    !
    interface Ethernet0/1.10
     encapsulation dot1Q 10
     ip address 10.1.10.252 255.255.255.0
     ip helper-address 10.1.30.1
     vrrp 10 ip 10.1.10.254
     vrrp 10 priority 120
     vrrp 10 track 1 decrement 21
    !         
    interface Ethernet0/1.20
     encapsulation dot1Q 20
     ip address 10.1.20.252 255.255.255.0
     ip helper-address 10.1.30.1
     vrrp 20 ip 10.1.20.254
    !         
    interface Ethernet0/1.30
     encapsulation dot1Q 30
     ip address 10.1.30.252 255.255.255.0
     vrrp 30 ip 10.1.30.254
     vrrp 30 priority 120
     vrrp 30 track 1 decrement 21
    ! --- 网管地址网关
    interface Ethernet0/1.99
     encapsulation dot1Q 99
     ip address 20.1.1.252 255.255.255.0
     vrrp 99 ip 20.1.1.254
     vrrp 99 priority 120
     vrrp 99 track 1 decrement 21
    !

  2. SW4 是内网用户接入交换机（仅具二层功能），要求内网两个网段的用户均能 telnet 到该设备。

    S：配置 VLAN ，划分接口，配置 Trunk，配置默认网关和远程网管

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    ! --- SW4 配置
    !
    interface Ethernet0/0
     switchport trunk allowed vlan 10,20,30,99
     switchport trunk encapsulation dot1q
     switchport mode trunk
    !
    interface Ethernet0/1
     switchport trunk allowed vlan 10,20,30,99
     switchport trunk encapsulation dot1q
     switchport mode trunk
    !
    interface Ethernet1/1
     switchport access vlan 10
    !
    interface Ethernet1/2
     switchport access vlan 20
    !
    interface Ethernet1/3
     switchport access vlan 30
    ! --- 网管IP地址
    interface Vlan99
     ip address 20.1.1.10 255.255.255.0
    ! -- 本想使用 ip default-gateway，但是不起作用，下面这条效果是一样
    ip route 0.0.0.0 0.0.0.0 20.1.1.254
    ! --- 网管配置 略
    ……

    由于 VPCS 不支持 Telnet ，此处使用 DHCPServer 做测试。

  1. R3 和 R4 作为内网用户的网关设备，互为热备份。

    S：这一条前面提过了，整个拓扑完整配置后边发，我打个包。

  2. R3、R4、SW2 及 SW3 上不允许出现任何手工配置的静态路由条目。

    S：好的，满足你。

  3. SW1 采用重发布的方式，将直连的服务器网段路由（如10.1.100.0/24）注入 EIGRP。

    S：好的，满足你。

  4. 内网用户（PC1、PC2）访问核心服务器 Server（10.1.100.1）的数据流走向如下：

    PC1 访问 Server：R3 > R1 > SW2 > SW1 > Server；

    PC2 访问 Server：R4 > R2 > SW3 > SW1 > Server；

    沿途任何设备上到达 Server 的路由不允许出现负载均衡，且 PC 访问 Server 的流量往返路径一致。

    S：在配置完路由协议后，查看沿途设备路由表发现到达 Server 的路由出现负载均衡是正常现象，旁观大局，逐个处理就行。

    但是有一个现象我不知是模拟器的 Bug 还是镜像的问题，查看 SW3 和 SW4 ，总有一台设备到达 Server 的路由是这样的：

    1
    D EX     10.1.100.0/24 [170/307200]

    另一台学习到去往 Server 网段的路由是从上面这台学习到的外部路由，重启两台交换机的 OSPF 进程，这条路由又可能显示在第二台了。我又用 GNS3 做了测试，也是这种情况，按理说加载到路由表的不应该是管理距离为 110 的 OSPF 外部路由么？

    我思考了一番，可能是 OSPF 进程启动先后顺序的问题，先启动的交换机 OSPF 进程加载了 EIGRP 外部路由，而后启动的交换机 OSPF 进程学习到 EIGRP 外部路由和 OSPF 外部路由，按照规则选择了管理距离值较小的 OSPF 路由条目。

    PC1 访问 Server：R3 > R1 > SW2 > SW1 > Server；

    1
    2
    3
    4
    5
    ! --- R1 配置，修改 OSPF 入向接口的 cost ，使从 e0/0 收到去往10.1.100.0网段的路由更优
    !
    interface Ethernet0/1
     ip ospf cost 11
    !
    1
    2
    3
    4
    5
    6
    7
    8
    ! --- SW2 配置, 在 OSPF 进程下过滤入方向收到的去往 10.1.100.0 网段的条目，为什么这么做呢，从后面需求看，断掉 SW2/SW3 与 SW1 的线路之一，去往 Server的流量就不需要经过断掉线路这台交换机，而且断掉线路还要流量经过这台设备，走了个直角线路，并不是最优路径
    !
    router ospf 200
     distribute-list 10 in
    !
    access-list 10 deny   10.1.100.0 0.0.0.255
    access-list 10 permit any
    !

    PC2 访问 Server ：R4 > R2 > SW3 > SW1 > Server；

    思路和 PC1 访问 Server 一样，逆推一下即可，不占用篇幅了（懒得码字）

    PC1 访问 Server 回程路径： Server> SW1 > SW2 > R1 >R3 ；

    1
    2
    3
    4
    5
    6
    7
    8
    9
    ! --- SW1 配置，观察到去往内网网段的路由条目是负载均衡，配置偏移列表和指定入向接口，增加希望不要出现在路由表里的条目 metric 偏移，影响路由表加载
    !
    router eigrp 100
     offset-list 20 in 1024 Ethernet0/2 
     offset-list 10 in 1024 Ethernet0/1 
    !
    access-list 10 permit 10.1.20.0 0.0.0.255
    access-list 20 permit 10.1.10.0 0.0.0.255
     !
    1
    2
    3
    4
    5
    ! --- SW2 配置，修改 e0/3 接口 cost，使得从该接口学习到去往 10.1.10.0 和 10.1.20.0 网段的路由不是最优路由
    !
    interface Ethernet0/3
      ip ospf cost 11
    !

    PC2 访问 Server 回程路径： Server> SW1 > SW3 > R2 >R3 ；

    思路和 PC1 访问 Server 回程路径一样，逆推一下即可，不占用篇幅了（懒得码字）

  5. 要求 SW2 和 SW3 访问 Server 都走最优路径，即 SW2 前往 Server 的数据流走 SW1，SW3 前往 Server 的数据流也直接到 SW1。

    S：这一条也佐证了我在上面说到的流量走直角路径不是最优的想法。说的通俗一点就是：SW1 上的有流量要去往 Server 只能从 e0/1 出去，不走直角。即使 SW1 上的出口线路故障了也不走，走的路径是：拓扑上的对角线。退一步来说当 SW2/SW3 的出口线路故障了，下联的 R1/R2 不会从 SW2/SW3 学习到去往 Server 的路由条目。SW2 也是这个道理。

  1. SW1 上关于 10.1.10.0/24 和 10.1.20.0/24 的路由不应该出现等价负载均衡，正常情况下访问 10.0/24 网段的数据流走 SW2，访问2 0.0/24 网段的数据流走 SW3。

    S：在 PC1/PC2 访问 Server 的回程路径时候已经解决这一条，不占用篇幅了（懒得码字）。

  2. 当 SW1-SW2 之间的链路 DOWN 掉时，PC1 访问 Server 的数据流切换至路径： R3>R1>SW3>SW1>Server，且往返路径一致。而当 SW1-SW3 之间的链路 DOWN 掉时，PC2 应该仍然能够访问 Server，情况类似。

    S：正如我前面所说的：当 SW2/SW3 的出口线路故障了，下联的 R1/R2 也不会从 SW2/SW3 学习到去往 Server 的路由条目。此时去往 Server 的流量已经在 R1/R2 通过走对角线的路径来到 SW3/SW2 上。

    重点解决回程的路径。因为前面已经修改了 SW2 和 SW3 上的 e0/3 的 cost ，这就使得当 SW1-SW2 之间的链路 DOWN 掉或者 SW1-SW3 之间的链路 DOWN 掉时，SW3/SW2 去往 10.1.10.0 和 10.1.20.0 网段都是直线往下经过 R2 或者 R1 回程到业务网段，并不符合需求。需要添加策略路由 PBR 实现往返路径一致。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    ! --- SW2 配置，配置匹配去往 10.1.20.0 网段的 ACL，配置 route-map 匹配 ACL ，设置去往10.1.20.0 网段的下一跳地址，配置 SLA 监测，最后在 e0/1 调用
    !
    access-list 101 permit ip any 10.1.20.0 0.0.0.255
    !
    route-map pbr_20.0 permit 10
     match ip address 101
     set ip next-hop verify-availability 10.1.254.105 1 track 1
    !
    ip sla 1
     icmp-echo 10.1.254.105 source-interface Ethernet0/3
     frequency 5
    ! 设置 delay 是为了及时观察现象，实际生产环境不需这么做
     track 1 ip sla 1 reachability
     delay down 5 up 3
    !
    ip sla schedule 1 life forever start-time now
    !
    interface Ethernet0/1
     ip policy route-map pbr_20.0
    !

    当SW1-SW3之间的链路DOWN掉时，PC2应该仍然能够访问Server，情况类似。解决思路和上面一样，懒-码-字。

  3. 当 SW2-R1 之间的链路 DOWN 掉时，PC1 访问 Server 的数据流切换至路径：R3>R1>SW3>SW1>Server，此时不要求流量往返路径完全一致。当 SW3-R2 之间的链路 DOWN 掉时，PC2 应该仍能够访问到 Server。

    S：当 SW2-R1 之间的链路 DOWN 掉时，R1 是能够从 SW3 学习到去往 Server 的路由的，只是回程的时候路径是： Server> SW1 > SW2 > R2 >R4 ，不要求流量往返路径完全一致，本条需求已经自动实现了。当SW3-R2之间的链路DOWN掉时同理。

  4. R3、R4 任意一台路由器与内网交换机直连链路 DOWN 掉，不影响内网 PC 访问外网。

    S：配置的 VRRP 可以实现。

  5. 【可选】若 R3 的出口 DOWN 或 R1 的两条上联链路都 DOWN，以上两种情况，R3 都能检测到，要求此两种情况发生时内网用户访问 SERVER 都不受影响，R4 同理。

    S：R3 的出口 DOWN 或 R1 的两条上联链路都 DOWN，明显要求配置 SLA 特性，我的做法是在 SW3 和 SW2 上配置一个环回地址，R3/R4 检测这个地址的可达性。举例：当 R3 配置了监测 SW3 的环回地址可达性，无论是 R3 的出口 DOWN 或 R1 的两条上联链路都 DOWN 其中一个条件达成，都会导致监测失败不可达，再在相应的内网子接口下配置 Track 联动降低 VRRP 组的优先级，使其成为 Backup 状态，另一台路由器成为 Master ，此时内网用户访问 Server 路径自动切换不受影响（其实还是会掉包的，取决于你配置的监测周期，抢占延时，生成树协议）。R4 同理。

    （11月10日发现，可以使用 Track list 的方式实现）

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    ! --- R3 配置
    interface Ethernet0/1.10
     vrrp 10 track 1 decrement 21
    !
    ip sla 1
     icmp-echo 33.33.33.33 source-interface Ethernet0/0
     frequency 5
    ip sla schedule 1 life forever start-time now
    !
    track 1 ip sla 1 reachability
     delay down 5 up 3
    !

Ending

  • 配置存阿里云盘了，这是链接：[分享的文件]
  • 欢迎“来电”来函探讨。
#Network Emulator #PNETLab #Cisco
No.002 Simple Case PNETLab试用
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×