GRE tunnel default MTU

Anybody know the default mtu setting on a gre tunnel interface such as this?:
interface Tunnel1
description "xxx"
ip address x.x.x.x 255.255.255.252
tunnel source Loopback1
tunnel destination x.x.x.x
I'm asking cause on the core redundant to this one where I've copied code from, the config line 'ip mtu 1500' is configured. I want to make sure these are matched up.
Thanks in advance.
/rls

Robert,
Sorry, I spoke too soon. I should have focused on your question, which is "IP MTU" and referred you to the command "show ip interface Tu0" instead of "show interface tu0".
GRE packets are formed by the addition of the original packets and the required GRE
headers. These headers are 24-bytes in length and since these headers are added to the
original frame, depending on the original size of the packet we may run into IP MTU
problems.
Even though the maximum IP datagram has been defined as 64K, most links enforce a smaller
maximum size for the packets. This maximum size is known as MTU (Maximum Transmission
Unit) and as you also know, different types of media have different MTU sizes they can
accommodate and transport. The most common IP MTU is 1500-bytes in length (Ethernet).
The IP implementation, as we know it, provides a mechanism to allow routers the
fragmentation and transmission of packets larger if there are differences in the MTU and a
packet is larger than what the outgoing media will support. Once a packet has been
fragmented to be sent over a media that will not support the original packet size, the end
station is responsible for the reassembly of the different fragments the original packet
was broken into.
GRE tunnels normally calculate their IP MTU size based on the physical link they will use
as the outgoing interface.
What you see in “show interface Gig X” is the MTU of the interface and NOT the IP MTU.
In order for you to see the IP MTU you need to use the “show ip interface Gig X”
When the tunnel is created, it deducts the 24-bytes it needs to encapsulate the passenger
protocols and that is the IP MTU it will use.
For example, if we are forming a tunnel over FastEthernet (IP MTU 1500) the IOS calculates
the IP MTU on the tunnel as:
1500-bytes from Ethernet - 24-bytes for the GRE encapsulation = 1476-Bytes
Let me explain this with a simple set up:
Lets say I configure a Tunnel interface and sourcing it via a physical interface which has an MTU of 1500, then the Tunnel
interface will have IP MTU of 1476, leaving space for the 24 byte GRE Header.
In my case, I am sourcing the packets from Gig0/0 which has physical interface of MTU 1500, so when I do a "show ip int Tu0",
You will see that the IP MTU is 1476.
Router#sh run int gi0/0
Building configuration...
Current configuration : 118 bytes
interface GigabitEthernet0/0
ip address 10.89.245.253 255.255.255.0
duplex auto
speed auto
media-type rj45
end
Router#sh run int tu0
Building configuration...
Current configuration : 127 bytes
interface Tunnel0
ip address 1.1.1.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 10.89.245.1
end
Router#sh int gi 0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 10.89.245.253/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
Router#sh ip int tu 0
Tunnel0 is up, line protocol is up
Internet address is 1.1.1.1/30
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1476 bytes
Now, lets say I lower the IP MTU value on Gi0/0 to 1400, What should be the default new value on the tunnel interface?? You
are absolutely right, 1376 :-)
Router#sh run int gi0/0
Building configuration...
Current configuration : 131 bytes
interface GigabitEthernet0/0
ip address 10.89.245.253 255.255.255.0
ip mtu 1400
duplex auto
speed auto
media-type rj45
end
Router#sh ip int tu0
Tunnel0 is up, line protocol is up
Internet address is 1.1.1.1/30
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1376 bytes
Please standby.... More to follow in the second post due to character limitation
Regards,
Arul
** Please rate all helpful posts **

