From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Fri Aug 06 2004 - 17:21:20 GMT-3
Tim,
You can also do this debug on the router in the transit path.
Turn off route-cache on the interface to force traffic to be processed
switched (no ip route-cache), then do something like this:
Access-list 100 permit tcp any any eq bgp
Access-list 100 permit tcp any eq bgp any
Access-list 100 permit gre any any
!
Debug ip packet detail 100
What debug output do you get? If it's only GRE, the BGP packet
is encapsulated inside GRE. If you see BGP then GRE is not being used.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> James
> Sent: Friday, August 06, 2004 11:05 AM
> To: ccie2be
> Cc: 'Brian McGahan'; 'Group Study'; samccie2004@yahoo.co.uk
> Subject: Re: Using Tunnels with iBGP
>
> On Fri, Aug 06, 2004 at 12:02:52PM -0400, ccie2be wrote:
> > James,
> >
> > So, are you saying that the debug ip packets is an added
verification
> that
> > the acl is working properly, not something I would do instead of
using
> the
> > acl?
>
> debug ip packets is just another way to verify. If you do debug ip
packets
> on Serial0 and you see bgp packets between two peers you are talking
about
> that
> is not encapsulated in GRE, then there is a problem. Debug ip packets
may
> not
> be a good idea in real world though as that Serial0 may be pushing god
> knows
> how much packets per second than what line console can handle. It is
good
> for
> lab though.
>
> >
> > Can using the debug ip packet (or maybe, debug ip bgp events ?)
indicate
> if
> > the tunnel is being used if I don't use the acl?
>
> Exactly. Use the ACL if you want to verify otherwise. I like the ACL
way
> myself
> better since it seriously verifies it for sure, by actively blocking
bgp
> packets
> over the serial interface.
>
> HTH,
> -J
>
> >
> > Tim
> >
> > ----- Original Message -----
> > From: "James" <james@towardex.com>
> > To: "ccie2be" <ccie2be@nyc.rr.com>
> > Cc: "'Brian McGahan'" <bmcgahan@internetworkexpert.com>; "'Group
Study'"
> > <ccielab@groupstudy.com>; <samccie2004@yahoo.co.uk>
> > Sent: Friday, August 06, 2004 11:54 AM
> > Subject: Re: Using Tunnels with iBGP
> >
> >
> > > > int tun 0
> > > > ip add y.y.y.y
> > > > tun source s0
> > > > tun dest y.y.y.z
> > > >
> > > > int s0
> > > > ip access-group # <---- blocks bgp traffic
> > >
> > > Yup. Just make sure s0 is the transiting interface on behalf of
tun0,
> in
> > which
> > > in your config, it is :)
> > >
> > > >
> > > > Now, if the neighbor comes up, I know that it's using the tunnel
> because
> > the
> > > > physical int is blocking bgp traffic. Is this correct?
> > >
> > > Right. what you want to do to speed up the observation: clear ip
bgp *
> > > Let the bgp session clear and watch it come back up. It may take a
> little
> > while
> > > as usual as FSM needs to react to connectivity collisions as
usual.
> But if
> > its
> > > taking more than 2 minutes, then check the acl to see if its
blocking
> > something
> > > although it shouldn't if you use the one I mentioned.
> > >
> > > >
> > > > With your other suggestion, debug ip packets, what is the
output I
> > should
> > > > look for?
> > >
> > > As long as BGP pkts traverse over the tunnel peering, you will see
> 'permit
> > ip
> > > any any' incrementing hits while you should really NOT be seeing
any
> hits
> > under
> > > deny port 179 rules on the acl applied to s0. If you do, that
means
> bgp is
> > > somehow trying to send a bgp packet over to s0, that is bad news.
> > >
> > >
> > > >
> > > > Thanks alot for your help.
> > >
> > > No prob!
> > >
> > > >
> > > > BTW, have you set a date for your lab?
> > >
> > > Not sure yet, I am deciding tomorrow actually. I am thinking of
> > mid-september
> > > for my 2nd attempt by may change. How about you?
> > >
> > > -J
> > >
> > > --
> > > James Jun TowardEX
> > Technologies, Inc.
> > > Technical Lead Network Design, Consulting,
IT
> > Outsourcing
> > > james@towardex.com Boston-based Colocation &
> Bandwidth
> > Services
> > > cell: 1(978)-394-2867 web: http://www.towardex.com ,
noc:
> > www.twdx.net
>
> --
> James Jun TowardEX
> Technologies, Inc.
> Technical Lead Network Design, Consulting, IT
> Outsourcing
> james@towardex.com Boston-based Colocation &
Bandwidth
> Services
> cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
> www.twdx.net
>
>
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:34 GMT-3