笔记实时更新中。。

Core、Emane 介绍

官方文档

一句话概括:

CORE侧重于模拟如网络层传输层、会话层和应用层，提供了用户构建虚拟网络的图形用户界面；在一台或多台计符机上进行网络模拟的工具，实时运行的模拟。这些模拟的网络可以实时连接到物理网络和路由器，可以在使用相对廉价的硬件的前提下，保证在模拟网络上运行实时的应用程序的真实性。

EMANE主要针对物理层和数据链路层工作，为模拟链路层和物理层的无线网络提供了必需的可插拔框架。关于网络层路由协议可以选用适用移动自组网的 OSPF MDR 协议。

Core

Core源码

通用开放式研究仿真器（Common Open Research Emulator）是一种构建虚拟网络的工具。作为模拟器，CORE 构建了实时运行的真实计算机网络的表示，而不是使用抽象模型的模拟。实时运行的仿真可以连接到物理网络和路由器。它提供了运行真实应用程序和协议的环境，利用了 Linux 操作系统提供的工具。

CORE 通常用于网络和协议研究、演示、应用程序和平台测试、评估网络场景、安全研究以及增加物理测试网络的规模。

以下所有记录基于 core版本 7.5.1 Ubuntu20.4系统测试

基础内容学习

• TLV编码格式详解

• 了解 gRPC协议

• 什么是GRE隧道

• OSPF MDR OSPF即开放最短路径优先(Open Shortest Path First)是为有线网络设计的标准路由协议。

  每个自治系统AS（Autonomous System）内部的路由选路协议，位于网络层。

  OSPF MDR即OSPF指定路由器移动自组网协议（OSPF MANET Designated Routers）也是美国海军研究实验室(NRL)开发，其源码在这可以找到。Quagga 中OSPFv3的OSPF MDR是依照移动自组织网络(MANETs: Mobile Ad Hoc Networks)中有效路由的 RFC 5614 (OSPF MDR), RFC 5243 (OSPF Database Exchange Optimization), 和 RFC 5838 (OSPFv3 Address Families)来实现的。

  该软件基于开源的Quagga路由套件，最初由Richard Ogier和波音幻影工程公司开发，现在由NRL的移动路由项目维护。

• Linux基础网络设备详解：Core的链路实现就是依赖这些虚拟网络设备，利用Linux命名空间特性创建各个独立的虚拟节点。

Core 开发相关

源码概述

由于历史原因，CORE源代码由几种不同的编程语言组成。目前的开发重点是Python模块和守护进程。下面是源目录的简要描述。(netns = network nodes)

其切换开发版本分支

git clone https://github.com/coreemu/core.git
cd core
git checkout develop

安装开发环境

此命令将自动安装系统依赖项、克隆和构建 OSPF-MDR, 搭建CORE, 设置CORE poetry 环境, 然后安装 pre-commit hooks.您可以参考install docs来了解不同发行版的相关问题。

./install -d

其中pre-commit帮助自动运行工具检查修改的代码。每次提交时，都会运行python实用程序来检查代码的有效性，可能会失败并退出提交。这些更改目前是作为当前CI的一部分强制执行的，因此添加更改并再次提交。

运行core

您现在可以像平常一样运行core，或者利用一些调用任务来方便地运行测试等。

# run core-daemon
sudo core-daemon

# run python gui
core-pygui

# run tcl gui
core-gui

# run mocked 单元测试
cd <CORE_REPO>
inv test-mock

容器命令

Linux namespace containers通常使用Linux容器工具或lxc-tools包进行管理。lxc-tools网站可在这里http://lxc.sourceforge.net/获得更多信息。CORE不使用这些管理core实用工具(utilities)，core自己实现了一组用于实例化和配置网络名称空间容器的工具。这些工具大体分为：

