How is a GRE tunnel applied to a physical interface?

Within a tunnel's configuration we use the commands, source and destination for the tunnel but how does the physical interface know to use the tunnel? Do the tunnel's source settings override the physical interface? If we only configure a tunnel with the correct source would that interface then send all information out encapsulated in GRE?
If we also configure IPSec on the interface and specify a crypto map to only encrypt the matching traffic would this matching traffic only use the GREtunnel or is all information regardless if it's encrypted in IPSec also be encapsulated in GRE?
Also, I read here: https://supportforums.cisco.com/docs/DOC-3067
"Bind crypto map to the physical (outside) interface if you are running Cisco IOS  Software Release 12.2.15 or later. If not, then the crypto map must be applied to the tunnel interface as well as the physical interace."
Why was it necessary to apply the crypto map to both the physical and tunnel interfaces, and why is it not necessary with newer IOS versions?
Thanks for any help!  -mark

Mark Mattix wrote:I did some reading on EIGRP and is it correct that the EIGRP Header and Payload (TLV) are encapsulated in an IP packet and addressed to the address, 224.0.0.10? Is this the reason why multicast traffic must be encapsulated first in GRE to travel over the internet? Olivier Pelerin> This is correct
When I set up a site to site VPN using GRE tunnels and an IPSec config on the interfaces would this be considered, IPSec over GRE, or GRE over IPSec? I don't understand that difference.
Olivier Pelerin> See the diagram below - this explain GRE over IPSEC. That's a diagram I did here for a training
On the example packet I posted above, is the public address that's routed over the internet part of the IPSec packet/suite? I guess a better question is, what portions of the packet make up IPSec and which portion is just regular IPv4 addressing?
Olivier Pelerin> the diagram below should answer that
I've been wrong in thinking that GRE and IPSec go hand in hand when infact it's possible to only use IPSec and no type of tunnel. If IPSec is set up on the interfaces and the tunnels are configured at both end points, what does your information first get encapsulated by, GRE or IPSec? In your example packet format Olpeleri, is looks like the IP packet is first encapsulated in GRE then encapsulated by IPSec. Is this correct? If so when information leaves our LAN and heads to the internet, does it first go through the tunnel to be encapsulated by GRE then out the physical link that adds the IPSec encapsulation?
Olivier Pelerin> Correct. GRE first then encryption
Sorry for all these questions, I'm just trying to learn how this works! Thanks again for the help!
[red = encrypted]

