GCP hybrid connectivity: ping from customer router to VPC












0















I'm using a partner connection (hybrid connectivity) to my VPC where I do manage the BGP peering. The router entity is automatically created by GCP in MANAGED_BY_ATTACHMENT mode so I cannot specify which addresses are used for peering.



From my router (169.254.61.250) I can ping a host in the VPC but the return traffic is filtered. I don't know if this is expected:




  • The next trace is captured in a host in the VPC


root@bd-ecs-gcp-host1:~# tcpdump -nl -i ens4 "( tcp port 22 or icmp ) and host 169.254.61.250"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
18:19:37.263045 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 29, length 64
18:19:37.263102 IP 10.3.0.2 > 169.254.61.250: ICMP echo reply, id 27711, seq 29, length 64
18:19:38.262916 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 30, length 64
18:19:38.262967 IP 10.3.0.2 > 169.254.61.250: ICMP echo reply, id 27711, seq 30, length 64




  • The return traffic towards my router (169.254.61.250) is dropped somewhere. The next trace is captured in my router:



19:19:35.240929 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 27, length 64 out slot1/tmm0 lis=
19:19:36.240934 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 28, length 64 out slot1/tmm0 lis=
19:19:37.240878 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 29, length 64 out slot1/tmm0 lis=
19:19:38.240724 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 30, length 64 out slot1/tmm0 lis=
19:19:39.240767 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 31, length 64 out slot1/tmm0 lis=



I understand that using 169.254.x.x addresses is not ideal for monitoring because they are meant that they are link local. Ideally the customer should be able to specify a range for the peering.



Alternatively, could be possible to allow such traffic to be allowed? I don't need this only for testing initial connectivity but also for continious monitoring.



Any comments would be greatly appreciated



Thanks










share|improve this question























  • The address 169.254.x.x should only exist inside the tunnel. One address for each end. No routing is done with these addresses, they are point-to-point. The actual payload will be contained inside the tunnel. If the 169.254.x.x is being used for a device outside the tunnel, this is not a valid configuration.

    – John Hanley
    Nov 23 '18 at 20:02













  • @JohnHanley I agree. For monitoring purposes I need to use as source address the IP address of my BGP peering side. I don't find any way to specify a custom IP range for the BGP peering (this is possible with Azure and AWS)

    – MM93
    Dec 7 '18 at 9:16
















0















I'm using a partner connection (hybrid connectivity) to my VPC where I do manage the BGP peering. The router entity is automatically created by GCP in MANAGED_BY_ATTACHMENT mode so I cannot specify which addresses are used for peering.



From my router (169.254.61.250) I can ping a host in the VPC but the return traffic is filtered. I don't know if this is expected:




  • The next trace is captured in a host in the VPC


root@bd-ecs-gcp-host1:~# tcpdump -nl -i ens4 "( tcp port 22 or icmp ) and host 169.254.61.250"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
18:19:37.263045 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 29, length 64
18:19:37.263102 IP 10.3.0.2 > 169.254.61.250: ICMP echo reply, id 27711, seq 29, length 64
18:19:38.262916 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 30, length 64
18:19:38.262967 IP 10.3.0.2 > 169.254.61.250: ICMP echo reply, id 27711, seq 30, length 64




  • The return traffic towards my router (169.254.61.250) is dropped somewhere. The next trace is captured in my router:



19:19:35.240929 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 27, length 64 out slot1/tmm0 lis=
19:19:36.240934 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 28, length 64 out slot1/tmm0 lis=
19:19:37.240878 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 29, length 64 out slot1/tmm0 lis=
19:19:38.240724 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 30, length 64 out slot1/tmm0 lis=
19:19:39.240767 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 31, length 64 out slot1/tmm0 lis=



I understand that using 169.254.x.x addresses is not ideal for monitoring because they are meant that they are link local. Ideally the customer should be able to specify a range for the peering.



Alternatively, could be possible to allow such traffic to be allowed? I don't need this only for testing initial connectivity but also for continious monitoring.



Any comments would be greatly appreciated



Thanks










