AWS: The Case of the iBGP Peer that Worked – Part 1: The Facts

I was so surprised when the BGP neighbor came up. I kinda just blinked and stared at it for awhile. I knew it couldn’t be an AWS bug. This was just too basic a setup. Did I misconfigure something? If I did, what was it? Still being new to AWS was it just something I just didn’t understand yet?

Figured it out finally. Now it is your turn.

AWS Top with EIP
AWS iBGP Logical

The Big Picture

I wanted to create a YouTube video showing iBGP peers not coming up between the local CSR and the AWS CSR. Then I would walk the person through the “why” of why it wasn’t coming up. I was quite pleased at the idea and patted myself on the back for “job well done” on coming up with an idea that would allow me to highlight this one thing about AWS that I wanted to show.

When I first configured it, it did exactly as I expected – it did NOT come up. So started working on the accompanying slides for the video which isn’t quite as much fun as just geeking out. So when I had a few thoughts about other ideas for future AWS blogs or YouTube videos… I stopped working on the ppt building and went pure geek. Yup, meaning I was making config changes in both the CSRs… and still in the AWS console and tweaking things. Just generally having fun and learning. I decided I had gotten off track enough and it was time to get back to the ppt and creating the video. And then i saw it…..

…. my BGP peer that was “supposed to not come up” was up!

I will freely admit now I was stumped! Just totally stumped. I backed out all my modifications… did a write mem and a reload on both routers. When the routers came back up we were back to the BGP peer not up. So I got everything back to square 1… now to try to figure out what I had done.

So…. “who done it”? Your turn

“Who Done it?”

So… while I was geeking out…. I clearly “did” something that then allowed the BGP neighbor to come up when I didn’t think it would come up configured that way. So here is the question – which one of the following did I do that ended up allowing the BGP to successfully neighbor up?

  1. Leaving the AWS CSR still in “listen mode”, change the AS of the local CSR to 65002 and do eBGP with multihop
  2. Leaving the AWS CSR still in “listen mode”, change the peering to be between the ends of the GRE tunnel
  3. Ping 192.168.14.1 from my laptop
  4. SSH to 192.168.14.1 from my laptop
  5. Add 10.179.179.2 to the VPC route table and point to the IGW
  6. Add 10.179.179.0/24 to the VPC route table and point to the IGW
  7. Ping 192.168.14.1 from the local CSR
  8. Ping 192.168.14.2 from the AWS CSR
  9. Enable IPSec on the GRE tunnel

The Evidence

Local CSR Router Configs

Here is a snippet of the Local CSR configs. You can also click here to download them.

ASR CSR Router Configs

Here is a snippet of the Local CSR configs. You can also click here to download them.

AWS Related Config

For the AWS related configs we will just look at the VPC route table and the CSR Security Group.

Can you guess? Do you know?

Check out Part 2 for the answer.



Categories: AWS

3 replies

  1. Hi Fish – interesting scenario. I had to lab it up. Unfortunately I can’t use AWS so I used CSR to mimic EIP. And the BGP session session came UP.

    So my guess is that it has something to do with the AWS SG – specifically the inbound rules and the fact that your AWS BGP is only listening.

    So I think option 8. When you ping from AWS it brings up the tunnel. AWS will allow return traffic. Then the BGP transport has end-to-end reachability and the session comes UP.

    • You are SPOT on! Option 8.
      And yes… it was AWS Security groups that wanted originally to show and discuss. And yes… hence why I did the BGP in “listen only” mode. :).

Trackbacks

  1. AWS: The Case of the iBGP Peer that Worked – Part 2: The Answer

Leave a Reply