• vnoded (Virtual nodes daemon )

  vnoded daemon是用于创建新名称空间的程序，并在控制通道上侦听可能实例化其他进程的命令。这个守护进程在容器中作为PID 1运行。它由CORE守护进程自动启动。控制通道是UNIX域套接字，通常命名为/tmp/pycore。对于运行在CORE会话23098上的节点3，例如:23098/n3。创建一个新的命名空间需要Root特权。

• vcmd (Virtual cmd )

  vcmd程序用于连接Linux网络命名空间中的vnoded，用于运行命名空间容器中的命令。CORE守护进程使用相同的通道设置节点并在其中运行进程。这个程序有两个必需的参数，控制通道名和要在命名空间中运行的命令行。该命令不需要以root权限运行。

  当你在运行模拟中双击一个节点时，CORE会使用如下命令打开该节点的shell窗口:

  gnome-terminal -e vcmd -c /tmp/pycore.50160/n1 -- bash
  

  类似地，IPv4路由观察者小部件将运行一个命令来显示路由表，使用如下命令:

  vcmd -c /tmp/pycore.50160/n1 -- /sbin/ip -4 ro
  

• core-cleanup 脚本

  提供了一个名为 core-cleanup 的脚本来清理任何正在运行的CORE仿真。它将试图杀死任何剩余的vnoded进程，杀死任何EMANE进程，删除 :file:/tmp/pycore.* 会话目录。删除任何bridge或ebtables规则。使用*-d*选项，它也将杀死任何正在运行的CORE守护进程。

• netns 命令

  CORE不直接使用netns命令。此实用程序可用于在新的网络名称空间中运行命令，以进行测试。它不会打开一个控制通道来接收进一步的命令。

• 其他常用命令

  # 查看Linux网桥配置
  ip link show type bridge
  
  # 查看某网桥被attach设备
  brctl show bridge_name
  
  # 查看用于应用链接效果的netem规则
  tc qdisc show
  
  # 查看使无线局域网工作的规则
  ebtables -L
  

Core 性能分析

关于CORE性能的首要问题通常是它能处理多少个节点?答案取决于几个因素:

在典型的单cpu 3.0GHz Xeon服务器上，2GB RAM运行Linux，我们发现运行30-75个节点运行OSPFv2和OSPFv3路由是合理的。在这个硬件上，CORE可以实例化100个或更多的节点，但是在这一点上，每个节点在做什么就变得至关重要了。

因为这个软件主要是一个网络模拟器，所以更合适的问题是它能处理多少网络流量?在上面描述的3.0GHz服务器上，运行Linux，大约每秒可以通过系统推送30万个包。跳数和报文大小不那么重要。限制因素是操作系统需要处理数据包的次数。300,000pps表示系统作为一个整体需要处理一个数据包的次数。随着更多的网络跳数的增加，上下文切换的数量会增加，并且会降低整个网络路径上的吞吐量。

注意: 问题关键在于是能跑多少流量? 而不是多少节点

有关CORE性能的更详细研究，请参阅以下出版物:

• J. Ahrenholz, T. Goff, and B. Adamson, Integration of the CORE and EMANE Network Emulators, Proceedings of the IEEE Military Communications Conference 2011, November 2011.
• Ahrenholz, J., Comparison of CORE Network Emulation Platforms, Proceedings of the IEEE Military Communications Conference 2010, pp. 864-869, November 2010.
• J. Ahrenholz, C. Danilov, T. Henderson, and J.H. Kim, CORE: A real-time network emulator, Proceedings of IEEE MILCOM Conference, 2008.

节点类型

CORE中可以配置不同的节点类型，每个节点类型都表示节点在运行时将如何表示的机器类型。不同的机器类型允许不同的选择。

Netns 节点

netns(net nodes) 类型是默认的节点类型， 这是用于由 Linux 网络命名空间支持的节点。这种机器类型很少使用系统资源来模拟网络。这被指定为默认机器类型的另一个原因是，此技术通常不需要更改内核，它可从最新的主流Linux发行版中开箱即用。

物理 节点

physical 机器类型用于表示真正的基于linux的机器的节点，这些机器将参与模拟的网络场景。该节点通常用于合并来自模拟测试平台的服务器机组。物理节点是运行CORE守护进程(CORE-daemon)的节点，它不会被进一步分区到容器中。在物理节点上运行的服务不是在一个隔离的环境中运行，而是直接在操作系统上运行。

必须给物理节点分配服务器，与使用分布式仿真（Distributed Emulation）将节点分配仿真服务器的方式相同。可用物理节点列表当前与仿真服务器共享同一个对话框和列表，可以使用Session菜单中的emulation servers…条目进行访问。

对物理节点的支持正在开发中，并可能在未来的版本中得到改进。目前，当任何节点连接到一个物理节点时，会画一条虚线来表示网络隧道。将在物理节点上创建一个GRE隧道接口，用于隧道通信流进出模拟世界。

在运行时双击物理节点将打开一个终端，该终端带有指向该节点的SSH shell。用户应该像使用仿真服务器那样配置公钥SSH登录。

SDT 3D安装

首先安装对应Java环境，推荐java8，根据源码手册下面为Ubuntu的安装教程

git clone https://github.com/USNavalResearchLaboratory/sdt
sudo apt-get install openjdk-8-jdk

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/
source $HOME/.bashrc # jdk变量生效  当前用户
# source $HOME/.profile # jdk变量生效  全部用户


update-alternatives --display java
update-alternatives --display javac
update-alternatives --display jar

sudo apt-get install libvecmath-java
sudo apt-get install libpcap-dev
sudo apt-get install libnetfilter-queue-dev

# <arm64> 替换为安装软件的系统架构
cd sdt/makefiles 
make -f Makefile.linux_<arm64> sdt3d sdtcmd
make -f Makefile.linux_<arm64> distclean #卸载包，有问题需要清理时运行

#绑定脚本至core中
sudo make -f Makefile.linux_amd64 install /usr/local/bin/
#修改 /usr/local/bin/sdt3d.sh 内容：
THISDIR=/home/$USER/sdt/makefiles/build/sdt3d

之后设定 场景设置的 sdtoutput 为true即可

在仿真启动前开启 设置 Preferences 点击 3D GUI… 开启3d界面

执行仿真即可看到节点初始化过程

Core 常见问题：

