packet tracer 不同网段的PC和服务器如何连通??????????????????
1我给个建议,服务器和中心交换机之间加个交换机,三台服务器加入一个VLAN,然后做单臂路由,VLAN间可以实现相互通信,学生服务中心的PC和服务器就可以连通了。
2必须用TRUNK,而且路由的子接口必须封奘8021Q协议
3做单臂路由后,你的所有VLAN都可以相互通信,网内的PC,服务器全部可以相互通讯
以下是我做的单臂路由实验,给你参考:
如图,交换机下接三台PC,IP分别是:
192168202
192168203
192168302
现在建立两个VLAN,VLAN20,VLAN30
PC0,PC1划给VLAN20,PC4划给VLAN30
代码如下:
1建立VLAN:
Switch(config)#vlan 20
Switch(config-vlan)#vlan 30
2划分端口:
Switch(config)#int range fa0/2 - 3 \\请注意range的使用
Switch(config-if-range)#switchport access vlan 20
Switch(config-if-range)#exi
Switch(config)#int fa0/4
Switch(config-if)#switchport access vlan 30
3交换机连接路由端口开TRUNK
Switch(config)#int fa0/1
Switch(config-if)#switchport mode trunk
4路由器命令:
Router(config)#int fa0/1
Router(config-if)#no shutdown \\启动端口
Router(config-if)#int fa0/11 \\启动子接口
Router(config-subif)#
%LINK-5-CHANGED: Interface FastEthernet0/11, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/11, changed state to up
Router(config-subif)#encapsulation dot1q 20 \\封装8021协议 注意20是想对应的VLAN
Router(config-subif)#ip add 192168201 2552552550 \\IP地址就是VLAN20的网关
Router(config-subif)#int fa0/12
%LINK-5-CHANGED: Interface FastEthernet0/12, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/12, changed state to up
Router(config-subif)#encapsulation dot1q 30
Router(config-subif)#ip add 192168301 2552552550 \\讲解参照上面的
结论:测试VLAN 20和VLAN30可以相互通讯,PC0,PC1,PC4可以相互PING通这是典型单臂路由实验,我写了个,希望可以对你有所帮助,如果觉得上面的实验对你帮助有限,可以参考我的另外个实验,和你的要求很相似,地址:http://goomeblog51ctocom/4045241/1077175
Cisco packet tracer62
拓扑图构建和配置PC
1、根据给出的参考图,选择相关设备设计拓扑图
2、PC中需要将配置方式改为自动获取,参考图如下
设置服务器
1、设置服务器的ip、mask、gateway,给出的图仅做参考
2、设置HTTP服务
3、设置DHCP服务
4、设置DNS服务
测试设置是否正确和生效
1、测试DHCP服务。
任选一个PC,查看ip、mask、gateway、dns是否如下图所示(如果不是,将配置方式切换到手动即static,再切换回来)
2、测试HTTP服务。请看下图
3、测试DNS服务。请看下图
1、进入 域名的管理控制台,就可以看到域名的全部信息了,接下来需要对域名进行解析了。
2、点击“域名解析”进入到域名解析的界面。
3、需要解析,进入解析设置,接下来才能进行下一步操作。
4、解析到其他主机,需要再设置解析。解析部分到这就完成,如下图所示。
制作nat 步骤:
路由器配置清单:
interface fastethernet0/0
ip address 1921681001 25525500 //定义本地端口IP地址
ip nat inside // 定义为内部端口(本地) !
interface fastethernet0/1
ip address 20299160129 255255255252
ip nat outside ! 定义外部端口(外网)
ip nat pool onlyone 20299160130 20299160130 netmask 255255255252 //定义合法 IP地址池,名称为onlyone
access-list 1 permit 1921681000 000255 //定义本地访问列表
ip nat inside source list1 pool onlyone overload //采用端口复用动态地址转换
另外nat可以分为静态、动态、端口映射
web服务器这方面,我还没学到抱歉
TTL是IP协议包中的一个值,它告诉网络路由器包在网络中的时间是否太长而应被丢弃。有很多原因使包在一定时间内不能被传递到目的地。例如,不正确的路由表可能导致包的无限循环。所以需要在包中设置这样一个值,包在每经过一个节点,将这个值减1,反复这样操作,最终可能造成两个结果:包在这个值还为正数的时候到达了目的地,或者是在经过一定数量的节点后,这个值减为了0。前者代表完成了一次正常的传输,后者代表包可能选择了一条非常长的路径甚至是进入了环路,这显然不是我们期望的,所以在这个值为0的时候,网络设备将不会再传递这个包而是直接将他抛弃,并发送一个通知给包的源地址,说这个包已死。 第二个问题,通过TTL值我们能得到什么 其实TTL值这个东西本身并代表不了什么,对于使用者来说,关心的问题应该是包是否到达了目的地而不是经过了几个节点后到达。但是TTL值还是可以得到有意思的信息的。 每个操作系统对TTL值得定义都不同,这个值甚至可以通过修改某些系统的网络参数来修改,例如Win2000默认为128,通过注册表也可以修改。而Linux大多定义为64。不过一般来说,很少有人会去修改自己机器的这个值的,这就给了我们机会可以通过ping的回显TTL来大体判断一台机器是什么操作系统。如你看到112,可能是初始128,跳了16个节点,或者是初始160,跳了48次。
不同的操作系统,它的TTL值默认值是不相同的。默认情况下,Linux系统的TTL值为64或255,Windows NT/2000/XP系统的TTL值为128,Windows 98系统的TTL值为32,UNIX主机的TTL值为255。
以我公司2台机器为例 看如下命令 ping 6115293131
Pinging 6115293131 with 32 bytes of data:
Reply from 6115293131: bytes=32 time=21ms TTL=118
Reply from 6115293131: bytes=32 time=19ms TTL=118
Reply from 6115293131: bytes=32 time=18ms TTL=118
Reply from 6115293131: bytes=32 time=22ms TTL=118
Ping statistics for 6115293131: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss
Approximate round trip times in milli-seconds:
Minimum = 18ms, Maximum = 22ms, Average = 20ms
ping 6115210440 Pinging 6115210440 with 32 bytes of data:
Reply from 6115210440: bytes=32 time=28ms TTL=54
Reply from 6115210440: bytes=32 time=18ms TTL=54
Reply from 6115210440: bytes=32 time=18ms TTL=54
Reply from 6115210440: bytes=32 time=13ms TTL=54
Ping statistics for 6115210440: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 28ms, Average = 19ms
第一台TTL为118,则基本可以判断这是一台Windows机器,从我的机器到这台机器经过了10个节点,因为128-118=10。而第二台应该是台Linux,理由一样64-54=10。 了解了上面的东西,可能有人会有一些疑问,例如以下: 1,不是说包可能走很多路径吗,为什么我看到的4个包TTL都是一样的,没有出现不同? 这是由于包经过的路径是经过了一些最优选择算法来定下来的,在网络拓扑稳定一段时间后,包的路由路径也会相对稳定在一个最短路径上。具体怎么算出来的要去研究路由算法了,不在讨论之列。 2,对于上面例子第二台机器,为什么不认为它是经过了74个节点的Windows机器?因为128-74=54。 对于这个问题,我们要引入另外一个很好的ICMP协议工具。不过首先要声明的是,一个包经过74个节点这个有些恐怖,这样的路径还是不用为好。 要介绍的这个工具是tracert(nix下为traceroute),让我们来看对上面的第二台机器用这个命令的结果 tracert 6115210440
Tracing route to 6115210440 over a maximum of 30 hops
1 13 ms 16 ms 9 ms 10120321
2 9 ms 9 ms 11 ms 219233244105
3 12 ms 10 ms 10 ms 219233238173
4 15 ms 15 ms 17 ms 21923323813
5 14 ms 19 ms 19 ms 2029622273
6 14 ms 17 ms 13 ms 20296222121
7 14 ms 15 ms 14 ms 611528186
8 15 ms 14 ms 13 ms 6115287162
9 16 ms 16 ms 28 ms 611529926
10 12 ms 13 ms 18 ms 611529994
11 14 ms 18 ms 16 ms 6115210440
Trace complete
从这个命令的结果能够看到从我的机器到服务器所走的路由,确实是11个节点(上面说10个好像是我犯了忘了算0的错误了,应该是64-54+1,嘿嘿),而不是128的TTL经过了70多个节点。 既然已经说到这里了,不妨顺便说说关于这两个ICMP命令的高级一点的东西。 首先是ping命令,其实ping有这样一个参数,可以无视操作系统默认TTL值而使用自己定义的值来发送ICMP Request包。 例如还是用那台Linux机器,用以下命令: ping 6115210440 -i 11
Pinging 6115210440 with 32 bytes of data:
Reply from 6115210440: bytes=32 time=10ms TTL=54
Reply from 6115210440: bytes=32 time=13ms TTL=54
Reply from 6115210440: bytes=32 time=10ms TTL=54
Reply from 6115210440: bytes=32 time=13ms TTL=54
Ping statistics for 6115210440: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 10ms, Maximum = 13ms, Average = 11ms
这个命令我们定义了发包的TTL为11,而前面我们知道,我到这台服务器是要经过11个节点的,所以这个输出和以前没什么不同。现在再用这个试试看: ping 6115210440 -i 10
Pinging 6115210440 with 32 bytes of data:
Reply from 611529994: TTL expired in transit
Reply from 611529994: TTL expired in transit
Reply from 611529994: TTL expired in transit
Reply from 611529994: TTL expired in transit
Ping statistics for 6115210440: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
可以看到,结果不一样了,我定义了TTL为10来发包,结果是TTL expired in transit就是说在到达服务器之前这个包的生命周期就结束了。注意看这句话前面的ip,这个ip恰好是我们前面tracert结果到服务器之前的最后1个ip,包的TTL就是在这里减少到0了,根据我们前面的讨论,当TTL减为0时设备会丢弃包并发送一个TTL过期的ICMP反馈给源地址,这里的结果就是最好的证明。 通过这里再次又证明了从我机器到服务器是经过了11个节点而不是70多个,呵呵。 最后再巩固一下知识,有人可能觉得tracer这个命令很神奇,可以发现一个包所经过的路由路径。其实这个命令的原理就在我们上面的讨论中。 想象一下,如果我给目的服务器发送一个TTL为1的包,结果会怎样? 根据前面的讨论,在包港出发的第一个节点,TTL就会减少为0,这时这个节点就会回应TTL失效的反馈,这个回应包含了设备本身的ip地址,这样我们就得到了路由路径的第一个节点的地址。 因此,我们继续发送TTL=2的包,也就受到第二个节点的TTL失效回应 依次类推,我们一个一个的发现,当最终返回的结果不是TTL失效而是ICMP Response的时候,我们的tracert也就结束了,就是这么简单。 顺便补一句ping命令还有个-n的参数指定要发包的数量,指定了这个数字就会按照你的要求来发包了而不是默认的4个包。如果使用-t参数的话,命令会一直发包直到你强行中止它。
0条评论