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

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

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

4-Redirected traffic

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/

OSPF external E1, E2, N1, N2…Who is the winner?

This lab focuses on route selection mechanism of OSPF external routes. The complexity of OSPF selection process is due to its inherent hierarchical structure.

The following selection order should be familiar to you:

1. intra-area (O)
2. inter-area (IA)
3. external routes

OSPF provides more flexibility for external routes by manipulating the following criteria:

• Regular areas or NSSA (Not So Stubby Area)
• type1 or type2
• total cost, cost to ABR and cost to ASBR

The idea is to provide a lab topology in which all types of external routes are artificially available in the same time to the main router (R1). This is done by injecting an overlapping prefix 10.10.10.1/32 through different areas into the same OSPF process.

R1(made the DR) is configured not to advertise LSAs and prefixes between its interfaces.

Each lab starts with all paths available (case1), then the forwarding interface of the best elected path is shutdown (case2) to see who is the next best route. And so on until the last preferable path.

Three topologies are used to narrow down the tests:

• The 1^st lab (Mix of external routes): Compare all types of external routes
• The 2^nd lab (All E2): Compare E2 routes with the same redistribution cost, but different costs to ABR and costs to ASBR.
• The 3^rd lab (All E1): Compare E1 routes with the same total cost, but different costs to ABR and costs to ASBR.

For each lab, the following is provided:

• Lab topology
• The result table for studied cases
• Verification commands
• An offline lab (A comprehensive report of the network state during each test case)

To keep visible the general structure of the post, verifications commands, configuration listings and the gory details of router configurations are kept in compact flash boxes with selectable text.

Lab1

Lab1 topology

Table1: Lab1 (Mix of external routes)

Case	Route type	Route cost	Next-hop	Cost to ABR	Cost to ASBR From ABR (LSA4)	ASBR	Redistribution Cost
1	E1	22	192.168.121.2	1	1	192.168.61.8	20
2	E1	22	192.168.121.2	1	64	192.168.62.8	20
3	N1	30	192.168.161.6		10	192.168.161.6	20
4	N1	84	192.168.162.6		64	192.168.162.6	20
5	E1	85	192.168.122.2	64	64	192.168.62.8	20
***	N2	20	192.168.163.7		1	192.168.163.7	20
6	N2	20	192.168.164.7		64	192.168.164.7	20
7	E2	83	192.168.131.3	1	62	192.168.63.9	20
8	E2	83	192.168.131.3	1	64	192.168.64.9	20
9	E2	83	192.168.132.3	64	64	192.168.64.9	20

*** During the automatic testing the link from R1 to R2 (192.168.167) was unstable, so R1 RIB didn’t take it into account. But, theoretically it should be there.

Results:

