Let’s 6rd!


6rd mechanism belongs to the same family as automatic 6to4, in which IPv6 traffic is encapsulated inside IPv4.

The key difference is that with 6rd, Service Providers use their own 6rd prefix and control the transition of their access-aggregation IPv4-only part of their networks to native IPv6. In the same time, SPs transparently provide IPv6 availability service to their customers.

6rd is generally referred as stateless transition mechanism.

Stateless
In stateless mechanisms an algorithm is used to automatically map between addresses, the scope of mechanism is limited to a local domain in which devices, mapping device (6rd BR) and devices that need mapping (6rd CE), share a common elements of the configuration.
Stateful
On a gateway device, we need to specify a specific address or a range of addresses (not used elsewhere) that will represent another range of addresses.
For example IPv4 NAT on Cisco (NAT44):
ip nat source …
The router relies on the configured statement which address (all bits) to translate to which address (all bits). Which is done independently of devices whose address needs to be translated (inside local/outside global).
For redundancy we need additional configuration to synchronize connection state information between devices. for example SNAT(Stateful NAT failover).

Customer CE routers generate their own IPv6 from the delegated 6rd prefix from BRs (Border relays).


Both CEs and BRs encapsulate IPv6 traffic into IPv4 traffic by automatically reconstructing the header IPv4 addresses from IPv6.


  • Lab topology

top1

For end-to-end testing I am using Ubunu Server version for client host behind CE and Internet host.

Here, is a brief and I hope concise explanation of the main 6rd operations:


6rd configuration

6rd address planning depends on each SP. IPv4 bits must be unique to each CE to show the flexibility of the configuration, I fixed the first 16 bits (10.1) as prefix and the last octets (.1) as suffix and attributed the third octet to CEs.

6rd domain configured parameters:

Tunnel source interface fa0/0
6rd prefix 2001:DEAD::/32
IPv4 prefix length 16
IPv4 bits 8
IPv4 suffix 8
Tunnel source interface IP 10.1.4.1

BR1

ipv6 general-prefix 6RD-PREFIX 6rd Tunnel0
!
interface Tunnel0
ipv6 address 6RD-PREFIX 2001:DEAD::/128 anycast
ipv6 enable

tunnel source FastEthernet0/0
tunnel mode ipv6ip 6rd
tunnel 6rd ipv4 prefix-len 16 suffix-len 8


tunnel 6rd prefix 2001:DEAD::/32

interface FastEthernet0/0

ip address 10.1.4.1 255.255.0.0

We need a couple of static routes to make 6rd work in lab conditions; generally, BR announces client assigned IPv4 to clients to Internet.

  • Default ipv4 static route to outside
  • Static route to SP 6rd prefix pointing to the tunnel
  • Default ipv6 static route to outside
ip route 0.0.0.0 0.0.0.0 192.168.20.100
ipv6 route 2001:DEAD::/32 Tunnel0
ipv6 route ::/0 2001:DB9:5AB::100

CE1

The same 6rd parameters are configured on CE:

  • IPv4 affixes
  • 6rd domain global prefix
  • BR IPv4 address (remote tunnel end point)
interface Tunnel0
ipv6 enable
tunnel source 10.1.1.1
tunnel mode ipv6ip 6rd

tunnel 6rd ipv4 prefix-len 16 suffix-len 8

tunnel 6rd prefix 2001:DEAD::/32

tunnel 6rd br 10.1.4.1
!

interface FastEthernet0/0

ip address 10.1.1.1 255.255.0.0

ipv6 enable

!

interface FastEthernet0/1

ip address 192.168.10.100 255.255.255.0


ipv6 address 6RD-PREFIX ::/64 eui-64 ! * <<<

* Note the CE WAN interface fa0/0 is only enabled for IPv6 to be attributed a link-local address.

Fa0/0 IPv4 address is generally assigned by IPv4 DHCP. If the ISP assigns private addresses, CGN NAT44 is needed at the BR to translate them into global IPv4.

6rd prefix is delegated not to CE fa0/0 WAN interface but CE inside LAN interface fa0/1.

