Closed zlion closed 3 weeks ago
Performed debugging into this problem and it turns out the pairing-key has been passed to the I2 virtual networks. But the Virtual Network seems not making handshake correctly. I will open a ticket to VirtualNetwork team to fix it.
My recent tests tried to make L3 connection between GCP and Fabric via AL2S. The request to VirtualNetwork API contains all required parameters including pairing-key as shown below. authnConfig": { "md5": "0xzsEwC7xk6c1fK_h.xHyAdx" }, "authnType": "MD5", "authoringState": "LIVE", "bfdEnable": true, "cloudConnectionConfig": { "pairingKey": "dd0d3dae-de0f-46ab-8817-a10668eeabe4/us-east4/any" }, "cloudConnectionType": "GCP", "displayPosition": 1, "encapsulationType": "DOT1Q", "gtsmEnable": true, "interfaceId": "e7a2d767-83f6-4013-a928-f90f988db419", "ipv4PrefixLength": 30, "ipv6PrefixLength": 0, "localIPv4": "192.168.100.1", "localIPv6": null, "maxBandwidth": 50, "mtu": 9001, "notes": null, "remoteASN": "16550", "remoteIPv4": "192.168.100.2", "remoteIPv6": null, "remoteName": "Google Cloud Platform", "virtualRouterId": "55079d58-fbeb-47c4-97ce-a682dc394a92", "vlanInnerId": 0, "vlanOuterId": "100" The response looks all right. "json": { "actions": [ "vl3c_create", "vl3c_delete", "vl3c_retrieve", "vl3c_update" ], "authnConfig": { "md5": "0xzsEwC7xk6c1fK_h.xHyAdx" }, "authnType": "MD5", "authoringState": "LIVE", "bfdEnable": true, "bgpStatusIPv4": "UNKNOWN", "bgpStatusIPv6": "UNKNOWN", "cloudConnectionConfig": { "pairingKey": "dd0d3dae-de0f-46ab-8817-a10668eeabe4/us-east4/any" }, "cloudConnectionType": "GCP", "display": "VNL3C-10634", "displayPosition": 1, "encapsulationType": "DOT1Q", "gnocdbInterfaceId": "", "gtsmEnable": true, "interfaceId": "e7a2d767-83f6-4013-a928-f90f988db419", "ipv4PrefixLength": 30, "ipv6PrefixLength": 0, "localASN": 55038, "localIPv4": "192.168.100.1", "localIPv6": null, "maxBandwidth": 50, "mtu": 9001, "name": 10634, "notes": "", "provisioningDetails": "", "provisioningState": "PENDING", "remoteASN": 16550, "remoteIPv4": "192.168.100.2", "remoteIPv6": null, "remoteName": "Google Cloud Platform", "subintId": 100, "virtualL3ConnectionId": "db4a7937-5510-4bbe-8ed6-0dd6abbe2d87", "virtualRouterId": "55079d58-fbeb-47c4-97ce-a682dc394a92", "vlanInnerId": 0, "vlanOuterId": 100 }, The VirtualNetwork portal also show both connections are provisioned. But the GCP console shows it still waits for service provider (VirtualNetworks) to accept it and ping message can not get through. Could you please take a look? Thanks. (edited) Screen Shot 2024-03-11 at 1.08.54 PM.png
Got response from I2 VirtualNetworks as shown below. Basically, GCP is not completely automatically and Matt will help me with a temporary fix. I will test it again and verify it is fixe.
las, GCP is still not fully automated. I can complete. I’ve been avoiding doing FABRIC because you often do create/delete pairs as part of testing.
[1:22](https://internet2.slack.com/archives/C0604JMV8Q7/p1710181347667709)
if I know in advance when you might want to show off or demo, I can be sure to react quickly too (should you want to do that next week; I should be in San Diego too)
[1:23](https://internet2.slack.com/archives/C0604JMV8Q7/p1710181381224829)
Anyway, I’ll complete this one so you can see it come up (and make sure all the parameters are there)
I had conversation with I2 engineer in slack. In summary, GCP automation will not be accomplished before the Knit8. We need to ask I2 engineer to manually configure it and that would be done within one day.
So keep this issue open and continue to work on it after the GCP automation is done.
Some key configuration parameters: MTU: 1460 MD5: True BFD: True
As of now, the GCP automation remains unfinished, as reported by Internet2 engineers.
Updated from Internet2
The GCP stuff is in testing as of yesterday. I have been busy with
TechEx proposals today, but intend to give it a try, likely tomorrow.
Assuming it is close, I would guess +/- 2 weeks until general release?
I'll give you a heads up if it looks like there are issues.
--Matt
Ping can not get through for both native GCP and SENSE GCP cases.
The reason is that the VLAN Attachment is not accepted on the Fabric side.