<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>运维 on WWayne&#39;s Blog</title>
		<link>https://blog.wenb.in/tags/%E8%BF%90%E7%BB%B4/</link>
		<description>Recent content in 运维 on WWayne&#39;s Blog</description>
		<generator>Hugo</generator>
		<language>zh-CN</language>
		
		
		
		
			<lastBuildDate>Thu, 01 Aug 2013 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://blog.wenb.in/tags/%E8%BF%90%E7%BB%B4/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>eBGP中，“network”命令的影响</title>
				<link>https://blog.wenb.in/posts/2013-08-01_ebgp%E4%B8%ADnetwork%E5%91%BD%E4%BB%A4%E7%9A%84%E5%BD%B1%E5%93%8D/</link>
				<pubDate>Thu, 01 Aug 2013 00:00:00 +0000</pubDate>
				<guid>https://blog.wenb.in/posts/2013-08-01_ebgp%E4%B8%ADnetwork%E5%91%BD%E4%BB%A4%E7%9A%84%E5%BD%B1%E5%93%8D/</guid>
				<description>&lt;p&gt;&lt;a href=&#34;https://syslog.lofter.com/post/bc649_7c1cd2&#34;&gt;前一篇文章&lt;/a&gt;讨论了“network”命令在iBGP当中的影响。接下来简单分析一下“network”在eBGP中的影响。&lt;/p&gt;&#xA;&lt;p&gt;依然是这个拓扑：&lt;br&gt;&#xA;![](https://imglf5.&lt;!-- more --&gt;lf127.net/img/RXh1WFV3cG95ZEEwMkFTWTJKakhldE9DREs1TEJCdGNCR2FRMkZmbElPYy9DV01KaENGR2VBPT0.jpg)&lt;/p&gt;&#xA;&lt;p&gt;如果Taos（AS200）和Vail（AS100）都将“192.168.1.224/30”通过“network”命令加入到BGP进程当中，Telluride（AS100）会将192.168.1.224/30的路由下一条设置为192.168.1.221还是192.168.1.225。&lt;/p&gt;&#xA;&lt;p&gt;BGP中有个相当重要的原则就是EBGP路由比IBGP路由优先级更高！在理解这句话的时候注意，这是针对某一台路由器去比较从EBGP邻居和IBGP邻居学习的相同目的网络时的处理机制。在上面的拓扑当中，Telluride与Vail建立了IBGP对等体，而与Taos没有建立对等关系。所以对于Telluride来讲，去往192.168.1.224/30的路由是由Vail通告的。那么Vail通告的地址会是哪一个呢？这是应该参考另一条BGP路由的选路优先准则：当一个路由器既通过本地学到这条路由，又通过BGP邻居学到这条路由，那么优先选用本地的路由。本例中，Vail关于192.168.1.224/30的路由，一方面有直连路由，另一方面，EBGP对等体Taos也会通告这条路由，更具本地优先的准则，会将直连路由作为最优路由，并且再想其他对等体通告的时候，也会使用这个条目。那么作为Vail对等体之一的Telluride，也会得到通告，下一条地址当然就是Vail自己了。&lt;/p&gt;&#xA;&lt;p&gt;这是我的一个理解，不一定对。&lt;/p&gt;</description>
			</item>
			<item>
				<title>反向路径转发</title>
				<link>https://blog.wenb.in/posts/2011-09-26_%E5%8F%8D%E5%90%91%E8%B7%AF%E5%BE%84%E8%BD%AC%E5%8F%91/</link>
				<pubDate>Mon, 26 Sep 2011 00:00:00 +0000</pubDate>
				<guid>https://blog.wenb.in/posts/2011-09-26_%E5%8F%8D%E5%90%91%E8%B7%AF%E5%BE%84%E8%BD%AC%E5%8F%91/</guid>
				<description>&lt;p&gt;反向路径转发（RPF），即IP验证。在思科的IOS中，用于反向路径转发（RPF）的命令是以“ip verify”开始的。&lt;/p&gt;&#xA;&lt;p&gt;RPF在工作起来就象一个反垃圾邮件解决方案的部分功能一样，该功能部分收到进入的电子邮件消息，找到源电子邮件的源地址，然后到发送服务器上执行一个检查操作，确定发送者是否真&lt;!-- more --&gt;的存在于发送消息的服务器上。如果发送者不存在，服务器就丢弃此电子邮件消息，因为它极有可能是一个垃圾邮件。&lt;/p&gt;&#xA;&lt;p&gt;RPF对数据包作出相似的操作。它取出所收到的来自互联网的某个数据包的源地址，查看在路由器的路由表中是否存在一个路由可以应答此数据包。如果路由表中没有路由来作为返回给源IP地址的数据包的应答，那么就是有人发送了欺骗性数据包，路由器就丢弃这个数据包。&lt;/p&gt;</description>
			</item>
			<item>
				<title>Wireshark错误Headerchecksum0x0000(incorrect,sh</title>
				<link>https://blog.wenb.in/posts/2011-05-18_wireshark%E9%94%99%E8%AF%AFheaderchecksum0x0000incorrectsh/</link>
				<pubDate>Wed, 18 May 2011 00:00:00 +0000</pubDate>
				<guid>https://blog.wenb.in/posts/2011-05-18_wireshark%E9%94%99%E8%AF%AFheaderchecksum0x0000incorrectsh/</guid>
				<description>&lt;p&gt;Wireshark抓主机自身的包时，某些情况下会发现IP包头中出现如标题所示的错误提示。&lt;/p&gt;&#xA;&lt;p&gt;原因如下：&lt;br&gt;&#xA;a lot of modern network cards use TCP/IP checksum o&lt;!-- more --&gt;ffloading, in which case Windows doesn&amp;rsquo;t bother generating a checksum for each outbound packet and the network card adds them just before transmission.&lt;br&gt;&#xA;This reduces the amount of work that the computer&amp;rsquo;s CPU has to do, but the problem is that Wireshark can only intercept packets at the OS level, and hence thinks the checksums are invalid (when in fact the problem is that they haven&amp;rsquo;t been added yet).&lt;/p&gt;</description>
			</item>
			<item>
				<title>带宽测试工具IPerf</title>
				<link>https://blog.wenb.in/posts/2010-12-08_%E5%B8%A6%E5%AE%BD%E6%B5%8B%E8%AF%95%E5%B7%A5%E5%85%B7iperf/</link>
				<pubDate>Wed, 08 Dec 2010 00:00:00 +0000</pubDate>
				<guid>https://blog.wenb.in/posts/2010-12-08_%E5%B8%A6%E5%AE%BD%E6%B5%8B%E8%AF%95%E5%B7%A5%E5%85%B7iperf/</guid>
				<description>&lt;p&gt;如果你有过测试网络吞吐量的经验，那你肯定用过Ixia出品的NetIQ Chariot。首先你需要在待测环境中的每台机器上安装Ixia EndPoint，然后在某一台上安装Chariot控制台。完成这些部署后，你才可以开始测试（详细操作就不赘述了）。&lt;br&gt;&#xA;但是，在点对点的测试中，这样的做&lt;!-- more --&gt;法显得有些兴师动众，有没有更方便的工具呢？有的，就是这款非主流的IPerf（当然，测试吞吐量本身也是非主流的），108K大小的一个命令行工具。IPerf的项目主页在https://dast.nlanr.net/Projects/Iperf/（可能已经无法访问了），需要下载折腾可以访问https://www.noc.ucf.edu/Tools/Iperf/default.htm获取。IPerf本身是多平台的工具，目前有Windows/Sun Solaris/Mac OS X。下面以Windows平台为例简要说明它的用法（不管如何，我最爱的平台还是WIN）。&lt;br&gt;&#xA;把下载得到的“iperf.exe”放到你能找到的目录，CMD后定位到它。常用的参数如下：&lt;/p&gt;&#xA;&lt;p&gt;  -i, &amp;ndash;interval  #        带宽测试结果现实间隔&lt;br&gt;&#xA;  -w, &amp;ndash;window    #[KM]    TCP窗口大小&lt;br&gt;&#xA;  -s, &amp;ndash;server             以服务端模式运行&lt;br&gt;&#xA;  -c, &amp;ndash;client    &lt;host&gt;   以客户端模式运行&lt;br&gt;&#xA;  -t, &amp;ndash;time      #        测试持续时间&lt;br&gt;&#xA;  -l, &amp;ndash;len       #[KM]    缓冲大小&lt;/p&gt;&#xA;&lt;p&gt;其他参数打“－－help”能够获取。&lt;br&gt;&#xA;典型测试案例：&lt;br&gt;&#xA;A端作为服务器端，IP地址为192.168.1.111；B端作为客户端，IP地址为10.10.10.200。A端运行如下命令：&lt;/p&gt;&#xA;&lt;p&gt;C:&amp;gt;iperf.exe -s 10.10.10.200 -w 2M -l 16M&lt;/p&gt;&#xA;&lt;p&gt;B端运行如下命令：&lt;/p&gt;&#xA;&lt;p&gt;C:&amp;gt;iperf.exe -c 192.168.1.111 -w 2M -l 16M -t 120 -i 30&lt;/p&gt;&#xA;&lt;p&gt;先运行A端命令，再运行B端命令；如此，在B上没30秒会有一条测试结果。120秒后A电脑上会有最终的测试平均值。&lt;br&gt;&#xA;当然，对于更加复杂的测试网络环境，还是老老实实的使用Chariot吧。&lt;br&gt;&#xA;那是所有。&lt;/p&gt;</description>
			</item>
			<item>
				<title>上班第四天</title>
				<link>https://blog.wenb.in/posts/2009-07-03_%E4%B8%8A%E7%8F%AD%E7%AC%AC%E5%9B%9B%E5%A4%A9/</link>
				<pubDate>Fri, 03 Jul 2009 00:00:00 +0000</pubDate>
				<guid>https://blog.wenb.in/posts/2009-07-03_%E4%B8%8A%E7%8F%AD%E7%AC%AC%E5%9B%9B%E5%A4%A9/</guid>
				<description>&lt;p&gt;今天，是我上班的第四天，整个白天几乎都没有什么事情，但是夜晚却是精彩纷呈。 今天网上，我们配合公安局的通知进行对近期疯狂作案的基站窃贼的蹲点抓捕行动。我先睡觉，明天写吧。 天天都很忙，我没时间写了……&lt;/p&gt;&#xA;&lt;!-- more --&gt;</description>
			</item>
	</channel>
</rss>
