The Answer: “#8 – Ping 192.168.14.2 from the AWS CSR”

Summary: Why? What does BGP coming up have to do with the AWS CSR pinging the other side of GRE tunnel? Well if you know the answer… don’t read anymore. lol. You will be bored. 🙂

If you recall from AWS: The Case of the iBGP Peer that Worked – Part 1: The Facts, my BGP neighbor wasn’t supposed to come up. When it did…. it was a complete surprise to me.

Let’s Review

So I have my local lab environment on the left and on the right I have AWS. My original PLAN was to have the CSR in AWS configured to have BGP in what is referred to as “listen mode”. In other words… it won’t actively call. The REASON I wanted to do this was to teach about the AWS Security Group and the need to make sure to keep that in mind along with the AWS VPC route table.

My Original Idea

On my YouTube Channel, in one of my AWS videos, I had created a scenario that allowed me to remind networking people (like me) to not forget the basics when troubleshooting networking with AWS and to make sure you

• Check Routing
• Check Security

To solve that “who done it” you had to

• Routing: Add a static 0.0.0.0/0 to the AWS IGW of the VPC so that traffic could get out of the VPC
• Security: Allow SSH and ICMP in the Security Group associated with the CSR.

So what I wanted to do next was to go to the next level and make people have to add port 179 for BGP to be able to come up between a CSR in AWS and a CSR outside of AWS.

Let’s take a look at that Security Group I had in Part 1… just adding a little more verbiage around it this time.

Originally I didn’t have the AWS CSR in BGP “listen mode” and then I saw that the BGP neighbor came up. I’m like… oh right… the AWS CSR can initiate the BGP. So I thought I’d be “clever” and put BGP in listen mode on the AWS CSR. Then I would “teach” and “explain” in the YouTube that i was missing TCP 179 on the inbound rule.

LOL. So imagine my surprise (okay and slight embarrassment) when I realized it was the ping to 192.168.14.2 from the AWS CSR” that allowed the BGP neighbor to come up.

“Cloudy Brain”

I keep doing this again and again…. okay and again and again. lol. I keep forgetting networking basics whenever I’m playing in and learning the cloud. Honestly. This really keeps happening to me. Normally I can just “see the flow”. But when it comes to the pieces that are in the cloud I get “cloudy brain” – I keep thinking too much about the cloud pieces and assume something is going on “in the cloud” as opposed to just networking basics.

So Why did the Ping Work?

What did the ping due? I mean it was just a simple ping from the AWS CSR to the other side of the tunnel. Which, of course, is allowed because of the security group allowing all out.

Well let’s think about this.

When the CSR in my local lab hits that Security rule… what is the SIP and the DIP at that point? Well it’s a tunnel isn’t it? lol. So the local CSR is putting any traffic (including the attempt to start up BGP) into a tunnel and setting the outer SIP as the local CSR tunnel (198.18.14.2) and the outer DIP as the other side of the tunnel (198.18.14.1). Yeah… “cloudy brain”… so it isn’t that the I was going to need TCP port 179 allowed inbound. Cause at the point where the Security Group is… it would never see that. lol.

So what did the ping do?

The ping from from the AWS CSR (198.18.14.1) to the local CSR (198.18.14.2) was allowed because the security group allows all from the AWS out. Once it is allowed out in the security group, obviously, the reverse is allowed back in. :). I mean it would be kinda stupid of AWS not to default to that behavior. lol. So once the ping went out allowing 198.18.14.1 to communicate with 198.18.14.2 – the reverse would be allowed. Result?

BGP came up.

lol.. watch out for “cloudy brain”.

Categories: Uncategorized