Cisco NIM NIM-4G-LTE-NA routing issue

[davec4351]

I have a few interfaces on my router one of which I want to use a cellular interface as a backup. I am having trouble with the routing for my internal lan out to the cellular interface, though I am able to do a route statement 8.8.8.8 255.255.255.255 cell0/3/0 , and ping 8.8.8.8 just fine, see below. I just need the correct routing statement from 172.x to the cell network. This configuration isn't the actual config, but very close to the actual due to security reasons can't post the actual. 

#show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0/0 10.10.10.2 YES NVRAM up up
GigabitEthernet0/0/1 172.16.1.1 YES NVRAM up up
Cellular0/3/0 100.66.58.219 YES IPCP up up

interface GigabitEthernet0/0/0
encapsulation dot1Q 10
ip address 10.10.10.2 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
no cdp enable
ip virtual-reassembly

interface GigabitEthernet0/0/1
encapsulation dot1Q 172
ip address 172.16.1.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
no cdp enable
ip virtual-reassembly

interface Cellular0/3/0
description VZ
ip address negotiated
ip nat outside
ip virtual-reassembly in
ip address negotiated
dialer in-band
dialer idle-timeout 0
dialer enable-timeout 1
dialer-group 1

ip nat inside source list 1 interface Cellular0/3/0 overload
ip route 0.0.0.0 0.0.0.0 10.10.10.1
ip route 172.16.1.0 255.255.255.0 Cellular0/3/0

dialer-list 1 protocol ip permit

ip access-list extended 1
permit ip 172.16.1.0 0.0.0.255 any log

ip nat inside source list 100 interface GigabitEthernet0/0/0 overload
ip nat inside source list 101 interface cel0/3/0 overload

access-list 100 permit ip 10.10.10.0 0.0.0.255 any

access-list 101 permit ip 172.16.1.0 0.0.0.255 any

[Giuseppe Larosa]

Hello Dave,

I don't understand your configuration template.

If Gi0/0/0 is your primary WAN link to reach the internet.

You would need

int gi0/0/0

no ip nat inside

ip nat outside

!

Your internal interface should be in any case the gi0/0/1.

You would need to use route-maps to check the outgoing interface in use in NAT statements

! backup static route

ip route 0.0.0.0 0.0.0.0 Cell0/3/0 200

! the following is not needed

no ip route 172.16.1.0 255.255.255.0 Cellular0/3/0

access-list 111 permit ip 172.16.1.0 .0.0.0.255 any

route-map NAT-GE permit 10

match address 111

match interface gi0/0/0

route-map NAT-Ce permit 10

match address 111

match interface ce0/3/0

ip nat source inside route-map NAT-GE interface gi0/0/0 overload

ip nat source inside route-map NAT-Ce interface ce0/3/0 overload

no ip nat inside source list 100 interface GigabitEthernet0/0/0 overload

no ip nat inside source list 101 interface cel0/3/0 overload

Note:

if you want to use enc dot1q command you need to use subinterfaces as far as I know.

This is true for both gi0/0/0 and gi0/0/1.

Unless you have a new IOS that allows for this setup.

Hope to help

Giuseppe

[davec4351]

Thanks for the reply Giuseppe, the Gi0/0/0 was a typo, I was manually creating an example config. I will test it out shortly, if I want ce0/3/0 to be active and not as a backup to the 172.16.x.x network how would that differ from the current config. Basically having two links active but for different network, 172 using the cell and the 10.x using the gi0/0/0 network. 

[Giuseppe Larosa · Accepted solution]

Hello Dave,

>> if I want ce0/3/0 to be active and not as a backup to the 172.16.x.x network how would that differ from the current config. Basically having two links active but for different network, 172 using the cell and the 10.x using the gi0/0/0 network

You will use two different extended ACLs

access-list 112 pemit ip 10.10.10.0 0.0.0.255 any

access-list 130 permit ip 172.16.1.0 0.0.0.255 any

route-map NAT-GE permit 10

match address 112

match interface gi0/0/0

route-map NAT-ce permit 10

match address 130

match interface ce0/3/0

The same NAT statements as in my previous post invoking route-maps are still valid.

You may need a PBR route-map on the internal interface with IP 172.16.1.x to trigger use of the cell interface.

Hope to help

Giuseppe

[davec4351]

Thank you again, that is what I am looking for!

[davec4351]

I did apply a pbr to the interface and works great. 

