Config Cisco IOS Port forwarding(静态端口映射)

NAT overload(PAT)在进行地址转换时会为转换后的IP包随机分配一个端口,这也就造成了地址转换后IP数据包中源端口的不确定性了,配置PortForwarding(静态端口映射)可以弥补这一缺陷。更多关于PortForwarding的知识可以在Google上找到,或者在本站的文章:“DD-WRT PortForwarding配置及其作用”一文中了解到。
这项特性在绝大多数具有NAT功能的路由器上都可以配置,在cisco IOS上可以很简单地完成端口映射的配置,以我遇到的情况为例:
一个公司使用一台2621xm路由器作为网关通过ADSL上网,并在网关上启用PAT,但内网有一个监控摄像头需要被外网访问,并且需要通过特定的端口实现。所以这里有必要为监控摄像头所监听的端口进行静态的端口映射。先给出重点配置:
interface FastEthernet0/0
description LAN
ip address 192.168.1.1 255.255.255.0
ip access-group upload_flow in
ip nat inside

interface FastEthernet0/1
description WAN
no ip address
pppoe enable group global
pppoe-client dial-pool-number 1
no cdp enable
interface Dialer0
ip address negotiated
ip mtu 1492
ip nat outside
encapsulation ppp
ip tcp adjust-mss 1452
dialer pool 1
dialer-group 1
no snmp trap link-status
ppp pap sent-username xxxxx  password 0 xxxxxx
ip route 0.0.0.0 0.0.0.0 Dialer0
ip nat [...]

MPLS introducing Part.2

这些天一直在忙着准备面试,没能抽空出来更新一下,还好,笔试通过了,下星期一还有一次面试,希望可以通过吧!今天原以为出去的,结果还没出门就下起了大雨,趁有空就写一下MPLS introducing的第二部分吧。
MPLS是怎样工作的?
MPLS在转发数据包时使用了FEC(Forwarding Equivalence Class,转发等价类)这一概念,转发等价类是一组或者一系列沿相同路径转发的,且都按照相同的规则进行交换的数据流,属于同一个FEC的所有报文都使用相同的标签,需要注意,并不是所有拥有相同标签的报文都属于同一个FEC。所有运行MPLS的路由器(LSR、LER)为每一个FEC分配标签,并且使用标签分发协议(如LDP ,Label Distribution Protocol)把标签跟FEC的捆绑关系发送给邻居。最终, 某个FEC会在该MPLS区域内形成一条LSP(Label Switched path)。
一个Packet可能起源于MPLS区域的外部,从MPLS区域的边缘路由器进入,也有可能是起源于内部,这里假设Packet起源于外部。当入口路由器收到一个Packet时,它将会根据FIB表和LFIB表决定下一跳、为这个Packet打上一个或者多个的标签(当然可能因为PHP或者其他原因也有可能不打标签,以后再探讨)。打上标签的Packet被发送到下一条路由器(下游)。当下游路由器收到该Packet,它会检查Packet中的顶层标签,然后根据LFIB(Label Forward Information Base)确定对标签实施哪种操作(可能是交换、弹出或者添加标签等)和决定Packet的下一跳。
在经过LSP中的所有LSR之后,数据包最终到达LSP的末端,这时根据PHP机制,一般来说到达MPLS网络边缘的Packet应该不带标签以IP报文的形式发给出口路由器,然后出口路由器对Packet进行常规的IP查找和交换。但根据MPLS应用的不同,Packet到达最后一跳路由器时还可能包含标签(如显式空),这时就不得不为数据包进行两次查找了(题外话)。
下面是一个例子:

