Tunnel interface to physical interface

Hi All,
I was wondering if it is possible to build a site to site vpn connection one side using tunnel interface and the other end using a physical interface.
My plan is to use a 3945 router, build multiple tunnel interfaces on the router to connect 50 clients. By using tunnel interface on the router i could leverage on the vrf feature to isolate clients but if i use tunnel interface on my end i am not certain if the tunnel will come up if my client is using 1) ASA 2) PIX 3) vpn concentrator - which doesnt support tunnel interface.
Thanks for your help in advance.
Lou

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

The difference between IEEE802.1Q Native VLAN sub-interface and Physical interface?

Hello
I think the following topologies are supported for Cisco Routers
And the Physical interface also can be using as Native VLAN interface right?
Topology 1.
R1 Gi0.1 ------ IEEE802.1Q Tunneling L2SW ------ Gi0 R2
R1 - configuration
interface GigabitEthernet0.1
encapsulation dot1Q 1 native
ip address 10.0.0.1 255.255.255.0
Topology 2.
R1 Gi0 ------ IEEE802.1Q Tunneling L2SW ------ Gi0 R2
interface GigabitEthernet0
ip address 10.0.0.1 255.255.255.0
And is it ok to use the physical interface and sub-interface with dynamic routing such as EIGRP or OSPF etc?
R1 Gi 0 ---- Point to Multipoint EIGRP or OSPF ---- Gi0 R2 / R3
Gi 0.20--- Point to Point EIGRP or OSPF --- Gi0.10 R4 (same VLAN-ID)
R1 - configuration
interface GigabitEthernet0
ip address 10.0.0.1 255.255.255.0
interface GigabitEthernet8.20
encapsulation dot1Q 20
ip address 20.0.0.1 255.255.255.0
Any information is very appreciated. but if there is any CCO document please let me know.
Thank you very much and regards,
Masanobu Hiyoshi

Hello,
The diagram is helpful.
If I am getting you correctly, you have three routers interconnected by a switch, and you want them to operate in a hub-and-spoke fashion even though the switch is capable of allowing direct communication between any of these routers.
Your first scenario is concerned with all three routers being in the same VLAN, and by using neighbor commands, you force these routers to establish targeted EIGRP adjacencies R1-R2 and R1-R3, with R1 being the hub.
Your second scenario is concerned with creating one VLAN per spoke, having subinterfaces for each spoke VLAN created on R1 as the router, and putting each spoke just in its own VLAN.
Your scenarios are not really concerned with the concept of native VLAN or the way it is configured, to be honest. Whether you use a native VLAN in either of your scenarios, or whether you configure the native VLAN on a subinterface or on the physical interface makes no difference. There is simply no difference to using or not using a native VLAN in any of your scenarios, and there is no difference to the native VLAN configuration being placed on a physical interface or a subinterface. It's as plain as that. Both your scenarios will work.
My personal opinion, though, is that forcing routers on a broadcast multi-access segment such as Ethernet to operate in a hub-and-spoke fashion is somewhat artificial. Why would you want to do this? Both scenarios have drawbacks: in the first scenario, you need to add a neighbor statement for each spoke to the hub, limiting the scalability. In the second scenario, you waste VLANs and IP subnets if there are many spokes. The primary question is, though: why would you want an Ethernet segment to operate as a hub-and-spoke network? Sure, these things are done but they are motivated by specific needs so I would like to know if you have any.
Even if you needed your network to operate in a hub-and-spoke mode, there are more efficient means of achieving that: Cisco switches support so-called protected ports that are prevented from talking to each other. By configuring the switch ports to spokes as protected, you will prevent the spokes from seeing each other. You would not need, then, to configure static neighbors in EIGRP, or to waste VLANs for individual spokes. What you would need to do would be deactivating the split horizon on R1's interface, and using the ip next-hop-self eigrp command on R1 to tweak the next hop information to point to R1 so that the spokes do not attempt to route packets to each other directly but rather route them over R1.
I do not believe I have seen any special CCO documents regarding the use of physical interfaces or subinterfaces for native VLAN or for your scenarios.
Best regards,
Peter