Similar Messages

  • GRE tunnel MTU and bandwidth

                       Hi Everyone.
    GRE tunnel from Site A has
    MTU 17916 bytes, BW 100 Kbit, DLY 50000 usec,
    Site B has
    MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
    I read that default BW for GRE is 9kbit  but here 1 side has default and other side has 100.
    One side has default MTU other side has 17916
    so is this normal behaviour?
    So need to know the purpose of using MTU 17916 and bandwidth of 100  on Site A?
    Thanks
    Mahesh

    Hello Mahesh,
    The bandwidth and Delay on the Tunnel interface is sometimes used to change the EIGRP metrics to influence routing table. For example if you have two equal cost paths to certain network in your routing table, you can increase the delay on one of the tunnels and make the other tunnel the preffered one. Not sure if this is the case with your setup.. it;s really hard to say without looking at the config.
    As for the MTU, not sure why MTU size is 17916..  1514 make sense but still too big for a GRE tunnel.. I think
    Please rate this post if helpful.. THanks

  • GRE Tunnel/NAT with multiple subnets and interfaces

    So, I am not sure if we are trying to accomplish too many things at once and what we are attempting to do is not possible or if we are missing something in our configurations...
    Here is the situation...
    We are migrating some equipment between datacenters.  The equipment only a has a /27 worth of IP space assigned to it so we cannot simply "move" the IP space to the new datacenter.  Further because we have several VPNs terminated in the old IP space that originate from devices we do not directly control and are essential in continuing to provide service, it was/is difficult to magically update some DNS entries and change IP addresses overnight.  The last twist in this puzzle is that at the new datacenter, we will deploying some new equipment that will be in a separate subnet (with a separate Windows AD structure) but sharing the new public IP space we have in the new datacenter.
    We thought using a GRE tunnel, some trunks, and a bunch of NATs would make the whole process easy and we tested ti in a lab and everything SEEMED to work.  However, when we performed the move we ran into an odd issue that we were unable to figure out and had to go back to a failsafe configuration that has the essentials up and running, but the environment is not running in an ideal way for us to gradually transition as we would like.
    Essentially what we had/have and how it was configured is as follows:
    Site A
    Edge Router - x.x.x.x /24 BGP announcement
    x.x.x.y/27 that is within the /24 that we need at site b
    GRE tunnel configuration
    interface tunnel0
      ip address 10.x.x.1 255.255.255.252
      tunnel source <router edge IP>
      tunnel destination <site b router edge ip>
      keepalive 10 3
    static route for site a public ip to bring it to site b via GRE tunnel
    ip route x.x.x.y 255.255.255.224 10.x.x.2
    Site B
    Edge Router - y.y.y.y /24 BGP announcement
    Similar GRE tunnel configuration (tunnel comes out and works so don't think issue is here)
    2 Vlans (1 for site a ip space, 1 for site b ip space)
    int vlan 50
    ip address x.x.x.1 /27
    int vlan 51
    ip address y.y.y.129 /25
    Trunk port for the VLANs going down to an ASA
    int g1/1
      swi mode trunk
      swi trunk native vlan 51
      swi tru all vlan 50,51
      swi tru en dot1q
    Then on the ASA, I have 2 physical interfaces for 4 logical interfaces (outside, outsideold, inside, insideold)
    int e0/0
     nameif outside
     sec 0
     ip address y.y.y.130 /25
    int e0/0.50
     nameif outsideold
     sec 0
     ip address x.x.x.2 /27
     vlan 51
    int e0/1
      nameif inside
      sec 100
      ip address 192.168.y.1 /24
    int e0/1.60
      nameif insideold
      sec 100
      ip address 192.168.x.1 /24
      vlan 60
    A static route using the new ip space on the native outside interface...
    route 0 0 y.y.y.129
    And then I have some nat rules which is where I think things go a little haywire...
    object network obj-y.y.y.0-24
      subnet y.y.y.0 255.255.255.0
     nat (inside,outside) dynamic interface
    object network obj-x.x.x.0-24
      subnet x.x.x.0 255.255.255.0
     nat (insideold,outside) dynamic interface
    object network obj-y.y.y.135-160
      range y.y.y.135 y.y.y.160
    object network obj-192.168.y.135-160
      range 192.168.y.135 192.168.y.160
      nat (inside,outside) static obj-y.y.y.135-160
    object network obj-x.x.x.10-20
      range x.x.x.10 x.x.x.20
    object network obj-192.168.x.10-20
      range 192.168.x.10 192.168.x.20
      nat (insideold,outsideold) static obj-x.x.x.10-20
    From some debugging and looking at packet-tracer, I found out I left out the below which was needed to properly nat traffic as it leaves the outside interface (when the default sends the traffic)
    object network obj-192.168.x.10-20-2
      range 192.168.x.10 192.168.x.20
      nat (insideold,outside) static obj-x.x.x.10-20
    There are / were a bunch of other nat exemptions for the VPNs and specific external routes to ensure all vpn traffic exited the "outsideold" interface which is where all the existing tunnels were terminated.
    Everything appeared to be working great as all the VPN tunnels came up perfectly as expected and traffic appeared to be flowing, except for some of the most important traffic.  The following was what was observed:
    1.  Any traffic using the dynamic NAT (ie...a machine with IP x.x.x.200 or y.y.y.20) would connect to the internet perfectly and work fine using the "new interface ip".
    2.  Any traffic in the "new range" using a one to one nat worked perfectly (ie y.y.y.140).  Internet would work etc and nat translation would properly occur and everything could connect fine as expected.
    3.  ICMP packets to "old ip range" flowed perfectly fine to one to one nat IP (ie I could ping x.x.x.20 from outside) and likelise I could ping anywhere on the internet from a machine with a static natted ip.
    4.  Heres the butt...no traffic other than ICMP would reach these machines with static ips.  Same range, same subnet as ones using the dynamic port translation that worked perfectly.  Do not understand why this was / is the case and this is what I am seeking a solution to.  I have attempted the following troubleshooting steps without success:
    A. Confirmed MTU size was not an issue with the GRE tunnel.  2 methods, one plugging to edge router and using the "outsideold" ip space works perfectly and 2 if I assign outsideold ip space to "outside" interface, everything nats fine.
    B. Ran packet-tracer, all results show "allow" as if I should be seeing the packets.
    C. Confirmed local windows machine firewall was off and not blocking anything.
    D. Reviewed logs and observed SYN timeouts and TCP teardowns as if the firewall is not getting a response and this is where I am stumped.  There is no path around the firewall so asymmetric routing should not be an issue and if that was the problem it should not work when the "outsideold" ip space is assigned and natted from the "outside" interface, but it does.  Packet-tracer shows proper nat translations occurring and there is definitely proper routing along the path for stuff to return to the network or ICMP would not work (IE I can ping www.google.com but not open the web page).
    So what simple piece of the nat configuration am I overlooking because I cannot possible wrap my head around it being anything else.
    Any suggestions / lessons would be greatly appreciated.

    is this still a problem?

  • GRE tunnel could not be used by the hosts connected to the router

    Hi,
    I am using cisco ASR1013 (RP2) and a Mikrotik Router for setting up a GRE tunnel for LAN to LAN routing over a broadband link. The tunnel works fine (able to ping tunnel end points and also all the connected interfaces on both the Mikrotik and Cisco ASR) but the hosts that are connected directly to the Cisco router interface over a layer 2 cisco switch are unable to connect (ping) the hosts or connected interfaces on the mikrotik side. I am sure its not a mikrotik issue as i dont see any traffic coming through the tunnel using the mikrotik torch utility.  There are no ACL's or firewall rules on any of the devices...... 
    Source and destination of the tunnel are public IP's and are pingable via internet (The tunnel is connected and endpoints are pingable)
    Mikrotik connected interface IP = 192.168.253.1/24
    Mikrotik tunnel end point IP = 192.168.254.1/30
    Cisco tunnel end point IP = 192.168.254.2/30
    Connected cisco subnet to reach Mikrotik = M.N.O.32/28
    Cisco interface IP for LAN = M.N.O.33
    Test host IP on the LAN subnet = M.N.O.34
    The below is my Cisco config
    ASR-1#sh run int tun 1
    Building configuration...
    Current configuration : 144 bytes
    interface Tunnel1
     ip address 192.168.254.2 255.255.255.252
     ip mtu 1400
     tunnel source A.B.C.D
     tunnel destination W.X.Y.Z
    end
    ASR-1#sh run int g0/1/7
    Building configuration...
    Current configuration : 280 bytes
    interface GigabitEthernet0/1/7
     description LAN
     ip address M.N.O.33 255.255.255.240
     ip verify unicast source reachable-via rx
     no negotiation auto
     cdp enable
    end
    ASR-1#sh ip ro 192.168.253.1
    Routing entry for 192.168.253.0/24
      Known via "static", distance 1, metric 0 (connected)
      Routing Descriptor Blocks:
      * directly connected, via Tunnel1
          Route metric is 0, traffic share count is 1
    ASR-1#ping 192.168.253.1 so M.N.O.33
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.168.253.1, timeout is 2 seconds:
    Packet sent with a source address of M.N.O.33 
    Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/6 ms
    ASR-1#pi M.N.O.34
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to M.N.O.34, timeout is 2 seconds:
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
    If i try to ping 192.168.253.1 (network connected to Mikrotik) from the host M.N.O.34 (the gateway of this host is M.N.O.33 - Int g0/1/7 of the Cisco ASR), i cannot reach detination - request timed out.... Below are the results of trace and ping from the host connected to ASR G1/0/7
    PING TO THE GATEWAY *********
    [root@localhost ~]# ping M.N.O.33
    PING M.N.O.33 (M.N.O.33) 56(84) bytes of data.
    64 bytes from M.N.O.33: icmp_seq=1 ttl=255 time=0.161 ms
    64 bytes from M.N.O.33: icmp_seq=2 ttl=255 time=0.143 ms
    ^C
    --- M.N.O.33 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1357ms
    rtt min/avg/max/mdev = 0.143/0.152/0.161/0.009 ms
    PING TO THE TUNNEL END POINT IN CISCO ASR
    [root@localhost ~]# ping 192.168.254.2
    PING 192.168.254.2 (192.168.254.2) 56(84) bytes of data.
    64 bytes from 192.168.254.2: icmp_seq=1 ttl=255 time=0.141 ms
    64 bytes from 192.168.254.2: icmp_seq=2 ttl=255 time=0.141 ms
    ^C
    --- 192.168.254.2 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1739ms
    rtt min/avg/max/mdev = 0.141/0.141/0.141/0.000 ms
    PING TO THE TUNNEL ENDPOINT IN MIKROTIK
    [root@localhost ~]# ping 192.168.254.1
    PING 192.168.254.1 (192.168.254.1) 56(84) bytes of data.
    ^C
    --- 192.168.254.1 ping statistics ---
    11 packets transmitted, 0 received, 100% packet loss, time 10413ms
    PING TO THE CONNECTED INTERFACE ON MIKROTIK
    [root@localhost ~]# ping 192.168.253.1
    PING 192.168.253.1 (192.168.253.1) 56(84) bytes of data.
    ^C
    --- 192.168.253.1 ping statistics ---
    4 packets transmitted, 0 received, 100% packet loss, time 3641ms
    TRACE TO THE CONNECTED INTERFACE ON MIKROTIK
    [root@localhost ~]# traceroute 192.168.253.1
    traceroute to 192.168.253.1 (192.168.253.1), 30 hops max, 60 byte packets
     1  M.N.O.33 (M.N.O.33)  0.180 ms  0.156 ms  0.145 ms
     2  * * *
     3  * * *
     4  * * *
     5  * * *
    Please help

    Hi,
    Sorry for the delayed response ....Both ends static routes are added for the connected test interfaces.....
    Regards,
    Mahesh 

  • IP routing utilizing Verizon private network (GRE tunnel) with remote cellular gateways

    Okay, I give up, and think I have done my due diligence (I have been engrossed and fascinated spending many more hours than allotted to try and learn some of the finer details).  Time for some advice.  My usual trade is controls engineering which generally require only basic knowledge of networking principals.  However I recently took a job to integrate 100 or so lift stations scattered around a county into a central SCADA system.  I decided to use cellular technology to connect these remote sites back to the main SCADA system.  Well the infrastructure is now in and it’s time to get these things talking.  Basic topology description is as follows:  Each remote site has an Airlink LS300 gateway.  Attached to the gateway via Ethernet is a system controller that I will be polling via Modbus TCP from the main SCADA system.  The Airlinks are provisioned by Verizon utilizing a private network with static IP's.  This private networks address is 192.168.1.0/24.  Back at the central office the SCADA computer is sitting behind a Cisco 2911.  The LAN address of the central office is 192.168.11.0/24.  The 2911 is utilizing GRE tunnels that terminate with Verizon.  The original turn up was done with another contractor that did a basic config of the router which you will find below.  As it stands now I am pretty confident the tunnels are up and working (if I change a local computers subnet to 255.255.0.0 I can surprisingly reach the airlinks in the field), but this is obviously not the right way to solve the problem, not to mention I was unable to successfully poll the end devices on the other side of the Airlinks.  I think I understand just about every part of the config below and think it is just missing a few items to be complete.  I would greatly appreciate anyone’s help in getting this set up correctly.  I also have a few questions about the set up that still don’t make sense to me, you will find them below the config.  Thanks in advance.
    no aaa new-model
    ip cef
    ip dhcp excluded-address 10.10.10.1
    ip dhcp pool ccp-pool
     import all
     network 10.10.10.0 255.255.255.248
     default-router 10.10.10.1 
     lease 0 2
    ip domain name yourdomain.com
    no ipv6 cef
    multilink bundle-name authenticated
    username cisco privilege 15 one-time secret 
    redundancy
    crypto isakmp policy 1
    encr 3des
    hash md5
     authentication pre-share
     group 2
    crypto isakmp key AbCdEf01294 address 99.101.15.99  
    crypto isakmp key AbCdEf01294 address 99.100.14.88 
    crypto ipsec transform-set VZW_TSET esp-3des esp-md5-hmac 
    mode transport
    crypto map VZW_VPNTUNNEL 1 ipsec-isakmp 
     description Verizon Wireless Tunnel
     set peer 99.101.15.99
     set peer 99.100.14.88
     set transform-set VZW_TSET 
     match address VZW_VPN
    interface Tunnel1
     description GRE Tunnel to Verizon Wireless
     ip address 172.16.200.2 255.255.255.252
     tunnel source 22.20.19.18
     tunnel destination 99.101.15.99
    interface Tunnel2
    description GRE Tunnel 2 to Verizon Wireless
     ip address 172.16.200.6 255.255.255.252
     tunnel source 22.20.19.18
     tunnel destination 99.100.14.88
    interface Embedded-Service-Engine0/0
     no ip address
     shutdown
    interface GigabitEthernet0/0
     description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
     ip address 10.10.10.1 255.255.255.248
     shutdown
     duplex auto
     speed auto
    interface GigabitEthernet0/1
     ip address 192.168.11.1 255.255.255.0
     duplex auto
     speed auto
    interface GigabitEthernet0/2
     ip address 22.20.19.18 255.255.255.0
    duplex full
     speed 100
     crypto map VZW_VPNTUNNEL
    router bgp 65505
     bgp log-neighbor-changes
     network 0.0.0.0
     network 192.168.11.0
     neighbor 172.16.200.1 remote-as 6167
     neighbor 172.16.200.5 remote-as 6167
    ip forward-protocol nd
    ip http server
    ip http access-class 23
    ip http authentication local
    ip http secure-server
    ip http timeout-policy idle 60 life 86400 requests 10000
    ip route 0.0.0.0 0.0.0.0 22.20.19.19
    ip access-list extended VZW_VPN
     permit gre host 99.101.15.99 host 22.20.19.18
     permit icmp host 99.101.15.99 host 22.20.19.18
     permit esp host 99.101.15.99 host 22.20.19.18
     permit udp host 99.101.15.99 host 22.20.19.18 eq isakmp
     permit gre host 22.20.19.18 host 99.101.15.99
     permit gre host 22.20.19.18 host 99.100.14.88
    access-list 23 permit 10.10.10.0 0.0.0.7
    control-plane
    end
    So after spending countless hours analyzing every portion of this,  I think that adding one line to this will get it going (or at least closer).
    ip route 192.168.1.0 255.255.0.0 22.20.19.19
    That should allow my internal LAN to reach the Airlink gateways on the other side of the tunnel (I think)
    Now for a couple of questions for those that are still actually hanging around.
    #1 what is the purpose of the Ethernet address assigned to each tunnel?  I only see them being used in the BGP section where they are receiving routing tables from the Verizon side (is that correct?).  Why wouldn't or couldn't you just use the physical Ethernet address interface in its place (in the BGP section)?
    #2 is the config above correct in pointing the default route to the physical Ethernet address?  Does that force the packets into the tunnel, or shouldn’t you be pointing it towards the tunnel IP's (172.16.200.2)?  If the config above is correct then I should not need to add the route I described above as if I ping out to 192.168.1.X that should catch it and force it into the tunnel where Verizon would pick it up and know how to get it to its destination??
    #3 Will I need to add another permit to the VZW_VPN for TCP as in the end I need to be able to poll via Modbus which uses port 502 TCP.  Or is TCP implicit in some way with the GRE permit?
     I actually have alot more questions, but I will keep reading for now.
    I really appreciate the time you all took to trudge through this.  Also please feel free to point anything else out that I may have missed or that can be improved.  Have a great day!

    This post is a duplicate of this thread
    https://supportforums.cisco.com/discussion/12275476/proper-routing-lan-through-verizon-private-network-gre-airlink-gateways
    which has a response. I suggest that all discussion of this question be done through the other thread.
    HTH
    Rick

  • Ip route command in GRE tunnel

                       Hi Everyone,
    I have setup GRE Lab between Routers R1 and R3.
    R1 is connected to R2 using OSPF  and R2  is connected to R3 using OSPF.
    I config GRE tunnel interface on R1 and R3.
    R1 has internal subnet say 100.x.x.x.x to share with R3.
    R3 has internal Lan subnet  say 101.x.x.x.x  to share with R1.
    Interesting traffic to pass through GRE tunnel is subnets 100.x.x.x.  and 101.x.x.x.x.
    R1 tunnel config
    R1#            sh run int tunnel 0
    Building configuration...
    Current configuration : 168 bytes
    interface Tunnel0
    ip address 13.13.13.1 255.255.255.0
    keepalive 3
    cdp enable
    tunnel source Loopback0
    tunnel destination 20.0.0.1
    tunnel path-mtu-discovery
    R3 Tunnel config
    R3#sh run int tunnel 0
    Building configuration...
    Current configuration : 158 bytes
    interface Tunnel0
    ip address 13.13.13.3 255.255.255.0
    keepalive 3 1
    tunnel source Loopback0
    tunnel destination 10.0.0.1
    tunnel path-mtu-discovery
    So my question is instead of using Routing protocols to advertise the Lan subnets from R1 and R3  can i use static routes?
    for example
    If i can use static routes say on R1
    ip route 101.101.101.101 255.255.255 ?
    what should be next hop IP here ?
    tunnel interface of R3 Router  or physical interface of R3 that connects to R2?
    Then same way i can use static routes on R3 right ?
    Thanks
    Mahesh

    Hello Mahesh,
    You can use IP address as long as Tunnel IP addresses on both sides are in the same subnet. So in your case you can use
    ip route 101.101.101.101 255.255.255 13.13.13.3
    Or you can use the tunnel interface
    ip route 101.101.101.101 255.255.255 Tunnel0
    Although I have seen issues in some cases when the interface name is used instead of tunnel IP.
    Please rate this post if helpful.
    THanks
    Shaml

  • Problem with a simple GRE tunnel

    Hello everyone:
    I have a problem with a simple GRE tunnel, and can not make it work, the problem lies in the instruction "tunnel source loopback-0" if I use this command does not work, now if I use "tunnel source <ip wan >" if it works, someone can tell me why?
    Thanks for your help
    Router 1: 2811
    version 12.4
    no service password-encryption
    hostname cisco2811
    no aaa new-model
    ip cef
    interface Loopback0
    ip address 2.2.2.2 255.255.255.255
    interface Tunnel0
    ip address 10.10.1.1 255.255.255.0
    tunnel source Loopback0
    tunnel destination 217.127.XXX.188
    interface Tunnel1
    ip address 10.10.2.1 255.255.255.0
    tunnel source Loopback0
    tunnel destination 80.32.XXX.125
    interface FastEthernet0/0
    description LOCAL LAN Interface
    ip address 192.168.1.254 255.255.255.0
    ip nat inside
    ip virtual-reassembly
    duplex auto
    speed auto
    interface FastEthernet0/1
    description WAN Interface
    ip address 195.77.XXX.70 255.255.255.248
    ip nat outside
    ip virtual-reassembly
    duplex auto
    speed auto
    ip forward-protocol nd
    ip route 0.0.0.0 0.0.0.0 195.77.XXX.65
    ip route 192.168.3.0 255.255.255.0 Tunnel0
    ip route 192.168.4.0 255.255.255.0 Tunnel1
    ip nat inside source route-map salida-fibra interface FastEthernet0/1 overload
    access-list 120 deny ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
    access-list 120 deny ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255
    access-list 120 permit ip 192.168.1.0 0.0.0.255 any
    route-map salida-fibra permit 10
    match ip address 120
    Router 2: 2811
    version 12.4
    service password-encryption
    ip cef
    no ip domain lookup
    multilink bundle-name authenticated
    username admin privilege 15 password 7 104CXXXXx13
    interface Loopback0
    ip address 4.4.4.4 255.255.255.255
    interface Tunnel0
    ip address 10.10.1.2 255.255.255.0
    tunnel source Loopback0
    tunnel destination 195.77.XXX.70
    interface Ethernet0
    ip address 192.168.3.251 255.255.255.0
    ip nat inside
    ip virtual-reassembly
    hold-queue 100 out
    interface ATM0
    no ip address
    no ip route-cache cef
    no ip route-cache
    no atm ilmi-keepalive
    dsl operating-mode auto
    interface ATM0.1 point-to-point
    ip address 217.127.XXX.188 255.255.255.192
    ip nat outside
    ip virtual-reassembly
    no ip route-cache
    no snmp trap link-status
    pvc 8/32
    encapsulation aal5snap
    ip route 0.0.0.0 0.0.0.0 ATM0.1
    ip route 192.168.1.0 255.255.255.0 Tunnel0
    ip nat inside source route-map nonat interface ATM0.1 overload
    access-list 100 permit ip 192.168.3.0 0.0.0.255 192.168.1.0 0.0.0.255
    access-list 120 deny ip 192.168.3.0 0.0.0.255 192.168.1.0 0.0.0.255
    access-list 120 permit ip 192.168.3.0 0.0.0.255 any
    route-map nonat permit 10
    match ip address 120

    Hello, thank you for the answer, as to your question, I have no connectivity within the tunnel, whether from Router 1, I ping 10.10.1.2 not get response ...
    Now both routers remove the loopback, and the interface tunnel 0 change the tunnel source to "tunnel source " tunnel works perfectly, the problem is when I have to use the loopback. Unfortunately achieved when the tunnel work, this will have to endure multicast, and all the examples found carrying a loopback as' source '... but this is a step back ..
    Tunnel0 is up, line protocol is up
    Hardware is Tunnel
    Internet address is 10.10.1.1/24
    MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
    reliability 255/255, txload 1/255, rxload 1/255
    Encapsulation TUNNEL, loopback not set
    Keepalive not set
    Tunnel source 2.2.2.2 (Loopback0), destination 217.127.XXX.188
    Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
    Tunnel TTL 255
    Fast tunneling enabled
    Tunnel transmit bandwidth 8000 (kbps)
    Tunnel receive bandwidth 8000 (kbps)
    Last input 09:04:38, output 00:00:19, output hang never
    Last clearing of "show interface" counters never
    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    Queueing strategy: fifo
    Output queue: 0/0 (size/max)
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute output rate 0 bits/sec, 0 packets/sec
    0 packets input, 0 bytes, 0 no buffer
    Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    11101 packets output, 773420 bytes, 0 underruns
    0 output errors, 0 collisions, 0 interface resets
    0 unknown protocol drops
    0 output buffer failures, 0 output buffers swapped out

  • Tcp mss adjust calculation for GRE tunnel over DSL line

    hi guys,
    need your advice on this one, as i search on cisco.com and netpro but unable to find the exact info that i required.
    First, can anyone confirm the following calculation to find out MSS size.
    Mss size = MTU size - encapsulation size - tcp header size
    So for normal case;
    MSS = 1500 - 48 (48 is the tcp/ip header)
    so MSS = 1452
    Thus in my case GRE tunnel over DSL connection;
    MSS = 1492 - 24 - 48 (24 is the GRE encap; 48 is the tcp/ip header)
    MSS = 1420
    is this correct?
    Secondly, where should the ip tcp mss-adjust to be implemented. Is it at the Dialer(DSL) interface or at Tunnel interface?

    I don't use the math (it doesn't work for me probably b/c I miss something). Here's how I do it-
    C:\>ping 10.125.0.250 -f -l 1600
    Pinging 10.125.0.250 with 1600 bytes of data:
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.
    Ping statistics for 10.125.0.250:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
    C:\>ping 10.125.0.250 -f -l 1500
    Pinging 10.125.0.250 with 1500 bytes of data:
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.
    Ping statistics for 10.125.0.250:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
    C:\>ping 10.125.0.250 -f -l 1400
    Pinging 10.125.0.250 with 1400 bytes of data:
    Reply from 10.125.0.250: bytes=1400 time=19ms TTL=251
    Reply from 10.125.0.250: bytes=1400 time=19ms TTL=251
    Reply from 10.125.0.250: bytes=1400 time=19ms TTL=251
    Reply from 10.125.0.250: bytes=1400 time=19ms TTL=251
    Ping statistics for 10.125.0.250:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 19ms, Maximum = 19ms, Average = 19ms
    C:\>ping 10.125.0.250 -f -l 1450
    Pinging 10.125.0.250 with 1450 bytes of data:
    Reply from 10.125.0.250: bytes=1450 time=19ms TTL=251
    Reply from 10.125.0.250: bytes=1450 time=20ms TTL=251
    Reply from 10.125.0.250: bytes=1450 time=19ms TTL=251
    Reply from 10.125.0.250: bytes=1450 time=19ms TTL=251
    Ping statistics for 10.125.0.250:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 19ms, Maximum = 20ms, Average = 19ms
    C:\>ping 10.125.0.250 -f -l 1475
    Pinging 10.125.0.250 with 1475 bytes of data:
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.
    Ping statistics for 10.125.0.250:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
    C:\>ping 10.125.0.250 -f -l 1470
    Pinging 10.125.0.250 with 1470 bytes of data:
    Reply from 10.125.0.250: bytes=1470 time=19ms TTL=251
    Reply from 10.125.0.250: bytes=1470 time=22ms TTL=251
    Reply from 10.125.0.250: bytes=1470 time=20ms TTL=251
    Reply from 10.125.0.250: bytes=1470 time=19ms TTL=251
    Ping statistics for 10.125.0.250:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 19ms, Maximum = 22ms, Average = 20ms
    C:\>
    1470 works and has a little bit of extra room. The tcp mss-adjust should be done on the LAN interface.
    Hope it helps.

  • IPsec over GRE tunnel's line protocol is down but able to ping the tunnel destination

    >>both routers are located in different countries and connected with ISP
    >>IPsec over GRE tunnel is configured on both the routers 
    >>tunnel's line protocol is down for both the ends but able to reach the tunnel destination with tunnel source
    >>Packet is not receiving on the router_1 and but could see packets are getting encrypting on the Router_2
    >>ISP is not finding any issue with their end 
    >>Please guide me how i can fix this issue and what need to be check on this ????
    ========================
    Router_1#sh run int Tunnel20
    Building configuration...
    Current configuration : 272 bytes
    interface Tunnel20
     bandwidth 2048
     ip address 3.85.129.141 255.255.255.252
     ip mtu 1412
     ip flow ingress
     delay 1
     cdp enable
     tunnel source GigabitEthernet0/0/3
     tunnel destination 109.224.62.26
    end
    ===================
    Router_1#sh int Tunnel20
    Tunnel20 is up, line protocol is up>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Keepalive is not set
      Hardware is Tunnel
      Description: *To CRPrgEIQbaghd01 - 2Mb GRE over Shared ISP Gateway*
      Internet address is 3.85.129.141/30
      MTU 17916 bytes, BW 2048 Kbit/sec, DLY 10 usec,
         reliability 255/255, txload 1/255, rxload 1/255
      Encapsulation TUNNEL, loopback not set
      Keepalive not set
      Tunnel source 195.27.20.14 (GigabitEthernet0/0/3), destination 109.224.62.26
       Tunnel Subblocks:
          src-track:
             Tunnel20 source tracking subblock associated with GigabitEthernet0/0/3
              Set of tunnels with source GigabitEthernet0/0/3, 32 members (includes iterators), on interface <OK>
      Tunnel protocol/transport GRE/IP
        Key disabled, sequencing disabled
        Checksumming of packets disabled
      Tunnel TTL 255, Fast tunneling enabled
      Tunnel transport MTU 1476 bytes
      Tunnel transmit bandwidth 8000 (kbps)
      Tunnel receive bandwidth 8000 (kbps)
      Last input 1w6d, output 14w4d, output hang never
      Last clearing of "show interface" counters 2y5w
      Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
      Queueing strategy: fifo
      Output queue: 0/0 (size/max)
      5 minute input rate 0 bits/sec, 0 packets/sec
      5 minute output rate 0 bits/sec, 0 packets/sec
         1565172427 packets input, 363833090294 bytes, 0 no buffer
         Received 0 broadcasts (0 IP multicasts)
         0 runts, 0 giants, 0 throttles
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
         1778491917 packets output, 1555959948508 bytes, 0 underruns
         0 output errors, 0 collisions, 0 interface resets
         0 unknown protocol drops
         0 output buffer failures, 0 output buffers swapped out
    =============================
    Router_1#ping 109.224.62.26 re 100 sou 195.27.20.14
    Type escape sequence to abort.
    Sending 100, 100-byte ICMP Echos to 109.224.62.26, timeout is 2 seconds:
    Packet sent with a source address of 195.27.20.14
    Success rate is 92 percent (92/100), round-trip min/avg/max = 139/142/162 ms
    Router_1#
    ============================================
    Router_1#sh cry ip sa pe 109.224.62.26 | in caps
        #pkts encaps: 831987306, #pkts encrypt: 831987306, #pkts digest: 831987306
        #pkts decaps: 736012611, #pkts decrypt: 736012611, #pkts verify: 736012611
    Router_1#sh clock
    15:09:45.421 UTC Thu Dec 25 2014
    Router_1#
    ===================
    Router_1#sh cry ip sa pe 109.224.62.26 | in caps
        #pkts encaps: 831987339, #pkts encrypt: 831987339, #pkts digest: 831987339
        #pkts decaps: 736012611, #pkts decrypt: 736012611, #pkts verify: 736012611>>>>>>>>>>>>>>>>>>>>Traffic is not receiving from Router 2 
    Router_1#sh clock
    15:11:36.476 UTC Thu Dec 25 2014
    Router_1#
    ===================
    Router_2#sh run int Tu1
    Building configuration...
    Current configuration : 269 bytes
    interface Tunnel1
     bandwidth 2000
     ip address 3.85.129.142 255.255.255.252
     ip mtu 1412
     ip flow ingress
     load-interval 30
     keepalive 10 3
     cdp enable
     tunnel source GigabitEthernet0/0
     tunnel destination 195.27.20.14
    end
    Router_2#
    =======================
    Router_2#sh run | sec cry
    crypto isakmp policy 10
     authentication pre-share
    crypto isakmp key Router_2 address 195.27.20.14
    crypto isakmp key Router_2 address 194.9.241.8
    crypto ipsec transform-set ge3vpn esp-3des esp-sha-hmac
     mode transport
    crypto map <Deleted> 10 ipsec-isakmp
     set peer 195.27.20.14
     set transform-set ge3vpn
     match address Router_2
    crypto map <Deleted> 20 ipsec-isakmp
     set peer 194.9.241.8
     set transform-set ge3vpn
     match address Router_1
     crypto map <Deleted>
    Router_2#
    ====================================
    Router_2#sh cry ip sa pe 195.27.20.14 | in caps
        #pkts encaps: 737092521, #pkts encrypt: 737092521, #pkts digest: 737092521
        #pkts decaps: 828154572, #pkts decrypt: 828154572, #pkts verify: 828154572>>>>>>>>>>>>Traffic is getting encrypting from router 2 
    Router_2#sh clock
    .15:10:33.296 UTC Thu Dec 25 2014
    Router_2#
    ========================
    Router_2#sh int Tu1
    Tunnel1 is up, line protocol is down>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Down
      Hardware is Tunnel
      Internet address is 3.85.129.142/30
      MTU 17916 bytes, BW 2000 Kbit/sec, DLY 50000 usec,
         reliability 255/255, txload 1/255, rxload 1/255
      Encapsulation TUNNEL, loopback not set
      Keepalive set (10 sec), retries 3
      Tunnel source 109.224.62.26 (GigabitEthernet0/0), destination 195.27.20.14
       Tunnel Subblocks:
          src-track:
             Tunnel1 source tracking subblock associated with GigabitEthernet0/0
              Set of tunnels with source GigabitEthernet0/0, 2 members (includes iterators), on interface <OK>
      Tunnel protocol/transport GRE/IP
        Key disabled, sequencing disabled
        Checksumming of packets disabled
      Tunnel TTL 255, Fast tunneling enabled
      Tunnel transport MTU 1476 bytes
      Tunnel transmit bandwidth 8000 (kbps)
      Tunnel receive bandwidth 8000 (kbps)
      Last input 1w6d, output 00:00:02, output hang never
      Last clearing of "show interface" counters never
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 14843
      Queueing strategy: fifo
      Output queue: 0/0 (size/max)
      30 second input rate 0 bits/sec, 0 packets/sec
      30 second output rate 0 bits/sec, 0 packets/sec
         1881547260 packets input, 956465296 bytes, 0 no buffer
         Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
         1705198723 packets output, 2654132592 bytes, 0 underruns
         0 output errors, 0 collisions, 0 interface resets
         0 unknown protocol drops
         0 output buffer failures, 0 output buffers swapped out
    =============================
    Router_2#ping 195.27.20.14 re 100 sou 109.224.62.26
    Type escape sequence to abort.
    Sending 100, 100-byte ICMP Echos to 195.27.20.14, timeout is 2 seconds:
    Packet sent with a source address of 109.224.62.26
    Success rate is 94 percent (94/100), round-trip min/avg/max = 136/143/164 ms
    Router_2#
    =========================

    Hello.
    First of all, try to reset IPSec (clear crypto isakmp sa ..., clear crypto session ...).
    Configure inbound ACL on the router to match esp protocol and check if the packets arrive.
    Please provide full output "show crypto ipsec sa"
     from both sides.

  • MPLS over GRE Tunnel

    Hi,
    Can any one guide me about the benefits of MPLS over GRE Tunnels. Do this serve the purpose of MPLS (except TE, which is suppose is not possible on GRE Tunnels) as Layer-3 is already involved before Label Switching even starts.
    thanx and regards,
    Shakeel Ahmad

    I have a problem with MPLS over GRE. When i try to apply a policy to shape the traffic it seems that the default-class dosent see the mpls packets.
    Im trying to shape the traffic to 256k but it seems that the shaping never are activated.
    Anyone have any idea how to solve this?
    Example:
    class-map match-all PING
    match access-group 171
    policy-map class-default
    class PING
    bandwidth percent 15
    policy-map PING
    class class-default
    shape average 256000
    service-policy class-default
    INterfacexx
    service-policy output PING
    access-list 171 permit icmp any any

  • Use of command tunnel path-mtu-discovery

                       Hi Everyone,
    Need to know why we have to use the command tunnel path-mtu-discovery  if we have GRE tunnels at both ends?
    Also can the same command be used if we have GRE  over IPSEC VPN?
    Thanks
    MAhesh

    You can read the description here:
    http://www.cisco.com/en/US/docs/ios-xml/ios/interface/command/ir-t2.html#GUID-3B831D75-DAD0-472A-AC32-A6A066F71C33
    It forces unreachables to be sent should we exceed MTU, rather fragmentation to occur.
    And yes it applies to GRE over IPsec and is quite a good feature in most cases.

  • Windows Replication RPC Problems with IPSec GRE Tunnel

    We have been having significant issue in troubleshooting random RPC errors with our directory controllers (MS AD 2008R2) and our distributed file shares.  Both services will randomly stop working, throwing RPC errors as the resulting cause.  We have been all over both Cisco and Microsoft forums in trying to troubleshoot this problem.  I'm trying to the Cisco forums first to see if anyone has any network layer thoughts as to best practices or ways to configure the tunnel.
    Our network is simple: two small branch offices connected to each other with two Cisco 2901 ISRs.  An IPSec GRE tunnel exists between both offices.  Interoffice bandwidth is approximately 10mbps.  Pings between offices work, remote desktop works most of the time, file transfers work, and DNS lookups work across both locations.  We really don't have a complicated environment, I'd think it wouldn't be too hard to set up.  But this just seems to be escaping me.  I can't think of anything at the network layer that would be causing problems but I was curious whether anyone else out there with knowledge of small office VPNs might be able to render some thoughts on the matter.
    Please let me know if there is anything further people need to see.  My next step is MS forums but I wanted to eliminate layer 3 first.
    Tunnel Config:
    crypto map outside_crypto 10 ipsec-isakmp
    set peer x.x.x.x
    set transform-set ESP-AES-SHA
    match address 102
    crypto ipsec df-bit clear
    interface Tunnel0
    bandwidth 10240
    ip address x.x.x.x x.x.x.x
    no ip redirects
    ip mtu 1420
    ip virtual-reassembly in
    zone-member security in-zone
    ip tcp adjust-mss 1375
    tunnel source GigabitEthernet0/0
    tunnel destination x.x.x.x
    crypto ipsec df-bit clear
    end

    Hi,
    Based on the third-party article below, you can setup VPN connection between Windows VPN client and Cisco firewall:
    Step By Step Guide To Setup Windows 7/Vista VPN Client to Remote Access Cisco ASA5500 Firewall
    What is the Windows server 2008 R2 for, a RADIUS server? If yes, maybe the links below would be helpful to you:
    RADIUS: Configuring Client VPN with Windows 2008 Network Policy Server (NPS) RADIUS Authentication
    Configuring RADIUS Server on Windows 2008 R2 for Cisco Device Logins
    RADIUS authentication for Cisco switches using w2k8R2 NPS
    Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.
    Best regards,
    Susie

  • URGENT - tag-switching over gre-tunnel - how ??

    hi,
    my problem is that i want to connect two pe-router
    over a gre-tunnel.
    this is because between the two pe´s i unfortunatly have two cisco828 router as modemrouter inbetween which do no tag-switching.
    so i decided to use a gre tunnel between the two pe´s to do tag-switching.
    but if i want to forward packets greater than 1492 bytes and the df-bit is set - no chance.
    here is the figure and config of the two tunnels:
    c3640 - c828 -LINE- c828 - c3640
    <==========TUNNEL===============>
    first c3640:
    interface Tunnel65052
    description PE-PE Verbdg. Hoersching-Pasching
    ip unnumbered Loopback0
    ip mtu 1512
    load-interval 30
    tag-switching mtu 1512
    tag-switching ip
    keepalive 10 3
    tunnel source 10.20.192.3
    tunnel destination 10.20.192.6
    second c3640:
    interface Tunnel65052
    description PE-PE Verbdg. Hoersching-Pasching
    ip unnumbered Loopback0
    ip mtu 1512
    load-interval 30
    tag-switching mtu 1512
    tag-switching ip
    keepalive 10 3
    tunnel source 10.20.192.6
    tunnel destination 10.20.192.3
    on the 828 router i did no adjustment of mtu !
    if i do a ping:
    r-enns1#pi vrf lkg 172.16.169.121 size 1492 df
    Type escape sequence to abort.
    Sending 5, 1492-byte ICMP Echos to 172.16.169.121, timeout is 2 seconds:
    Packet sent with the DF bit set
    Success rate is 100 percent (5/5), round-trip min/avg/max = 208/211/212 ms
    r-enns1#
    r-enns1#
    r-enns1#
    r-enns1#
    r-enns1#pi vrf lkg 172.16.169.121 size 1493 df
    Type escape sequence to abort.
    Sending 5, 1493-byte ICMP Echos to 172.16.169.121, timeout is 2 seconds:
    Packet sent with the DF bit set
    M.M.M
    Success rate is 0 percent (0/5)
    r-enns1#
    please help - thanks

    Here's at least two options you could try:
    1) Lower the MTU on the tunnel-interface and let PMTU on the endpoints take care of the fragmentation. This could have some serious implications all depending on the systems and applications/protocols used on the network, but in most cases it'll work just fine.
    2) Simply remove the DF-bit on incoming packets to the router and lower the MTU on the tunnel-interface and let the router do fragmentation regardless of what the endpoints says. Since you have a 3640 on each end and 828's in the middle, I think it should be capable of this..
    You should do a MSS-modification as well in both cases.
    Change the MTU like this:
    interface Tunnel65052
    ip mtu 1488
    tag-switching mtu 1500
    Then you have set all IP-packets to maximum 1488 bytes (including headers) and let there be room for 3 MPLS labels...
    At least I think it should behave like this... please don't kill me if i'm wrong.. :)
    Remove the DF-bit with route-map's on the inside interfaces:
    interface FastEthernet1/0.100
    description inside interface
    ip policy route-map clear-df
    ip tcp adjust-mss 1424
    route-map clear-df permit 10
    set ip df 0

  • When do i have to use a gre over ipsec tunnel? i have heard that when i m using a routing protocol and vpn site to site i need a gre tunnel

    i have configured a network with ospf and a vpn site to site without gre tunnel and it works very well. I want to know, when do i have to use gre tunnel over ipsec

    Jose,
    It sounds like you currently have an IPsec Virtual Tunnel Interface (VTI) configured. By this, I mean that you have a Tunnel interface running in "tunnel mode ipsec ipv4" rather than having a crypto map applied to a physical interface. In the days before VTIs, it was necessary to configure GRE over IPsec in order to pass certain types of traffic across an encrypted channel. When using pure IPsec with crypto maps, you cannot pass multicast traffic without implementing GRE over IPsec. Today, IPsec VTIs and GRE over IPsec accomplish what is effectively the same thing with a few exceptions. For example, by using GRE over IPsec, you can configure multiple tunnels between two peers by means of tunnels keys, pass many more types of traffic rather than IP unicast and multicast (such as NHRP as utilized by DMVPN), and you can also configure multipoint GRE tunnels whereas VTIs are point to point.
    Here's a document which discusses VTIs in more depth: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnips/configuration/xe-3s/sec-sec-for-vpns-w-ipsec-xe-3s-book/sec-ipsec-virt-tunnl.html#GUID-A568DA9D-56CF-47C4-A866-B605804179E1
    HTH,
    Frank

  • GRE Tunnel and static PAT

    Hi to all,
    I would like to know if it is possible to create a static Port Address Translation (PAT) that would translate a routable IP address to a private address where  a GRE tunnel would end.
    In other words, I am trying to see if we can use a static PAT for a GRE tunnel like the one that we can used to reach a HTTP server using a private IP address via static PAT to a routable IP address.
    Just trying to see if it is possible to initiate a GRE tunnel from 192.168.1.1 (R1) and used 1.1.1.1 (R2), IP address reachable via internet, as destination address, in the case where we would do a PAT translation on R2 in order to actually terminate the tunnel on R3 router. The static PAT on R2 would translate 1.1.1.1 to 172.16.1.2.
    I am basically looking for an equivalent to the following static PAT but for GRE tunnel
              ip nat inside source static tcp 10.10.10.5 80 192.168.2.1 80
    Thanks for your help
    Stephane

    Hello Stephane,
    GRE is neither TCP nor UDP, GRE has its own protocol number 47. You can allow the traffic by either by calling GRE instead of TCP or UDP or by just putting a normal IP static NAT entry.
    Extended IP access list GRE
        10 permit tcp any any eq 47 log <--- No Hits
        15 permit tcp any any log          <--- No Hits
        20 permit udp any any eq 47 log <--- No Hits
        25 permit udp any any log          <--- No Hits
        30 permit gre any any log (20 matches)
        40 permit ip any any (43 matches)
    *Mar  1 00:27:48.435: IP: tableid=0, s=10.10.10.2 (local), d=10.10.10.1 (Tunnel1), routed via FIB
    *Mar  1 00:27:48.435: IP: s=10.10.10.2 (local), d=10.10.10.1 (Tunnel1), len 100, sending
    *Mar  1 00:27:48.435:     ICMP type=0, code=0
    *Mar  1 00:27:48.435: IP: s=192.168.9.5 (Tunnel1), d=192.168.8.2 (FastEthernet0/0), len 124, sending, proto=47
    I hope it helps great for you. Please rate if you fell this is helpfull.
    Thanks,
    Kasi

