成都市庆云南街69号红星国际3栋3楼

您现在的位置: IT培训 > CCNP > CCNP常见问答 > 正文

CCNP常见问题汇总

发布时间:2017-12-04 11:52:38

路由相关
Q:Cisco路由器究竟是如何进行等价负载均衡的?
A:负载均衡的方式取决于路由器的交换方式。如果使用进程交换(process switching),路由器进行per-packet负载均衡,即为每一个数据包选择不同的转发路径;如果使用快速交换(fast switching),路由器进行per-destination负载均衡,即为去往同一个目的地的所有数据包选择同一条转发路径,去往不同目的地的数据包选择不同的转发路径。CEF支持per-destination和per-packet两种负载均衡方式,在大多数情况下默认使用的是per-destination方式。关于CEF负载均衡的具体信息请参考:
http://www.cisco.com/en/US/products/hw/modules/ps2033/prod_technical_reference09186a00800afeb7.html#wp16235

Q:为什么设置了ip default-gateway以后却不起作用?
A:ip default-gateway类似于普通网络终端上的设置默认网关,在IOS上这条命令设置的参数只有在设备不支持路由功能或者在路由器上使用no ip routing将路由功能关闭后才会生效。如果你需要在路由设备上设置默认路由,请使用ip route 0.0.0.0 0.0.0.0命令。
Q:怎样使用ACL控制路由协议的流量?
A:对于RIPv2,ACL的规则是:access-list 102 permit udp any any eq rip,对于EIGRP,ACL的规则是access-list 103 permit eigrp any any,对于OSPF,ACL的规则是access-list 104 permit ospf any any,对于BGP,ACL的规则是access-list 105 permit tcp any any eq 179和access-list 105 permit tcp any eq 179 any。
Q:上边的问题中好像没有IS-IS的规则。
A:IS-IS使用的是CLNS协议,不能够被IP ACL过滤。
Q:默认路由可以用于uRPF检查吗?
A:默认的情况下不可以。举例来说,如果路由表中只有一条默认路由指向S0,没有任何静态路由或动态路由,那么如果路由器从S0收到了任意非直连网段发来的数据包,这些数据包都被视为无法通过uRPF检查。这个限制在新版本的IOS中已经可以被关闭,在设置ip verify unicast命令最后加上allow-default就可以解除这个限制。
Q:为什么在OSPF中loopback总是以/32掩码通告?
A:RFC 2328就是如此定义的。这个规定在某些时候确实会带来一些问题,解决的方法是在loopback接口配置模式下使用命令ip ospf network point-to-point命令改变接口上的网络类型,就可以在通告时保持原先的子网掩码。
Q:在OSPF中怎样改变特定路由的metric?
A:你是在问OSPF中为什么没有offset-list这条命令?offset-list这条命令只能对距离矢量路由协议起效,也只存在与距离矢量路由协议中。
Q:为什么在OSPF中使用default-information originate命令后OSPF还是没有发布默认路由?
A:你需要确保路由表中已经存在一条默认路由之后,这条命令才会起作用。当然,在很多情况下你需要的仅仅是让这台路由器向外发布一条默认路由,那么你需要在这条命令之后增加always这个关键字。
Q:我可以在OSPF中使用distribute-list命令过滤路由吗?
A:应该说,在链路状态路由协议中使用distribute-list是没有意义的。out方向的distribute-list不能阻止LSA泛洪(LSA泛洪的原理决定),而in方向的distribute-list能做的仅仅是在本地路由器上阻止某些路由条目被装入路由表(甚至不能阻止路由器收到这些路由)。因此,你总是应该选择另外的方式在链路状态路由协议中过滤路由条目。
Q:很有趣的一个问题:如果我在同一个路由器上通过两个不同的EIGRP进程学到了一条相同的路由,那么路由表中会出现什么情况?
A:首先,肯定不会出现负载均衡。如果metric值不同,自然是metric较小的路由被装入路由表。如果metric相同,那么取决于哪一条路由的更新时间最新,哪一条路由就被装入路由表。
Q:EIGRP中的network命令后边跟的掩码是子网掩码还是通配码?
A:事实上两者都可以。
Q:在BGP中show ip bgp这条命令显示NEXT HOP是0.0.0.0,这个是什么意思?
A:NEXT HOP是0.0.0.0表示这条前缀是在本地被network命令放入BGP表的。
Q:BGP的路由反射器如何影响NEXT HOP属性?
A:在进行路由发射时,反射器并不会修改NEXT HOP属性,所以不用担心所有数据流量会经过路由反射器。

