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.4service timestamps debug datetime msecservice timestamps log datetime msecno service password-encryption!hostname R1!boot-start-markerboot-end-marker!aqm-register-fnf!!no aaa new-modelclock timezone CET 1 0mmi polling-interval 60no mmi auto-configureno mmi pvcmmi snmp-timeout 180!!!!!!!!!!ip cefno ipv6 cef!multilink bundle-name authenticated!!!!!!! !!redundancy!!!class-map match-all MAPMYGRE match access-group name MYGREclass-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 serverno ip http secure-serverip route 0.0.0.0 0.0.0.0 192.168.12.2ip route 3.3.3.3 255.255.255.255 172.16.13.3!ip access-list extended MYGRE permit gre any anyip access-list extended MYTELNET permit tcp any any eq telnet!!!!control-plane!!!!!!!!line con 0 logging synchronousline aux 0line vty 0 4 login transport input none!!endR1#
R2#sh run Building configuration...Current configuration : 1778 bytes!! Last configuration change at 21:18:16 CET Tue Sep 4 2018!version 15.4service timestamps debug datetime msecservice timestamps log datetime msecno service password-encryption!hostname R2!boot-start-markerboot-end-marker!!!no aaa new-modelclock timezone CET 1 0mmi polling-interval 60no mmi auto-configureno mmi pvcmmi snmp-timeout 180! !!!!!!!!!ip cefno 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 serverno ip http secure-serverip route 1.1.1.1 255.255.255.255 192.168.12.1ip route 3.3.3.3 255.255.255.255 192.168.23.3!!!!control-plane!!!!!!!!line con 0 logging synchronousline aux 0line vty 0 4 login transport input none!! endR2#
R3#sh run Building configuration...Current configuration : 1951 bytes!! Last configuration change at 09:38:09 CET Wed Sep 5 2018!version 15.4service timestamps debug datetime msecservice timestamps log datetime msecno service password-encryption!hostname R3!boot-start-markerboot-end-marker!aqm-register-fnf!!no aaa new-modelclock timezone CET 1 0mmi polling-interval 60no mmi auto-configureno mmi pvcmmi snmp-timeout 180!!!!!!!!!!ip cefno 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 serverno ip http secure-serverip route 0.0.0.0 0.0.0.0 192.168.23.2ip route 1.1.1.1 255.255.255.255 172.16.13.1!!!!control-plane!!!!!! !!line con 0 logging synchronousline aux 0line vty 0 4 login transport input telnet!!endR3#
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
RoutersSwitches / HubsNetworking
Last Comment
Aaron Street
8/22/2022 - Mon
Aaron Street
can you post the link to whaty you read online?
Aaron Street
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
David Favor
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.
@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.
jskfan
ASKER
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 0R1(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 countersClear "show interface" counters on all interfaces [confirm]R1#telnet 3.3.3.3 /source-interface loopback 0Trying 3.3.3.3 ... OpenNow 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: anyGreat! 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:
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.
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..
jskfan
ASKER
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