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:[email protected]]
Sent: Friday, February 24, 2012 1:08 PM
To: Bill D'Anjou
Cc: [email protected]
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
[email protected] 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:[email protected]]
Sent: Thursday, February 23, 2012 2:02 PM
To: Bill D'Anjou
Cc: [email protected]
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 [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
?
?
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
