Hello, If you don't have the configuration is going to be hard but anyways, I will give you my thoughts after reading your issue.
* Like you said before, getting connectivity from R1 to SW1 (SVI) and viceversa and NO-CONNECTIVITY from/to R2 --> Focus on SW1 & R2. Did you review that the same configuration using on over R1-SW1 is exactly the same in the other side??
* If you don't get it, can you restore R2 to default configuration ?? It would give you all default parameter in the router (even the ones that you cannot see over show-run command).
* I wouldn't focus on STP because there is no way to get loops in the connections R1-SW1-R2
Just a quick review. Let me know how are you doing and I will be back.
P.S. The configurations would be great.
Thanks for the response but like I said R2 is not within my reach but the claim is that if i fixed what needed to be fixed on my on side of things (which seems to be SW1 in this case) then i should have the connectivity I need. Nothing strange on the switch and it was reloaded but still no connectivity.
Sorry, I didn't pay enough attention to the fact that you cannot reach R2. So that, my guess is that you are missing something from the other side that is not letting you get the connectivity. If there is NO WAY that you get the configuration from the other side........ I would try to run debug commands to figure out what is going on. Right now, nothing else is comming to my mind.
If you get the arp for R2, then there is L2 connectivity. If you said you cand do ping, you dont get replies, your bgp session stuck in active, then for sure there is an access list in R2 that is blocking all this traffic. I suppose the exercise objetive is test your troubleshooting skills.
So, first think there is a access lists that block everything except BGP tcp connections, and traffic with other destination networks. Check this with a debug ip tcp transactions, you should see there is tcp sessions establishment, but after few seconds this should go down. Then, you have a AS number problem, the R2 router should reject every incoming bgp session, and your R1 router should do the same, because you are not using the right AS number and R1 is configured with other AS. Maybe you have to use the local-as feature in R1 router. How do you get the right AS number, check the logs, and/or do a debug ip bgp events. You will get some ex numbers, that you will have to convert to decimal and get the right AS number.
btw, there is something i dont understand about your post, you said you get the R2 arp at R1, but you dont see the icmp requests from R1 to R2. This cant be right, if you have the arp your router will send the icmp request. But if you dont have the ARP you will not be able to send icmp request packets.
Check your arp, check this points to the right interface, check you dont have the R2 ip address configured in R1 in other interface even as secondary.
Thanks for the input.
Yes that was what I thought maybe icmp was blocked by an ACL on R2. I did not do a debug ip bgp but I'm thinking if there was an issue with the AS number, I should have received the error message when I configured the bgp peering.
Not seeing icmp request when sending ping to R2 from R1 was the really strange thing and like I said it was the same case when i configured an SVI on the switch SW1 and I ping to R2 and did a debug also there was no requests sent out. But I could see request when the ping is between R1 and SW1.
I did clear the arp cache and R1 was able to learn the arp of R2 again. I even put a static entry for the arp but none of this helped.
I had never seen it so basic and weired before and that threw me off.
On some platforms, the router or switch generated traffic is not able to show on the debugs, usually have to configure a local policy that loop self generated traffic through a loopback interface. Then this traffic is considered transit and will be shown on every debug.
When you configure the as peer, you will not get any warning or error till the tcp session is establiched. It would be good if you could do the debug ip tcp transactions, or if you configure an input access lists, with a permit tcp any any log, permit ip any any log, this will show if R2 try to connect to R1.
If you have the arp, then problem is a access list at R2. Both R1 and R2 will try to establish the peer relationship on tcp port 179. Check this point. Or you could try to telnet to port 179, if connection opens bgp sessions are allowed, so problem is a access lists that drop icmp traffic.