DMVPN using loopback interface vs. physical interface

In a DMVPN,what´s the difference between using a loopback interface as a tunnel source instead of a physical interface?

It will work for a static one to one nat. PAT doesnt play well with GRE because ports dont exist in GRE (not sure if NAT traversal can help here like it does with ISAKMP - it works on spokes) You also need to make sure that the loopback is set to work with the crypto profile. Joe is right, the address it terminates on is best to be Public address space that you own, that is multihomed - if this is a hub.

Virtual interface or physical interface

Hi All,
Need your help select IPSce config in following environment
We are working in Joint venture. Two different companies are working under one banner. But one company's computers requires services from other company's server.
We are thinking to make site to site connection along with IPSec. Both sites have static public IP's.
Configuring Virtual Tunnel interface OR
Configuring Physical Interface OR
GRE Point to Point

Hi Omer,
I would prefer VTI on GRE over IPSec . Although IPsec provides a secure method for tunneling data across an IP network, it has limitations. IPsec does not support IP broadcast or IP multicast, preventing the use of protocols that rely on these features, such as routing protocols. IPsec also does not support the use of multiprotocol traffic.
GRE is a protocol that can be used to “carry” other passenger protocols, such as IP broadcast or IP multicast, as well as non-IP protocols.
Vitual Tunnel Interfaces you can set them up with a profile that uses IPsec for transport and so the interface tu0 is treated like a usual IP interface that can also handle routing protocols.
However, different tunnel mode can apply different application. Here are some considerations for IPSec VTI. The IPsec VTI is limited to IP unicast and multicast traffic only, as opposed to GRE tunnels, which have a wider application for IPsec implementation. Thus, for some non-IP traffic, we still need IPSec over GRE.
Header related overhead is about same, However VTI is less CPU intensive. Well also matter what platfrom is part of solution.
Br.
Mohseen

Crypto Map on Loopback interface or Physical Interface

Dear All,
When we try to apply the crypto map on any physical interface or the loopback interface on WS-6506-E, it is showing the error. But the same i could apply on VLAN interface. Can anyone explain me what is the issue..?
6506(config)#interface loopback 3
6506(config-if)#crypto map XXXX
ERROR: Crypto Map configuration is not supported on the given interface
Any hardware limitation?

This was proven to break CEF in the past and is a bad design choice by default.
Newer release do not allow you to configure this.
If you're curious if it will work for you check releases prior to 15.x.
M.

Policy-map on tunnel or physical interface?

Hi all,
I have a 3800 headend router which has a number of ipsec tunnels to remote office sites. Our current QoS design applies a policy-map to each tunnel interface to prioritise and shape outbound traffic.
My question is how does the physical egress interface queue and transmit traffic from tunnel interfaces with this design? For example, if a mixture of large data packets and voice packets from different tunnel interfaces hit the physical interface around the same time what will happen to the voice packets?
Furthermore, would it be a better to apply the policy-map to the physical interface instead of the tunnel interfaces? What advantages if any would this bring?
Many thanks.

