-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Simon PBrown <sctcisco YAHOO.COM> wrote:
>
> I define a source NAT to translate a source address of
a packet to
> another IP when it goes out via the outer interface.
For example I
> translate 10.10.10.10 to 100.100.100.100 when it goes
out via the
> outer interface but it cannot connect.
It is true, you cannot just make up an IP and expect traffic
to come to
you; there has to be some mechanism for an upstream router
to know where
to find your IP, and send traffic to you.
Generally that mechanism is ARP. The firewall will
naturally respond to
any IP's assigned to its interfaces with ARP replies that
respond to any
device asking. However, for a NAT IP, the firewall does not
have the IP
assigned to any interface, so it does not respond unless you
add a Proxy
ARP.
If you go the way of Proxy ARP, you should make sure to set
it up on
BOTH of your cluster members. Otherwise, if the primary
fails, the
secondary will not know to answer ARP requests and your
traffic will
fail to reach you after a while.
Another way to do this is to use a static route on the
upstream router,
pointing the extra NAT IP traffic to a next-hop with the
firewall's
actual (cluster) IP. Either way will work fine.
> I was troubleshooting and I found that there are proxy
ARP setting in
> the outer interface Nokia box that mapping
100.100.100.101 and 102 and
> 103 to this MAC address 01:00:5e:00:01:08 then I tried
to Proxy Arp
> the 100.100.100.100 to 01:00:5e:00:01:08 and the
connection pass thru.
> I am curious where the Multicast MAC address
01:00:5e:00:01:08 come
> from ?
Are you sure the MAC is not 00:00:5e:00:01:08? This would
define it as
a VRRP virtual MAC for use with VRID 8. RFC 2338 defines
the virtual
MAC to be:
00:00:5E:00:01:<VRID>
It is this MAC to which you should direct all your Proxy ARP
replies,
because that virtual MAC will follow your cluster in
whichever direction
traffic fails over.
Note that the MAC is a Unicast MAC, not Multicast. It will
be delivered
to only one device, whichever is VRRP Master.
> I did a tcpdump on the outer interface of Nokia box
> and I found the following message appear, and I
> know 224.0.0.18 is the multicast IP of VRRP
>
> 100.100.100.101 > 224.0.0.18: VRRPv2-adver 20: vrid
> 103 pri 95 [tos 0xc0] 00:46:11.379961 O
> 100.100.100.102 > 224.0.0.18: VRRPv2-adver 20: v
You should add a -e switch to your tcpdump, so that you can
see the MAC
addresses being used. For example:
0:0:5e:0:1:9d 1:0:5e:0:0:12 8100 58: 172.16.30.2 >
224.0.0.18:
VRRPv2-adver 20: vrid 157 pri 110 [tos 0xc0]
Here the VRID in use is 157, so the virtual MAC is
0:0:5e:0:1:9d, which
is the source MAC. The destination MAC is 1:0:5e:0:0:12, a
multicast
MAC, which is for the VRRP group 224.0.0.18.
Because the ethernet frame is sourced from the virtual MAC,
your
switches will learn instantly where traffic needs to go, if
the source
changes to a different device.
You can also learn the virtual MAC via ifconfig on the
master:
eth-s1p1c2: lname eth-s1p1c2
inet 172.16.30.2/24 broadcast 172.16.30.255
inet 172.16.30.1/24 broadcast 172.16.30.255 vrrpmac
0:0:5e:0:1:9d
phys eth-s1p1
flags=4133<UP,LINK,BROADCAST,MULTICAST,PRESENT>
ether 0:a0:8e:a5:fe:90 speed 1000M full duplex
Notice the "vrrpmac" attribute.
> I thought 224.0.0.18 should be related to MAC address
> 01:00:5e:00:01:08. But after the calculation , I found
that the MAC
> address should match 224.0.1.8 instead. Did I calcuate
wrongly ? If
> not, where is the MAC address come from ?
You should check again to see if the first octet of your
virtual MAC is
00 or 01. It should be 00 (unicast) not 01 (multicast).
- --
David DeSimone == Network Admin == fox verio.net
"It took me fifteen years to discover that I had no
talent for writing, but I couldn't give it up because
by that time I was too famous. -- Robert Benchley
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFG5CSzFSrKRjX5eCoRAmE1AJ4mQwjbjshRXujvRoIWmRyWDCmZNgCg
iO+H
bQZ0RS1hzfp50RxQTBgGF70=
=gvO/
-----END PGP SIGNATURE-----
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to LISTSERV amadeus.us.checkpoint.com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http:
//www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
fw-1-owner ts.checkpoint.com
=================================================
|