From: ccie2be (ccie2be@nyc.rr.com)
Date: Fri Aug 06 2004 - 13:02:52 GMT-3
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?
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?
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
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:34 GMT-3