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
/BentYes, 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 -
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 workA "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,
GurjinderIf 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 - thanksHere'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 -
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 AhmadI 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
StuartIt'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. -
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. LeoHello
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 -
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
-
I'm getting "Installer disk not found" message during boot camp 5 and windows 8 install on late 2001 MBP running Mavericks. Any ideas? I've downloaded the Window support option software and the WindowSetupBox.exe and copied it to the USB drive. Thank
-
For selection parameter the default date should be of the previous month.
Hi all, In my selection-screen what i want is for the selection parameter "Selection period month" the default value to be the previous month. For example today is 24.09.2008 so the default value of this field has to be 200808 instead of 200809 toda
-
How to get Custom Time Correction business logic implement for ESS in R/3?
Hi Experts, I am in trouble of implementing the custom requirement of correcting the time in ESS. I have to implement the time corrections as per business logic. Can any body tell me where to do this? What I need is suppose employee DWS is from 9:30
-
Non admins trying to reinstall printer drivers
We are having an issue that started last night (after updates/maybe coincidental) That our users(Non-admins) are having to reinstall the printer driver for the policy pushed printers. And unfortunately its prompting them for Admin creds. All the pri
-
SimpleText files to jpegs? How?
I have a bunch of Simple Text files (saved to my G4, running 9.2.2) that I want to convert to something I can view on a PC -- jpegs or whatever. Any advice?