Electronic Platform Information Console
Page tree
Skip to end of metadata
Go to start of metadata

Client INTERNETLink is implemented using a virtual private network (VPN) connection. A VPN is a secure, point-to-point connection between a client and the CME Group data centers. Unlike a direct Wide Area Network (WAN) connection over a costly, leased facility, VPN traffic is carried over the Internet using tunneling technology. Customers will be configured with a VPN to CME Group's production data center. When CME Group goes into DR mode, CME Group will port the CME side of the VPN to the CME Group DR data center. No changes are required on the customer side of the configuration.

A VPN connection is created using IPSec, the Internet standard protocol for tunneling, encryption, and authentication. It protects data traffic by addressing basic usage issues, including:

  • Access control
  • Connection integrity
  • Authentication of data origin
  • Protections against replays
  • Traffic flow confidentiality

The technique used to protect data being transmitted over the Internet is encryption. Data is scrambled (encrypted) when transmitted then it is unscrambled (decrypted) when it is received. An encryption algorithm determines how the data is encrypted and decrypted.

A key is the secret code that the encryption algorithm uses to create a unique version of encrypted data. Keys are rated by their cryptographic strength. The cryptographic strength of a key refers to the length of the key in bits.
The Internet Key Exchange (IKE) management protocol standard is used in conjunction with the IPSec standard. IKE is a hybrid protocol that implements the Oakley key exchange and Skeme key exchange inside the Internet security association and key management protocol (ISAKMP) framework. IKE authenticates the IPSec peers, negotiates IPSec keys, and negotiates Security Associations (SAs).
For site-to-site VPN connections, peer devices must authenticate one another before IPSec communications can occur. CME Group uses a Pre-Shared Key (PSK) for device authentication. PSK is the most efficient IKE authentication mechanism.
A unique PSK is the most secure type of PSK since it is tied to a specific IP address. This is ideal for site-to-site VPNs where the identity of the peer device is always known. CME Group will generate and provide customers with a unique key.

Please review the prerequisites below to determine any services, addressing tasks, software, or hardware that your firm must have available or complete prior to enabling multicast connectivity for Client INTERNETLink access to the CME Group production environment.
CME Group does not require customers to use specific consultant vendors. If internal resources are not available, customers are responsible for engaging resources to establish and support connectivity to CME Group.

Customers must provide a high-speed connection to the Internet. The connection must meet the following criteria:

  • The registered IP address must be static and publicly routable on the Internet.
  • Internet with speed at least equal to the CIL subscriber rate
  • Your Internet service provider (ISP) must support VPN protocols.

The VPN software on your device or service must support the following encryption requirements:

  • PSK for Internet Security Association and Key Management Protocol (ISAKMP)/IKE
  • 3DES/SHA1 encryption or stronger for phase 1
  • AES256/SHA1 encryption or stronger phase 2

The device prerequisites vary slightly depending on whether existing devices will be leveraged. The following sections describe the two tunneling configuration options that can be used to create the VPN. To support MDP redundancy, you may want to configure a second device.

  • Option 1 uses separate units for VPN and GRE tunneling.
  • Option 2 uses a single unit for VPN and GRE tunneling.

Customers that choose to utilize a device or service that does not support GRE tunnel encapsulation, will have to separate the IPsec and GRE termination between 2 endpoints.


Figure: Customer-Side Connections for Option 1

This option requires separate VPN and GRE tunneling endpoints.

New CME Group customers and those CME Group customers without previous experience accessing the CME Group production environment may be building a CME Group connection for the first time. Therefore, these users have the opportunity to incorporate a device or service combining VPN and GRE technologies. 



Figure: Customer-Side Connections for Option 2

This option requires a device or service capable of the following: ipsec/isakmp crypto, ip multicast, GRE (for market data) CME Group does not make hardware or software recommendations. Customers should contact their network vendor.

Upon successful validation of the physical circuit and site acceptance by CME Group, the customer is responsible for the following procedures:

  • Activating the multicast stream
  • Configuring the listener device on the arbitration server
  • Configuring routers
  • Configuring of the rendezvous point's IP address
  • Configuring a fixed path between each router and corresponding CME Group data center
  • Validating that the listener server is receiving data from the correct source

The following configuration procedures describe how to manage the behavior of the data feed routes.

To activate the multicast stream, contact CME Global Account Managementt.

On each listener server on the CME Group-defined subnet that is associated with the CME Group data center, define the port and multicast addresses associated with the channel of the selected contract type and CME Group data center.

To locate port and multicast addresses, refer to the CME Globex Market Data Platform Production and Replay Channel Definitions via the FTP site:  CME Globex Market Data Platform Production Channel DefinitionsMarket Data - FTP Site Information.

The customer routers must be configured to PIM (protocol independent multicast) sparse mode (PIM-SM). PIM-SM uses an explicit request approach, where a router has to ask for the multicast feed with a PIM Join message. PIM-SM allows customer to more precisely control traffic, especially if you have large volumes of IP multicast traffic compared to your bandwidth. PIM-SM scales well because packets only go where they are needed, and because it creates state in routers only as needed. Your The assigned CME Networking engineer provides the data center IP addresses.

  1. For each router interface connected to a CME Group data center, enable PIM-SM using the following command: ip pim sparse-mode
  2. Refer to the example as needed:

    interface Ethernet4/0
    ip address IP_address IP_subnet_address
    ip pim sparse-mode


On each customer side router, such as Customer-Managed Router 1, define the IP address of the corresponding rendezvous point, such as Rendezvous Point 1, which points to a CME Group data center such as CME Data Center 1. Your CME Group account representative provides the rendezvous point IP addresses.

  1. For each router interface connected to a CME Group data center, define the rendezvous point address using the following command: ip pim rp-address rp_address [access-list]
  2. Refer to the example, as needed:

ip pim rp-address rp_address [access-list]

The route, or path, of the data feed must be static between each data center and customer-managed router. Customers must define certain router features to ensure the predictability of this path.

  1. Use the following command: ip pim spt-threshold {kbps | infinity} [group-list access-list]
  2. Refer to the example: ip pim spt-threshold infinity
  • The default value is 0, which causes the router to join the SPT immediately upon the first data packet it receives.
  • Specifying the infinity keyword causes the router never to move to the shortest-path tree; it remains on the shared tree. This keyword applies to a multicast environment of "many-to-many" communication.
  • Standard implementation of PIM entails the automatic definition of one of the routers as the designated router. Under PIM, the designated router represents all routers sharing the same subnet address and is the normal terminus for inbound and outbound packets. All other routers on the subnet are used on an exception basis.
  • To ensure that both customer-side routers regularly exchange inbound and outbound packets with their corresponding rendezvous points and CME Group data centers, customers must disable the designated router feature.
  1. Use the following command:  ip pim neighbor-filter access-list
  2. Refer to the example, as needed:

    interface Ethernet4/3
    ip address IP_address
     ip pim neighbor-filter 77
     ip pim sparse-mode
     …
     …
     …
    access-list 77 deny any
  1. Verify that the feeds are working by temporarily using a static join command on the router Ethernet interface facing the customer LAN:

    ip igmp static-group group_address
     
  2. After entering the static join command, use a show command to verify that the multicast feed is being forwarded:

    show ip mroute
     
  3. Review the output from the command. It will look similar to the following:

    (, 239.37.50.1), 1w3d/stopped, RP 10.128.0.1, flags: SJCF
    Incoming interface: Port-channel11, RPF nbr 192.168.1.1, Partial-SC
    Outgoing interface list:
    Vlan10, Forward/Sparse, 04:16:14/00:02:47, H

     Where 239.37.50.1 represents the channel that your router has joined and RP 10.128.0.1 represents the rendezvous point address associated with the router. Compare the displayed multicast address to the multicast address of the intended channel. To locate port and multicast addresses, refer to the CME Globex Market Data Platform Production and Replay Channel Definitions via the FTP site:  CME Globex Market Data Platform Production Channel DefinitionsMarket Data - FTP Site Information.
  4. Remove the IGMP static group command.

ip multicast-routing
!
ip pim spt-threshold infinity
!
interface <LAN interface>
ip pim sparse-mode
ip pim neighbor-filter PIMFilter
!
interface <WAN interface>
ip pim sparse-mode
!
ip pim rp-address <CME RP> DC1_WAN
!
ip access-list standard PIMFilter
deny any
!
ip access-list standard DC1_WAN

permit 233.119.160.0 0.0.0.63

permit 233.72.75.0 0.0.0.63

permit 224.0.26.0 0.0.0.255

permit 224.0.31.0 0.0.0.255

permit 224.0.33.0 0.0.0.255

deny any