这样大家都学到了彼此的路由了,看看能不能通。
下面写一个小脚本测试一下网络。
CE2-A(tcl)#foreach address {
+>172.16.10.1
+>172.16.20.1
+>172.16.30.1
+>} {
+>ping $address source loopback 0
+>}
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.20.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/58/108 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.20.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.30.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.20.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/76/96 ms
都通了。
下面trace一下数据包的路径。
CE2-A#traceroute
Protocol [ip]:
Target IP address: 172.16.30.1
Source address: 172.16.20.1
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]: 10
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 172.16.30.1
1 25.1.1.5 56 msec 68 msec 12 msec
2 41.1.1.4 [MPLS: Label 403 Exp 0] 28 msec 48 msec 28 msec
3 41.1.1.1 88 msec 16 msec 52 msec
4 14.1.1.4 44 msec 76 msec 72 msec
5 36.1.1.6 [MPLS: Label 604 Exp 0] 52 msec 64 msec 72 msec
6 36.1.1.3 92 msec * 36 msec
分析上面的输出。CE2-A的ping包到达PE2-AS1后,进入VRF ×××-A路由表,到达172.16.30.0的下一跳是4.4.4.4.打上***v4标
签403,因为ldp下一跳是直连,因此pop tag发送。
PE2-AS1#sh ip bgp ***v4 vrf ×××-A 172.16.30.0 255.255.255.0
BGP routing table entry for 1:5:172.16.30.0/24, version 33
Paths: (1 available, best #1, table ×××-A)
Advertised to update-groups:
2
65123 1 1, imported path from 1:456:172.16.30.0/24
4.4.4.4 (metric 10) from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:456
mpls labels in/out nolabel/403
到达PE1-AS1后的动作是关键。
从traceroute的输出可以很清楚看见,PE1-AS1将数据包包给了CE1-A,然后CE1-A又传给了PE1-AS1。也就是说数据包在HUB绕了一圈才去往目的地。
这就达到了hub-spoke拓扑的目的,hub端实现流量的监控,安全审计等需求。
需要注意的一点就是绕圈的路径:从FROM-HUB到CE1-A,然后再通过FROM-SPOKE到达PE1-AS1。
因为PE2-AS1是通过FROM-HUB的路由学习到的,FROM-HUB的路由又是从FROM-SPOKE学习到的,FROM-SPOKE的路由又是从各个
SPOKE端学习到的。从PE1-AS1和CE1-A的bgp表上可以看出这个顺序关系。
PE1-AS1#show ip bgp ***v4 all
BGP table version is 41, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:4 (default for vrf FROM-SPOKE)
*> 172.16.10.0/24 14.1.1.1 0 0 65123 i
*>i172.16.20.0/24 5.5.5.5 0 100 0 65123 i
*>i172.16.30.0/24 6.6.6.6 0 100 0 65123 i
Route Distinguisher: 1:5
*>i172.16.20.0/24 5.5.5.5 0 100 0 65123 i
Route Distinguisher: 1:6
*>i172.16.30.0/24 6.6.6.6 0 100 0 65123 i
Route Distinguisher: 1:456 (default for vrf FROM-HUB)
*> 172.16.10.0/24 41.1.1.1 0 0 65123 i
*> 172.16.20.0/24 41.1.1.1 0 65123 1 1 i
*> 172.16.30.0/24 41.1.1.1 0 65123 1 1 i
RD 1:456学习到的路由的下一跳都为41.1.1.1,即指向CE1-A。
下面是CE1-A的路由。
CE1-A#show ip bgp
BGP table version is 8, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 172.16.10.0/24 0.0.0.0 0 32768 i
*> 172.16.20.0/24 14.1.1.4 0 1 1 i
*> 172.16.30.0/24 14.1.1.4 0 1 1 i
下一跳指向的是14.1.1.4,即PE1-AS1。呵呵,看起来好像是环路了,但是不是这样,他们是两个VRF,要搞清楚了。
这个实验到这里基本就差不多了。通过这个实验,对hub-spoke有了深入一层的认识。根据路由的走向,我前面配置的路由反射器其实是多余,可以省略掉,对本实验没有任何影响。但是配上也没有坏处,在实际环境下,如果总部自身的路由(在本例中是172.16.10.0)具有一定的数量级,那么RR还是有必要的。RR不光是解决了内部路由传递的限制,因为他的路由复制传播,能够大大的降低CPU负载。所以这里用了也无妨。
另外一个问题就是FROM-SPOKE的RD。我以前都是要设置的,看了cisco的文档后没有配,结果排错怎么也排不出来,客户端都学习到了路由,就是通不了。MPLS在这里是很简单的,基本都是pop tag,越简单反而越难找出错,这个时候就比较考验人了,关键时刻就能看出自己学的扎实不扎实,不扎实的话到处瞎忙乎,招招不致命。
模拟器也确实除了些莫名其妙的问题,我原来是这么想的。其实后来才知道不是这样,IOS不会情绪化,他不会骗人。更改VRF的设置不是马上就能生效的,而且这个时间还不短,你怎么清配置清路由都没用,我也是无意中发现了这一点。这样导致的结果就是,配置对了,但是路由还没通。唉,能不迷糊嘛!
这个实验最让我不能忘怀的就是RD,一定要配!不配的去hub端show run看看BGP的配置是什么样的就发现问题了。
查了些资料,hub-spoke拓扑在某些情况下并不是最优的选择,但是从技术的实施和复杂度等方面考虑,最终还是选择了这种拓扑。
另外,hub-spoke拓扑有一个很严重的问题,一旦hub端的设备当掉,分部间的通信也将中断。由此而引出的方法是在hub端作冗余,尚待研究。
好,到此结束,了却一桩心事。
转载于:https://blog.51cto.com/edges/423014