[c-nsp] Megapath frame relay question

Sun Feb 26 07:48:27 EST 2012

Best not to run sip through local nat.

For sip, this should do the job.

voice service voip
  sip
   bind control source-interface f0/0
   bind media source-interface f0/0

Bill D'Anjou 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:jmaimon at ttec.com]
> Sent: Friday, February 24, 2012 1:08 PM
> To: Bill D'Anjou
> Cc: cisco-nsp at 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
>
>
>
>
>
>
> bill at 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:scott at granados-llc.net]
>> Sent: Thursday, February 23, 2012 2:02 PM
>> To: Bill D'Anjou
>> Cc: cisco-nsp at 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 at 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 at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>
>
>
>