ip problem

Tidbit: Hide Routers from Traceroute

Do you have that one guy in desktop support that always blames the network? Does he constantly ask why his trace route is going through device XYZ!? Then I have a solution for you! Hide your network from that sketchy desktop support guy!

In MPLS its easy squeezy (‘no mpls ip propagate-ttl’), but what if you don’t have MPLS? Well here’s a quick way to do it:

ip access-list extended ACL_Traceroute
 permit icmp any any time-exceeded
 permit icmp any any port-unreachable

Firstly just make an extended ACL to match (permit) imcp time-exceeded and port-unreachable. The time-exceeded messages are basically the messages that the TTL is decremented (is decremented even a real word?) in and sent back to the original sender. The port-unreachable is basically what it sounds like — if the gateway does not have a route for the prefix, this message should be sent back to the sender.

So what are we doing with this ACL? Well we match it in a route-map, point it to the bit bucket, and apply it as local policy:

route-map RM_Traceroute perm 10
 match ip add ACL_Traceroute
 set interface null0
 !
 ip local policy route-map RM_Traceroute

The outcome is that the devices configured with this local policy do not show up in a trace route. Below is the initial ‘baseline’ test from an OSX client to an OSX client across three routers:

Carls-MacBook-Pro:~ carl$ traceroute 10.10.200.5
 traceroute to 10.10.200.5 (10.10.200.5), 64 hops max, 52 byte packets
 1 10.10.100.1 (10.10.100.1) 4.144 ms 1.497 ms 2.159 ms <--- Gateway for my first laptop 2 10.10.1.2 (10.10.1.2) 8.056 ms 6.473 ms 6.217 ms <--- R1 3 10.10.1.6 (10.10.1.6) 10.247 ms 10.345 ms 10.267 ms <--- R2 4 10.10.200.5 (10.10.200.5) 12.336 ms 12.538 ms 12.312 ms <--- Final host connected to R3

Now, here is that exact same trace route after adding our local policy:

Carls-MacBook-Pro:~ carl$ traceroute 10.10.200.5
 traceroute to 10.10.200.5 (10.10.200.5), 64 hops max, 52 byte packets
 1 * * *
 2 * * *
 3 * * *
 4 10.10.200.5 (10.10.200.5) 12.807 ms 11.450 ms 12.440 ms

As you can see this doesn’t ‘break’ the trace route, just kind of hides our routers. Note that a trace route TO a router will not complete since there is no message being sent back to the original sender since you are basically dropping the relevant incoming messages. As long as your destination is connected to a router that does NOT have the local policy though your traces will complete as per normal.

My understanding is that there are essentially three different ‘flavors’ of trace route — UNIX trace route (UDP), Windows trace route (tracert) which is strictly ICMP, and TCPTraceroute. So I tested this policy with a Windows host as well with basically the same results.

The baseline test:

C:\Users\Carl>tracert 10.10.200.6
Tracing route to Carl-PC [10.10.200.6]
 over a maximum of 30 hops:
1 3 ms 2 ms 2 ms 10.10.100.1
 2 7 ms 6 ms 6 ms 10.10.1.2
 3 11 ms 11 ms 10 ms 10.10.1.6
 4 12 ms 11 ms 12 ms Carl-PC [10.10.200.6]

And after adding the policy:

C:\Users\Carl>tracert 10.10.200.6
Tracing route to Carl-PC [10.10.200.6]
 over a maximum of 30 hops:
1 * * * Request timed out.
 2 * * * Request timed out.
 3 * * * Request timed out.
 4 12 ms 12 ms 13 ms Carl-PC [10.10.200.6]

So everything worked as planned!

I’m fairly confident that this will work for TCPTraceroutes as well but I didn’t test it out as I’m not 100% how to go about doing that… perhaps thats a post for another time.

cisco

1        ^254_[0-9]*_253$    //////表示起源于253,本地连接为254,中间有一个任意AS
2        ^254_[0-9_]*_253$    //////起源于253,本地连接为254,中间包括多个任意AS
3        ^254_[0-9]?_253$      /////起源于253,本地连接为254,中间包括一个AS,{AS0-AS9或中间没有AS}    
4        ^254_[0-9]+_253$      /////起源于253,本地连接为254,相对于1来说,其中间必须存在一个AS,而1可以只有AS254,AS253
5        ^254_[0-9_]+253$      /////起源于253,本地连接为254,相对于2来说,其中间必须还经过一个AS或多个AS,而2可以只经过AS254,AS253

directadmin lets

nano /usr/local/directadmin/scripts/letsencrypt.sh