This way the customer LAN can benefit directly from the globally IPv6 address without interrupting IPv6 address continuity and the same prefix can be assigned to client IPv6 network using SLAAC (stateless auto configuration).

A recursive (output interface + next-hop) IPv6 default route points to the BR tunnel interface.

ipv6 route ::/0 Tunnel0 2001:DEAD:400::1

Debugging 6rd tunnel

CE1

CE1#debug tunnel
Tunnel Interface debugging is on
CE1#
Tunnel0: IPv6/IP adjacency fixup, 10.1.1.1->10.1.4.1, tos set to 0x0
Tunnel0: IPv6/IP (PS) to decaps 10.1.4.1->10.1.1.1 (tbl=0, “default”, len=124, ttl=254)
Tunnel0: decapsulated IPv6/IP packet (len 124)

BR1

BR1#debug tunnel
Tunnel Interface debugging is on
BR1#
Tunnel0: IPv6/IP to classify 10.1.1.1->10.1.4.1 (tbl=0,”default” len=124 ttl=254 tos=0x0) ok, oce_rc=0x0
Tunnel0: IPv6/IP adjacency fixup, 10.1.4.1->10.1.1.1, tos set to 0x0
BR1#

As shown by the debug, the end-to-end IPv6 traffic is encapsulated into IPv4 packets between CE and BR.

$iperf -u -t -i1 -V -c 2001:db9:5ab::10 -b 10K
WARNING: delay too large, reducing from 1.2 to 1.0 seconds.
————————————————————
Client connecting to 2001:db9:5ab::100, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 112 KByte (default)
————————————————————
[ 3] local 2001:dead:100:0:a00:27ff:fe0f:20e9 port 39710 connected with 2001:db9:5ab::100 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0- 1.0 sec 1.44 KBytes 11.8 Kbits/sec

[ 3] 1.0- 2.0 sec 1.44 KBytes 11.8 Kbits/sec

[ 3] 2.0- 3.0 sec 4.00 GBytes 34.4 Gbits/sec

[ 3] 3.0- 4.0 sec 1.44 KBytes 11.8 Kbits/sec

[ 3] 4.0- 5.0 sec 1.44 KBytes 11.8 Kbits/sec

[ 3] 5.0- 6.0 sec 4.00 GBytes 34.4 Gbits/sec

[ 3] 6.0- 7.0 sec 1.44 KBytes 11.8 Kbits/sec

[ 3] 7.0- 8.0 sec 4.00 GBytes 34.4 Gbits/sec

[ 3] 8.0- 9.0 sec 1.44 KBytes 11.8 Kbits/sec

[ 3] 9.0-10.0 sec 4.00 GBytes 34.4 Gbits/sec

[ 3] 0.0-11.0 sec 16.0 GBytes 12.5 Gbits/sec

[ 3] Sent 11 datagrams

read failed: Connection refused

[ 3] WARNING: did not receive ack of last datagram after 4 tries.

Following, is a wireshark traffic capture of the previous iperf testing

6rd-iperf-wireshark

Verification commands

BR1:

BR1#sh tunnel 6rd tunnel 0
Interface Tunnel0:
Tunnel Source: 10.1.4.1
6RD: Operational, V6 Prefix: 2001:DEAD::/32
V4 Prefix, Length: 16, Value: 10.1.0.0
V4 Suffix, Length: 8, Value: 0.0.0.1
General Prefix: 2001:DEAD:400::/40
BR1#
BR1#sh tunnel 6rd destination 2001:dead:100:: tunnel0
Interface: Tunnel0
6RD Prefix: 2001:DEAD:100::
Destination: 10.1.1.1
BR1#
BR1#sh tunnel 6rd prefix 10.1.1.1 tunnel 0
Interface: Tunnel0
Destination: 10.1.1.1
6RD Prefix: 2001:DEAD:100::
BR1#

CE1:

CE1#sh tunnel 6rd tunnel 0
Interface Tunnel0:
Tunnel Source: 10.1.1.1
6RD: Operational, V6 Prefix: 2001:DEAD::/32
V4 Prefix, Length: 16, Value: 10.1.0.0
V4 Suffix, Length: 8, Value: 0.0.0.1
Border Relay address: 10.1.4.1
General Prefix: 2001:DEAD:100::/40