share|improve this question























  • The address 169.254.x.x should only exist inside the tunnel. One address for each end. No routing is done with these addresses, they are point-to-point. The actual payload will be contained inside the tunnel. If the 169.254.x.x is being used for a device outside the tunnel, this is not a valid configuration.

    – John Hanley
    Nov 23 '18 at 20:02













  • @JohnHanley I agree. For monitoring purposes I need to use as source address the IP address of my BGP peering side. I don't find any way to specify a custom IP range for the BGP peering (this is possible with Azure and AWS)

    – MM93
    Dec 7 '18 at 9:16














0












0








0








I'm using a partner connection (hybrid connectivity) to my VPC where I do manage the BGP peering. The router entity is automatically created by GCP in MANAGED_BY_ATTACHMENT mode so I cannot specify which addresses are used for peering.



From my router (169.254.61.250) I can ping a host in the VPC but the return traffic is filtered. I don't know if this is expected:




  • The next trace is captured in a host in the VPC


root@bd-ecs-gcp-host1:~# tcpdump -nl -i ens4 "( tcp port 22 or icmp ) and host 169.254.61.250"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
18:19:37.263045 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 29, length 64
18:19:37.263102 IP 10.3.0.2 > 169.254.61.250: ICMP echo reply, id 27711, seq 29, length 64
18:19:38.262916 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 30, length 64
18:19:38.262967 IP 10.3.0.2 > 169.254.61.250: ICMP echo reply, id 27711, seq 30, length 64




  • The return traffic towards my router (169.254.61.250) is dropped somewhere. The next trace is captured in my router:



19:19:35.240929 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 27, length 64 out slot1/tmm0 lis=
19:19:36.240934 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 28, length 64 out slot1/tmm0 lis=
19:19:37.240878 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 29, length 64 out slot1/tmm0 lis=
19:19:38.240724 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 30, length 64 out slot1/tmm0 lis=
19:19:39.240767 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 31, length 64 out slot1/tmm0 lis=



I understand that using 169.254.x.x addresses is not ideal for monitoring because they are meant that they are link local. Ideally the customer should be able to specify a range for the peering.



Alternatively, could be possible to allow such traffic to be allowed? I don't need this only for testing initial connectivity but also for continious monitoring.



Any comments would be greatly appreciated



Thanks










share|improve this question














I'm using a partner connection (hybrid connectivity) to my VPC where I do manage the BGP peering. The router entity is automatically created by GCP in MANAGED_BY_ATTACHMENT mode so I cannot specify which addresses are used for peering.



From my router (169.254.61.250) I can ping a host in the VPC but the return traffic is filtered. I don't know if this is expected:




  • The next trace is captured in a host in the VPC


root@bd-ecs-gcp-host1:~# tcpdump -nl -i ens4 "( tcp port 22 or icmp ) and host 169.254.61.250"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
18:19:37.263045 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 29, length 64
18:19:37.263102 IP 10.3.0.2 > 169.254.61.250: ICMP echo reply, id 27711, seq 29, length 64
18:19:38.262916 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 30, length 64
18:19:38.262967 IP 10.3.0.2 > 169.254.61.250: ICMP echo reply, id 27711, seq 30, length 64




  • The return traffic towards my router (169.254.61.250) is dropped somewhere. The next trace is captured in my router:



19:19:35.240929 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 27, length 64 out slot1/tmm0 lis=
19:19:36.240934 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 28, length 64 out slot1/tmm0 lis=
19:19:37.240878 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 29, length 64 out slot1/tmm0 lis=
19:19:38.240724 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 30, length 64 out slot1/tmm0 lis=
19:19:39.240767 IP 169.254.61.250 > 10.3.0.2: ICMP echo request, id 27711, seq 31, length 64 out slot1/tmm0 lis=



I understand that using 169.254.x.x addresses is not ideal for monitoring because they are meant that they are link local. Ideally the customer should be able to specify a range for the peering.



Alternatively, could be possible to allow such traffic to be allowed? I don't need this only for testing initial connectivity but also for continious monitoring.



Any comments would be greatly appreciated



Thanks







google-cloud-platform gcloud connectivity hybrid






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 23 '18 at 19:11









MM93MM93

52




