1841 route two isp

I have a customer, they just got an Eschelon T1 in addition to their existing wireless broadband from Sprint. I have been searching through groups trying to find a definitive answer, but can't...I need to how routing can be implimented using NAT over just the broadband.

T1 csu/dsu wireless modem | / s0/0/0 fa0/0

------------------ |___1841___| fa0/1 | | w/ 1.2.3.4/29 IP block | -------------- | pix 501 | -------------- 192.168.0.0/24

They have a block of 8 from Eschelon, and the pix already nat/pat internal net, but they want their traffic outbound (just from hosts; all server traffic will go over the T1) to go over the wireless. Obviously it doesn't need to be nat'd again over the T1, but how can I get it out the broadband link? I know I need to nat because Sprint won't take the Eschelon block over their network, and I'm just not familiar enough with route-map statements to configure them myself. Can I use a nat statement for just the interface of the PIX (which is the pat int of the internal hosts) over the fa0/0 of the router?

Reply to
Andrew Markey
Loading thread data ...

-bump-

Here is what someone has helped me with...

Thanks for the response. I will try this soon, but what I don't understand is how either the pix or the router will know how to split traffic out either end. The route statements don't look at source, only destination, right? So the default route on the router is set for Sprint, wouldn't all unknown traffic get pushed out that anyway, regardless of the policy on the pix...? Again, I'm not too keen on, nor a big fan of, the pix, so bear with me.

Also to clarify, they don't have a separate block from Sprint. Prior to this install, it was a little Linksys router that was auto-assigned an IP, and it was in a /24 block. I don't think that is correct, but regardless they don't have a dedicated block to play with. They may have one or two on the same subnet, but I need to double-check. So can the policy still use an IP that isn't a "leased block" so to speak?

-----Original Message----- From: *** Sent: Tuesday, November 07, 2006 10:58 AM To: snipped-for-privacy@gmail.com Subject: Re: 1841 route two isp

In article you write: X-Newsgroups: comp.dcom.sys.cisco

On the 501, have two distinct nat (inside) policy numbers, one of which matches the servers (-all- of their traffic is to go over the T1, right?), and the other policy number for the other hosts. Then have two distinct global (outside) statements, one for each policy. On the global policy for the servers, have the outside IP be one appropriate for the Eschelon. On the global policy for the other hosts, have the outside IP be one appropriate for sprint wireless.

Then at the 1841 level, do *not* NAT the IPs. Do, however, add one or more ip route statements to point both those IP ranges towards the outside interface IP of the PIX.

As long as the packet gets to the outside of the PIX (because of the 'ip route') then the PIX will not care that the packet is or is not part of the outside IP range: the PIX will look through its tables and see that it has a translation for that IP and will put the packet through as appropriate.

To emphasize and clarify: you may have an indefinite number of public IP ranges being global'd (or static'd) to the outside of the PIX, and as long as you route the packets to the PIX outside IP, the PIX will handle them fine even though they are not in the interface subnet. The PIX is happy to allow packets *through* that are not in the interface subnet. The interface subnet is only important for when the PIX needs to ARP the outside route destination, or when the PIX needs to *itself* create traffic (e.g., you ping'd from a CLI, or you configured the PIX to send RST packets), or the PIX needs to accept traffic itself (e.g., you ping the PIX -itself-, or you terminate a VPN tunnel at the PIX interface.) But for traffic flowing through, the PIX doesn't care what the IP range is as long as it has a translation.

Reply to
Andrew Markey

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.