If you're shaping each tunnel to the outbound physical bandwidth, yes it would be better to just have the policy, without any shaping, on the physical interface. Again, you'll will either need to depend on a copied ToS value in the outbound packet or use qos pre-classify. (A single physical policy would be much like your QUEUE_DATA if using qos pre-classify.)
e.g.
!assumes qos-preclassify
interface Ethernet0
service-policy output QUEUE_DATA
What I thought you might be doing, and you could also do, was shape each tunnel to the far side's ingress bandwidth. This would require a distinct policy, if the shaper values change, for every tunnel interface, or a policy on the physical interface that has a class per tunnel (matches against tunnel destination address).
e.g.
!assume local outbound interface not oversubscribed
policy-map NESTED_QOS_512K
class class-default
shape average 512000
service-policy QUEUE_DATA
policy-map NESTED_QOS_768K
class class-default
shape average 768000
service-policy QUEUE_DATA
policy-map NESTED_QOS_1500K
class class-default
shape average 1500000
service-policy QUEUE_DATA
interface Tunnel1
service-policy output NESTED_QOS_786K
interface Tunnel2
service-policy output NESTED_QOS_512K
interface Tunnel3
service-policy output NESTED_QOS_1500K
interface Tunnel4
service-policy output NESTED_QOS_512K
e.g.
!assume local outbound interface not oversubscribed
class-map match-all Tunnel1
match group (ACL that matches tunnel1 destination address)
class-map match-all Tunnel2
match group (ACL that matches tunnel2 destination address)
policy-map outbound_tunnels
class Tunnel1
shape average 768000
service-policy output QUEUE_DATA
class Tunnel2
shape average 512000
service-policy output QUEUE_DATA
Interface Ethernet 0
service-policy outbound outbound_tunnels
If all the far side bandwidths exceed your local outbound physical bandwidth, then you should have both tunnel policies, that shape each tunnel, and a physical interface policy.
e.g.
!assume local outbound interface is oversubscribed
policy-map NESTED_QOS_512K
class class-default
shape average 512000
service-policy QUEUE_DATA
policy-map NESTED_QOS_768K
class class-default
shape average 768000
service-policy QUEUE_DATA
policy-map NESTED_QOS_1500K
class class-default
shape average 1500000
service-policy QUEUE_DATA
interface Tunnel1
service-policy output NESTED_QOS_786K
interface Tunnel2
service-policy output NESTED_QOS_512K
interface Tunnel3
service-policy output NESTED_QOS_1500K
interface Tunnel4
service-policy output NESTED_QOS_512K
!assumes qos-preclassify
interface Ethernet0
service-policy output QUEUE_DATA

Dialler interface and Isdn interface

Can someone tell me the difference
When bringing up an isdn interface, Am I correct in saying it has to raise the line by calling the isdn number, If so whats the difference between this and a dialler interface ?
thanks
Carl

Hi Carl,
A dialer interface is a parent interface that holds central protocol characteristics for ISDN D channels, which are part of specified dialer rotary groups. Data packets are delivered to dialer interfaces, which in turn initiate dialing for inbound calls. In most cases, D channels get their core protocol intelligence from dialer interfaces.
A dialer interface is user configurable and linked to individual B channels (such as S0:0, S0:1, S0:2), where it delivers data packets to their physical destinations. Dialer interfaces seize physical interfaces to cause packet delivery.
ISDN BRI delivers a total bandwidth of a 144-kbps via three separate channels. Two of the channels, called B (Bearer) channels, operate at 64 kbps and are used to carry voice, video, or data traffic. The third channel, the D (Data) channel, is a 16-kbps signaling channel used to carry instructions which tells the telephone network how to handle each of the B channels. ISDN BRI is often referred to as "2 B+D."
A D channel notifies the central office switch to send the incoming call to particular timeslots on the router. Each one of the bearer or B channels carries data or voice. The D channel carries signaling for the B channels. The D channel also identifies if the call is a digital call or analog call. Analog calls are decoded and then get sent off to the modems. Digital calls are directly relayed off to the ISDN processor in the router.
HTH,
-amit singh

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]

Bandwith monitoring on physical interface or on tunnel interface ?

Hi All,
I would like to ask you a question .i am using solarwind monitoring tool for bandwith monioring.
I would like to know which interface we should use for monitoring ? Physical interface or tunnel interface .
I am using GRE tunnel in each of my remote locations.
and in some locations when i compare my physical interface graph and tunnel interface graph ,there is always hugh difference ,tunnel interface always has high utilization. but for some sides physical interface and tunnel interface graph are same .
please do let me know which is the best for monitoing .