52













  • The address 169.254.x.x should only exist inside the tunnel. One address for each end. No routing is done with these addresses, they are point-to-point. The actual payload will be contained inside the tunnel. If the 169.254.x.x is being used for a device outside the tunnel, this is not a valid configuration.

    – John Hanley
    Nov 23 '18 at 20:02













  • @JohnHanley I agree. For monitoring purposes I need to use as source address the IP address of my BGP peering side. I don't find any way to specify a custom IP range for the BGP peering (this is possible with Azure and AWS)

    – MM93
    Dec 7 '18 at 9:16



















  • The address 169.254.x.x should only exist inside the tunnel. One address for each end. No routing is done with these addresses, they are point-to-point. The actual payload will be contained inside the tunnel. If the 169.254.x.x is being used for a device outside the tunnel, this is not a valid configuration.

    – John Hanley
    Nov 23 '18 at 20:02













  • @JohnHanley I agree. For monitoring purposes I need to use as source address the IP address of my BGP peering side. I don't find any way to specify a custom IP range for the BGP peering (this is possible with Azure and AWS)

    – MM93
    Dec 7 '18 at 9:16

















The address 169.254.x.x should only exist inside the tunnel. One address for each end. No routing is done with these addresses, they are point-to-point. The actual payload will be contained inside the tunnel. If the 169.254.x.x is being used for a device outside the tunnel, this is not a valid configuration.

– John Hanley
Nov 23 '18 at 20:02







The address 169.254.x.x should only exist inside the tunnel. One address for each end. No routing is done with these addresses, they are point-to-point. The actual payload will be contained inside the tunnel. If the 169.254.x.x is being used for a device outside the tunnel, this is not a valid configuration.

– John Hanley
Nov 23 '18 at 20:02















@JohnHanley I agree. For monitoring purposes I need to use as source address the IP address of my BGP peering side. I don't find any way to specify a custom IP range for the BGP peering (this is possible with Azure and AWS)

– MM93
Dec 7 '18 at 9:16





@JohnHanley I agree. For monitoring purposes I need to use as source address the IP address of my BGP peering side. I don't find any way to specify a custom IP range for the BGP peering (this is possible with Azure and AWS)

– MM93
Dec 7 '18 at 9:16












1 Answer
1






active

oldest

votes


















0














Have you created the route for your custom IP address? Can you define the steps how you created the routes? Want to confirm if you are restricting the advertisement of subnets, which might be causing the issue. You can also check this document[1] for more details.



[1] https://cloud.google.com/solutions/custom-public-ip-addresses-on-compute-engine



Are you using Dedicated Interconnect attachments? To establish Hybrid connectivity?



Are you using any third-party firewall in between? I guess this could be related and that's why the return traffic is being filtered.



I also suspect that using 169.254.x.x is not appropriate, can you change the IP and check if it makes any difference on your ping result and returned traffic? I suspect it is not possible to ping a VPC host directly, there are no routes back to the 169.254.0.0 subnet.






share|improve this answer
























  • Hi Muhammad - I'm using a partner interconnect cloud.google.com/interconnect/docs/how-to/partner/… - there is no firewall in between I agree that 169.254.x.x is not appropriate, when using a partner interconnect. I don't find a way of specifying the IP range for the BGP peering. That would be the preferable option.

    – MM93
    Dec 7 '18 at 9:32













  • Border Gateway Protocol (BGP) sessions enable your VPC and on-premises networks to dynamically exchange routes. You configure BGP sessions and associate them with the connections between your networks, such as VPN tunnels or Dedicated Interconnects.See the attached document[1] for more details. For Dedicated Interconnect, the VLAN attachment allocates a VLAN on an interconnect and associates that VLAN with a single Cloud Router[2] [1]cloud.google.com/router/docs/how-to/configuring-bgp [2]cloud.google.com/interconnect/docs/how-to/dedicated/…

    – Muhammad Ebaduddin
    Dec 25 '18 at 0:39











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53451891%2fgcp-hybrid-connectivity-ping-from-customer-router-to-vpc%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














Have you created the route for your custom IP address? Can you define the steps how you created the routes? Want to confirm if you are restricting the advertisement of subnets, which might be causing the issue. You can also check this document[1] for more details.



[1] https://cloud.google.com/solutions/custom-public-ip-addresses-on-compute-engine



Are you using Dedicated Interconnect attachments? To establish Hybrid connectivity?



