wireshark

last time using this was long time ago which is why I almost forgot everything about it.

So this time I’ll write it down to help remember it.

  1. display filter & capture filter :capture filter is what packets you really capture and display is what you want to see. We can use the configuration icon on the top left for fast choosing capture filter, Expression icon for display filter.
  2. DSCP:
    Differentiated Services Code Point (DSCP)

    Originally defined as the Type of service (ToS) field. This field is now defined by RFC 2474 (updated by RFC 3168 and RFC 3260) forDifferentiated services (DiffServ). New technologies are emerging that require real-time data streaming and therefore make use of the DSCP field. An example is Voice over IP (VoIP), which is used for interactive data voice exchange.   https://en.wikipedia.org/wiki/IPv4#DSCP                     DiffServ uses a 6-bit differentiated services code point (DSCP) in the 8-bit differentiated services field (DS field) in the IP header for packet classification purposes. The DS field and ECN field replace the outdated IPv4 TOS field

  3. IntServ specifies a fine-grained QoS system, which is often contrasted with DiffServ’s coarse-grained control system. In order for IntServ to work, all routers along the traffic path must support it. Furthermore, many states must be stored in each router. As a result, IntServ works on a small-scale, but as you scale up to a system the size of the Internet, it is difficult to keep track of all of the reservations.[1]
  4. Per-hop behaviour

    From Wikipedia, the free encyclopedia

    In computer networking, per-hop behaviour (PHB) is a term used in differentiated services (DiffServ) or multiprotocol label switching(MPLS). It defines the policy and priority applied to a packet when traversing a hop (such as a router) in a DiffServ network.

    Rule that governs how packets are handled within a diffserv[1] network is called the Per-Hop Behavior (PHB). PHBs are defined to support the general properties controlled by IP precedence. DSCP Contains 6-bits, PHBs are created (one for each combination of the top 3 bits) of the form bbb000 to match the precedence behaviors and leaves the other DSCP values open where each b may take the value zero or 1.

    DSCP Bit Settings Meaning
    000000 Best effort
    bbb000 Conforms to the requirements of Type of Service queuing precedence
    bbbbb0 Available for standardization
    bbbb11 For experimental of local network usage
    bbbb01 For experimental of local network usage, but may be taken for standardization
    Class selector values
    DSCP Binary Hex Decimal Typical application Examples
    CS0 (Default) 000 000 0x00 0
    CS1 001 000 0x08 8 Scavenger YouTube, Gaming, P2P
    CS2 010 000 0x10 16 OAM SNMP,SSH,Syslog
    CS3 011 000 0x18 24 Signaling SCCP,SIP,H.323
    CS4 100 000 0x20 32 Realtime TelePresence
    CS5 101 000 0x28 40 Broadcast video Cisco IPVS
    CS6 110 000 0x30 48 Network control EIGRP,OSPF,HSRP,IKE
    CS7 111 000 0x38 56

     

  5. List of IP protocol numbers

    From Wikipedia, the free encyclopedia

    This is a list of IP numbers used in the Protocol field of the IPv4 header and the Next Header field of IPv6 header.

    Decimal Hex Keyword Protocol References
    0 0x00 HOPOPT IPv6 Hop-by-Hop Option RFC 2460
    1 0x01 ICMP Internet Control Message Protocol RFC 792
    2 0x02 IGMP Internet Group Management Protocol RFC 1112
    3 0x03 GGP Gateway-to-Gateway Protocol RFC 823
    4 0x04 IP-in-IP IP in IP (encapsulation) RFC 2003
    5 0x05 ST Internet Stream Protocol RFC 1190, RFC 1819
    6 0x06 TCP Transmission Control Protocol RFC 793
    7 0x07 CBT Core-based trees RFC 2189
    8 0x08 EGP Exterior Gateway Protocol RFC 888
    9 0x09 IGP Interior Gateway Protocol (any private interior gateway (used by Cisco for their IGRP))
    10 0x0A BBN-RCC-MON BBN RCC Monitoring
    11 0x0B NVP-II Network Voice Protocol RFC 741
    12 0x0C PUP Xerox PUP
    13 0x0D ARGUS ARGUS
    14 0x0E EMCON EMCON
    15 0x0F XNET Cross Net Debugger IEN 158
    16 0x10 CHAOS Chaos
    17 0x11 UDP User Datagram Protocol RFC 768
    18 0x12 MUX Multiplexing IEN 90
    19 0x13 DCN-MEAS DCN Measurement Subsystems
    20 0x14 HMP Host Monitoring Protocol RFC 869
    21 0x15 PRM Packet Radio Measurement
    22 0x16 XNS-IDP XEROX NS IDP
    23 0x17 TRUNK-1 Trunk-1
    24 0x18 TRUNK-2 Trunk-2
    25 0x19 LEAF-1 Leaf-1
    26 0x1A LEAF-2 Leaf-2
    27 0x1B RDP Reliable Datagram Protocol RFC 908
    28 0x1C IRTP Internet Reliable Transaction Protocol RFC 938
    29 0x1D ISO-TP4 ISO Transport Protocol Class 4 RFC 905
    30 0x1E NETBLT Bulk Data Transfer Protocol RFC 998
    31 0x1F MFE-NSP MFE Network Services Protocol
    32 0x20 MERIT-INP MERIT Internodal Protocol
    33 0x21 DCCP Datagram Congestion Control Protocol RFC 4340
    34 0x22 3PC Third Party Connect Protocol
    35 0x23 IDPR Inter-Domain Policy Routing Protocol RFC 1479
    36 0x24 XTP Xpress Transport Protocol
    37 0x25 DDP Datagram Delivery Protocol
    38 0x26 IDPR-CMTP IDPR Control Message Transport Protocol
    39 0x27 TP++ TP++ Transport Protocol
    40 0x28 IL IL Transport Protocol
    41 0x29 IPv6 IPv6 Encapsulation RFC 2473
    42 0x2A SDRP Source Demand Routing Protocol RFC 1940
    43 0x2B IPv6-Route Routing Header for IPv6 RFC 2460
    44 0x2C IPv6-Frag Fragment Header for IPv6 RFC 2460
    45 0x2D IDRP Inter-Domain Routing Protocol
    46 0x2E RSVP Resource Reservation Protocol RFC 2205
    47 0x2F GRE Generic Routing Encapsulation RFC 2784, RFC 2890
    48 0x30 MHRP Mobile Host Routing Protocol
    49 0x31 BNA BNA
    50 0x32 ESP Encapsulating Security Payload RFC 4303
    51 0x33 AH Authentication Header RFC 4302
    52 0x34 I-NLSP Integrated Net Layer Security Protocol TUBA
    53 0x35 SWIPE SwIPe IP with Encryption
    54 0x36 NARP NBMA Address Resolution Protocol RFC 1735
    55 0x37 MOBILE IP Mobility (Min Encap) RFC 2004
    56 0x38 TLSP Transport Layer Security Protocol (using Kryptonet key management)
    57 0x39 SKIP Simple Key-Management for Internet Protocol RFC 2356
    58 0x3A IPv6-ICMP ICMP for IPv6 RFC 4443, RFC 4884
    59 0x3B IPv6-NoNxt No Next Header for IPv6 RFC 2460
    60 0x3C IPv6-Opts Destination Options for IPv6 RFC 2460
    61 0x3D Any host internal protocol
    62 0x3E CFTP CFTP
    63 0x3F Any local network
    64 0x40 SAT-EXPAK SATNET and Backroom EXPAK
    65 0x41 KRYPTOLAN Kryptolan
    66 0x42 RVD MIT Remote Virtual Disk Protocol
    67 0x43 IPPC Internet Pluribus Packet Core
    68 0x44 Any distributed file system
    69 0x45 SAT-MON SATNET Monitoring
    70 0x46 VISA VISA Protocol
    71 0x47 IPCU Internet Packet Core Utility
    72 0x48 CPNX Computer Protocol Network Executive
    73 0x49 CPHB Computer Protocol Heart Beat
    74 0x4A WSN Wang Span Network
    75 0x4B PVP Packet Video Protocol
    76 0x4C BR-SAT-MON Backroom SATNET Monitoring
    77 0x4D SUN-ND SUN ND PROTOCOL-Temporary
    78 0x4E WB-MON WIDEBAND Monitoring
    79 0x4F WB-EXPAK WIDEBAND EXPAK
    80 0x50 ISO-IP International Organization for Standardization Internet Protocol
    81 0x51 VMTP Versatile Message Transaction Protocol RFC 1045
    82 0x52 SECURE-VMTP Secure Versatile Message Transaction Protocol RFC 1045
    83 0x53 VINES VINES
    84 0x54 TTP TTP
    84 0x54 IPTM Internet Protocol Traffic Manager
    85 0x55 NSFNET-IGP NSFNET-IGP
    86 0x56 DGP Dissimilar Gateway Protocol
    87 0x57 TCF TCF
    88 0x58 EIGRP EIGRP
    89 0x59 OSPF Open Shortest Path First RFC 1583
    90 0x5A Sprite-RPC Sprite RPC Protocol
    91 0x5B LARP Locus Address Resolution Protocol
    92 0x5C MTP Multicast Transport Protocol
    93 0x5D AX.25 AX.25
    94 0x5E IPIP IP-within-IP Encapsulation Protocol RFC 2003
    95 0x5F MICP Mobile Internetworking Control Protocol
    96 0x60 SCC-SP Semaphore Communications Sec. Pro
    97 0x61 ETHERIP Ethernet-within-IP Encapsulation RFC 3378
    98 0x62 ENCAP Encapsulation Header RFC 1241
    99 0x63 Any private encryption scheme
    100 0x64 GMTP GMTP
    101 0x65 IFMP Ipsilon Flow Management Protocol
    102 0x66 PNNI PNNI over IP
    103 0x67 PIM Protocol Independent Multicast
    104 0x68 ARIS IBM’s ARIS (Aggregate Route IP Switching) Protocol
    105 0x69 SCPS SCPS (Space Communications Protocol Standards) SCPS-TP[1]
    106 0x6A QNX QNX
    107 0x6B A/N Active Networks
    108 0x6C IPComp IP Payload Compression Protocol RFC 3173
    109 0x6D SNP Sitara Networks Protocol
    110 0x6E Compaq-Peer Compaq Peer Protocol
    111 0x6F IPX-in-IP IPX in IP
    112 0x70 VRRP Virtual Router Redundancy Protocol, Common Address Redundancy Protocol (not IANA assigned) VRRP:RFC 3768
    113 0x71 PGM PGM Reliable Transport Protocol RFC 3208
    114 0x72 Any 0-hop protocol
    115 0x73 L2TP Layer Two Tunneling Protocol Version 3 RFC 3931
    116 0x74 DDX D-II Data Exchange (DDX)
    117 0x75 IATP Interactive Agent Transfer Protocol
    118 0x76 STP Schedule Transfer Protocol
    119 0x77 SRP SpectraLink Radio Protocol
    120 0x78 UTI Universal Transport Interface Protocol
    121 0x79 SMP Simple Message Protocol
    122 0x7A SM Simple Multicast Protocol draft-perlman-simple-multicast-03
    123 0x7B PTP Performance Transparency Protocol
    124 0x7C IS-IS over IPv4 Intermediate System to Intermediate System (IS-IS) Protocol over IPv4 RFC 1142 and RFC 1195
    125 0x7D FIRE Flexible Intra-AS Routing Environment
    126 0x7E CRTP Combat Radio Transport Protocol
    127 0x7F CRUDP Combat Radio User Datagram
    128 0x80 SSCOPMCE Service-Specific Connection-Oriented Protocol in a Multilink and Connectionless Environment ITU-T Q.2111 (1999)
    129 0x81 IPLT
    130 0x82 SPS Secure Packet Shield
    131 0x83 PIPE Private IP Encapsulation within IP Expired I-D draft-petri-mobileip-pipe-00.txt
    132 0x84 SCTP Stream Control Transmission Protocol
    133 0x85 FC Fibre Channel
    134 0x86 RSVP-E2E-IGNORE Reservation Protocol (RSVP) End-to-End Ignore RFC 3175
    135 0x87 Mobility Header Mobility Extension Header for IPv6 RFC 6275
    136 0x88 UDPLite Lightweight User Datagram Protocol RFC 3828
    137 0x89 MPLS-in-IP Multiprotocol Label Switching Encapsulated in IP RFC 4023
    138 0x8A manet MANET Protocols RFC 5498
    139 0x8B HIP Host Identity Protocol RFC 5201
    140 0x8C Shim6 Site Multihoming by IPv6 Intermediation RFC 5533
    141 0x8D WESP Wrapped Encapsulating Security Payload RFC 5840
    142 0x8E ROHC Robust Header Compression RFC 5856
    143-252 0x8F-0xFC UNASSIGNED
    253-254 0xFD-0xFE Use for experimentation and testing RFC 3692
    255 0xFF Reserved.

Streaming Media Protocol

http://www.streamingmedia.com/Articles/Editorial/What-Is-…/What-Is-a-Streaming-Media-Protocol-84496.aspx

 

 

To follow all this, I recommend adding these fields as columns:

  • TCP length (tcp.len)
  • Sequence number (tcp.seq)
  • Next expected sequence number (tcp.nxtseq)
  • Acknowledgment number (tcp.ack)

There the follwing length now:
Frame length: Total length of the Frame, including the Padding Fields (if present and needed) of the Ethernet Layer
Captured Length: Frame Length which is captured (Interresting if a filter has been used)
IP.TotalLength: Total Packet Length. from IP-Header until Layer 7 payload ends
TCP.SegmentLegth: Resulting TCP Payload and only calculated by Wireshark
TCP.HeaderLength: Is the length of the TCP Header, because header size is variabel

Identification of TCP stream in wireshark

https://www.appneta.com/blog/how-to-easily-capture-tcp-conversation-streams/

 

TSHARK

 

https://ask.wireshark.org/questions/4677/easy-way-to-save-tcp-streams

 

 

wireshark

ICN, CCN, NDN

http://named-data.net/project/faq/#What_is_Information-Centric_Networking_ICN

How does NDN differ from CDNs?

A content distribution network (CDN) is a good example of service that is implemented as an overlay on today’s TCP/IP architecture to meet the demand for scalable content distribution, when the same content is requested by many users. CDN customers tend to be relatively large content owners who are willing to pay for higher performance delivery of their content. Content producers without CDN services would face load and performance challenges if/once their content becomes popular.

