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
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