Similar Messages

  • How to setup GRE tunnel on a 3005

    Does the vpn3005 support GRE tunnels and how do I configure it? Reference paper will be fine.
    Thanks
    /Bent

    Yes, VPN 3005 concentrator should support GRE tunnels. Here are some configuration examples for the same.
    Configuring a GRE Tunnel over IPSec with OSPF
    http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800a43f6.shtml.
    For more such examples please refer to:
    http://www.cisco.com/en/US/tech/tk583/tk372/tech_configuration_examples_list.html

  • 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 through asa no pptp, l2tp, ipsec

    Hello!
    can't understand how to configure GRE tunnel through ASA
    i have one router with public ip, connected to internet
    ASA 8.4 with public ip connected to internet
    router with private ip behind ASA.
    have only one public ip on ASA with /30 mask
    have no crypto
    have network behind ASA and PAT for internet users.
    can't nat GRE? cause only TCP/UDP nated(?)
    with packet-tracer i see flow already created but tunnel doesn't work

    A "clean" way would be to use a protocol that can be PATted. That could be GRE over IPSec. With that you have the additional benefit that your communication is protected through the internet.
    Don't stop after you've improved your network! Improve the world by lending money to the working poor:
    http://www.kiva.org/invitedby/karsteni

  • 2911 router - Netflow V5 through GRE Tunnels

    Hi All,
    Does the 2911 router support the ability for Netflow V5 to pass through GRE tunnels? I can't seem to find any documentation that indicates this.
    Thanks,
    Gurjinder

    If you are going to use a GRE tunnel as the flow export interface from the router exporting NetFlow, it will not work. Cisco bug IDs for this issue are CSCsk25481 and CSCef28662 and is applicable to both traditional and flexible NetFlow.
    To allow NetFlow export from a device through an encrypted tunnel on the same device, enable Flexible NetFlow and use the command output-features when configuring your flow exporter. That will allow NetFlow export over encrypted tunnels.
    Regards,
    Don Thomas Jacob
    http://www.solarwinds.com/netflow-traffic-analyzer.aspx
    NOTE: Please rate posts and close questions if you have found the answers helpful.

  • How many numbers of GRE Tunnels are supported on Cisco 3925 router?

    Hi...
    I would like to know that.......
    How many numbers of GRE Tunnels are supported on Cisco 3925 router?
    Thanks....

    This is what I found in my search:
    There may be factors such as memory constraints that will place practical limits on how many tunnels you can support. But there is also a hard limit on the number of tunnels that you can configure. That limit is based on the limitation of the number of IDBs supported by your router. The IDB is the Interface Descriptor Block and each interface (physical, or tunnel, or loopback, or whatever) requires an IDB. The number of IDBs will vary by platform and sometimes by release level of the code that you are running. You can use the privileged command show idb to see what the limitation is on your router. On the 1841 router that I just checked the limit on IDB is 1200 (which is a pretty large number - I believe that you would encounter other limits on performance or on size of configuration before you exhaust the IDB limit).
    https://supportforums.cisco.com/thread/2007932
    Hope it helps.
    Jatin Katyal
    - Do rate helpful posts -

  • 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

  • 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

  • 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

  • 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?

  • 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.

  • Interface Bridging Into GRE Tunnel

    Hello all, I was wondering if it is still possible as I know it was never supported to bridge a layer 2 interface directly into a GRE tunnel. I have a customer that currently has a dedicated L2 circuit and a new L3 connection, he wants to move his L2 device to his L3 link to save money on circuits. The issue that I have is he does not want to change his IP addresses and the layer 2 network terminates in another location 20 miles away. The layer 3 routed network is also between both buildings and I can create a GRE tunnel between the 2 locations without touching the Internet. I have tried this using a 2921 router runnning IOS 15.4(2)T1 but the bridge-group command is not available on the GRE tunnel interface.
    I have also looked at pseudowire and cannot find the commands related to this, do I need to upgrade my license to security?
    Cheers
    Stuart

    It's a hidden command.  Even do, you might get a warning messasge stating this is obsolete and unsupported, it still technically a valid configuration. Legacy, but works.
    Keep in mind there are better solutions for this kind of connections.  But you can try it, it's simple anyways.
    Host1---Fa0/0--R1-------------GRE------------R2--Fa0/0---Host2
    1. Create a Loopback intf. on both routers and ensure L3 connectivity between them.
    2. Create bridge:
    router(config)#bridge 1 protocol ieee
    3. Create a GRE tunnel interface (dont configure IP's):
    router(config)# interface tun0
    router(config-if)# tun source loopback x
    router(config-if)# tun destination <other router loopback ip>
    router(config-if)# bridge-group 1
    **This is a hidden cmd. You will get a warning message, but ignore it**
    3. Attach Physical Interface to Bridge as well:
    router(config)# interface Fa0/0
    router(config-if)# bridge-group 1
    4. Configure the Hosts IP addresses to be on the same IP Segment and validate communication between them.
    You can try this on GNS3 as well.  I made a diagram and a brief explanation at another thread, but really don't remember how to get to it.
    Once again, this is legacy and there are better ways to achieve this. But for small implementations this is valid and easier.  It also helps to understand the newer versions/enhancements to this as well. 
    HTH

  • 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.

  • GRE Tunnel QoS

    Hi
    I am looking for adding QoS for GRE Tunnel and found this info
    Where Do I Apply the Service Policy?
    You can apply a service policy to either the tunnel interface or to the underlying physical interface. The decision of where to apply the policy depends on the QoS objectives. It also depends on which header you need to use for classification.
    Apply the policy to a physical interface and enable qos-preclassify on a tunnel interface when you want to classify packets based on the pre-tunnel header.
    In our environment, I am using service policy under serial interface, the source interface of Tunnel is F0/0, so from above info, which interface is "physical interface" for my case, serial or F0/0 ?
    Thanks. Leo

    Hello
    You should determine which one is the physical interface by checking which interface (again, physical) will be used to router GRE packets towards the destination.
    For instance, you state that your tunnel configuration is as follows:
    interface Tunnel0
    ip address 10.0.0.1 255.255.255.252
    tunnel source FastEthernet0/0
    tunnel destination 192.168.1.1
    If the destination ip 192.168.1.1 is routed via your serial interface, then the physical interface that you will use to apply your Output service policy is SerialX/X.
    Your setup seems correct. You only need to review if your policies are correctly configured for the pre-gre header or the GRE encapsulated packets (as stated in the documentation
    Adolfo

  • Redirection on GRE tunnels

    I have implemented WCCP redirect on a serial interface I have. I also have a GRE tunnel interface sourced from that same serial interface.I would like to know the IOS order of operation for that GRE tunnel interface in regards to redirection. Do I have to specifically configure the "ip wccp redirect" command on the tunnel interafce or the command on the underlying serial interface would suffice?

    Hello Shiravani,
    You need to configure the "ip wccp redirect " on the GRE tunnel interface itself and not the serial interface ( if you want to redirect traffic coming out from the GRE tunnel ).
    The IOS order does not really apply on this case,the GRE tunnel is just like any other interface.( GRE/ipsec packets are handled by physical (WAN) interface.)
    I  also suggest to do a lab if any doubts or further questions before you making the changes.
    Hope this helps!
    Felix

Maybe you are looking for