From: Tim (ccie2be@nyc.rr.com)
Date: Sun Oct 16 2005 - 17:32:14 GMT-3
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.
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:51 GMT-3