CE1#

CE1#sh tunnel 6rd destination 2001:dead:100:: tunnel0
Interface: Tunnel0
6RD Prefix: 2001:DEAD:100::
Destination: 10.1.1.1
CE1#
CE1#sh tunnel 6rd prefix 10.1.4.1 tunnel 0
Interface: Tunnel0
Destination: 10.1.4.1
6RD Prefix: 2001:DEAD:400::
CE1#

We can use “mtr” command to check the performance of the end-to-end (linux-to-linux) communication.

router@router1:~$ mtr 2001:db9:5ab::100
HOST: router1 Loss% Snt Last Avg Best Wrst StDev
1.|– 2001:dead:100:0:c801:3dff 0.0% 30 27.7 25.2 9.7 34.4 5.9
2.|– 2001:db9:5ab::1 0.0% 30 181.3 126.2 99.1 181.3 19.3
3.|– 2001:db9:5ab::100 0.0% 30 67.3 82.8 67.3 121.6 14.1
router@router1:~$

Customer internal network


6rd and MTU

The default MTU on IOS is 1480 bytes, so the maximum IPv4 packet size encapsulating IPv6 is 1500 bytes.

userver1 end-to-end MTU

router@router1:~$ tracepath6 2001:db9:5ab::100
1?: [LOCALHOST] 0.051ms pmtu 1500
1: 2001:dead:100:0:c801:3dff:fe5c:6 27.130ms
1: 2001:dead:100:0:c801:3dff:fe5c:6 57.536ms
2: 2001:dead:100:0:c801:3dff:fe5c:6 30.005ms pmtu 1480
2: 2001:db9:5ab::1 135.158ms
3: 2001:db9:5ab::100 79.603ms reached

Resume: pmtu 1480 hops 3 back 253

router@router1:~$

Here is an animation explaining 6rd and fragmentation:

MTU recommendations

  • Using a redundant BR, there is no guarantee that traffic will be handled by the same BR, so fragmented packets are lost between BRs è BR anycast IPv4 + IPv4 fragmentation is not recommended.
  • Configure the same IPv4 MTU everywhere within the IPv4 segment and (DF=1) to disable fragmentation.
    • make sure the IPv4 MTU is coordinated with IPv6 MTU (IPv4 MTU < IPv6 MTU + 20 bytes)
  • Enable PMTUD to choose the smallest MTU in the path of CE-to-BR communication.
  • DO NOT Filter ICMP messages “Packet Too Big” and “Destination Unreachable” at routers and end-hosts, they provide inf. about transport issues, worse than traffic black hole is a silent traffic black hole.

Offline Lab

Finally, the offline lab with comprehensive command output during the lab:

Advertisements

WCCPv2 and Squid-cache v3.1, a nice couple.


WCCP protocol can be much more interesting than the two commands needed for the CCIE exam. In this lab we will deploy a basic end-to-end solution using IOS 15.2S and the well known open-source solution Squid v3.1 as the content engine.

WCCP version2 is deployed in the lab.

1-Topology

wccpv2top1

WCCP enables the router to transparently intercept client traffic destined to Internet and redirect it to a local content engine. Client browsers doesn’t point to the content engine as proxy.

Cisco and the content engine communicate through unidirectional point-to-point tunnels (either layer2 or GRE ).

2-WCCPv2 Interception

wccpv2top2

The tunnel interfaces are automatically created in order to process outgoing GRE-encapsulated traffic for WCCP.
Short definitions of some related concepts:

Forward proxy Filter access to Internet and reduces BW related to Internet static resources like regular updates, big file downloads…
Reverse proxy Allows external users (ex: on Internet) to access internal servers. Generally supports security features as well as caching and load balancing.
WCCP Bypass Packets When the content engine cannot manage the redirected packets appropriately, it returns the packets unchanged to the originating router. These packets are called bypass packets.
Closed service (default = open) WCCP discards packets that do not have a WCCP client registered (external devices) to receive the redirected traffic.

Router configuration