Hi ,
Genrally it can be posible due bandwidth configuration on tunnel interface but ther is no harm in monitoring both the interface,it is genarlly a benfit only for you as if tunnel goes down it will raise an alarm also for the same.
For exact monitoring for tunnel interface i would suggest you to check - VPNTTG (VPN Tunnel Traffic Grapher).
Advantage of VPNTTG over other SNMP based monitoring softwares is following: Other (commonly used) softwares are working with static OID numbers, i.e. whenever tunnel disconnects and reconnects, it gets assigned a new OID number. This means that the historical data, gathered on the connection, is lost each time. However, VPNTTG works with VPN peers IP address and it stores for each VPN tunnel historical monitoring data into the Database.
Hope that helps out your query !!
If helpful do rate the valauble post.
Regards
Ganesh.H

Physical interface Default Gateway connecting VPN with AnyConnect

When I connect vpn with AnyConnect, I can't see default gateway on Physical Interface.
before connect vpn
==========================================
C:\WINDOWS\system32>ipconfig
Windows IP Configuration
Ethernet adapter Local Area
        Connection-specific DNS Suffix . :
        IP Address. . . . . . . . . . . . : 10.1.1.100
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 10.1.1.10
after connect vpn with anyconnect
==========================================
C:\WINDOWS\system32>
C:\WINDOWS\system32>ipconfig
Windows IP Configuration
Ethernet adapter Local Area
        Connection-specific DNS Suffix . :
        IP Address. . . . . . . . . . . . : 10.1.1.100
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . :'Can't see default gateway'
Is this the specification of Anyconnect?

Nyanko,
This will happen when you are using tunnel all as the split tunneling policy, the computer will encrypt all the traffic so the default gateway will be removed from the physical connection and placed into the virtual adapter. If you take a look at the routing table you will see that what really happens is that the original default route's metric will be changed so that it is higher than the one injected by the virtual adapter, once you disconnect it should go back to normal.
Further information on split tunneling:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080975e83.shtml
HTH
Jonnathan

DMVPN & GRE over IPsec on the same physical interface

Dear All,
I'm configuring two WAN routers, each wan router has one physical interface connecting to branches and regional office using same provider.
We'll be using GRE over IPsec to connect to regional office and DMVPN + EIGRP to branches.
I would like to know if it's possible to configure tunnels for GRE over IPsec and DMVPN + EIGRP using the same source physical interface.
Kindly reply, it's an urgent request and your response is highly appreciated.
Regards,

Hi Savio,
It should work. we can configure dmvpn and gre-over-ipsec on ASA using same physical interface.
Regards,
Naresh

Multiple Public IP's on one physical interface for devices behind Router.

Hi guys, I am trying to find information on applying multiple IP addresses to a router
basically one for the Router itself and then some for the devices behind the router, Which i am sure I need to apply some 1 to 1 NATs. I just do not know if i need to specify all the IP addresses on the main interface.
Example being I have a router with WAN ip of xxx.xxx.xxx.xxx/25 , it only has 2 interface one for WAN one for LAN, i have a server I would like assigned its own public IP address. but still on the same LAN network.
Could someone help me out and point me in the right direction with a sample config

I agree with the previous response that you need a static NAT to allow outside resources to initiate traffic to your server. You also will need NAT or PAT using the router interface address to allow the other hosts in your network to access outside.
You do not need to configure any other of the addresses on the router interface other than the primary IP that you assign to the router interface. As long as the other addresses are used for NAT/PAT they are configured in the nat statements and not on the physical interface.
HTH
Rick

How to make ASR9000 bridge domain forward traffic between sub interfaces of same physical interface?

Hi,
I regularly use bridge domains to connect sub interfaces on different vlans using this sort of configuration:
interface GigabitEthernet0/0/0/5.21 l2transport
description CUSTOMER A WAN
encapsulation dot1q 21
rewrite ingress tag pop 1 symmetric
interface GigabitEthernet0/0/0/10.3122 l2transport
description CUSTOMER A CORE
encapsulation dot1q 3122
rewrite ingress tag pop 1 symmetric
l2vpn
bridge group WANLINKS
bridge-domain CUSTOMERA
   interface GigabitEthernet0/0/0/5.21
   interface GigabitEthernet0/0/0/10.3122
