From: Luis Rueda (luis.rueda@comsat.com.co)
Date: Sun Oct 16 2005 - 05:57:25 GMT-3
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 definate 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 rouuting? 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 accross 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.
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:51 GMT-3