The router configuration is straightforward:

ip cef
ip wccp web-cache password 0 cisco
!
interface FastEthernet0/0
ip wccp web-cache redirect in

We are not using ip wccp web-cache redirect out which is used on interfaces facing outside users trying to connect to inside servers (reverse-proxy)

Fa0/0 is the interface facing internal clients trying to connect to Internet.

Of course, you can add other functionalities like more services or filtering packets to be redirected.

Router verification commands

sh ip int fa0/0
sh ip int brief
sh tunnel in Tunnel0
sh tunnel in Tunnel1
sh ip wccp summary
sh ip wccp global counters
sh ip wccp
sh ip wccp web-cache counters
sh tunnel groups wccp
sh adjacency tunnel 0 detail
sh ip wccp web-cache detail

Here is the outcome


Squid config

The configuration is slightly different depending on what Squid and IOS version/platform you are using, so make sure to refer to appropriate configuration guides.

Enabling wccpv2 protocol on squid to work with your router.

wccp2_router 192.168.1.121wccp2_forwarding_method grewccp2_return_method gre

wccp2_service standard 0 password=cisco

http_port 3128 intercept

wccp2_router 192.168.1.121 Designate the router intercepting the traffic
wccp2_forwarding_method gre Router to squid encapsulation
wccp2_return_method gre Squid to router encapsulation
wccp2_service standard 0 password=cisco Standard service defines http traffic interception, with password protection between squid and the router
http_port 3128 intercept Configure Squid 3.1 to transparent interception

To illustrate the concept squid is configured with permissive strategy (last rule permit everything). As with Cisco ACLs, the first matched rule is applied. With restrictive strategy make sure to put permission rules “allow” before the last “deny all”.

The initial squid configuration file looks very intimidating, so create a version free of comments and empty lines using:

grep -ve ^$ -ve ^# /etc/squid3/squid.conf

Restart Squid after each modification of /etc/squid3/squid.conf
acl manager proto cache_objectacl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl localnet src 192.168.2.0/24
acl alldst dst 0.0.0.0/32
acl SSL_ports port 443acl Safe_ports port 80# httpacl Safe_ports port 21# ftpacl Safe_ports port 443

# httpsacl Safe_ports port 70

# gopheracl Safe_ports port 210

# acl Safe_ports port 1025-65535

# unregistered ports

acl Safe_ports port 280

# http-mgmtacl Safe_ports port 488

# gss-httpacl Safe_ports port 591

# filemakeracl Safe_ports port 777

# multiling http

acl CONNECT method CONNECT

http_access allow manager localhost

http_access deny manager

http_access deny

!Safe_ports

http_access deny CONNECT

!SSL_ports

http_access allow localhost

http_access allow localnet

http_access allow alldst

http_access allow all

#http_access deny all

http_port 3128 intercept

visible_hostname squid31.cciethebeginning.wordpress.com

wccp2_router 192.168.1.121

wccp2_forwarding_method gre

wccp2_return_method gre

wccp2_service standard 0 password=cisco

hierarchy_stoplist cgi-bin ?

coredump_dir /var/spool/squid3

refresh_pattern ^ftp: 1440 20% 10080

refresh_pattern ^gopher: 1440 0% 1440

refresh_pattern -i (/cgi-bin/|\?) 0 0% 0

refresh_pattern . 0 20% 4320

Linux verification


Observing IOS-Squid communication through Wireshark

The following Wireshark snapshots illustrates the two communication tunnels established between the router and Squid as well client-to-Internet traffic redirected from the router to Squid.

3-GRE tunnels

gretunnel

4-Redirected traffic

request

This should give you a starting point from which you can dig deeper into Squid and IOS cooperation.

Reference links

http://www.cisco.com/en/US/docs/ios-xml/ios/ipapp/configuration/15-mt/iap-wccp-v2-ipv6.html#GUID-608CB58E-EDD4-4073-A903-784CFB9AADCA

http://www.squid-cache.org/

http://wiki.squid-cache.org/Features/Wccp2

http://www.squid-cache.org/Versions/v3/3.1/cfgman/

%d bloggers like this: