Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
How Telnet works in GRE Tunnel
How Telnet works in GRE Tunnel
in the topology above I have created a GRE tunnel between R1 and R3. The configuration is shown below:
now if I run this command on R1:
R1#telnet 3.3.3.3 /source-interface loopback 0
then check policy map this way:
The class-map used for telnet named MAPTELNET shows 0 packets..
I have read online why this is showing 0 packets, but could not understand the logic they used to explain it..
Any clarification will be very much appreciated
Thank you
in the topology above I have created a GRE tunnel between R1 and R3. The configuration is shown below:
R1#show running-config
Building configuration...
Current configuration : 2295 bytes
!
! Last configuration change at 09:31:13 CET Wed Sep 5 2018
!
version 15.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
aqm-register-fnf
!
!
no aaa new-model
clock timezone CET 1 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
redundancy
!
!
!
class-map match-all MAPMYGRE
match access-group name MYGRE
class-map match-all MAPTELNET
match access-group name MYTELNET
!
policy-map MYPOLICE
class MAPTELNET
police 128000
class MAPMYGRE
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Tunnel0
ip address 172.16.13.1 255.255.255.0
tunnel source 192.168.12.1
tunnel destination 192.168.23.3
!
interface Ethernet0/0
ip address 192.168.12.1 255.255.255.0
service-policy output MYPOLICE
!
interface Ethernet0/1
no ip address
shutdown
!
interface Ethernet0/2
no ip address
shutdown
!
interface Ethernet0/3
no ip address
shutdown
!
interface Ethernet1/0
no ip address
shutdown
!
interface Ethernet1/1
no ip address
shutdown
!
interface Ethernet1/2
no ip address
shutdown
!
interface Ethernet1/3
no ip address
shutdown
!
interface Serial2/0
no ip address
shutdown
serial restart-delay 0
!
interface Serial2/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial2/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial2/3
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/0
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/3
no ip address
shutdown
serial restart-delay 0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 0.0.0.0 0.0.0.0 192.168.12.2
ip route 3.3.3.3 255.255.255.255 172.16.13.3
!
ip access-list extended MYGRE
permit gre any any
ip access-list extended MYTELNET
permit tcp any any eq telnet
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
line con 0
logging synchronous
line aux 0
line vty 0 4
login
transport input none
!
!
end
R1#
R2#sh run
Building configuration...
Current configuration : 1778 bytes
!
! Last configuration change at 21:18:16 CET Tue Sep 4 2018
!
version 15.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
clock timezone CET 1 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Ethernet0/0
ip address 192.168.12.2 255.255.255.0
!
interface Ethernet0/1
ip address 192.168.23.2 255.255.255.0
!
interface Ethernet0/2
no ip address
shutdown
!
interface Ethernet0/3
no ip address
shutdown
!
interface Ethernet1/0
no ip address
shutdown
!
interface Ethernet1/1
no ip address
shutdown
!
interface Ethernet1/2
no ip address
shutdown
!
interface Ethernet1/3
no ip address
shutdown
!
interface Serial2/0
no ip address
shutdown
serial restart-delay 0
!
interface Serial2/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial2/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial2/3
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/0
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/3
no ip address
shutdown
serial restart-delay 0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 1.1.1.1 255.255.255.255 192.168.12.1
ip route 3.3.3.3 255.255.255.255 192.168.23.3
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
line con 0
logging synchronous
line aux 0
line vty 0 4
login
transport input none
!
!
end
R2#
R3#sh run
Building configuration...
Current configuration : 1951 bytes
!
! Last configuration change at 09:38:09 CET Wed Sep 5 2018
!
version 15.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
aqm-register-fnf
!
!
no aaa new-model
clock timezone CET 1 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Tunnel0
ip address 172.16.13.3 255.255.255.0
tunnel source 192.168.23.3
tunnel destination 192.168.12.1
!
interface Ethernet0/0
ip address 192.168.23.3 255.255.255.0
!
interface Ethernet0/1
no ip address
shutdown
!
interface Ethernet0/2
no ip address
shutdown
!
interface Ethernet0/3
no ip address
shutdown
!
interface Ethernet1/0
no ip address
shutdown
!
interface Ethernet1/1
no ip address
shutdown
!
interface Ethernet1/2
no ip address
shutdown
!
interface Ethernet1/3
no ip address
shutdown
!
interface Serial2/0
no ip address
shutdown
serial restart-delay 0
!
interface Serial2/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial2/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial2/3
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/0
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial3/3
no ip address
shutdown
serial restart-delay 0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 0.0.0.0 0.0.0.0 192.168.23.2
ip route 1.1.1.1 255.255.255.255 172.16.13.1
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
line con 0
logging synchronous
line aux 0
line vty 0 4
login
transport input telnet
!
!
end
R3#
now if I run this command on R1:
R1#telnet 3.3.3.3 /source-interface loopback 0
then check policy map this way:
R1#show policy-map interface e0/0
Ethernet0/0
Service-policy output: MYPOLICE
Class-map: MAPTELNET (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: access-group name MYTELNET
police:
cir 128000 bps, bc 4000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps
Class-map: MAPMYGRE (match-all)
11 packets, 893 bytes
5 minute offered rate 0000 bps
Match: access-group name MYGRE
Class-map: class-default (match-any)
57 packets, 6335 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
R1#
The class-map used for telnet named MAPTELNET shows 0 packets..
I have read online why this is showing 0 packets, but could not understand the logic they used to explain it..
Any clarification will be very much appreciated
Thank you
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Also do you put the policy on the physial interface of the tunnel?
Tunnel marking policy can be applied on Ingress or Egress direction. A tunnel marking policy can be applied as an ingress policy on the ingress physical interface of a Service Provider Edge (SPE) router or as an egress policy on a tunnel interface.
reading that and you have put an egress policy on the physical interface, but it sounds like it should be apploied egress to the tunnel interface.
This makes sense as by the time the paket it sent out the Physcial interface it is already enclapasated in by GRE
Tunnel marking policy can be applied on Ingress or Egress direction. A tunnel marking policy can be applied as an ingress policy on the ingress physical interface of a Service Provider Edge (SPE) router or as an egress policy on a tunnel interface.
reading that and you have put an egress policy on the physical interface, but it sounds like it should be apploied egress to the tunnel interface.
This makes sense as by the time the paket it sent out the Physcial interface it is already enclapasated in by GRE
Several things for you to consider.
1) Likely a ticket opened with Cisco will provide you fastest + most correct answer.
2) To use GRE, as best I recall, both endpoints must use GRE, so you can only connect inside your enterprise.
3) Or each endpoint must run an OS like Ubuntu Bionic, which provides latest GRE support.
4) Both your source connection endpoint + target connection endpoint must support GRE to conduct GRE communications.
5) Start with Firewalls completely off (all IPs/ports/protocols allowed), then get GRE working, then turn on your Firewall on both ends.
6) Note: If you can't run GRE on all your target endpoints (they're owned by other companies), just use SSH, for better encryption (depending on cypher you choose) + full support every where, so no concern about setting up GRE on every target machine.
1) Likely a ticket opened with Cisco will provide you fastest + most correct answer.
2) To use GRE, as best I recall, both endpoints must use GRE, so you can only connect inside your enterprise.
3) Or each endpoint must run an OS like Ubuntu Bionic, which provides latest GRE support.
4) Both your source connection endpoint + target connection endpoint must support GRE to conduct GRE communications.
5) Start with Firewalls completely off (all IPs/ports/protocols allowed), then get GRE working, then turn on your Firewall on both ends.
6) Note: If you can't run GRE on all your target endpoints (they're owned by other companies), just use SSH, for better encryption (depending on cypher you choose) + full support every where, so no concern about setting up GRE on every target machine.
@David, GRE does not do any encryption? its a tunne protocol do no encryption at all. you can encapslate GRE with IPsec (which is a good thing to do) but GRE does not protect data, it jsut gives you a transparrent tunnel across mutiply layyer 3 devices.
In point 3 you say end points must support GRE such as Unbunta? you dont run GRE on servers, its a Router to router (or firewall) protocol it is transpartent to the end point devices.
as for firewalls the need to support and pass protocol 47 which most can do.
And end points do not need to support GRE apart from the routers that hold the tunnel end points. the only poiont to note about GRE is it does reduce the MAx MTU the link will support, in 99% of cases this is not an issue, but you should set the MTU and turn on MTU path discoiver on end points if they support it, they will work with out (As long as you allow frangmatation) however they my be in efficent if they expect to use full size packets.
For example the standard MTU is 1500, and GRE will reduce it to 1476. So if an end station send a packet of 1500 the router wilkl split it in to two packets one of 1476 and a second with the few remaining bytes. If you have path discover the end station will no not to send packets larger than 1476 and so you dont get the frangmatation happening.
In point 3 you say end points must support GRE such as Unbunta? you dont run GRE on servers, its a Router to router (or firewall) protocol it is transpartent to the end point devices.
as for firewalls the need to support and pass protocol 47 which most can do.
And end points do not need to support GRE apart from the routers that hold the tunnel end points. the only poiont to note about GRE is it does reduce the MAx MTU the link will support, in 99% of cases this is not an issue, but you should set the MTU and turn on MTU path discoiver on end points if they support it, they will work with out (As long as you allow frangmatation) however they my be in efficent if they expect to use full size packets.
For example the standard MTU is 1500, and GRE will reduce it to 1476. So if an end station send a packet of 1500 the router wilkl split it in to two packets one of 1476 and a second with the few remaining bytes. If you have path discover the end station will no not to send packets larger than 1476 and so you dont get the frangmatation happening.
can you post the link to whaty you read online?, it is a learning site that requires login.
So, following the Output I pasted in the question above
I will try to paste the content of the Author that we need to see here:
Pre Header Classification (Physical Interface)
The first method to solve this issue is to enable pre-classification on the tunnel interface. This tells the router to create a copy of the original IP header and to use that for the policy. Here's how to do this:
R1(config)#interface Tunnel 0
R1(config-if)#qos pre-classify
You can use the qos pre-classify command to do this. Let's do another test and we'll see the difference:
R1#clear counters
Clear "show interface" counters on all interfaces [confirm]
R1#telnet 3.3.3.3 /source-interface loopback 0
Trying 3.3.3.3 ... Open
Now take a look at the policy-map:
R1#show policy-map interface FastEthernet 0/0
FastEthernet0/0
Service-policy output: POLICE
Class-map: TELNET (match-all)
11 packets, 735 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name TELNET
police:
cir 128000 bps, bc 4000 bytes
conformed 11 packets, 889 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: GRE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: access-group name GRE
Class-map: class-default (match-any)
1 packets, 60 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Great! Now we see matches on our telnet traffic so it can be policed if needed. We don't see any matches on our GRE traffic anymore. Let me visualize what just happened for you:
I can see what it is saying.
In a simualr way to you can't do traffic inspection on traffic that is encrypted in a Ip-sec tunnel.
So the orignal pack might had an IP header of
src 192.168.1.25 dst 8.8.8.8 port 23.
but once encapslated it would have the source and destination of the Tunnle end points and a protocol of 47
Source 192.168.12.1
Destination 192.168.23.3
So now the packet is not a telnet packet but a GRE packet and will not get classified correctly.
By turning on pre-classification you are telling the Router to figure out what the origianl packet was, then wrapping it up in GRE so it can still classify it correctly.
It a bit like putting some thing in a box and then attaching a lable on the out side describing the contents.
If you put a log in one box and a glass vase in the other, unless you lable one with "fragile" then the postman will not know which one to treat carefull.
In a simualr way to you can't do traffic inspection on traffic that is encrypted in a Ip-sec tunnel.
So the orignal pack might had an IP header of
src 192.168.1.25 dst 8.8.8.8 port 23.
but once encapslated it would have the source and destination of the Tunnle end points and a protocol of 47
Source 192.168.12.1
Destination 192.168.23.3
So now the packet is not a telnet packet but a GRE packet and will not get classified correctly.
By turning on pre-classification you are telling the Router to figure out what the origianl packet was, then wrapping it up in GRE so it can still classify it correctly.
It a bit like putting some thing in a box and then attaching a lable on the out side describing the contents.
If you put a log in one box and a glass vase in the other, unless you lable one with "fragile" then the postman will not know which one to treat carefull.
Aaron Street:
You are correct when you said put the Service-Policy in the tunnel interface instead of physical interface. The Author, mentioned that as a 2nd method, in addition to the method indicated on my last comment above..
You are correct when you said put the Service-Policy in the tunnel interface instead of physical interface. The Author, mentioned that as a 2nd method, in addition to the method indicated on my last comment above..
Aaron Street:
if you can elaborate on that , that would help to understand the reason of applying Service-Policy in the tunnel interface instead of physical interface, in order to see the Telnet packets Marked instead of GRE packets.
Thank you
if you can elaborate on that , that would help to understand the reason of applying Service-Policy in the tunnel interface instead of physical interface, in order to see the Telnet packets Marked instead of GRE packets.
Thank you
When a company such as CISCO design a network device they will have to define in what order it takes actions on the traffic flowing though, some of this will to od with logical operations
For example the device will have to look up the packet destiantaion address before it can look up the egress interface to use.
But in some cases it is more complicated such as when NATing. At what point do you check the access list, before the Destination is NATed or after. And many devices will do it once before and once after.
For a GRE tunnel the flow is some thing like this
Packet arrives at tunnel interface and any ACL or Policies on the Tunnel intreface are applied, then it gets encapspated in to a GRE packet and is sent to the physical interface. At this point the physical interface policy is applied to the encapslated packet not the origianl telnet.
A policy only sees what is paasing though it at that point in time, it does not drill down in to the packet (talking basic switching and routing devices not ful blow firewalls with deep packet inspection). This is to make sure routing and switching can happen fast, you want as little priocess as possible and want every thing to be the same. You dont want the router having to check to see if it needs to look inside the encapslation for each packet "hey this is GRE i need to look inside", oh this one is a standard packet i can jsut check it", "oh does this one need natting, let me check and do that before I check is agisnt the ACL"....
Instead there is a very clearly defined flow or operations that at each stage is optermised for the operation takeing place to insure a few resorce cycels are wasted as possible. an in this case the packet passes though the GRE tunnel interface before the physical (which makes sense and the GRE tunnle interface is virtual and the Physical inteface is the last thing the packet will pass though before leaving the device.
See this image, can you see why a policy applied to the outoging physical intreface will apply ot the GRE headder and not the origianl packet header.
https://1.bp.blogspot.com/_Lvh-OYvhatI/THOw_L4jZtI/AAAAAAAAAO4/Ok46aZzZS9c/s1600/tunnel_flow.png
Jsut remember no mattter what it looks like every thing that happends on the network is squencial and happens in a predefined order.
For example the device will have to look up the packet destiantaion address before it can look up the egress interface to use.
But in some cases it is more complicated such as when NATing. At what point do you check the access list, before the Destination is NATed or after. And many devices will do it once before and once after.
For a GRE tunnel the flow is some thing like this
Packet arrives at tunnel interface and any ACL or Policies on the Tunnel intreface are applied, then it gets encapspated in to a GRE packet and is sent to the physical interface. At this point the physical interface policy is applied to the encapslated packet not the origianl telnet.
A policy only sees what is paasing though it at that point in time, it does not drill down in to the packet (talking basic switching and routing devices not ful blow firewalls with deep packet inspection). This is to make sure routing and switching can happen fast, you want as little priocess as possible and want every thing to be the same. You dont want the router having to check to see if it needs to look inside the encapslation for each packet "hey this is GRE i need to look inside", oh this one is a standard packet i can jsut check it", "oh does this one need natting, let me check and do that before I check is agisnt the ACL"....
Instead there is a very clearly defined flow or operations that at each stage is optermised for the operation takeing place to insure a few resorce cycels are wasted as possible. an in this case the packet passes though the GRE tunnel interface before the physical (which makes sense and the GRE tunnle interface is virtual and the Physical inteface is the last thing the packet will pass though before leaving the device.
See this image, can you see why a policy applied to the outoging physical intreface will apply ot the GRE headder and not the origianl packet header.
https://1.bp.blogspot.com/_Lvh-OYvhatI/THOw_L4jZtI/AAAAAAAAAO4/Ok46aZzZS9c/s1600/tunnel_flow.png
Jsut remember no mattter what it looks like every thing that happends on the network is squencial and happens in a predefined order.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial