To build in redundancy and eliminate the need to schedule an outage when a Transit Gateway router must down for maintenance, there is a new redundant GRE type, which is essentially a grouping of at least two GRE tunnels that can connect to classic or VPC networks. This connection type allows GRE tunnels to be placed on different devices in the same zone and not flag overlapping routes that are in the redundant GRE's tunnels. For more information, see Creating a redundant GRE tunnel.

New commands:

• tg connection-rgre-create - Create a redundant GRE.
• tg redundant-gre-tunnel-add - Add a tunnel to a redundant GRE.
• tg redundant-gre-tunnel-remove - Remove a tunnel from a redundant GRE.

To improve performance and reliability, the ibmcloud tg connections command has been enhanced to support pagination. With pagination, if you have more connections than the requested limit (default: 100, maximum 500) only the number of connections within the size limit are returned, sorted by date with the oldest first.

To avoid disruption, upgrade your CLI version and update your tooling that uses CLI to handle the pagination. To test that your tooling handles pagination correctly, set the limit size on the ibmcloud tg connections command. For more information, see Preparing for connection lists pagination support.

You can use an unbound Generic Routing Encapsulation (GRE) tunnel connection to connect endpoints, which allows a transit gateway to connect to overlay networks hosted on classic infrastructure resource.

New tg connection-create-gre command options:

• base-network-type - Network type of the base connection (classic). For use only with the unbound_gre_tunnel network type.
• network-account-id - ID of account to connect to a classic connection. For use only with the classic type when the account of the connection is different than the gateway's account.
• network-type - Network type of the GRE connection. Values are gre_tunnel or unbound_gre_tunnel. The default value is gre_tunnel.