That solution works Christopher. Thank-you! Joe, your NAT suggestion also works. Thanks again!
Not sure which solution I'll stick with. The NAT solution provides more functionality - i.e. I can ping from the CLI now! I'm using very tight ACL entries due to my concern that the NAT process could interfere with the PPP negotiation. Thanks again everyone! Bill -----Original Message----- From: Christopher J. Pilkington [mailto:c...@0x1.net] Sent: Friday, February 24, 2012 6:15 PM To: Bill D'Anjou Subject: Re: [c-nsp] Megapath frame relay question Take a look at https://supportforums.cisco.com/thread/2069010 -cjp On Feb 24, 2012, at 16:45, Bill D'Anjou <b...@siliconics.net> wrote: > Thanks Joe. > > I'll give this a try... I didn't realize NAT rules could interact with > traffic originating from the router itself. > > BTW, the reason I need this to work is the router has a couple FXS > ports in it. None of the dial-peer stuff works under the current > configuration. > > -----Original Message----- > From: Joe Maimon [mailto:jmai...@ttec.com] > Sent: Friday, February 24, 2012 1:08 PM > To: Bill D'Anjou > Cc: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] Megapath frame relay question > > Use some nat if you want to source traffic from the router and have it > attempt to use the unrouted address and still work. > > Of course, you could start hard configuring which address various > router initiated traffic sourced from, but this is a much more > complete approach. > > ip access-list extended inside-nat-rules > deny ip any 192.168.0.0 0.0.255.255 > deny ip any 172.16.0.0 0.15.255.255 > deny ip any 10.0.0.0 0.255.255.255 > permit ip 192.168.0.0 0.0.255.255 any permit ip 172.16.0.0 > 0.15.255.255 any permit ip 10.0.0.0 0.255.255.255 any > deny ip any any > > route-map inside-nat-f0/0 den 200 > route-map inside-nat-f0/0 per 100 > match ip add inside-nat-rules > > > int f0/0 > ip nat in > int Virtual-Tem1 > ip nat ou > > ip nat ins so rou inside-nat-f0/0 int f0/0 ov > > > > > > > b...@siliconics.net wrote: >> Thank-you all for the responses. >> >> I don't think "unnumbered" or "multilink" are options for me since >> the > >> WAN IP - AND the default route - are "obtained." >> Note the following directives on the virtual-template: >> int virtual-template1 >> ip address negotiated >> ppp ipcp route default >> >> As Scott & others have pointed out, Megapath is giving me a >> non-routable address. See below. >> >> sh ip route >> Gateway of last resort is 172.22.0.1 to network 0.0.0.0 >> 172.22.0.0/32 is subnetted, 2 subnets C 172.22.0.1 is directly >> connected, Virtual-Access1 C 172.22.246.177 is directly connected, >> Virtual-Access1 >> 74.0.0.0/29 is subnetted, 1 subnets >> C x.x.x.x is directly connected, FastEthernet0/0 >> S* 0.0.0.0/0 [1/0] via 172.22.0.1 >> >> So that's the crux of the issue right? If they were giving me a "real" >> IP I wouldn't have the issue, right? >> Anyway, it doesn't look like any of the solutions offered thus far >> will work for me. And Megapath is not inclined to provide > configuration support. >> >> -----Original Message----- >> From: Scott Granados [mailto:sc...@granados-llc.net] >> Sent: Thursday, February 23, 2012 2:02 PM >> To: Bill D'Anjou >> Cc: cisco-nsp@puck.nether.net >> Subject: Re: [c-nsp] Megapath frame relay question Ok, few points. >> FIrst, yes, Megapath is going to assign you a 172.16 address to your >> wan interface. This is a pretty standard Covad / Megapath thing. >> Next, when I've done this is memory served I had to use a dialer >> interface for the actual interface and bind that to a sub interface >> using a dialer pool You should see something like a standard >> interface > >> when you show the dialer that includes the IP assigned. >> Then you set your default route with ip route 0.0.0.0 0.0.0.0 >> interface >> dialer1 and it should work, at least as well as Megapath circuits >> ever > >> work which is definitely not that well. If you google Cisco PPP over >> FR you should find the example I used as the first or second listing >> with a great config example. >> GOod luck >> ? >> On Feb 23, 2012, at 1:09 PM, Bill wrote: >>> Dear Cisco gurus, >>> >>> I have the following simple config for a frame-relay T1 on >>> Megapath's >>> network: >>> >>> interface FastEthernet0/0 >>> ip address x.x.x.x x.x.x.x !!!!!!!!!!!!(publicly addressable /29) >>> duplex auto speed auto ! >>> interface Serial0/0 >>> no ip address >>> encapsulation frame-relay IETF >>> no fair-queue >>> frame-relay interface-dlci 16 ppp Virtual-Template1 !!!!!!!!!(I've >>> seen examples where this line is entered on a sub-interface - not >>> sure if this >>> matters) >>> frame-relay lmi-type ansi >>> ! >>> interface Virtual-Template1 >>> ip address negotiated >>> ppp chap hostname username@bz8 >>> ppp chap password 0 password >>> ppp ipcp dns request >>> ppp ipcp route default >>> ppp ipcp address accept >>> ! >>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >>> The issue I have is, there's no connectivity from the router itself. >>> Anything behind the router - using the LAN IP block - works fine. >>> For > >>> example, within the Cisco CLI, if I issue the ping command by >>> itself, > >>> I get no reply. If I issue the ping command & specify that the >>> source > >>> address is the IP on the FastE interface, then I get replies. >>> >>> This seems to me like an issue with the way Megapath provisions >>> these > >>> circuits but I'm trying to see if there's a simple way to workaround >>> the issue. Such as making ALL traffic from the router appear to >>> originate from the IP on the FastE interface. >>> >>> Thanks in advance for your help/replies. >>> >>> Bill >>> >>> _______________________________________________ >>> cisco-nsp mailing list cisco-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> ? >> ? >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> > > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/