From: Daniel Fredrick (dfredrick@gmail.com)
Date: Wed Jun 21 2006 - 14:28:19 ART
ok... yeah... I wasn't seeing the wrong AS error message... so I don't think
i was the AS.
About the Debug ip tcp trans...
If I see output from that... shouldn't I see a little output from debug ip
packet detail?
thanks,
Dan
On 6/21/06, Godswill Oletu <oletu@inbox.lv> wrote:
>
> Fredrick,
>
> It looks more like a password problem. If the BB router is configured with
> a
> password, you will not get any notification, however the BB router will be
> displaying sometime like:
>
> *Jun 21 14:38:03.519: %TCP-6-BADAUTH: No MD5 digest from 172.1.17.6(179)
> to
> 172.1.17.7(61687) (RST)
>
> But since, you do not have access to the BB router, there will be no way
> of
> seeing that error message.
>
> The other school of thought, as someone else suggested, will be a wrong
> AS.
> However, if you have the wrong AS configured, you will know because, your
> router will display an error message similar to this:
>
> *Jun 21 14:36:18.851: %BGP-3-NOTIFICATION: sent to neighbor 172.1.17.6 2/2
> (peer in wrong AS) 2 bytes 00FA FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> 002D
> 0104 00FA 00B4 AC01 1106 1002 0601 0400 0100 0102 0280 0002 0202 00
>
> The leading 00FA in the error message above is an indication that, the
> eBGP
> peer is expecting a peering on AS 250 (0x00FA).
>
> Since, your post did not state that, you got that type of error message,
> it
> might not be a wrong AS problem.
>
> 'debug ip tcp transactions'
>
> Is a good tool that will help in isolating the problem and point you one
> way
> or the other:
>
> R3640-R2#debug ip tcp transaction
> R3640-R2#
> *Apr 18 07:48:32.580: TCP: sending SYN, seq 1869623725, ack 0
> *Apr 18 07:48:32.580: TCP0: Connection to 172.1.17.7:179, advertising MSS
> 1460
> *Apr 18 07:48:32.580: TCP0: state was CLOSED -> SYNSENT [22587 ->
> 172.1.17.7(179)]
> *Apr 18 07:48:34.580: 172.1.17.6:22587 <---> 172.1.17.7:179 congestion
> window changes
> *Apr 18 07:48:34.580: cwnd from 1460 to 1460, ssthresh from 65535 to 2920
> *Apr 18 07:48:34.580: TCP0: timeout #1 - timeout is 4000 ms, seq
> 1869623725
> *Apr 18 07:48:34.580: TCP: (22587) -> 172.1.17.7(179)
> *Apr 18 07:48:38.300: MD5 received, but NOT expected from 172.1.17.7:61745
> to 172.1.17.6:179
> *Apr 18 07:48:38.304: TCB654938A0 created
> *Apr 18 07:48:38.304: TCP0: state was LISTEN -> SYNRCVD [179 ->
> 172.1.17.7(61745)]
> *Apr 18 07:48:38.304: TCP: tcb 654938A0 connection to 172.1.17.7:61745,
> peer
> MSS 1440, MSS is 516
> *Apr 18 07:48:38.304: TCP: sending SYN, seq 1080374276, ack 3010331734
> *Apr 18 07:48:38.304: TCP0: Connection to 172.1.17.7:61745, advertising
> MSS
> 1440
> *Apr 18 07:48:38.580: TCP0: timeout #2 - timeout is 8000 ms, seq
> 1869623725
> *Apr 18 07:48:38.580: TCP: (22587) -> 172.1.17.7(179)
> *Apr 18 07:48:40.300: MD5 received, but NOT expected from 172.1.17.7:61745
> to 172.1.17.6:179
> *Apr 18 07:48:40.300: TCP0: bad seg from 172.1.17.7 -- bad sequence
> number:
> port 179 seq 3010331733 ack 0 rcvnxt
>
> <result truncated>
>
> 'debug ip bgp'
>
> Is another good tool, but it will not give your alot of actionable
> information like the 'debug ip tcp transaction'
>
> HTH
> Godswill Oletu
>
>
>
>
> ----- Original Message -----
> From: <dfredrick@gmail.com>
> To: <ccielab@groupstudy.com>
> Sent: Wednesday, June 21, 2006 9:57 AM
> Subject: eBGP Neighbors
>
>
> > Hello,
> >
> > I just finish an online lab. I had trouble with getting an eBGP neighbor
> > to come up. It was a BB router, so I didn't have access to see the
> config.
> > Any who... I was recieving RIP updates for it. It was directly
> connected,
> > on the same vlan, and I could ping it.
> >
> > I tried the following and still didn't work...
> >
> > - used the ebgp 255 (just incase it was further than I thought)
> >
> > - used the update loopback0 (just incase it was peering to my loopback)
> >
> > - and stripped it down to just basics on the router...
> > (meaning, didn't have any confederations or anything... just the
> AS
> > it was going to peer with)
> >
> > Then I turned on all debugging for BGP...
> >
> > The only message I could get was "connection refused from remote" or
> > something like that...
> >
> > Then I turned on debug ip packet detail... to see if I was recieving any
> > packets via TCP port 179... and I wasn't... all I saw from the backbone
> > router was rip updates via 224.0.0.9.
> >
> > Then I the only last thing I could think that could prevent updates...
> was
> > an ACL... I looked at the whole path... no ACLs anywhere...
> >
> >
> > So what else could prevent eBGP neighbors from forming?
> >
> > Thanks,
> >
> > Daniel Fredrick
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:33 ART