Are you using any third-party firewall in between? I guess this could be related and that's why the return traffic is being filtered.



I also suspect that using 169.254.x.x is not appropriate, can you change the IP and check if it makes any difference on your ping result and returned traffic? I suspect it is not possible to ping a VPC host directly, there are no routes back to the 169.254.0.0 subnet.






share|improve this answer
























  • Hi Muhammad - I'm using a partner interconnect cloud.google.com/interconnect/docs/how-to/partner/… - there is no firewall in between I agree that 169.254.x.x is not appropriate, when using a partner interconnect. I don't find a way of specifying the IP range for the BGP peering. That would be the preferable option.

    – MM93
    Dec 7 '18 at 9:32













  • Border Gateway Protocol (BGP) sessions enable your VPC and on-premises networks to dynamically exchange routes. You configure BGP sessions and associate them with the connections between your networks, such as VPN tunnels or Dedicated Interconnects.See the attached document[1] for more details. For Dedicated Interconnect, the VLAN attachment allocates a VLAN on an interconnect and associates that VLAN with a single Cloud Router[2] [1]cloud.google.com/router/docs/how-to/configuring-bgp [2]cloud.google.com/interconnect/docs/how-to/dedicated/…

    – Muhammad Ebaduddin
    Dec 25 '18 at 0:39
















0














Have you created the route for your custom IP address? Can you define the steps how you created the routes? Want to confirm if you are restricting the advertisement of subnets, which might be causing the issue. You can also check this document[1] for more details.



[1] https://cloud.google.com/solutions/custom-public-ip-addresses-on-compute-engine



Are you using Dedicated Interconnect attachments? To establish Hybrid connectivity?



Are you using any third-party firewall in between? I guess this could be related and that's why the return traffic is being filtered.



I also suspect that using 169.254.x.x is not appropriate, can you change the IP and check if it makes any difference on your ping result and returned traffic? I suspect it is not possible to ping a VPC host directly, there are no routes back to the 169.254.0.0 subnet.






share|improve this answer
























  • Hi Muhammad - I'm using a partner interconnect cloud.google.com/interconnect/docs/how-to/partner/… - there is no firewall in between I agree that 169.254.x.x is not appropriate, when using a partner interconnect. I don't find a way of specifying the IP range for the BGP peering. That would be the preferable option.

    – MM93
    Dec 7 '18 at 9:32













  • Border Gateway Protocol (BGP) sessions enable your VPC and on-premises networks to dynamically exchange routes. You configure BGP sessions and associate them with the connections between your networks, such as VPN tunnels or Dedicated Interconnects.See the attached document[1] for more details. For Dedicated Interconnect, the VLAN attachment allocates a VLAN on an interconnect and associates that VLAN with a single Cloud Router[2] [1]cloud.google.com/router/docs/how-to/configuring-bgp [2]cloud.google.com/interconnect/docs/how-to/dedicated/…

    – Muhammad Ebaduddin
    Dec 25 '18 at 0:39














0












0








0







Have you created the route for your custom IP address? Can you define the steps how you created the routes? Want to confirm if you are restricting the advertisement of subnets, which might be causing the issue. You can also check this document[1] for more details.



[1] https://cloud.google.com/solutions/custom-public-ip-addresses-on-compute-engine



Are you using Dedicated Interconnect attachments? To establish Hybrid connectivity?



Are you using any third-party firewall in between? I guess this could be related and that's why the return traffic is being filtered.



I also suspect that using 169.254.x.x is not appropriate, can you change the IP and check if it makes any difference on your ping result and returned traffic? I suspect it is not possible to ping a VPC host directly, there are no routes back to the 169.254.0.0 subnet.






share|improve this answer













Have you created the route for your custom IP address? Can you define the steps how you created the routes? Want to confirm if you are restricting the advertisement of subnets, which might be causing the issue. You can also check this document[1] for more details.



[1] https://cloud.google.com/solutions/custom-public-ip-addresses-on-compute-engine



Are you using Dedicated Interconnect attachments? To establish Hybrid connectivity?



Are you using any third-party firewall in between? I guess this could be related and that's why the return traffic is being filtered.