1. R1通过IGP通告了前缀10.10.10.0/24,这里假设R1是去往该子网的唯一路径;
2. 一个目的地为10.10.10.1的IP Packet进入R4(LER);
3. R4会查找FIB和LFIB(cisco IOS中只需对CEF进行查找即可),确定下一跳为R3,然后为Packet压入一个由R3为10.10.10.0这一FEC分配的标签L4;
4. R3从R4收到这一Packet查看二层报头,发现这是一个带标签的报文,于是查看LFIB表,将L4的标签交换为由R3分配的标签L3,进而发给R2;
5. 同样地,R2收到Packet并确认其为带标签报文,查找LFIB表,对标签进行操作,这里是典型的例子,R2作为LSP的倒数第二跳,R1为FEC分配了隐式空标签3并传给R2,但R2并不会把这个标签值为3的标签压入报文,而是采取弹出一层标签的行为。而在这个例子中只有一层报文,所以标签被弹出后,就露出了原来的IP报文,这个Packet最终被R2以IP报文的形式发给了R1,这样当R1接收到Packet之后只需进行IP查找就可以确定Packet的去向,这也就是MPLS中的PHP机制。
6. R1从R2收到IP Packet,查看IP头,并转发报文,Packet顺利穿越MPLS网络并到达目的地!
由此可以体现出的好处就是,MPLS区域内的路由器可以设计成由此至终都使用标签作为转发依据,因此区域内的LSR根本不用理会标签以后的内容是什么,这有利于运营商使用MPLS去运载不同的流量。而且标签交换在大多数环境下比IP查找要快,开销要少。
将于近期更新part3,有关MPLS标签的操作。如果对本文有任何疑问或建议,请留言指出,谢谢!
To be continue……

MPLS introducing Part1

MPLS是Multi-protocol Label Switching(多协议标签交换)的缩写,MPLS是一种能够携带任何三层协议(数据)的包转发技术,这也名称中“多协议”一词的由来。当装有层三(或以上数据)的数据包需要穿越部署了MPLS的网络时,处于MPLS网络边缘的路由器会在该数据包的L3头和L2头之间打上标记(label),使这些三层的数据包可以顺利穿越一个部署了MPLS的网络到目的地。
MPLS Label的结构及其作用:
MPLS label是一个固定长度4Byte,被入口路由器添加在L2和L3报头之间,主要用于识别数据包目的地的标识符。这个标识符被那些MPLS网络内部(非边缘)路由器所使用,这些内部路由器只需要根据数据包中这个处于L2.5(2.5层)的标识符就可以知道它的目的地,而不用进行任何的三层路由表查找,这也意味着可以带来一定性能上的提升!

在入口路由器处,一个或多个标签被压(pushed)进了包里面,我们通常称第一个标签为顶层标签或者传输(transport)标签,根据不同MPLS应用(如MPLS VPN),这个顶层标签后可能还有其他标签。
上图是一个完整的标签结构,一共32位,可见除了标签(Label)之外,还有一些其他的字段。这里简单介绍一下这四个字段:

Label:“真正”的标签,20bits的标签值;
EXP:Experimental bits 实验位,3bits,主要用于区分流量,也是在MPLS网络中实施QoS的依据;
S Bit:Botton栈底位,1bit,用于标识当前标签是否为标签栈中的最后一个标签(栈底),值为“1”时表示当前标签为栈底,值为“0”时当前标签后面还有后续标签;
TTL:Time to live生存时间,8bits,跟IP报头中的TTL一样,主要用于防环,MPLS label与label,label与IP之间的TTL行为有详细定义,具体可参考相关文档;

MPLS的一些术语:

DownStream router:下游路由器,该路由器是某目的网络前缀的通告者,举个例,从下游路由器(A)收到网络前缀(N)的路由器的路由器(B)将以A作为该目的网络N的下一跳路由器,而这个前缀的接受者B向网络N发送数据时,数据流必须发送到A,因此我们称之为下游路由器,由此也可以看出,“下游”这一概念是相对于去往某特定网络前缀的数据流和路由器而言的。一路由器作为某网络前缀的下游路由器,但同时它也可能是另一网络前缀的上游路由器。
UpStream router:上游路由器,正如上面所说的,上游路由器是某网络前缀的被通告者(接收者),通俗一点,“下游”和“上游”的意思就是某网络前缀的“通告方”和“被通告方”。