Obviously OSPF consider type1 before type2 as indicated by RFC2328 (http://www.ietf.org/rfc/rfc2328.txt)

… There are four possible types of paths used to route traffic to the destination, listed here in decreasing order of preference: intra-area, inter-area, type 1 external or type 2 external. …

Knowing that type 1 cost is equal to the total cost of the route (redistribution cost + cost inside OSPF domain), OSPF does not differentiate between external routes from regular areas and NSSA areas. The one with the lowest total cost wins (N1 and E1 in table1).

Lab1 verification commands

Lab1 offline

Lab2 (All E2)

Lab2 topology

According to lab1 results, though the cost of type 2 route is equal to the cost of the redistribution, it looks like among routes with the same cost OSPF considers other criteria.

Let’s consider a separated lab to compare routes with the same redistribution cost but different combinations of (cost to ABR + cost to ASBR).

Table2: Lab2 (All E2)

Case	Route type	Route cost	Next-hop	Cost to ABR	Cost to ASBR From ABR (LSA4)	Redistribution Cost
1	E2	20	192.168.163.7	1	1	20
2	E2	20	192.168.162.6	64	1	20
	E2	20	192.168.131.3	1	64	20
3	E2	20	192.168.122.2	64	64	20

Results:

According to the table, even though E2 cost is equal to the cost of redistribution, among routes with the same cost, OSPF consider the total cost as the tie breaker.

E2 selection process: Redistribution cost Total cost Multiple path installed

Lab2 verification commands

Lab2 offline

Lab3 (All E1)

Lab3 topology

Table3: Lab3 (All E1)

Case	Route type	Route cost	Next-hop	Cost to ABR	Cost to ASBR From ABR (LSA4)	Redistribution Cost
1	E1	148	192.168.163.7	1	1	146
	E1	148	192.168.162.6	64	1	83
	E1	148	192.168.131.3	1	64	83
	E1	148	192.168.122.2	64	64	20

Results

For E1 routes, it looks like nothing counts but the total cost.

Lab3 verification commands

Lab3 offline

Conclusion

According to lab results, OSPF external route selection process works as follow:

External routes type 1: Lowest total cost Multipath External routes type 2: Redistribution cost Total cost Multipath

Administrative Distance, prefix length, metric… Who is the winner?

• The Concept
  
• Procedural tasks
  
• Result table
  
• Conclusion
  

The concept

The idea of the lab is to test the RIB best route election criteria of a border router. To do so, four overlapping subnets are configured in different parts of the network and available to a border router through different routing protocols. One of them is directly connected.

All prefixes are made available and reachable in the same time to see who is going to be elected as best route, then remove the winner from the competition by making the corresponding path unavailable and iterate the selection process until the last path.

One directly connected segment and three routing protocols, so four administrative distances: directly connected (AD=0), RIP(AD=120),OSPF(AD=110) and EIGRP internal(AD=90).

Each protocol has two unequal paths (different metrics) to reach the same prefix.

Prefix masks are configured to be inversely proportional to routing protocol administrative distances.

Lab topology

Procedural tasks

For each test case, the routing table is checked for the best route, a trace route to check the path and make the winner path unavailable.

Result table

Classification	Mask length	metric	AD	prefix	Path	Routing protocol
4	28	110	110	192.168.1.64	A	OSPF
3		74		192.168.1.64	B
1	29	1	120	192.168.1.64	C	RIP
2		2		192.168.1.64	D
6	27	32195456	90	192.168.1.64	E	EIGRP
5		2195456		192.168.1.64	F
7	26	0	0	192.168.1.64	G	- Directly connected

RIB looks at the mask length first. The directly connected prefix with the shortest mask length is considered last as the longer the mask, the more accurate the prefix.

Conclusion

With the same prefix and different mask lengths, the border router considers the following criteria in order of preference:

1. Longest mask among all routing protocols
2. Lowest cost with the same routing protocol

IPv6 over AToM pseudowire

The purpose of this lab is to show the flexibility of Layer2 VPN technology AToM (Any Transport over MPLS), which allows service providers to smoothly transit the core network from legacy layer2 technologies into a single MPLS infrastructure ready for customer IPv6 transport.

Customer transition from IPv4 to dual stack is as easy as adding an IPv6 configuration to a point-to-point segment.

The lab is organized as follow:

• Lab topology overview
  
• MPLS Core
  
• Pseudowire circuit establishment over MPLS
  
• Customer configuration
  
• MTU
  
• Offline Lab
  
• Quiz
  
• Conclusion
  

Lab topology overview

Let’s consider the following lab topology: one core MPLS and three customers. Customer1 uses Ethernet port-to-port layer2 circuit to connect to Provider Edge access router, Customer2 uses Ethernet VLAN layer2 circuit and customer3 uses Frame Relay layer2 circuit.

Picture1: High-level Lab topology

Picture2: Low-level Lab topology

MPLS Core

The MPLS core is configured independently from any pseudowire configuration.

Picture3: MPLS core

In the core MPLS, there is practically nothing special to do. IGP and LDP configuration is straightforward. The goal is to guarantee core stability.

Make sure LDP router id is forced to a loopback interface.

 

Pseudowire circuit establishment over MPLS

Picture4: AToM Pseudowire establishment

The configuration to establish the different pseudowires do not depend on client configuration.

Note for each virtual circuit a directed LDP session is established between PEs connecting customer sites. Each PE uses a /32 loopback IP.

Layer2 Circuit	PE2	PE1
Port-to-port	interface FastEthernet0/0 no cdp enable xconnect 22.2.2.2 24 encapsulation mpls	interface FastEthernet0/0 no cdp enable xconnect 44.4.4.4 24 encapsulation mpls

Layer2 Circuit	PE2	PE1
Vlan	interface FastEthernet1/0 no cdp enable ! interface FastEthernet1/0.10 encapsulation dot1Q 10 xconnect 22.2.2.2 242 encapsulation mpls	interface FastEthernet1/0 no cdp enable ! interface FastEthernet1/0.10 encapsulation dot1Q 10 xconnect 44.4.4.4 242 encapsulation mpls

Layer2 Circuit	PE2	PE1
FR	connect fratom Serial2/0 501 l2transport xconnect 22.2.2.2 241 encapsulation mpls ! interface Serial2/0 encapsulation frame-relay frame-relay lmi-type cisco frame-relay intf-type dce	connect fratom Serial2/0 105 l2transport xconnect 44.4.4.4 241 encapsulation mpls ! interface Serial2/0 encapsulation frame-relay frame-relay lmi-type cisco frame-relay intf-type dce

Now, let’s take the east side as example of configuration between clients and the provider edge

Customer configuration

Picture5: Customer circuits

Note the provider edge is configured independently of the client layer3 protocol IPv4/IPv6.

Customer devices are configured in dual stack.

Ethernet port-to-port pseudowire

	East C1	PE1
IPv4	interface FastEthernet0/0 ip address 192.168.15.1 255.255.255.0 ip ospf 15 area 0	interface FastEthernet0/0 no cdp enable xconnect 44.4.4.4 24 encapsulation mpls
IPv6	interface FastEthernet0/0 ipv6 address FE80::15:5 link-local ipv6 address 2001:DB8:15::5/64 ipv6 ospf 15 area 0

Ethernet vlan pseudowire

	East C3		PE1
IPv4	interface Vlan10 ip address 192.168.152.1 255.255.255.0 ip ospf 15 area 0	interface FastEthernet1/0 switchport access vlan 10 switchport mode trunk	interface FastEthernet1/0 no cdp enable ! interface FastEthernet1/0.10 encapsulation dot1Q 10 xconnect 44.4.4.4 242 encapsulation mpls
IPv6	interface Vlan10 ipv6 address FE80::152:1 link-local ipv6 address 2001:DB8:152::1/64 ipv6 ospf 15 area 0

Use sub-interface on PE and disable CDP on the main interface.

FR pseudowire

	East C2	PE1
IPv4	interface Serial1/0 ip address 192.168.151.1 255.255.255.0 encapsulation frame-relay ip ospf network broadcast frame-relay interface-dlci 105	connect fratom Serial2/0 105 l2transport xconnect 44.4.4.4 241 encapsulation mpls ! interface Serial2/0 encapsulation frame-relay clock rate 2016000 frame-relay lmi-type cisco frame-relay intf-type dce
IPv6	interface Serial1/0 encapsulation frame-relay ipv6 address FE80::151:5 link-local ipv6 address 2001:DB8:151::5/64 ipv6 enable ipv6 ospf network broadcast ipv6 ospf 15 area 0 frame-relay map ipv6 FE80::151:1 105 frame-relay map ipv6 2001:DB8:151::1 105 broadcast

For the west side the client configuration is mirrored.

The offline lab provides a complete access to outcomes of large range of commands related to AToM.

The resulting virtual topology looks as follow, typical point-to-point circuits between client devices:

Picture6: Logical connections

MTU

Let’s analyse the path for each type of AToM:

• VC label (identify the pseudowire) = 4 bytes

• LDP Core switching label = 4 bytes

• AToM header for Ethernet = 4 bytes (empty)

• AToM header for Frame Relay = 4 bytes
• Ethernet port-to-port = 14 bytes
• Ethernet VLAN = 14 bytes (Ethernet port-to-port) + 4 bytes (VLAN tag) = 18 bytes
• Frame Relay encapsulation (Cisco) = 2 bytes.

Ethernet port-to-port AToM

Edge MTU	AToM header for Ethernet	Ethernet port-to-port	LDP Core switching label	VC label
1500	4 (empty)	14	4	4	1526 bytes

Ethernet VLAN AToM

Edge MTU	AToM header for Ethernet	Ethernet VLAN	LDP Core switching label	VC label
1500	4 (empty)	18	4	4	1530 bytes

FR AToM

Edge MTU	AToM header for FR	FR encapsulation	LDP Core switching label	VC label
1500	4	2	4	4	1514 bytes

Let’s set Max calculated MTU as Interface MTU of P/PE routers

On PE1 (Fa0/1), PE2 (FA0/1) and P (Fa0/0, Fa0/1)

(config-if)# mtu 1530

#sh int fa1/0 | i MTU MTU 1530 bytes, BW 100000 Kbit/sec, DLY 100 usec, #

MPLS MTU <= Core interfaces MTU

It is very important to distinguish IOS commands for setting MTU:

Hardware MTU

(config-if)# mtu <>: The maximum packet length the interface can support.

IP MTU

(config-if)# ip mtu <>: The maximum size of a non-labelled IP packet without fragmentation.

MPLS MTU

(config-if)# mpls mtu <>: The maximum size of a labelled IP packet without fragmentation (<= Hardware MTU).

Ivan Pepelnjak provides an excellent article about the difference between different MTU commands.

PE2#sh mpls int fa0/1 detail Interface FastEthernet0/1: IP labeling enabled (ldp): Interface config LSP Tunnel labeling not enabled BGP labeling not enabled MPLS operational MTU = 1500 PE2#

Testing end-to-end MTU

Note: Lab limitation

This lab was performed on GNS3 and I had some difficulties building MPLS core using C7200 platform with IOS 12.4(24) as P router. 3700 platform IOS doesn’t allow me to change Hardware MTU.

So the following test is done considering the maximum MTU through MPLS core of 1500 bytes.

The ping test is performed on a client site using EoMPLS VLAN to test the MTU limit

WestC3#ping Protocol [ip]: ipv6 Target IPv6 address: 2001:db8:52::1 Repeat count [5]: Datagram size [100]: 1400 Timeout in seconds [2]: Extended commands? [no]: yes Source address or interface: 2001:db8:12::1 UDP protocol? [no]: Verbose? [no]: Precedence [0]: DSCP [0]: Include hop by hop option? [no]: Include destination option? [no]: Sweep range of sizes? [no]: yes Sweep min size [1400]: Sweep max size [18024]: 1530 Sweep interval [1]: 4 Type escape sequence to abort. Sending 165, [1400..1530]-byte ICMP Echos to 2001:DB8:52::1, timeout is 2 seconds: Packet sent with a source address of 2001:DB8:12::1 !!!!!!!!!!!!!!!!C!. (size 1472) . (size 1476) . (size 1480) . (size 1484) . (size 1488) . (size 1492) . (size 1496) . (size 1500) . (size 1504) . (size 1508) . (size 1512) . (size 1516) . (size 1520) . (size 1524) . (size 1528) … <output omitted> Success rate is 53 percent (88/165), round-trip min/avg/max = 28/136/344 ms WestC3#

Note that ping fails starting from a packet size of 1472.

EoMPLS VLAN pseudowire adds 30 bytes to 1472 bytes which makes the packet bigger than 1500 bytes (lab max MTU limitation).

In fact, beyond the configured MTU on the core MPLS there is an implicit 18 bytes of the underlying Ethernet.

Following an illustrating hopefully clarifies the relationship between different MTUs:

Interactive illustration of Wireshark captured MPLS core transport packet

Offline Lab

Quiz

Conclusion

• AToM pseudowires are configured independently of IPv4/IPv6, which makes the client transition from IPv4 to IPv6 transparent.
• From the client point of view it is a directly connected point-to-point circuit.
• Make sure MPLS core interfaces MTU are configured with the maximum packet size and the MPLS MTU is not bigger that interface hardware MTU to avoid unnecessary fragmentation.

6VPE (IPv6 VPN Provider Edge Router)

6VPE is an easy solution to connect IPv6 customers through an existing stable IPv4 MPLS infrastructure.

All clients have to do is to connect to a Provider Edge (configured with IPv6 VRFs) using IPv6.

I hope this post will provide you with a brief and concise explanation about 6VPE.

Let’s start with a short animation resuming the 6VPE forwarding process:

Following the main configuration steps.

Lab topology

Core IGP

For the sake of backbone stability, we need to configure the Core IGP (OSPF) to use loopback interfaces (always UP/UP) on all P and PE routers. {2.2.2.2, 3.3.3.3, 4.4.4.4}

22.2.2.2, 33.3.3.3, 44.4.4.4 loopback interfaces are used for MPLS router-id and need to be advertised through Core OSPF.

22.22.2.2, 44.4.4.4 loopback interfaces are used for MP-iBGP neighbor relationships and need to be advertised through Core OSPF.

By default OSPF will not advertise a 32-bit loopback mask. We need to configure the interface to be an OSPF network type point-to-point. For more details refer to this post…

6VPE2

interface Loopback0 ip address 4.4.4.4 255.255.255.255 ! ! interface Loopback2 ip address 44.4.4.4 255.255.255.0 ! ! interface Loopback3 ip address 44.44.4.4 255.255.255.255 ip ospf network point-to-point ! router ospf 234 router-id 4.4.4.4 network 44.4.4.4 0.0.0.0 area 0 network 44.44.4.4 0.0.0.0 area 0 network 192.0.0.0 0.255.255.255 area 0

Core

interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! router ospf 234 router-id 3.3.3.3 network 33.3.3.3 0.0.0.0 area 0 network 192.0.0.0 0.255.255.255 area 0

6VPE1

interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! ! interface Loopback2 ip address 22.2.2.2 255.255.255.255 ! ! interface Loopback3 ip address 22.22.2.2 255.255.255.255 ip ospf network point-to-point ! mpls ldp router-id Loopback2 force ! router ospf 234 router-id 2.2.2.2 network 22.2.2.2 0.0.0.0 area 0 network 22.22.2.2 0.0.0.0 area 0 network 192.0.0.0 0.255.255.255 area 0

MPLS-LDP

MPLS-LDP establishes back-to-back sessions for label exchange in the control plane and label swapping in the forwarding plane.

Just configure MPLS LDP the appropriate interfaces and force a loopback interface for MPLS LDP router-id.

Core

interface FastEthernet0/0 ip address 192.168.23.3 255.255.255.0 mpls label protocol ldp mpls ip ! interface FastEthernet0/1 ip address 192.168.34.3 255.255.255.0 mpls label protocol ldp mpls ip ! mpls ldp router-id Loopback2 force

6VPE1

interface FastEthernet1/0 ip address 192.168.23.2 255.255.255.0 mpls label protocol ldp mpls ip ! mpls ldp router-id Loopback2 force

6VPE2

interface FastEthernet1/0 ip address 192.168.34.4 255.255.255.0 mpls label protocol ldp mpls ip ! mpls ldp router-id Loopback2 force

Provider Edge VRFs

Make sure IPv6 routing and IPv6 CEF are enabled.

6VPE1

vrf definition west-c1 rd 100:100 ! address-family ipv6 route-target export 100:100 route-target import 100:100 exit-address-family

interface FastEthernet0/0 vrf forwarding west-c1 ipv6 address FE80::12:2 link-local ipv6 address 2001:DB8:12::2/64

router bgp 65234 no synchronization bgp router-id 22.2.2.2 bgp log-neighbor-changes ! address-family ipv6 vrf west-c1 redistribute connected no synchronization neighbor 2001:DB8:12::1 remote-as 65010 neighbor 2001:DB8:12::1 activate exit-address-family

West6

router bgp 65010 bgp router-id 1.1.1.1 bgp log-neighbor-changes neighbor 2001:DB8:12::2 remote-as 65234 ! address-family ipv6 neighbor 2001:DB8:12::2 activate network 2001:DB8:10::/64 network 2001:DB8:12::/64 exit-address-family

6VPE2

vrf definition east-c1 rd 100:100 ! address-family ipv6 route-target export 100:100 route-target import 100:100 exit-address-family

interface FastEthernet0/0 vrf forwarding east-c1 ipv6 address FE80::45:4 link-local ipv6 address 2001:DB8:45::4/64

router bgp 65234 no synchronization bgp router-id 44.4.4.4 bgp log-neighbor-changes ! address-family ipv6 vrf east-c1 redistribute connected no synchronization neighbor 2001:DB8:45::5 remote-as 65050 neighbor 2001:DB8:45::5 activate exit-address-family

Note: With BGP used as customer protocol redistribution is not needed between PE-CE routing protocol (BGP) and MP-BGP

East6

router bgp 65050 bgp router-id 5.5.5.5 bgp log-neighbor-changes neighbor 2001:DB8:45::4 remote-as 65234 ! address-family ipv6 neighbor 2001:DB8:45::4 activate network 2001:DB8:45::/64 network 2001:DB8:50::/64 exit-address-family

Provider Edge-to-Provider Edge VPNv6

To understand the difference between PE-PE and PE-CE interactions, think about the difference between a routing protocol and a routed protocol:

• BGP, OSPF, EIGRP, RIP are routing protocols.
• IPv4, IPv6, IPX, AppleTalk are routed protocol.

So routing protocols exchange routed protocol information. In our particular case:

• PE-CE routing protocol is BGP and PE-CE routed protocol is IPv6.
• PE-PE routing protocol is MP-BGP and PE-PE routed protocol is vpnv6.
• Core routing protocol is OSPF and the routed protocol is IPv4.

Vpnv4 = RD + VRF IPv4 prefix

Vpnv6 = RD + VRF IPv6 prefix

RD (Route Distinguisher) uniquely identifies the VRF on the PE and allows having multiple customer VPNs with overlapping address schemas.

RT is a BGP extended community attribute (need to be enabled) used to control the installation of exchanged routes between PEs into the correct VRF.

PE-PE (MP-BGP) updates containing MP_BGP_NLRI information:

vpnv4 + (BGP attributes+ RT extended attribute) + Label

VPNv6 route exchange (using MP-BGP)

MPLS network autonomous system 65234 transits traffic between customer autonomous systems 65010 and 65040.

In our case all MPLS routers (P and PE) belong to the same AS. Therefore we need to configure next-hop-self on each PE; otherwise customer prefixes will be visible in BGP table with unreachable next-hops.

Another solution is to enable MPLS IP on interfaces facing clients to include them in MPLS updates, then don’t forget to filter LDP(UDP 646),TDP(TCP 711) traffic with the clients .

6VPE1

router bgp 65234 no synchronization bgp router-id 22.2.2.2 neighbor 44.44.4.4 remote-as 65234 neighbor 44.44.4.4 update-source Loopback3 neighbor 44.44.4.4 next-hop-self no auto-summary

The address-family vpnv4 is used to exchange customer IPv4 prefixes between PEs (through IPv4 core)

The address-family vpnv6 is used to exchange customer IPv6 prefixes between PEs (through IPv4 core)

router bgp 65234 address-family vpnv4 neighbor 44.44.4.4 activate neighbor 44.44.4.4 send-community extended exit-address-family ! address-family vpnv6 neighbor 44.44.4.4 activate neighbor 44.44.4.4 send-community extended exit-address-family

6VPE2

router bgp 65234 no synchronization bgp router-id 44.4.4.4 neighbor 22.22.2.2 remote-as 65234 neighbor 22.22.2.2 update-source Loopback3 neighbor 22.22.2.2 next-hop-self no auto-summary

router bgp 65234 address-family vpnv4 neighbor 22.22.2.2 activate neighbor 22.22.2.2 send-community extended exit-address-family ! address-family vpnv6 neighbor 22.22.2.2 activate neighbor 22.22.2.2 send-community extended exit-address-family

And a small QUIZ to check the very basic

The offline lab provides you with more information about the network behavior and its states in different test cases.

An extensive range of commands is provided.

I hope you will find it useful. Suggestions and critics are welcome.

IPv6 BGP synchronization

If you have been dealing with BGP under IOS < 12.0, you know something about BGP synchronization.

This post is driven by three reasons…nostalgia is not one of them : )

