How Telnet works in GRE Tunnel

How Telnet works in GRE Tunnel

t
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#

Open in new window


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#

Open in new window



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# 

Open in new window


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#

Open in new window


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
jskfanAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Aaron StreetTechnical infrastructure architectureCommented:
can you post the link to whaty you read online?
0
Aaron StreetTechnical infrastructure architectureCommented:
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
0
David FavorLinux/LXD/WordPress/Hosting SavantCommented:
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.
0
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

Aaron StreetTechnical infrastructure architectureCommented:
@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.
0
jskfanAuthor Commented:
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:

g
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:

Open in new window


g
0
Aaron StreetTechnical infrastructure architectureCommented:
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.
0
jskfanAuthor Commented:
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..
0
jskfanAuthor Commented:
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
0
Aaron StreetTechnical infrastructure architectureCommented:
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.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jskfanAuthor Commented:
Thank you Guys
0
Aaron StreetTechnical infrastructure architectureCommented:
Glad we could help.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Routers

From novice to tech pro — start learning today.