Replace Line 31

Code:
LICENSE="https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf"

With

Code:
LICENSE="https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf"

如何使用Windows Server 2008自带的端口转发功能实现内网端口映射

Server2008系统可以使用netsh命令实现端口

cmd执行:

netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=192.168.1.100

listenport是外网服务监听端口,connectport是连接内网服务器的端口 注意要使用管理员权限运行cmd 这样就可以实现有公网服务器到内网服务器的端口转发了

删除端口转发的cmd命令:

netsh interface portproxy delete v4tov4 listenport=80 listenaddress=0.0.0.0

使用起来和Linux的iptables一样方便

ipmi问题导致很多系统卡在ipmiload或者无法安装

Today, when I restart a failed server, stuck inLoading module ipmi_si_drv …, about 30 minutes boot is completed.

First try setting IPMI toSharedin BIOS, if the option is available. When booting your installation media, pressShiftOto display the boot arguments and addnoipmiEnabledto the boot arguments. Remember to do the same once the
installation/upgrade is complete. Manually turn off or remove the module
by turning the optionVMkernel.Boot.ipmiEnabledoff in vSphere or using the commands below:

# Do a dry run first:
esxcli software vib remove –dry-run –vibname ipmi-ipmi-si-drv
# Remove the module:
esxcli software vib remove –vibname ipmi-ipmi-si-drv

or try the following command in an unsupported shell connection:

esxcfg-module -d ipmi_si_drv

This disables the module although it still gets loaded.

Use a-largument to see what modules are enabled/loaded
and check that your desired one is disabled. This appears to be
persistent across a reboot.

dhcp滥用问题

近期发现网络中有滥发dhcp,导致云服务器无法获取到争取的外网ip

查处发送dhcp网段为192.168.30

在交换机ACL规则关闭68端口无效

最终在母鸡中临时关闭

iptables -t mangle -I PREROUTING -s 192.168.30.1 -jDROP

尝试在母鸡中疯掉68,但是会导致母鸡本身发出的dhcp也被疯掉。

只有在观察了

kvm host安装优化

1.selinux/ssh port

2.

有整列卡用这个

Disk Scheduler Selection

cat /sys/block/<block device>/queue/scheduler
echo noop | sudo tee /sys/block/<block device>/queue/scheduler
	

Adding the following lines to your/etc/sysctl.conffile will increase network throughput

net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216

如何使用parted对齐分区以得到最优性能

How to align partitions for best performance using parted

There are two common problems when creating partitions in Linux on
big storage arrays. The first is easy, and the warning message from
fdisk is a bit of a giveaway:

WARNING: The size of this disk is 8.0 TB (7970004230144 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID
partition table format (GPT).

The answer: use parted. Don’t have it? Install it!

The second problem is this warning from parted:

(parted) mklabel gpt
(parted) mkpart primary 0 100%
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel?

…and no matter what combination of numbers you use, the message just keeps coming back. It’s tempting to ignore it, but don’t.

There are a few posts on the subject, but this one from HP really gets to the guts of the problem.

Here’s a quick step-by-step guide to aligning partitions properly.
It’s just an abstraction of the HP post, but hopefully easier to follow.
This will work for most arrays (in fact it works for all the arrays
that I’ve seen); there are more options in HP’s post, but I’ve included
the most common configuration here.

1. Get the alignment parameters for your array (remember to replace sdb with the name of your device as seen by the kernel).

    # cat /sys/block/sdb/queue/optimal_io_size
    1048576
    # cat /sys/block/sdb/queue/minimum_io_size
    262144
    # cat /sys/block/sdb/alignment_offset
    0
    # cat /sys/block/sdb/queue/physical_block_size
    512

2. Add optimal_io_size to alignment_offset and divide the result
by physical_block_size. In my case this was (1048576 + 0) / 512 = 2048.
3. This number is the sector at which the partition should start. Your new parted command should look like

    mkpart primary 2048s 100%

The trailing ‘s’ is important: it tells parted that you’re talking about sectors, not bytes or megabytes.

4. If all went well, the partition will have been created with no
warnings. You can check the alignment thusly (replacing ’1′ with the
partition number if necessary):

    (parted) align-check optimal 1                                           
    1 aligned

As I alluded to before, there are cases where this won’t work: if
optimal_io_size is zero, for example, there are other rules to follow.
Of course it would be nice if parted could do this—the values are all
available as ioctls, after all—but then what would I write about? :)

末尾的最后一条评论更加实用:
Apparently, using % causes parted to automatically align the sectors for best performance:

(parted) mkpart primary ext4 0% 100%