1. BGP synchronization illustrates the difference of BGP with the traditional concept of interior routing protocols like OSPF, RIP or EIGRP.
2. With ever-growing transition to IPv6, I wanted to test the concept of synchronization with IPv6.
3. You need to work out your brain muscles and be ready to deal with anything in the CCIE exam where your problem-solving skills will be tested more than your knowledge of best practices.

So let’s brush up our knowledge of the concept with a brief definition of BGP:

BGP is used to advertise NLRI (Network Layer reachability information) between ASs (Autonomous Systems) and it relies on TCP (179) for reliability of the communications. BGP is an attribute-based path-vector protocol.

BGP synchronization states that, if your autonomous system passes traffic from another AS to a third AS (transit), eBGP speaker should not advertise a route before all the routers in your AS have learned about the NLRI via IGP. So BGP will wait until IGP has propagated the route within the AS.

If not done properly, the transit AS will turn into a route black hole.

Here is a small animation illustrating the concept:

Animation

The solution is mutual redistribution of routes between BGP and the IGP.

Nowadays, BGP is running on all routers in autonomous system transit paths, so synchronization is disabled by default.

This allows you to carry fewer routes in your IGP and allow BGP to converge more quickly.

IPv6 configuration

Topology

Router R1:

Redistribution from OSPF TO BGP

router bgp 65012
address-family ipv6 unicast

redistribute ospf 125 route-map RM6_OSPF_TO_BGP match external 2

route-map RM6_OSPF_TO_BGP permit 10 match ipv6 address ACL6_OSPF_TO_BGP ! ipv6 access-list ACL6_OSPF_TO_BGP permit ipv6 2001:db8:209::/64 any log permit ipv6 2001:db8:23::/64 any log

Redistribution from BGP to OSPF

route-map RM6_BGP_TO_OSPF permit 10
match ip address ACL6_BGP_TO_OSPF
!
ip access-list standard ACL6_BGP_TO_OSPF
permit ipv6 2001:db8:14::/64 any log
!
ipv6 router ospf 125

redistribute bgp 65012 subnets route-map RM6_BGP_TO_OSPF

Redistribution from BGP to OSPF

R1# sh ipv6 route
IPv6 Routing Table - 8 entries
…
C   2001:DB8:14::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:14::1/128 [0/0]
via ::, FastEthernet0/1
C   2001:DB8:15::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:15::1/128 [0/0]
via ::, FastEthernet0/0
O   2001:DB8:25::/64 [110/20]
via FE80::15:5, FastEthernet0/0
B   2001:DB8:40::/64 [20/0]
via FE80::14:4, FastEthernet0/1