When I try to use the same method to bridge two sub interfaces on the same physical interface so as to create a L2 VPN no data flows:
interface GigabitEthernet0/0/0/5.21 l2transport
description CUSTOMER A WAN
encapsulation dot1q 21
rewrite ingress tag pop 1 symmetric
interface GigabitEthernet0/0/0/5.22 l2transport
description CUSTOMER A WAN2
encapsulation dot1q 22
rewrite ingress tag pop 1 symmetric
l2vpn
bridge group WANLINKS
bridge-domain CUSTOMERA
   interface GigabitEthernet0/0/0/5.21
   interface GigabitEthernet0/0/0/5.22
If I add a BVI interface to the bridge domain then the CE devices at the remote end of the WAN interface can both ping the BVI IP but they remain unable to ping each other.
Is this because tag rewrites are not happening since packets don't leave the physical interface?
How can I work around this and establish a L2 connection between the two subinterfaces?
Thank you

a vlan is usually the equivalent of an l3 subnet, so linking 2 vlans together in the same bridge domain, likely needs to come with some sort of routing (eg a BVI interface).
If these 2 vlans are still in the same subnet, then there is still arp going on, from one host to the other that traverses the bD.
you will need to verify the state of the AC, the forwarding in the BD and see if something gets dropped somewhere and follow the generic packet troubleshooting guides (see support forums for that also).
that might give a hint to what the precise issue in your forwarding is.
regards
xander

How to Add a Physical Interface After Installation in Solaris 10

How to Add a Physical Interface After Installation in Solaris 10
Hi Java Specialist,
I am trying to setup a network interface with the following steps on a new fresh Solaris 10 installation using the instruction titled How to Add a Physical Interface After Installation in Solaris 10 3/05 ONLY from http://docs.oracle.com/cd/E19253-01/816-4554/esxhb/index.html:
1. # ifconfig lo0 plumb up
2. # ifconfig lo0 10.56.8.101 netmask 255.255.240.0. This was the working Windows DHCP environment prior to installing Solaris
10 on top of it.
3. # Added saturn to /etc/hostname.lo0.
4. # Added 10.56.8.101 to /etc/inet/hosts
5. # Added 10.56.0.0 255.255.240.0 to /etc/inet/netmasks
6.# reboot
However, the following errors kept recurring:
svcs –xv …. unable to qualify my own domain name,
failed with exit status 69.
Any idea on what other steps have I missed? I was hoping to only do step 3 – 6 for the change to apply permanently.
Many thanks,
Jack

Hi Java Specialist,... in a Solaris forum?
1. # ifconfig lo0 plumb upThe loopback connection (your lo0)is NOT a physical interface. There are no hardware components for it. Nor can I think of any reason why it should ever be anything other than the default 127.0.0.1
Use your favorite Internet search site (such as Google, Bing, Yahoo) to learn more about it.
2. # ifconfig lo0 10.56.8.101 netmask 255.255.240.0. This was the working Windows DHCP environment ...I have no idea how a nonexistent software construct gets a DHCP address in a MS Operating System, unless you are confusing this with the "Microsoft Loopback Adapter" which is an utterly different concept. Again, go see what Google tells you.
<br>
<br>
<br>
... completely unrelated to configuring an IP...
unable to qualify my own domain nameAgain, search the Internet or even search these forums with that string of words.
Go back through your two most recent posts and read the responses again.
They seem to both be on the same topic as this new one -- configuring an IP on something.
How to initialize new IP address on secondary interface permanently
How to change IP address permanently on Solaris 10
When you've done all that, then come back and tell us what you are actually trying to do.

Interfaces in Physical Inventory

Hi experts
Can i get info on interfaces in physical inventory process.
warm regards
marias

Hi
See all the MI** transactions for Physical inventory related transactions like
MI01/02/03 PI doc cretae/change/display
check the transactions
MI04,05,06,07,08,09,10,11,12,20,22,23,24 and
MMBE,MB51 etc
Reward points for useful Answers
Regards
Anji

Tunnel interface to physical interface

Similar Messages

Maybe you are looking for