• core安装、卸载重装等报错问题

  不能使用sudo 运行install.sh 否则后面装依赖包及生成虚拟环境目录权限为root用户，肯定会报错。

  似乎 ARM 架构的 ubuntu 无法安装该软件的虚拟环境，真实环境下也是各种不包的依赖环境不对。

  自动化安装脚本依赖invoke，其执行流程由core源码根目录的task.py脚本定义。其写法是一旦遇到装过pipx等就直接退出安装脚本，所以可以修改其执行语句（添加 –force）来强制安装已经装过的包。或者简单的做法就是把装的虚拟环境删除即可，删pipx的venv文件夹(~/.local/pipx/venvs/*) 和poetry生成的虚拟环境文件夹(~/.cache/pypoetry/virtualenvs/core-3XChpotV-py3.6)或使用命令

  cd ~/core/daemon
  poetry env list # 查看安装位置
  poetry remove  venv1
  pipx uninstall poetry
  pipx uninstall invoke
  pip3 uninstall pipx
  

  • poetry或pip安装满导致的超时错误

    python换源

    /home/lk233/core/daemon/pyproject.toml
    [[tool.poetry.source]]
    name = "tsinghua"
    default = true
    url = "https://pypi.tuna.tsinghua.edu.cn/simple"
    # 更新 poetry 锁文件
    poetry lock --no-update
    
    # 如果是安装本地直接如下
    pip config set global.index-url http://pypi.tuna.tsinghua.edu.cn/simple
    pip config set global.trusted-host pypi.tuna.tsinghua.edu.cn
    

  • 安装 pyymal 报错

    将pip降级可以解决pip install --upgrade --force-reinstall pip==9.0.3

  • poetry 安装 cffi 报错

    Building wheel for cffi (setup.py) error
    XXX..
    Package libffi was not found in the pkg-config search path.
    

    安装缺少的包sudo apt-get install libffi6 libffi-devsudo

  • local 安装 lxml 时报错

    安装缺少的包

    sudo apt-get install libxml2 
    sudo snap install libxslt
    

• 无法使用子节点终端的图形界面：

  # 报错提示
  No protocol specified
  Error: Can't open display: :0
  
  

  解决：Xserver默认情况下，不允许别的用户的图形程序的图形显示在当前屏幕上。在图形正常的用户终端中输入 xhost +

  xhost +  # access control enabled, only authorized clients can connect
  xhost -  # access control disabled, only authorized clients can connect
  

• Xterm下的Tcpdump 抓包不刷新问题：

  使用 -l 选项，设置stdout行缓冲， 这样也可以有效搭配如下命令

  tcpdump -l | tee dat  
  tcpdump -l > dat & tail -f dat	#终止时tcpdump未终止 记得kill pid
  

• iperf3等流量测试工具在走分布式场景时会发生数据无法传输问题：

  由于分布式之间的数据通过隧道链接，而建立的隧道默认MTU为1458字节。所以当分布式服务器的路由包的MTU过大时，不会转发数据。
  以iperf3为例，设定传输流量包mss为1024就能解决无法传输跨分布式服务器的包的数据

  iperf -c 192.168.131.161 -M 1024
  #注意，这里的-M设定的是MSS为TCP、STCP传输层概念，MTU为传输层传递的最大IP包
  

• 容器隔离问题

  注意虽然容器节点与外部物理机系统隔离有独立的网络、进程堆栈，但是部分文件系统是与外界共享的。例如家目录都是设置为外界用户的家目录，其他系统文件例如配置路由的转发的文件/proc/sys/net/ipv4/ip_forward却又是独立的（在终端使用sysctl不影响外面运行仿真的系统）

• emanesh脚本无导入库问题

  由于是安装在虚拟环境的python，所以执行得用core-python执行。有些脚本例如emanesh还是使用外部物理环境的python执行，将第一行的 执行文件修改成对应core-python路径。或者执行时加上core-python即可。

  #!/usr/bin/python3    =>   修改为类似的下面的执行路径
  #!/home/user/.cache/pypoetry/virtualenvs/core-3XChpotV-py3.6/bin/python
  

• core后台运行batch问题

  有一条issue提到了该问题： 程序自带的batch选项后续没有维护，运行带有移动拓扑及emane无线模型直接报错或是不加载。解决该问题需要使用前台gui启动或者带有虚拟帧缓冲区的启动，使用Xvfb可以正常运行，Xvfb 在虚拟内存中执行所有图形操作，而不显示任何屏幕输出，运行时部分ui报错可忽略。

  使用方法：xvfb-run core-gui -s ~/.core/configs/sample1.imn，提示没有这个包就apt-get安装即可。

  或者直接使用 grpc api open一个场景后台执行。

  如果是生成一个场景并后台执行，个人推荐使用 gRPC API Python API 直接构建场景实例化运行，并且也能调用savexml保存。

• 分布式场景初始化问题

  ​ 由于 boot_nodes 和 boot service 默认是调用线程池大小为10的非堵塞任务，所以瞬时业务的并发量特别大造成ssh通道饱和连接失败。具体问题示例如此处[SSH BUG] · Issue #622 · coreemu/core (github.com)。需要修改coreservices.py下的 boot_services 和 session.py下的 boot_nodes 的调用线程数量。当然也可以重构分布式通信部分，将多个连接命令合并之后解析ssh。