Thanks for Brett explained this issue perfectly :) As far as I did not saw any solution from cisco, so I decided to focus attatension on Linux Firewall/NAT,search whether netfilter can decapsulate keepalive GRE packet and NAT it's destination address....
if anyone have better idea ? Thanks :) Pigsign > The issue is that a GRE keepalive packet has the originating tunnel > endpoint IP address as the destination address of the encapsulated > packet. That is, consider the following: > interface tunnel1 > tunnel source 10.0.0.1 > tunnel destination 20.0.0.2 > tunnel keepalive > (Not sure I've got the syntax right, but you get the idea.) > > A keepalive packet generated by the router will look like the following: > IP header: Source=10.0.0.1 Destination=20.0.0.2 Protocol=GRE > GRE Header: Protocol=IP > Encapsulated Packet: > IP Header: Source=? (Not Inportant) Dest=10.0.0.1 Proto=GRE > GRE Header: 0x0000 > > The idea is that the router at the far end will received the packet, > remove the outer header, and transmit the encapsulated packet. (The > router at the far end will, then, not do any special processing all for > a keepalive packet originating from the near end.) THe issue with > keepalive is that the 10.0.0.1 appears in the encapsulated packet, so > if that's being NAT'd somewhere, for keepalive to work, the NAT needs > to translate the address on the encapsulated packet also. > > AFAIK, essentially no NATs will do that. > > So, anyway, suppose that 10.0.0.1 is being NAT'd to 30.0.0.1. The far > end router then receives: > IP header: Source=30.0.0.1 Destination=20.0.0.2 Protocol=GRE > GRE Header: Protocol=IP > Encapsulated Packet: > IP Header: Source=? (Not Inportant) Dest=10.0.0.1 Proto=GRE > GRE Header: 0x0000 > > The far end router's normal GRE processing then involves removing the > outer header, and attempting to send the following packer: > IP Header: Source=? (Not Important) Dest=10.0.0.1 Proto=GRE > GRE Header: 0x0000 > This fails because the far end router has no path to get to 10.0.0.1, > because it should be sending to 30.0.0.1. > > The reason that isn't a problem for "other" GRE packets is that, in > general, there's no requirement that the encapsulated packet be > translated by the NAT, because, in general, the tunnel endpoint IP > addresses don't appear as source or destination addresses on the > encapsulated packet. > > More generally, GRE works fine through NAT as long as the expectation > is that one or both of the tunnel endpoint addresses will be > translated, but the packets flowing through the tunnel don't need NAT. > However, once you enable keepalive, you effectively create a > requirement that the encapsulated packets be translated, because Cisco > GRE keepalive depends on using the tunnel origin/destination address in > encapsulated packet. > > This also, in general, breaks keepalives when a tunnel interface has > "ip forwarding vrf XXXX' and "tunnel vrf YYYY" where XXXX and YYYY > aren't the same. (This is because the keepalive processing on the far > end will result in a packet being send in vrf XXXX to a destination IP > address that is reallyin vrf YYYY.) > > And, yes, I think this is horribly broken. A much better GRE keepalive > implementation would be to just send > IP header: Source=30.0.0.1 Destination=20.0.0.2 Protocol=GRE > GRE Header: Protocol=KeepaliveRequest > and have the far end router generate a > IP header: Source=20.0.0.2 Destination=30.0.0.1 Protocol=GRE > GRE Header: Protocol=KeepaliveResponse > This would work through NAT and through complicated VRF configurations. > But that's not what Cisco implemented. > > -- Brett > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