NAT相关
Q:IOS中的NAT和ASA/PIX中的NAT有什么不同?
A:尽管命令看上去有很大的差别,但是从功能性上来说,两种系统上的NAT没有功能上的差异。
Q:NAT发生在路由之前还是路由之后?
A:取决于数据流的方向。从inside到outside的流量NAT发生在路由之后,而从outside到inside的流量NAT发生的路由之前。
Q:在IOS上最大支持多少条并发NAT会话?
A:IOS对会话的最大并发数没有硬性的限制,限制的因素仅仅是内存的大小。每1万条NAT会话大约会消耗3M多的内存。以现代路由器的内存量,可以说IOS支持足够庞大的NAT会话数。
Q:NAT可以被应用在子接口上吗?
A:完全可以。
Q:在进行PAT时,每一个global地址可以最多支持多少条并发转换?
A:最多支持65536条,因为端口的可用范围是从0-65535。换句话说,如果最大并发会话可能超过65536条,你需要考虑在NAT地址池中放置多个global地址。
Q:动态NAT和静态NAT可以在一台路由器上同时使用吗?
A:可以。但是要注意,IOS不会自动把静态NAT所用的地址从动态NAT的地址池中移除。这也就意味着你需要用ip dhcp exclude-address命令从地址池中移除那些被静态NAT使用的地址,以放置地址
Q:在企业连接公网的网关上经常需要对所有数据进行PAT,我好像听说NAT所用的ACL中不能有permit ip any any,这是真的吗?
A:没错。IOS不允许你在NAT使用的ACL中使用permit ip any any,即使你确实要permit所有的流量。你只能使用多条规则基于网段的把所有需要NAT的流量捕捉到。要特别注意的是,如果你真的使用了permit ip any any这条规则,IOS是不会报错的,但是思科官方的描述是:这会导致无法预料的结果。

HSRP相关
Q:在Catalyst 3550上最高支持多少个HSRP组?每个组最多允许多少个interfaces?
A:在Catalyst 3550上最高支持16个HSRP组,每个组中最多允许16个interfaces。
Q:在设置HSRP时,选择HSRP组ID时有没有什么限制?组ID是否需要连续?
A:组ID不需要连续,只需要从合法范围0-255之间选择任意16个值就可以。

QoS相关
Q:IOS最多支持多少个class-map?每个policy-map中最多可以有多少个class?
A:新版的IOS最多支持1024个class-map,而每个policy-map中最多可以调用256个class。
Q:在设置QoS时我注意到几乎没有配置案例中对路由协议流量或者其它管理性流量(例如keepalive流量)设置优先的QoS参数,但是它们对于网络的正常运行起到了至关重要的作用,那么这些重要的流量究竟应该如何被QoS进行处理?
A:这是一个非常好问题。首先,对于大部分IP路由协议和重要的管理性协议的流量,IOS在生成时会自动对它们设置较高的QoS参数,即便是管理员没有显式指定。除非管理员显式地将这些参数修改,否则这些流量会自动以高优先级低丢弃率的方式在网络中传输。对于其它重要的非IP流量(例如许多keepalive和IS-IS),没有可以设置的IP QoS参数,IOS内部还有一套标示机制。IOS在收到数据后,会根据数据的类型为数据设置一个仅在路由器内部使用的QoS标示,凭借这个标示,IOS一样可以准确地进行QoS处理。所以,通常情况下,你并不需要在设置QoS时过多地考虑管理型流量的标示分类。
Q:在CBWFQ中如果一个class中的流量没有用尽保留给这个class的带宽,这些多余的带宽可以被其它class使用吗?
A:bandwidth和priority命令虽然是对带宽的保留,但是并不是说带宽被这个class独占。对于多余的保留带宽,其它class总是可以按比例地分享。
Q:我在子接口上使用service-policy命令时报错,为什么?
A:IOS目前不允许你直接在子接口上设置CBWFQ中的队列参数。如果你尝试在子接口上应用一个包含bandwidth或priority命令的policy-map就会看到错误提示。解决的方法请看:
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a0080114326.shtml

              


本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u3/99768/showart_2018939.htm