[c-nsp] BGP sessions won't establish.

[Roy]

Steve Bertrand wrote:
> Roy wrote:
>> Hi,
>
> Hi. My message is long, but its from one small op to apparently 
> another.  It appears as the OP is on a similar page I am on. I am 
> always willing to accept criticism, on, and/or off-list.
>
>> We are working with a new ISP for service.  This one is via metro 
>> ethernet.  They require two BGP sessions.  One goes between the ends 
>> of the ethernet.  The other BGP session is between a loopback 
>> interface on our router and a loopback interface on one of the ISP's 
>> other routers.
>>
>> The first session comes up just fine but the second one using 
>> loopback interfaces will not establish.  
>
> What state does is sit in?

Active

>
>> I did some packet traces using a Linux box and tcpdump and it would 
>> seem that the packets from our loopback session go into the metro 
>> ethernet and disappear.  
>
> What within your datagram trace makes you think this?
When I issue the "clear ip bgp xxx.xxx.xxx.xxx", I see outgoing connect 
packets and no responses.
>
>> When their router tries to connect, the packets arrive and responses 
>> are sent but they too seem to be ignored.
>
> Do you have a datagram capture from their side that identifies (and 
> proves) that they receive and send you information? What is the status 
> on their router regarding a 'sh ip bgp sum' at the time?
No.. They keep telling me its our problem. 
>
> Do your datagram captures prove that a TCP session is established?
It proves it isn't
>
> Can they can show you the information from the datagrams they captured 
> that identify the header info, including the src/dst address info (L2 
> and IP), size of received and returned datagram and port numbers src/dst?
They haven't run a capture.
>
>> The ISP blames us of course.  I told them the packets seem to be 
>> going out the switch port to the metro ethernet.
>
> Heh, I'm in the same boat, but with other upper-layer applications 
> over TCP. I've had to dive head first into self-edumication regarding 
> tracking traffic via Layer-2 header info.
>
> The ISP that is not willing to fully troubleshoot and/or ask for help 
> will always blame you. I'm learning this from a small ISP standpoint 
> who has larger ISPs. I despise blame laying, sometimes I feel bad even 
> when I can without a doubt point my finger.
>
> (For those who are ops way above my head please forgive me)... but 
> unless the remote end can produce conclusive logs that state 
> otherwise, call their bluff. It's one thing to deny a problem, its 
> completely another to state that you just don't know at this time 
> (IMHO), and that you will get back to them once its investigated further.
>
> ....
>>

I feel basically the same way.  Of course tech people at any "big" ISP 
always feel they are more experienced and us small guys are just 
beginners.   After all, if I was an expert, I would be working for the 
big guys :-)   When they find out I have been around the block more than 
a few times then I am an old fart who is stuck in the stone age.

Roy