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

[Steve Bertrand]

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?

> 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 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?

Do your datagram captures prove that a TCP session is established?

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?

> 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.

> Has anyone seem such a problem?  

Yes, but not with BGP. I've been thankful that the peers I have[1] are 
exceptionally quick at identifying and rectifying problems.

The issues I have are irrelevant of BGP.

I would personally like to discuss this further with you, to enhance my 
knowledge with experience of a real-world scenario.

If you need to troubleshoot this further, especially if your BGP session 
fluctuates or remains somewhere between Idle and Active state, email me 
off list.

I'd really like to see and troubleshoot this at datagram level for my 
own personal gain.

Scenario evaluation is much easier for me if I can have provided to me 
the real-life scenario from an outside source, as opposed to trying to 
document/learn as I go when I have the same issues on my own networks...

> Is there some strange magic limit to 
> the number of peers or something?

No.

Steve

[1] I do not have control of my IPv4 address space, as an 'upstream' (I 
detest that term) advertises it for me. I do have two IPv6 BGP peers 
that I advertise my /32 through however, via our own AS.




> 
> Roy
> 
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/