#show run | sec LTE_policy

route-map LTE_policy permit 10
match ip address 130
set interface Cellular0/3/0

[Giuseppe Larosa]

Hello Dave,

very good news! yes the PBR is required in your scenario to achieve the desired behaviour.

Best Regards

Giuseppe

[davec4351]

Thanks, so it looks like I have a new issue, my cellular interface is flapping and it is probably due to the nat or an alternate source leaking out the cellular interface causing an ip violation of the lte provider, any thoughts on how I can determine if an alternate ip other than the cellular interface is leaking out?

“
7. If the LTE connection becomes active but then begins to flap (repeats going down and up periodically,
usually every 5 to 60 seconds), a configuration problem must be resolved.
a. This behavior can be caused by a network disconnect due to IP source address violations. It is resolved by reconfiguring the traffic to be tunneled, NAT, or access control lists (ACLs) so that no traffic is routed without being tunneled or subjected to NAT.”

[Giuseppe Larosa · Accepted solution]

Hello Dave,

you can verify the NAT activity using

show ip nat translations

To verify if any other source IP address is going out the cell0/3/0 you can use different methods

a) Use an IP extended ACL with log option

access-list 150 remark to check outbound traffic on cell0/3/0

access-list 150 permit ip host <cell0/3/0-ip-address> any

access-list 150 permit ip any  any log

int cell0/3/0

ip access-group 150 out

Then you check the logs with show log looking for messages written by the ACL

b) using debug ip packet with condition set to interface cell0/3/0

CAUTION: debug commands can have great impact on your router. so this is a last resort option to use.

You can use an ACL and you can use a debug condition to speciify you are interested only on cell0/3/0 interface.

Hope to help

Giuseppe

[davec4351]

Thank you, didn’t see anything in the acls with the log so the connection flap may not be the leak issue. Will keep checking thanks!

[davec4351]

I was able to resolve the flapping by adding a VRF instance to the cellular interface. Though, the PBR in the internal interface gi0/0/0.172 doesn't allow me to route from my other in the 192.168.1.x.  I have another subinterface 192.168.1.x that can't get to the 172.16.1.x network from my lan, but I can ping the 172.16.1.x subnet from the router, but not from the lan, see below 

interface Cellular0/3/0
ip vrf forwarding LTE
ip address negotiated previous
no ip unreachables
ip nat outside
dialer in-band
dialer idle-timeout 0
dialer watch-group 1
dialer-group 1
ipv6 enable
pulse-time msec 1
ip virtual-reassembly
end

ip vrf LTE
ip vrf forwarding LTE

####

ICNISR4#show run int gi0/0/1.901
Building configuration...

Current configuration : 212 bytes
!
interface GigabitEthernet0/0/1.901
encapsulation dot1Q 901
ip address 192.168.1.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
no cdp enable
ip virtual-reassembly
end

ICNISR4#show run int gi0/0/1.172
Building configuration...

Current configuration : 243 bytes
!
interface GigabitEthernet0/0/1.172
encapsulation dot1Q 172
ip address 172.16.1.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip policy route-map LTE_policy
no cdp enable
ip virtual-reassembly
end

I am able to ping both the default gateway on the lan of 172.16.1.1, but I cannot ping anything behind that interface, I checked the access-list and everything is open. When I remove the PBR, I can ping anything behind that lan for example 172.16.1.4, do I need to do anything else to allow 192.168.1.1 to route within that PBR assigned to the 172 interface?

[Giuseppe Larosa]

Hello Dave,

if you want to have connectivity between subnets 192.168.1.0/24 and 172.16.1.0/24 you need to use a modified version of the ACL used in the PBR route-map.

If your current ACL looks like the following:

access-list 130 permit ip 172.16.1.0 0.0.0.255 any

The PBR is triggered for any possible destination.

You should use a modified ACL like the following:

access-list 131 deny ip 172.16.1.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 131 permit ip 172.16.1.0 0.0.0.255 any

The first line with a deny allows traffic between subnets 172.16.1.0/24 and 192.168.1.0/24 to happen without triggering PBR and the cell0/3/0 interface as this is not needed as both are internal subnets in the site.

You should change the PBR route-map to use

match address 131

instead of match address 130

Hint:

config t

route-map PBR permit 10

no match address 130

match address 131

Then look at the show run  to see if the route-map has the correct configuration.

Hope to help

Giuseppe