- 博客(4)
- 资源 (4)
- 收藏
- 关注
RSS订阅原创 闲谈IPv6-为了每一粒沙，真实的代价！
周六早上，哈哈，喷一篇无关紧要的。IPv6最经典的广告词，可以为地球上每一粒沙子分配一个IP地址。提起IPv6，人们总是用这句话形容其地址之多，多到一个这么一个形象的天文数字。到底能不能为地球上每一粒沙子分配一个IPv6地址我们姑且不论，假设这是真的，我这里想摆一摆的是，存储所有的IPv6地址需要多大的物理空间。注意！是物理空间，只有这样才能体现出实施IPv6真实的，现实中的代价。一粒沙子到底多大呢？经常看到有人实际计算地球上沙子数量的时候用毫米做尺寸量级，但实际上那不是沙子，那是珠子。真正的沙
2020-12-26 09:10:32
4486
1
原创 Linux soft lockup时远程调试的可能性
曾经写过一个模块，当运行Linux内核的机器死机时，SSH肯定无法登录了，但只要它还响应中断，就尽力让它可以通过网络带回一些信息。陈年的事了：https://blog.csdn.net/dog250/article/details/43370611今日重提这件事，不陌生，但纠结。本文不谈sysrq，也不谈别的。Linux内核在发生soft lockup的时候，是可以ping通的，只要没有关中断，ping通一般没有问题。既然可以ping通，何必不带回一些真正重要的信息而不仅仅是echo的reply？
2020-12-19 11:08:14
9884
7
原创 IPv6的TSO/GRO/GSO及其Linux实现的不妥
很明确的一件事是，IPv6不允许中间设备对报文分片。具体为什么这么设计，就是为了简单高效。因此，IPv6报头简洁了不少。但TSO貌似并未违背取消IPv6分片的初衷，硬件把一些都处理的妥妥的，在路由软件层看来，一切好像没有发生过一样。我先简单解释一下TSO和IP分片的区别：我们来看一个简单的实验，用IPv6从服务端拉一个大文件，服务端和客户端的抓包如下：在客户端看来，没有IP分片，因此它不需要做分片重组的动作，它实实在在就是收到了一个完整的7140字节的报文，就好像这个报文就是从服务端真实发出的一
2020-12-19 09:02:21
4312
3
原创 NATv6是个笑话，那么IPv6本身呢？
近期遇到一个IPv6的NAT问题，在解决了之后总想写一点形而上的东西，什么是正确的，什么是错误的，什么合理，什么不合理，无关文档，无关代码，甚至无关技术，仅仅随便聊聊。昨天下班的路上整理了一下思路，周末了，写一点吧。如果一个报文过大却不能分片的时候，比方说携带了DF标志的IPv4报文和所有的IPv6报文，转发设备会给数据的始发站回送一则ICMP消息，意思是你这报文太大了，请缩小数据重新发。对于IPv4的情况，我们不用太在乎这种ICMP消息，因为IPv4网络中，IP报文本身只要没有DF标记，就是可以任意分
2020-12-19 07:27:10
11035
8
一个iptables的stateless NAT模块实现
2014-12-27
模块化的nf-HiPAC
2014-11-21
关于linux内核以及其他个人体会的文集
2009-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人