我们可以通过路由信息的方向和数据流的方向对上游和下游进行区分,路由信息是从下游路由器传给上游路由器的,而针对某特定前缀的数据流是从上游路由器流向下游路由器的。关于这两个概念很多都容易搞混了,所以我就花一些周章说明一下。

Label Edge Router(LER):边缘路由器,处于MPLS网络的边缘,一般地,他们根据IP报头作出转发决定;
Label Switch Router(LSR):标签交换路由器,处于MPLS网络的内部的路由器根据标签作出转发决策。

本文参考:What is MPLS,在结合自己的见解后在内容上稍作扩张和修改,如有错漏之处敬请提出
未完,待续。

MPLS-VPN基本配置实验

在我上一个实验“MPLS基础实验”中,在PE上不建立VRF的时候,要保证两个CE路由器可以互相学习到对方路由,不可避免地需要在CE和PE上运行路由协议,而且在没有BGP的协助下,这些路由必须要被重分布或者其他的方法进入Backbone区域,让Backbone区域帮忙传递路由信息,而这又可能会导致Backbone区域路由外泄和学习到了客户路由,这显然会带来包括路由条目过多、地址重叠等一连串问题。所以,分隔客户路由和Backbone路由时非常必要的,VRF应运而生,它可以有效分隔客户跟运营商路由,而Backbone区域并不需要知道这些路由,因为P路由器只需要运行MPLS就可以了,PE路由器会区分这些可会路由,在转发数据的时候为不同的路由打上不同的标签,所以P路由器只需要专注于标签转发就可以了。
如何使这些路由在Backbone区域不知道的情况下去传递呢?这就需要在PE路由器之间建立MP-BGP了,PE路由器将使用MP-BGP来传递客户的VPN路由,并且在这个过程中为他们分配和传递VPN标签。下面我们来做一下这个实验。
拓扑如图所示:在MPLS的基础上,PE与CE间运行了OSPF协议,两个PE路由器 R2、R4间运行了MP-BGP协议。为了不让客户路由跑进运营商内部,R4将建立VRF表达到客户路由和互联网路由隔离的目的。而分隔于运营商两端的客户路由将通过MP-BGP进行传递,期间需要对BGP和OSPF进行双向重分发。
实验步骤:
1. 先为各路由器接口配置好地址,保证底层的连通性,并配置好MPLS OSPF Backbone区域,(MPLS配置方法请参考以前的文章:MPLS基础实验);
2. 在PE路由器R2、R4上激活BGP进程,使两者建立iBGP邻居关系;
3. 在PE路由器R2、R4上全局建立VRF cisco;
4. 在PE路由器R2、R4上的BGP进程中激活VPNV4邻居,并且对邻居发送扩展community属性;
5. 在PE路由器R2、R4上与CE路由器相连的接口与vpn cisco关联起来(可能需要重新配置该接口IP地址);
6. 在PE路由器R2、R4上启动OSPF XX vrf cisco进程,将关联该VRF的接口宣告;
7. 在CE路由器R1、R5上启动ospf进程,将包括loopback口的所有直连接口宣告;
8. 在PE路由器R2上将ospf vrf cisco里的路由重发布到BGP中,并且在R4上观察BGP VPNV4路由的变化;
9. 在PE路由器R4上将BGP进程重分布到OSPF进程中,在R5上观察ospf路由的学习情况;
10. 在PE路由器R4上将ospf vrf cisco里的路由重发布到BGP中,并且在R2上观察BGP VPNV4路由的变化;
11. 在PE路由器R2上将BGP进程重发布到OSPF进程中,在R1上观察ospf路由的学习情况;
12. 检查R1上去往R5的所有路由可达性;
13. 检查运营商骨干路由器中是否获悉到客户路由(正常情况下没有),检查运营商内部路由是否泄漏到客户路由表中;