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