I also suspect that using 169.254.x.x is not appropriate, can you change the IP and check if it makes any difference on your ping result and returned traffic? I suspect it is not possible to ping a VPC host directly, there are no routes back to the 169.254.0.0 subnet.







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 1 '18 at 2:09









Muhammad EbaduddinMuhammad Ebaduddin

862




862













  • Hi Muhammad - I'm using a partner interconnect cloud.google.com/interconnect/docs/how-to/partner/… - there is no firewall in between I agree that 169.254.x.x is not appropriate, when using a partner interconnect. I don't find a way of specifying the IP range for the BGP peering. That would be the preferable option.

    – MM93
    Dec 7 '18 at 9:32













  • Border Gateway Protocol (BGP) sessions enable your VPC and on-premises networks to dynamically exchange routes. You configure BGP sessions and associate them with the connections between your networks, such as VPN tunnels or Dedicated Interconnects.See the attached document[1] for more details. For Dedicated Interconnect, the VLAN attachment allocates a VLAN on an interconnect and associates that VLAN with a single Cloud Router[2] [1]cloud.google.com/router/docs/how-to/configuring-bgp [2]cloud.google.com/interconnect/docs/how-to/dedicated/…

    – Muhammad Ebaduddin
    Dec 25 '18 at 0:39



















  • Hi Muhammad - I'm using a partner interconnect cloud.google.com/interconnect/docs/how-to/partner/… - there is no firewall in between I agree that 169.254.x.x is not appropriate, when using a partner interconnect. I don't find a way of specifying the IP range for the BGP peering. That would be the preferable option.

    – MM93
    Dec 7 '18 at 9:32













  • Border Gateway Protocol (BGP) sessions enable your VPC and on-premises networks to dynamically exchange routes. You configure BGP sessions and associate them with the connections between your networks, such as VPN tunnels or Dedicated Interconnects.See the attached document[1] for more details. For Dedicated Interconnect, the VLAN attachment allocates a VLAN on an interconnect and associates that VLAN with a single Cloud Router[2] [1]cloud.google.com/router/docs/how-to/configuring-bgp [2]cloud.google.com/interconnect/docs/how-to/dedicated/…

    – Muhammad Ebaduddin
    Dec 25 '18 at 0:39

















Hi Muhammad - I'm using a partner interconnect cloud.google.com/interconnect/docs/how-to/partner/… - there is no firewall in between I agree that 169.254.x.x is not appropriate, when using a partner interconnect. I don't find a way of specifying the IP range for the BGP peering. That would be the preferable option.

– MM93
Dec 7 '18 at 9:32







Hi Muhammad - I'm using a partner interconnect cloud.google.com/interconnect/docs/how-to/partner/… - there is no firewall in between I agree that 169.254.x.x is not appropriate, when using a partner interconnect. I don't find a way of specifying the IP range for the BGP peering. That would be the preferable option.

– MM93
Dec 7 '18 at 9:32















Border Gateway Protocol (BGP) sessions enable your VPC and on-premises networks to dynamically exchange routes. You configure BGP sessions and associate them with the connections between your networks, such as VPN tunnels or Dedicated Interconnects.See the attached document[1] for more details. For Dedicated Interconnect, the VLAN attachment allocates a VLAN on an interconnect and associates that VLAN with a single Cloud Router[2] [1]cloud.google.com/router/docs/how-to/configuring-bgp [2]cloud.google.com/interconnect/docs/how-to/dedicated/…

– Muhammad Ebaduddin
Dec 25 '18 at 0:39





Border Gateway Protocol (BGP) sessions enable your VPC and on-premises networks to dynamically exchange routes. You configure BGP sessions and associate them with the connections between your networks, such as VPN tunnels or Dedicated Interconnects.See the attached document[1] for more details. For Dedicated Interconnect, the VLAN attachment allocates a VLAN on an interconnect and associates that VLAN with a single Cloud Router[2] [1]cloud.google.com/router/docs/how-to/configuring-bgp [2]cloud.google.com/interconnect/docs/how-to/dedicated/…

– Muhammad Ebaduddin
Dec 25 '18 at 0:39




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53451891%2fgcp-hybrid-connectivity-ping-from-customer-router-to-vpc%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Wiesbaden

Marschland

Dieringhausen