OE2 2001:DB8:209::/64 [110/1] via FE80::15:5, FastEthernet0/0

L FF00::/8 [0/0] via ::, Null0 R1#

R2:

Redistribution from BGP to OSPF

route-map RM6_BGP_TO_OSPF permit 10
match ipv6 address ACL6_BGP_TO_OSPF
!
ipv6 access-list  ACL6_BGP_TO_OSPF
permit 2001:db8:209::/64 any log
permit 2001:db8:23::/64 any log
!
ipv6 router ospf 125

redistribute bgp 65012 route-map RM6_BGP_TO_OSPF

Redistribution from OSPF to BGP

router bgp 65012
address-family ipv6 unicast

redistribute ospf 125 route-map RM6_OSPF_TO_BGP match external 2

route-map RM6_OSPF_TO_BGP permit 10

match ipv6 address ACL6_OSPF_TO_BGP 

!

ipv6 access-list ACL6_OSPF_TO_BGP permit 2001:db8:14::/64 any log

The presence of prefix 2001:DB8:40::/64 originated in AS 65040 (iBGP administrative distance = 200) in the IGP table (OSPFv3 administrative distance =110) means that the core IGP has synchronized the prefix.

R2#sh bgp ipv6 unicast  2001:DB8:40::/64
BGP routing table entry for 2001:DB8:40::/64, version 4
Paths: (2 available, best #1, table Global-IPv6-Table)
Advertised to update-groups:
1    2
Local
:: from 0.0.0.0 (2.2.2.23)
Origin incomplete, metric 1, localpref 100, weight 32768, valid, sourced, best
65040
2001:DB8:15::1 (metric 20) from 2001:DB8:15::1 (1.1.1.14)
Origin IGP, metric 0, localpref 100, valid, internal,

synchronized

R2#

#R2 sh ipv6 route
IPv6 Routing Table - 8 entries
…
O   2001:DB8:15::/64 [110/20]
via FE80::25:5, FastEthernet0/0
C   2001:DB8:23::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:23::2/128 [0/0]
via ::, FastEthernet0/1
C   2001:DB8:25::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:25::2/128 [0/0]
via ::, FastEthernet0/0

OE2 2001:DB8:40::/64 [110/1]

via FE80::25:5, FastEthernet0/0

B 2001:DB8:209::/64 [20/0]

via FE80::23:3, FastEthernet0/1

L FF00::/8 [0/0]

via ::, Null0

#R2

From R5 core IGP router you can notice that OSPFv3 is synchronized with transit route prefixes from AS 64030 and AS 64040.

R5:

R5#sh ipv6 route
IPv6 Routing Table - 7 entries
…
C   2001:DB8:15::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:15::5/128 [0/0]
via ::, FastEthernet0/0
C   2001:DB8:25::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:25::5/128 [0/0]
via ::, FastEthernet0/1

OE2 2001:DB8:40::/64 [110/1] via FE80::15:1, FastEthernet0/0 OE2 2001:DB8:209::/64 [110/1] via FE80::25:2, FastEthernet0/1

L FF00::/8 [0/0] via ::, Null0 
R5#

Offline lab

With the offline lab you will have an idea about the network behavior its states in different test cases.

An extensive range of commands is provided. Both IPv6 and IPv4 BGP synchronization are configured in the offline lab.

I hope you will find it useful. Suggestions and critics are welcome.

IPv6 Embedded RP

This tutorial treats IPv6 embedded-RP method, how it works and how it can optimize the deployment of IPv6 multicast.