- play_arrow Overview
- play_arrow Circuit to Packet System Overview
-
- play_arrow Installation
- play_arrow Installation Tasks Overview
- play_arrow Installation and Upgrade Tasks for the CTPView Server OS and CTPView Software
- Installing or Upgrading the CTPView Server OS
- Saving the CTPView Configuration Settings and Data (CTPView Server Menu)
- Creating More Disk Space on the CTPView Server (CTPView)
- Creating More Disk Space on the CTPView Server (CTPView Server Menu)
- Installing the CTPView Server OS (CTPView Server CLI)
- Restoring CTPView Software Configuration Settings and Data (CTPView)
- Restoring CTPView Software Configuration Settings and Data with the Restore Utility (CTPView Server Menu)
- Restoring CTPView Software Data by Manually Synchronizing the CTPView Server (CTPView)
- Reviewing the Installation Log for Errors (CTPView Server CLI)
- Verifying the CTPView Server OS Installation (CTPView)
- Validating the CTPView Server Configuration (CTPView)
- play_arrow Upgrade Tasks for Only the CTPView Software
- play_arrow Configuration Tasks for CTPView Administrative Settings
- Configuring the CTPView Administrative Settings
- Preparing a New Server
- Changing the BIOS Menu Password (CTPView Server CLI)
- Changing the Server's Default User Account Password (CTPView Server CLI)
- Changing the Server's Root Account Password (CTPView Server CLI)
- Changing the GRUB Boot Loader Password (CTPView Server Menu)
- Changing the PostgreSQL Apache Account Password (CTPView Server Menu)
- Changing the PostgreSQL Administrator Account Password (CTPView Server Menu)
- Configuring the Network Access (CTPView Server Menu)
- Creating a Self-Signed Web Certificate (CTPView Server Menu)
- Renewing a Self-Signed Web Certificate (CTPView Server Menu)
- Updating the CTPView Software
- Logging In with a Browser (CTPView)
- Changing the CTPView GUI Default User Account Password (CTPView)
- Creating a New Global_Admin Account (CTPView)
- Changing the User Password (CTP Menu)
- Enabling OpenSSL Authentication of Users by Creating a Self-Signed Web Certificate (CTPView Server Menu)
- Importing Certificates Issued by a Third-Party CA (CTPView Server Menu)
- Configuring Subdomains in Hostnames (CTPView Server Menu)
- play_arrow Configuring the CTPView Server on Virtual Machines
- Guidelines for Configuring Virtual CTPView Servers on VMware ESX Servers
- CTPView Servers on Virtual Machines Overview
- Creating a Virtualized Instance of CTPView Server on a Hyper-V Server
- Creating a Virtualized Instance of CTPView Server on an ESX Server
- Creating a Virtualized Instance of CTPView 9.3Rx Server on Proxmox Server
- play_arrow Upgrade Tasks for CTPOS
- play_arrow Default Accounts and Passwords
- play_arrow Understanding CTPView Upgrade Files
-
- play_arrow Troubleshooting
- play_arrow Validating the CTPView Server System Configuration
- play_arrow Restoring CLI Access to the CTPView Server
- Restoring Access to a CTPView Server
- Accessing a Shell on the CTPView Server (CTPView Server CLI)
- Setting a New Password for a Nonroot User Account (CTPView Server CLI)
- Setting a New Password for a Root User Account (CTPView Server CLI)
- Creating a Nonroot User Account and Password (CTPView Server CLI)
- play_arrow Restoring Browser Access to a CTPView Server
- play_arrow Changing a CTPOS User Password
- play_arrow Booting the CTPView Server from the CD-ROM Drive
- play_arrow Restarting the Apache Daemon In the Event of Browser Issues
- play_arrow Displaying Jitter Statistics in MIBs and Supporting Acorn MIB for Daemon Model
- play_arrow Knowledge Base
-
Separate Interfaces for Management and Circuit Traffic Overview
Until CTPOS and CTPView Release 7.1, only one network device (the default device) is used for both management and circuit data. In certain network topologies, a segregation is required between the circuit or Ethernet traffic and management traffic. Therefore, separate interfaces need to be used for the management and circuit networks so that traffic segregation can be achieved at the physical interface level. Starting with CTPOS Release 7.2, support for configuring two default gateways, one for management traffic and the other for circuit device, is available, which enables circuit and management traffic to be segregated.
The functionality to segregate management and circuit traffic requires at least two Ethernet devices—one for circuit traffic and the other for management traffic. When this feature is enabled, both management and circuit interfaces are required to be configured. Segregation of traffic is performed on the basis of the management and circuit device or interface. CTP devices that support two default gateways are required—one for management device and other for circuit device. Each interface replies to incoming packets via its own default gateway. All incoming and outgoing packets in the circuit network traverse through the circuit device gateway (main default gateway). All incoming and outgoing packets in the management network traverse through the management device gateway.
For having two default gateways, policy-based routing is required. Policy-based routing enables the creation of multiple routing tables, one for each interface. Policy-based routing provides a flexible mechanism for forwarding data packets based on polices configured by a network administrator. This capability enables you to implement policies that selectively cause packets to take different paths. For circuit traffic, the main routing table, inet.0 is referred and for management traffic, the newly-created policy-based routing table is referred. The policy-based routing table is used, based on a set of rules. Using the main routing table for circuit device enables any IP table-related changes for the SAToP and CESoPSN bundles to be avoided. An entry of this newly created policy-based routing table is stored at /etc/iproute2/rt_tables.
The “IPV4 configuration” under “Config Network Settings” menu is modified to enable the configuration of different interfaces for management traffic and circuit or Ethernet traffic. The Display network settings menu is modified to display the circuit and management network devices. A separate conf file is implemented to indicate the status of this feature (whether it is enabled or not). Apart from feature status, this configuration file also stores information related to circuit and management device. With this feature to distinguish management and circuit traffic, Ethernet failover is supported only on the circuit interface and not on the management interface. This feature cannot be activated during the first boot process.
After the management device is selected, a new policy based routing table is created for this device. For example, if the routine table is named 10 tab-eth0, 10 denotes the route table number and tab-eth0 signifies the route table name created for management device eth0. This table is referred according to the rule specified in the rule-eth0 file.
The following command displays the main route table and the newly created policy based route table “tab-eth0”:
[root@ctp_90 ctp_cmd 2]# ip route show tab main 1.1.1.0/24 dev eth0 scope link 10.216.118.0/23 dev eth1 scope link 169.254.0.0/16 dev eth1 scope link 127.0.0.0/8 dev lo scope link default via 10.216.119.254 dev eth1
[root@ctp_90 ctp_cmd 3]# ip route show tab tab-eth0 1.1.1.0/24 dev eth0 scope link default via 1.1.1.3 dev eth0
The following command displays the rules added for the policy-based route table:
[root@ctp_90 ctp_cmd 4]# ip rule show 0: from all lookup local 32764: from all to 1.1.1.1 lookup tab-eth0 32765: from 1.1.1.1 lookup tab-eth0 32766: from all lookup main 32767: from all lookup 253
When this feature is disabled, the IP config/query section in the CTP Menu does not display the option for segregating management and circuit traffic.
Operations Performed When Management and Circuit Traffic Are Segregated
When you activate the feature to separate management and circuit traffic, you are prompted to enter the default circuit and default management device. If you enter the same device for both management and circuit devices, an error message is displayed stating that you need to define different devices for circuit and management traffic. When you enter a correct management device (say ethX), a reference for the policy-based routing table is created for management device. An entry of its route-table number and route-table name is added in /etc/iproute2/rt_tables. This route table is referred for the management device according to the rule specified by its rule file (rule-ethX).
After you configure the management device, a route entry for its own subnet and a default gateway route for that device is added to the route- ethX file. Rules are added to rule-ethX file to handle the inbound and outbound packets through this network. The rule-ethX file contains the rules such that if any packet arrives for the management network or if any packet is originated from the management network IP address, then such a packet is transmitted through the management device gateway. An existing configuration file, /etc/sysconfig/ctp, is used to store this feature configuration. The configuration of this feature contains the status of this feature, circuit device name, and management device name.
The following example illustrates the contents of the /etc/sysconfig/ctp file:
[root@ctp_90 ctp_cmd 5]# cat /etc/sysconfig/ctp CTP=yes TARGET=yes CTP_IP_PROTO=0 status=1 ckt_dev=eth0 mgmt_dev=eth1
When you disable this feature, the policy-based route table and the rules corresponding to that route table are deleted from the system and the system is configured as it was configured previously (with one default gateway). The route-ethX file and rule-ethX files are also be deleted from the system after the feature is disabled.
This feature is not supported with IPv6-only or independent IPv6 (and not a combination of IPv4 and IPv6) configuration. This limitation denotes that with IPv6 configuration settings specified on a CTP device, the option to separate management and circuit traffic is not available for configuration. If this feature is enabled on CTP150 devices, Ethernet failover cannot be activated because CTP150 devices contain only two Ethernet devices and the PCI mezzanine card (PMC) is not supported on such devices.