From: kevin gannon (kevin@gannons.net)
Date: Mon Oct 17 2005 - 03:28:59 GMT-3
It used to be limited to stub routing not sure how this has changed.
Last time I worked on them GRE was the way to go in complex
setups. But 7.0 has moved on a lot since then I would hope.
Regards
Kevin
On 10/16/05, Tim <ccie2be@nyc.rr.com> wrote:
> Hey Kevin,
>
> What do you mean when you say, "multicast support was limited"?
>
> I'm looking at the new CCSP book for the PIX and it looks like it's possible
> to use the mroute command to forward mcast traffic thru a pix.
>
> Example from CCSP Cisco Secure PIX Firewall Advanced 2nd Edition, Page 326.
>
> Pix(config)# multicast interface DMZ1
>
> Pix(config-multicast)# mroute (ip addr that's the source of mcast traffic)
> DMZ1 224.0.0.9 255.255.255.255 inside
>
> Pix(config-multicast)# exit
>
> Pix(config)# multicast interface inside
>
> Pix(config-multicast)# mroute (ip addr that's the source of mcast traffic)
> inside 224.0.0.9 255.255.255.255 DMZ1
>
> ***************
>
> Also, I seem to recall that the TTL for rip updates is 2.
>
> Is that true only if the neighbor command is used? Or if the default dest
> address is 224.0.0.9? Or, never?
>
>
>
> TIA, Tim
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Luis
> Rueda
> Sent: Sunday, October 16, 2005 4:57 AM
> To: kevin gannon; Feldman, Jim
> Cc: Brant I. Stevens; Ccie Lab (E-mail)
> Subject: RE: The PIX and RIP
>
> That is correct, 224.0.0.0/24 is a link-local address (must stay on the
> link), and also correct, the PIX had limited support for multicast on
> 6.3 train... There is one way to solve this, in PIX 7.0 you may use
> transparent firewall (this means L2 firewall), that way you may do it.
>
> Otherwise I don't see how you may do this.....
>
> Luis
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> kevin gannon
> Sent: Friday, October 14, 2005 1:51 PM
> To: Feldman, Jim
> Cc: Brant I. Stevens; Ccie Lab (E-mail)
> Subject: Re: The PIX and RIP
>
> Jim
> I only have remote access to my rack to confirm 100% if the TTL is 1 or
> 2.
> However even if it is two there would still be problems including
> breaking the RFC for the multicast address allocated RIPv2 RFC1112:
>
>
> The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive, is
> reserved for the use of routing protocols and other low-level topology
> discovery or maintenance protocols, such as gateway discovery and group
> membership reporting. Multicast routers should not forward any
> multicast datagram with destination addresses in this range, regardless
> of its TTL.
>
> Its a while since I have worked on pix but last time multicast support
> was limited anyway. I would also advise BGP if you can get away with it
> based on the topology you have.
>
> Regards
> Kevin
>
>
> On 10/14/05, Feldman, Jim <Jim.Feldman@amex.com> wrote:
> > Hi guys,
> >
> > Thanks for thinking about this and getting back to me.
> >
> > Kevin, I'm only 95% sure but I think that actually the TTL of RIP
> > updates to the mcast address is 2, not 1.
> >
> > Brett, yes, there's a need for routes to be passed from 1 side of the
> > PIX to another (DMZ1 to inside).
> >
> > If I use BGP which is a definite consideration, I'll need to redist
> > rip into BGP on the DMZ1 side and redist from bgp into rip on the
> inside of the PIX.
> >
> > I think both methods would work but why do you say using the BGP
> > method is better?
> >
> > TIA, Jim
> >
> > -----Original Message-----
> > From: Brant I. Stevens [mailto:branto@branto.com]
> > Sent: Friday, October 14, 2005 1:59 PM
> > To: 'kevin gannon'; 'Feldman, Jim'
> > Cc: 'Ccie Lab (E-mail)'
> > Subject: RE: The PIX and RIP
> >
> >
> > Is the requirement for dynamic routing? If so, then BGP would be the
>
> > best solution for something like this, provided that the routers on
> > the inside and outside are capable of using it.
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of kevin gannon
> > Sent: Friday, October 14, 2005 1:34 PM
> > To: Feldman, Jim
> > Cc: Ccie Lab (E-mail)
> > Subject: Re: The PIX and RIP
> >
> > Unless the PIX is in transparent mode the RIP will not get across the
>
> > PIX as the TTL of a RIP packet is 1.
> >
> > GRE is an option but then it will not be possible to inspect the
> > traffic within the GRE as all traffic will go over the GRE.
> >
> > Regards
> > Kevin
> >
> > On 10/14/05, Feldman, Jim <Jim.Feldman@amex.com> wrote:
> > >
> > > Hi Guys,
> > >
> > > I want 2 routers to pass rip updates to each other across a PIX
> firewall.
> > > The Pix is configured to allow UDP port 520 traffic.
> > >
> > > I can think of 2 potential ways to do this:
> > >
> > > 1) Use the command, "no validate source-update" because the 2
> > > routers are on 2 different subnets.
> > >
> > > 2) Set up a gre tunnel across the pix between the 2 routers.
> > >
> > >
> > > Am I correct that both ways will work?
> > >
> > > If so, is one way considered better?
> > >
> > > TIA, Jim
> > >
> > > ____________________________________________________________________
> > > __ _ Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > > --
> > > This message has been scanned for viruses and dangerous content by
> > > MailScanner, and is believed to be clean.
> >
> > ______________________________________________________________________
> > _ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > --
> > This message has been scanned for viruses and dangerous content by
> > MailScanner, and is believed to be clean.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:51 GMT-3