CDNs operate at the application layer, which gives rise to two issues: how to get customer content requests into the CDN system (a common solution is for the CDN provider to host DNS service for the domain name of the content it serves); and mapping each request to the nearest CDN node serving the content. NDN works directly at network layer and naturally forwards Interest packets along the best paths to the desired data.

Are there any commonalities between IP and NDN architectures?

Both architectures share the same hourglass shape, with the IP/NDN layer as the narrow waist.
Both send datagrams.
Both follow end-to-end principle.
Both use their own namespace for data delivery (i.e. IP uses IP addresses to deliver datagrams between IP nodes; NDN uses the application name space to deliver datagrams between NDN nodes).

What will the role of ICN be on the Internet in 20 years? Will it be the dominant paradigm of communications?

It’s the dominant paradigm now. YouTube, Netflix, Amazon, iTunes, …, are pure ICN and account for more than half of the world’s internet traffic. But today’s ICN-over-IP is inefficient and unsecure because the information-centric overlay is a poor match to the Internet’s conversationally-oriented underlay. The Internet is also already mostly mobile devices (whose users are also content-focused), which the IP architecture does not support well.  Finally, the IP architecture was not designed to naturally support secure communication or secure data distribution. Rather than ignore the growing incongruity between the architecture and global use of the Internet, we are inspired to design, develop, and incrementally deploy an architecture that `catches up’ with the dominant paradigm of communications today.

This architectural incongruity is analogous to the one between packet-oriented IP overlay and circuit-oriented telephony underlay during the Internet’s first 20 years. Imagine the 1990 question “What will be the role of the internet in the global telephony system 20 years from now?”  We now know the answer was “the global telephony system became just one of many applications running over IP internet,” i.e., the overlay became the underlay because it did more, better. We predict we could substitute `Internet’ for `telephony system’ and `NDN/ICN’ for `IP internet’ to move the clock forward 20 years.

ICN, CCN, NDN

openstack note 1

General purpose clouds are expected to include these base services:

  • Compute
  • Network
  • Storage

Each of these services have different resource requirements.

 Compute resource design

When designing compute resource pools, a number of factors can impact your design decisions. Factors such as number of processors, amount of memory, and the quantity of storage required for each hypervisor must be taken into account.

A compute design that allocates multiple pools of resources makes best use of application resources, and is commonly referred to as bin packing.

When selecting a processor, compare features and performance characteristics. Some processors include features specific to virtualized compute hosts, such as hardware-assisted virtualization, and technology related to memory paging (also known as EPT shadowing). These types of features can have a significant impact on the performance of your virtual machine.

good or bad impact???????

You will also need to consider the compute requirements of non-hypervisor nodes (sometimes referred to as resource nodes). This includes controller, object storage, and block storage nodes, and networking services

The number of processor cores and threads impacts the number of worker threads which can be run on a resource node

Workload can be unpredictable in a general purpose cloud, so consider including the ability to add additional compute resource pools on demand

start by allocating hardware designs that are capable of servicing the most common instance requests.

Choose a networking service based on the requirements of your instances. The architecture and design of your cloud will impact whether you choose OpenStack Networking(neutron), or legacy networking (nova-network).

Management software

Selected supplemental software solution impacts and affects the overall OpenStack cloud design. This includes software for providing clustering, logging, monitoring and alerting.

Inclusion of clustering software, such as Corosync or Pacemaker, is determined primarily by the availability requirements. The impact of including (or not including) these software packages is primarily determined by the availability of the cloud infrastructure and the complexity of supporting the configuration after it is deployed. The OpenStack High Availability Guide provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design.

Requirements for logging, monitoring, and alerting are determined by operational considerations. Each of these sub-categories includes a number of various options.

 Monitoring

OpenStack clouds require appropriate monitoring platforms to ensure errors are caught and managed appropriately. Specific meters that are critically important to monitor include:

  • Image disk utilization
  • Response time to the Compute API

Leveraging existing monitoring systems is an effective check to ensure OpenStack environments can be monitored.

Assessing the average workloads and increasing the number of instances that can run within the compute environment by adjusting the overcommit ratio is another option. It is important to remember that changing the CPU overcommit ratio can have a detrimental effect and cause a potential increase in a noisy neighbor. The additional risk of increasing the overcommit ratio is more instances failing when a compute host fails.

 OpenStack components

A general purpose OpenStack cloud design should incorporate the core OpenStack services to provide a wide range of services to end-users. The OpenStack core services recommended in a general purpose cloud are:

A general purpose cloud may also include OpenStack Object Storage (swift). OpenStack Block Storage (cinder). These may be selected to provide storage to applications and instances.

An overcommit ratio is the ratio of available virtual resources to available physical resources. This ratio is configurable for CPU and memory. The default CPU overcommit ratio is 16:1, and the default memory overcommit ratio is 1.5:1. Determining the tuning of the overcommit ratios during the design phase is important as it has a direct impact on the hardware layout of your compute nodes.

Network architecture

When you design an OpenStack network architecture, you must consider layer-2 and layer-3 issues. Layer-2 decisions involve those made at the data-link layer, such as the decision to use Ethernet versus Token Ring. Layer-3 decisions involve those made about the protocol layer and the point when IP comes into the picture. As an example, a completely internal OpenStack network can exist at layer 2 and ignore layer 3. In order for any traffic to go outside of that cloud, to another network, or to the Internet, however, you must use a layer-3 router or switch.

The past few years have seen two competing trends in networking. One trend leans towards building data center network architectures based on layer-2 networking. Another trend treats the cloud environment essentially as a miniature version of the Internet. This approach is radically different from the network architecture approach in the staging environment: the Internet only uses layer-3 routing rather than layer-2 switching.

A network designed on layer-2 protocols has advantages over one designed on layer-3 protocols. In spite of the difficulties of using a bridge to perform the network role of a router, many vendors, customers, and service providers choose to use Ethernet in as many parts of their networks as possible. The benefits of selecting a layer-2 design are:

  • Ethernet frames contain all the essentials for networking. These include, but are not limited to, globally unique source addresses, globally unique destination addresses, and error control.
  • Ethernet frames can carry any kind of packet. Networking at layer 2 is independent of the layer-3 protocol.
  • Adding more layers to the Ethernet frame only slows the networking process down. This is known as ‘nodal processing delay’.
  • You can add adjunct networking features, for example class of service (CoS) or multicasting, to Ethernet as readily as IP networks.
  • VLANs are an easy mechanism for isolating networks.

Most information starts and ends inside Ethernet frames. Today this applies to data, voice (for example, VoIP), and video (for example, web cameras). The concept is that, if you can perform more of the end-to-end transfer of information from a source to a destination in the form of Ethernet frames, the network benefits more from the advantages of Ethernet. Although it is not a substitute for IP networking, networking at layer 2 can be a powerful adjunct to IP networking.

Layer-2 Ethernet usage has these advantages over layer-3 IP network usage:

  • Speed
  • Reduced overhead of the IP hierarchy.
  • No need to keep track of address configuration as systems move around. Whereas the simplicity of layer-2 protocols might work well in a data center with hundreds of physical machines, cloud data centers have the additional burden of needing to keep track of all virtual machine addresses and networks. In these data centers, it is not uncommon for one physical node to support 30-40 instances.
[Important] Important
Networking at the frame level says nothing about the presence or absence of IP addresses at the packet level. Almost all ports, links, and devices on a network of LAN switches still have IP addresses, as do all the source and destination hosts. There are many reasons for the continued need for IP addressing. The largest one is the need to manage the network. A device or link without an IP address is usually invisible to most management applications. Utilities including remote access for diagnostics, file transfer of configurations and software, and similar applications cannot run without IP addresses as well as MAC addresses.

 Layer-2 architecture limitations

Outside of the traditional data center the limitations of layer-2 network architectures become more obvious.

  • Number of VLANs is limited to 4096.
  • The number of MACs stored in switch tables is limited.
  • You must accommodate the need to maintain a set of layer-4 devices to handle traffic control.
  • MLAG, often used for switch redundancy, is a proprietary solution that does not scale beyond two devices and forces vendor lock-in.
  • It can be difficult to troubleshoot a network without IP addresses and ICMP.
  • Configuring ARP can be complicated on large layer-2 networks.
  • All network devices need to be aware of all MACs, even instance MACs, so there is constant churn in MAC tables and network state changes as instances start and stop.
  • Migrating MACs (instance migration) to different physical locations are a potential problem if you do not set ARP table timeouts properly.

It is important to know that layer 2 has a very limited set of network management tools. It is very difficult to control traffic, as it does not have mechanisms to manage the network or shape the traffic, and network troubleshooting is very difficult. One reason for this difficulty is network devices have no IP addresses. As a result, there is no reasonable way to check network delay in a layer-2 network.

 Layer-3 architecture limitations

The main limitation of layer 3 is that there is no built-in isolation mechanism comparable to the VLANs in layer-2 networks. Furthermore, the hierarchical nature of IP addresses means that an instance is on the same subnet as its physical host. This means that you cannot migrate it outside of the subnet easily. For these reasons, network virtualization needs to use IP encapsulation and software at the end hosts for isolation and the separation of the addressing in the virtual layer from the addressing in the physical layer. Other potential disadvantages of layer 3 include the need to design an IP addressing scheme rather than relying on the switches to keep track of the MAC addresses automatically and to configure the interior gateway routing protocol in the switches.

http://docs.openstack.org/arch-design/content/arch-design-references.html

http://docs.openstack.org/openstack-ops/content/logging_monitoring.html

http://manageiq.org/

Monitoring

There are two types of monitoring: watching for problems and watching usage trends. The former ensures that all services are up and running, creating a functional cloud. The latter involves monitoring resource usage over time in order to make informed decisions about potential bottlenecks and upgrades.

Nagios

Nagios is an open source monitoring service. It’s capable of executing arbitrary commands to check the status of server and network services, remotely executing arbitrary commands directly on servers, and allowing servers to push notifications back in the form of passive monitoring. Nagios has been around since 1999. Although newer monitoring services are available, Nagios is a tried-and-true systems administration staple.

 Resource Alerting

Resource alerting provides notifications when one or more resources are critically low. While the monitoring thresholds should be tuned to your specific OpenStack environment, monitoring resource usage is not specific to OpenStack at all—any generic type of alert will work fine.

Some of the resources that you want to monitor include:

  • Disk usage
  • Server load
  • Memory usage
  • Network I/O
  • Available vCPUs

 OpenStack-Specific Resources

Resources such as memory, disk, and CPU are generic resources that all servers (even non-OpenStack servers) have and are important to the overall health of the server. When dealing with OpenStack specifically, these resources are important for a second reason: ensuring that enough are available to launch instances. There are a few ways you can see OpenStack resource usage. The first is through the nova command:

# nova usage-list

This command displays a list of how many instances a tenant has running and some light usage statistics about the combined instances. This command is useful for a quick overview of your cloud, but it doesn’t really get into a lot of details.

Next, the nova database contains three tables that store usage information.

The nova.quotas and nova.quota_usages tables store quota information. If a tenant’s quota is different from the default quota settings, its quota is stored in the nova.quotas table. For example:

mysql> select project_id, resource, hard_limit from quotas;
+----------------------------------+-----------------------------+------------+
| project_id                       | resource                    | hard_limit |
+----------------------------------+-----------------------------+------------+
| 628df59f091142399e0689a2696f5baa | metadata_items              | 128        |
| 628df59f091142399e0689a2696f5baa | injected_file_content_bytes | 10240      |
| 628df59f091142399e0689a2696f5baa | injected_files              | 5          |
| 628df59f091142399e0689a2696f5baa | gigabytes                   | 1000       |
| 628df59f091142399e0689a2696f5baa | ram                         | 51200      |
| 628df59f091142399e0689a2696f5baa | floating_ips                | 10         |
| 628df59f091142399e0689a2696f5baa | instances                   | 10         |
| 628df59f091142399e0689a2696f5baa | volumes                     | 10         |
| 628df59f091142399e0689a2696f5baa | cores                       | 20         |
+----------------------------------+-----------------------------+------------+

The nova.quota_usages table keeps track of how many resources the tenant currently has in use:

mysql> select project_id, resource, in_use from quota_usages where project_id like '628%';
+----------------------------------+--------------+--------+
| project_id                       | resource     | in_use |
+----------------------------------+--------------+--------+
| 628df59f091142399e0689a2696f5baa | instances    | 1      |
| 628df59f091142399e0689a2696f5baa | ram          | 512    |
| 628df59f091142399e0689a2696f5baa | cores        | 1      |
| 628df59f091142399e0689a2696f5baa | floating_ips | 1      |
| 628df59f091142399e0689a2696f5baa | volumes      | 2      |
| 628df59f091142399e0689a2696f5baa | gigabytes    | 12     |
| 628df59f091142399e0689a2696f5baa | images       | 1      |
+----------------------------------+--------------+--------+

By comparing a tenant’s hard limit with their current resource usage, you can see their usage percentage. For example, if this tenant is using 1 floating IP out of 10, then they are using 10 percent of their floating IP quota. Rather than doing the calculation manually, you can use SQL or the scripting language of your choice and create a formatted report:

+----------------------------------+------------+-------------+---------------+
| some_tenant                                                                 |
+-----------------------------------+------------+------------+---------------+
| Resource                          | Used       | Limit      |               |
+-----------------------------------+------------+------------+---------------+
| cores                             | 1          | 20         |           5 % |
| floating_ips                      | 1          | 10         |          10 % |
| gigabytes                         | 12         | 1000       |           1 % |
| images                            | 1          | 4          |          25 % |
| injected_file_content_bytes       | 0          | 10240      |           0 % |
| injected_file_path_bytes          | 0          | 255        |           0 % |
| injected_files                    | 0          | 5          |           0 % |
| instances                         | 1          | 10         |          10 % |
| key_pairs                         | 0          | 100        |           0 % |
| metadata_items                    | 0          | 128        |           0 % |
| ram                               | 512        | 51200      |           1 % |
| reservation_expire                | 0          | 86400      |           0 % |
| security_group_rules              | 0          | 20         |           0 % |
| security_groups                   | 0          | 10         |           0 % |
| volumes                           | 2          | 10         |          20 % |
+-----------------------------------+------------+------------+---------------+

The preceding information was generated by using a custom script that can be found on GitHub.

 Trending

Trending can give you great insight into how your cloud is performing day to day. You can learn, for example, if a busy day was simply a rare occurrence or if you should start adding new compute nodes.

Trending takes a slightly different approach than alerting. While alerting is interested in a binary result (whether a check succeeds or fails), trending records the current state of something at a certain point in time. Once enough points in time have been recorded, you can see how the value has changed over time.

All of the alert types mentioned earlier can also be used for trend reporting. Some other trend examples include:

  • The number of instances on each compute node
  • The types of flavors in use
  • The number of volumes in use
  • The number of Object Storage requests each hour
  • The number of nova-api requests each hour
  • The I/O statistics of your storage services

As an example, recording nova-api usage can allow you to track the need to scale your cloud controller. By keeping an eye onnova-api requests, you can determine whether you need to spawn more nova-api processes or go as far as introducing an entirely new server to run nova-api. To get an approximate count of the requests, look for standard INFO messages in/var/log/nova/nova-api.log:

# grep INFO /var/log/nova/nova-api.log | wc

You can obtain further statistics by looking for the number of successful requests:

# grep " 200 " /var/log/nova/nova-api.log | wc

By running this command periodically and keeping a record of the result, you can create a trending report over time that shows whether your nova-api usage is increasing, decreasing, or keeping steady.

A tool such as collectd can be used to store this information. While collectd is out of the scope of this book, a good starting point would be to use collectd to store the result as a COUNTER data type. More information can be found in collectd’s documentation.

——————————-install etherpad————————————————-

Feature requests typically start their life in Etherpad, a collaborative editing tool, which is used to take coordinating notes at a design summit session specific to the feature.

https://github.com/ether/etherpad-lite#installation

for etherpad, Additionally, you’ll need node.js installed, Ideally the latest stable version, we recommend installing/compiling nodejs from source (avoiding apt).

https://www.digitalocean.com/community/tutorials/how-to-install-node-js-on-an-ubuntu-14-04-server

How To Install Using a PPA

——————————-install etherpad————————————————

how to interact with openstack

http://docs.openstack.org/openstack-ops/content/upstream_openstack.html

TBD

openstack note 1

reference reading: Survey on caching approaches in Information Centric Networking //2015

Abstract

Determining what part of the content is to be cached? When is the most appropriate time for caching?
How would the object be cached (placed and replaced) and also what path would the object be cached?
Thus, this paper span through some selected ICN architectures and projects to investigate and suggest
forms of caching in minimizing the total bandwidth consumption, enhanced Delivery of Service (DoS),
reduced upwards and downward streaming.

The caching influencing factors can further be elabo-rated as:

(a) Frequency – in number terms, how many requests are posted or how frequent is an object requested for?
(b) Recency – the time an object or content was referred to or demanded for
(c) Size – the size of a content
(d) Cost of retrieval – the cost incurred to retrieve the content or object
(e) Time of update – a modification in the cache
(f) Replacement – the best time a content becomes less relevant

reference reading: Survey on caching approaches in Information Centric Networking //2015

paper writing

 reading

1st  title abstract intro headings conclusion refs

2nd section figure

3st detail

an app named myline?

writing

 put the most info at first of paragraph, for example the result including percent data

introduction

  1. motivation: broadly what is problem area why important
  2. narrow down what si problem you specifically consider 
  3. in the paper,…..most crucial para, tell your elevator pitch
  4. how different /better /relate to other work
  5. structure 

only put topic sentences related information into a single para

figs lists are better than text 

remove words para unnecessary 

less is more 

if you delete something and nothing changed , delete it 

clearly state your assumption what your work build on

state experiment condition 

recommendation

the elements of style 

writing for computer science,

writing paper while doing research helps you find which part is unnecessary 

bullet point list of contribution in the intro on first page to help them to fill the review forms especially in the strengths part

mindmap 

10.27

Keywords: Enter key words or phrases in alphabetical order, separated by commas.

paper writing