Maybe you are looking for

  • In ME21N,User Exit/BADI for  Defaulting  Vendor number at item level.

    Hi Experts. In ME21N, for every purchase order, we have condtion tab for each line item. Many condition typesot taxes  are listed based on the config for the materials. My requirements is, When we go inside by selecting a condition type we find vendo

  • What is SPRY??

    I am redesigning a website and want to make it primarily XML driven as the content is updated quite a lot. This is my first project since upgrading to CS3 and have just come accross SPRY but have no idea what it is. Everything ive found about it on t

  • Need help with pc sync - 6220, outlook and vista

    everything seems to be working right, it says its syncing, my phone tells me the sync happened yet none of my contacts, bookmarks, mails or calendar entries transfer either onto my pc (outlook 2007) or transfer onto my phone. anyone know if im missin

  • Fuzzy output when I convert mp3 to aac (to make audiobook)

    That's pretty much it. I have imported CDs of audio books that I want to put on my iphone. I am converting the mp3s to AAC - then changing the extension from mp4a to mp4b so that it is filed in the audio book section. But during the conversion the qu

  • Profile for Canon G10 to simulate Olympus E-3 colors

    I want to create a profile for Canon G10 which will simulate Olympus E-3 colors. I performed the following steps, but the result is very disappointing: 1. Photographed a GretacgMacbeth ColorChecker with a G10 and a E-3, in the same light conditions (