CCIE, the beginning!

January 29, 2010

VRF-Lite as an alternative to VPC

Filed under: Routing protocols — cciethebeginning @ 11:30 am
Tags: VRF-lite

Introduction

Whether it is for a certification purpose or not, especially with new topics you have just learnt, a great amount of practice is needed using real equipments or dynamips/GNS3; very often you will need a couple of end hosts for testing.

You can use VPC or individual routers 26xx or 36xx with generally a low IOS version.

In the first case, it is very limited tools (only simple ping and trace), however in the second case entire router resources reserved just for a couple of connectivity check.

An alternative solution is to take profit of virtualization feature offered by Cisco, called VRF-Lite and build separated virtual routing processes inside a single device to serve as virtual end-devices.

Concept:

- Use a router (+ switch model), a layer3 switch or just a simple router, it depends on the number of end-devices you need and the number of interfaces available on your router.

- Each End-device will have its own VRF (its own Routing process and its interfaces).

- The only limit is the available resources of your real device or host workstation (on which you run dynamips/GNS3).

The main devices you can emulate are:

- Single or multi-interface Stub network or router with either static or IGP routing.

- End-host (with just a static default route).

- Separated layer3 switches (with separated VLANs, interfaces and RIB for routing between VLANs)

I recommend you to keep it as simple as possible, after all the purpose is to help build the framework for your labs.

Picture 1: general concept

Advantages

- No need to map special dynamips interfaces to 3rd party software (All within dynamips/GNS3)

- Advanced ping and trace.

- Flexibility: IOS tools & functionality Available per -VRF (ex: EEM)

Important notes

There are a couple of caveats you should be aware of:

Virtual hosts cannot be reachable through the same dynamic routing process, IGP processes are uniquely configured per-VRF: you cannot configure two separate VRFs to communicate through the same routing process

For example if you use OSPF (100) for one VRF, IOS will not allow you to configure ospf (100) for another VRF. But two different IGP processes in different VRFs can communicate with each other if redistribution is performed in the intermediate network.

Configuration template

IP CEF is required, to deploy VRF.

You can use the following templates to quickly build separated end hosts and stub routers for you topology.

End-host template

!# End-host #######

interface FastEthernet<X/X>

description end-host outbound interface

! Turn Layer2 interface into Layer3 routed interface

no switchport

! vrf only locally significant to separate traffic for each VRF instance

ip vrf forwarding <VRF-name>

! set your own IP according to your topology

ip address X.X.X.X.X <mask>

! For an end-host, a default route is enough

ip route vrf <VRF-name> 0.0.0.0 0.0.0.0 192.168.37.101

Stub router template

!# STUB ROUTER #######
! Emulate STUB network behind your stub router.

! You can configure as many loopback interfaces as you need.

interface Loopback<x>

! vrf only locally significant to separate traffic for each VRF instance.

ip vrf forwarding <VRF-name>

ip address X.X.X.X.X <mask>

interface FastEthernet<X/X>

description end-host outbound interface

! Turn Layer2 interface into Layer3 routed interface

no switchport

! vrf only locally significant to separate traffic for each VRF instance

ip vrf forwarding <VRF-name>

! set your own IP according to your topology

ip address X.X.X.X.X <mask>

! using OSPF as IGP

router ospf <unique_pid> vrf <VRF-name>

! Announce your network(s)

network X.X.X.X.X <wildcard> area <x> ! outbound interface

network X.X.X.X.X <wildcard> area <x> ! directly connected networks (loo interfaces)

! using default static route for a stub network

ip route vrf <VRF-name> 0.0.0.0 0.0.0.0 <next-hop>

Example:

Picture 2: logical topology:

Picture 3: virtual end-devices to deploy

Let’s suppose we have to configure connectivity between hosts “vhostx” as shown in picture2.

Vhost1-host8 can be configured using one single device (picture3)

A c3745 router with NM-16ESW interface module will host six virtual devices.

- vhost1: a stub router announcing the stub network .60.0/24 through OSPF.

- vhost2: vhost3, vhost6 and vhost7 are end-hosts configured with static default routes.

- vhost8: a stub router announcing a stub network and dual-homed to R0 to provide traffic load-sharing .

Picture 3: Physical topology:

To ensure connectivity between OSPF and EIGRP domains, mutual redistributed is performed on R0.

Note that (.37) is not announced in OSPF on R1, so to ensure connectivity with vhost3, OSPF generate a default route that will be propagated to R0 and consequently to EIGRP through redistribution.

Configuration

! CEF required by VRF

ip cef

Vhost1:

ip vrf vhost1

rd 100:100

interface Loopback1

ip vrf forwarding vhost1

ip address 192.168.60.1 255.255.255.0

interface FastEthernet0/1

no switchport

ip vrf forwarding vhost1

ip address 192.168.61.1 255.255.255.0

router ospf 15 vrf vhost1

log-adjacency-changes

network 192.168.60.0 0.0.0.255 area 0

network 192.168.61.0 0.0.0.255 area 0

vhost2:

ip vrf vhost2

rd 200:200

nterface FastEthernet0/2

no switchport

ip vrf forwarding vhost2

ip address 192.168.52.2 255.255.255.0

ip route vrf vhost2 0.0.0.0 0.0.0.0 192.168.52.101

vhost3:

ip vrf vhost3

rd 300:300

interface FastEthernet0/3

no switchport

ip vrf forwarding vhost3

ip address 192.168.37.3 255.255.255.0

ip route vrf vhost3 0.0.0.0 0.0.0.0 192.168.37.101

vhost6:

ip vrf vhost6

rd 600:600

interface FastEthernet0/6

no switchport

ip vrf forwarding vhost6

ip address 192.168.62.6 255.255.255.0

ip route vrf vhost6 0.0.0.0 0.0.0.0 192.168.62.102

vhost7:

ip vrf vhost7

rd 700:700

interface FastEthernet0/7

description host7_l3_interface

no switchport

ip vrf forwarding vhost7

ip address 192.168.73.7 255.255.255.0

ip route vrf vhost7 0.0.0.0 0.0.0.0 192.168.73.102

vhost8 :

ip vrf vhost8

rd 800:800

interface Loopback8

ip vrf forwarding vhost8

ip address 192.168.80.8 255.255.255.0

interface FastEthernet0/8

description host8_l3_interface

no switchport

ip vrf forwarding vhost8

ip address 192.168.84.4 255.255.255.0

interface FastEthernet0/10

no switchport

ip vrf forwarding vhost8

ip address 192.168.85.4 255.255.255.0

router eigrp 10

network 192.168.80.0

network 192.168.84.0 0.0.0.0

network 192.168.85.0 0.0.0.0

maximum-paths 2

no auto-summary

address-family ipv4 vrf vhost8

network 192.168.80.0

network 192.168.84.0

network 192.168.85.0

auto-summary

autonomous-system 1

exit-address-family

Connectivity check

Here some tools to check connectivity between different virtual hosts thoughout the intermediate topology

! ### From vhost1

vhost(tcl)#foreach VAR {

+>192.168.61.1

+>192.168.52.2

+>192.168.37.3

+>192.168.62.6

+>192.168.73.7

+>192.168.84.4

+> } { puts [exec "trace vrf vhost1 $VAR"] }

Type escape sequence to abort.

Tracing the route to 192.168.61.1

1 192.168.61.1 4 msec * 4 msec

Type escape sequence to abort.

Tracing the route to 192.168.52.2

1 192.168.61.101 28 msec 24 msec 16 msec

2 192.168.52.2 16 msec * 20 msec

Type escape sequence to abort.

Tracing the route to 192.168.37.3

1 192.168.61.101 48 msec 28 msec 8 msec

2 192.168.37.3 16 msec * 24 msec

Type escape sequence to abort.

Tracing the route to 192.168.62.6

1 192.168.61.101 40 msec 36 msec 40 msec

2 192.168.10.10 20 msec 24 msec 16 msec

3 192.168.62.6 20 msec * 40 msec

Type escape sequence to abort.

Tracing the route to 192.168.73.7

1 192.168.61.101 48 msec 28 msec 4 msec

2 192.168.10.10 20 msec 20 msec 12 msec

3 192.168.73.7 24 msec * 68 msec

Type escape sequence to abort.

Tracing the route to 192.168.84.4

1 192.168.61.101 44 msec 12 msec 8 msec

2 192.168.10.10 56 msec 16 msec 12 msec

3 192.168.84.4 20 msec * 60 msec

vhost(tcl)#

Note that, though the source and the destination are inside vhost; trace traffic is forwarded to the intermediate topology and from there to the destination virtual hostx

Separate Routing tables:

vhost#tclsh

vhost#foreach VAR {

+>vhost1

+>vhost2

+>vhost3

+>vhost6

+>vhost7

+>vhost8

+> } { puts [exec "show ip route vrf $VAR | b Gateway"] }

Gateway of last resort is 192.168.61.101 to network 0.0.0.0

O 192.168.73.0/24 [110/3] via 192.168.61.101, 00:55:40, FastEthernet0/1

O 192.168.62.0/24 [110/3] via 192.168.61.101, 00:55:40, FastEthernet0/1

C 192.168.61.0/24 is directly connected, FastEthernet0/1

C 192.168.60.0/24 is directly connected, Loopback1

O 192.168.10.0/24 [110/2] via 192.168.61.101, 00:55:40, FastEthernet0/1

O E2 192.168.80.0/24 [110/20] via 192.168.61.101, 00:55:40, FastEthernet0/1

O 192.168.52.0/24 [110/2] via 192.168.61.101, 00:55:40, FastEthernet0/1

O E2 192.168.85.0/24 [110/20] via 192.168.61.101, 00:55:40, FastEthernet0/1

O E2 192.168.84.0/24 [110/20] via 192.168.61.101, 00:55:40, FastEthernet0/1

O*E2 0.0.0.0/0 [110/1] via 192.168.61.101, 00:55:40, FastEthernet0/1

Gateway of last resort is 192.168.52.101 to network 0.0.0.0

C 192.168.52.0/24 is directly connected, FastEthernet0/2

S* 0.0.0.0/0 [1/0] via 192.168.52.101

Gateway of last resort is 192.168.37.101 to network 0.0.0.0

C 192.168.37.0/24 is directly connected, FastEthernet0/3

S* 0.0.0.0/0 [1/0] via 192.168.37.101

Gateway of last resort is 192.168.62.102 to network 0.0.0.0

C 192.168.62.0/24 is directly connected, FastEthernet0/6

S* 0.0.0.0/0 [1/0] via 192.168.62.102

Gateway of last resort is 192.168.73.102 to network 0.0.0.0

C 192.168.73.0/24 is directly connected, FastEthernet0/7

S* 0.0.0.0/0 [1/0] via 192.168.73.102

Gateway of last resort is 192.168.85.102 to network 0.0.0.0

D EX 192.168.73.0/24

[170/1711616] via 192.168.85.102, 00:56:30, FastEthernet0/10

[170/1711616] via 192.168.84.102, 00:56:30, FastEthernet0/8

D EX 192.168.62.0/24

[170/1711616] via 192.168.85.102, 00:56:30, FastEthernet0/10

[170/1711616] via 192.168.84.102, 00:56:30, FastEthernet0/8

D EX 192.168.61.0/24

[170/1711616] via 192.168.85.102, 00:55:59, FastEthernet0/10

[170/1711616] via 192.168.84.102, 00:55:59, FastEthernet0/8

192.168.60.0/32 is subnetted, 1 subnets

D EX 192.168.60.1

[170/1711616] via 192.168.85.102, 00:55:49, FastEthernet0/10

[170/1711616] via 192.168.84.102, 00:55:49, FastEthernet0/8

D EX 192.168.10.0/24

[170/1711616] via 192.168.85.102, 00:56:30, FastEthernet0/10

[170/1711616] via 192.168.84.102, 00:56:30, FastEthernet0/8

C 192.168.80.0/24 is directly connected, Loopback8

D EX 192.168.52.0/24

[170/1711616] via 192.168.85.102, 00:55:59, FastEthernet0/10

[170/1711616] via 192.168.84.102, 00:55:59, FastEthernet0/8

C 192.168.85.0/24 is directly connected, FastEthernet0/10

C 192.168.84.0/24 is directly connected, FastEthernet0/8

D*EX 0.0.0.0/0 [170/1711616] via 192.168.85.102, 00:55:59, FastEthernet0/10

[170/1711616] via 192.168.84.102, 00:55:59, FastEthernet0/8

vhost#

Summary:

We can think of it as a reduced model of “Iaas” (Infrastructure as a Service), where” you” provide virtual end-devices as a service to yourself for labbing p-)

Leave a Comment

November 20, 2009

Interactive BGP troubleshooting

Filed under: BGP, troubleshooting — cciethebeginning @ 11:04 am
Tags: BGP, troubleshooting

As you probably know, one of the major changes in CCIE R&S (4.0) is the troubleshooting section, 10 tickets to troubleshoot in 2 hours, a new challenge to face for CCIE candidates,

Of course troubleshooting has always been an inherent part of the exam, which depends on the task difficulty, the candidate level of preparation and personal experience.

Less experienced or not very prepared candidates will have heuristic oriented approach to troubleshooting: using “trial and error”, rely more on “show running-config” and the memory of how the configuration “should look like”.

More experienced and well prepared candidates, will rely more on systematic and organized approach: analysis of configuration parameters and an accurate interpretation of the appropriate “show “commands.

So the idea of this post, inspired from the comprehensive, but not very comfortable to read (at least for me:-P) ) BGP troubleshooting flowchart of Cisco (picture1). A regular usage of such approach will help acquire and consolidate a systematic method of troubleshooting.

Picture1

I turned the flowchart into an interactive flash (picture2) using Adobe Captivate, I hope making it easier and more comfortable to read. (click picture2 to browse it)

Picture2

I hosted the “swf” at a third-party site, because unfortunately wordpress doesn’tb allow them, you can also download it to browse offline

Of course, it is subject to changes and modifications, so please don’t hesitate to leave your comments and suggestions.

A similar work for OSPF, EIGRP, MPLS, MPLS VPN troubleshooting will follow.

Leave a Comment

July 27, 2009

Ipv6 NAT-PT Transition

Filed under: IPv6, Uncategorized — cciethebeginning @ 6:09 pm
Tags: IPv6, NAT-PT

NAT-PT method allow IPv6 ONLY nodes to communicate with IPv4 ONLY nodes or vice versa, a sort of gateway for IPv4/IPv6 networks, so dual stack is needed ONLY the NAT-PT device.

This Transition method can be a good solution when IPv6 will be the predominant connectivity type with a need to connect to specific IPv4 nodes in their way to die out.

Depending on your needs you can use NAT-PT in four different ways (similar to NAT for IPv4):

- Static NAT-PT.

- Dynamic NAT-PT.

- PAT overload.

- IPv4-mapped.

Also an example of NAT-PT with ALG (Application Layer Gateway) is provided.

In this lab, IPv6 site is communicating with specific IPv4 nodes from IPv4 site (except for IPv4-mapped NAT-prefix)

Figure 1 illustrate the Lab topology used to test each of the previously mentioned NAT-PT methods.

Figure 1 Topology:

So if you have an internal IPv6-only network, and you want to communicate with the outside world (IPv4-ONLY), all hosts will see the outside world as IPv6; also the outside world will have no idea about what is happening inside (figure 2,3).

Both networks route their traffic to the Border router (NAT gateway) supporting dual-stack, where translation from IPv6 to IPv4 and IPv4 to IPv6 will be performed.

Figure 2: The network as seen from IPv4 side.

Figure 3: The network as seen from IPv6 side

The key concept in Translation is how the IPv6 site will see IPv4 nodes, and how IPv4 site will see IPv6 nodes (figure2 & 3)

STATIC NAT-PT

Table 1 :v6v4 Address translation

*v6v4*	*IPv6 network* IPv6	*IPv6 nodes as seen by IPv4 network*	IPv4
	2001:a:b:c::1/64	====> will be seen as	192.168.40.1
	2001:a:b:c::2/64	====> will be seen as	192.168.40.2
	2001:a:b:c::3/64	====> will be seen as	192.168.40.3

So any traffic originated from 2001:a:b:c::
will trigger v6v4 operations. (figure4)

The prefix 2001:a:b:c:: represent IPv6 address scheme inside IPv6 site.

Table 2 :v4v6 Address translation

v4v6

IPv4 node

IPv4 nodes as seen by IPv6 network

IPv6 network

IPv6

192.168.40.200

====> will be seen as

2001::c018:28c8/96

c018:28c8 Is the representation of IPv4 address in Hexadecimal.

The prefix 2001::/96

is called NAT-PT prefix and represent IPv6 address prefix reserved for IPv4 nodes from the IPv4 site as seen from the IPv6 site, it could be part of the IPv6 site address scheme or a different prefix allocated from the ISP for the subject in matter.

Any IPv4 node will be represented inside IPv6 site as <NAT-PT-prefix>::<IPv4-in-hex>

So any traffic destined to an IPv6 address with <NAT-PT-prefix> will trigger v4v6 operations. (figure4)

As mentioned earlier, IPv6 site is communicating with specific IPv4 nodes from IPv4 site (except for IPv4-mapped NAT-prefix).

Figure 4: v6v4 & v4v6 operations

Static NAT-PT:

!! This is the IPv6 side interface

interface FastEthernet0/0

no ip address

ipv6 address 2001:A:B:C::4/64

!! Enable IPv6 NAT

ipv6 nat

!! This is the IPv4 side interface

interface FastEthernet1/0

ip address 192.168.40.199 255.255.255.0

!! Enable IPv6 NAT

ipv6 nat

!! any IPv6 packet with destination 2001::c0a8:28c8 will be translated to an IPv4 destination !!192.168.40.200

ipv6 nat v4v6 source 192.168.40.200 2001::C0A8:28C8

!! any IPv6 packet with IPv6 source address 2001:a:b:c:X with X=1,2,3 will be translated to an IPv4 source address 192.168.40.X with X=1,2,3 respectively.

ipv6 nat v6v4 source 2001:A:B:C::1 192.168.40.1

ipv6 nat v6v4 source 2001:A:B:C::2 192.168.40.2

ipv6 nat v6v4 source 2001:A:B:C::3 192.168.40.3

!! IPv6 prefix 2001::/96 is allocated to represent IPv4 addresses in IPv6 format and will be inspected by NAT-PT otherwise dropped

ipv6 nat prefix 2001::/96

connectivity check:

Routerv6_1#ping 2001::C0A8:28C8 repeat 3

Type escape sequence to abort.

Sending 3, 100-byte ICMP Echos to 2001::C0A8:28C8, timeout is 2 seconds:

!!!

Success rate is 100 percent (3/3), round-trip min/avg/max = 72/80/88 ms

Routerv6_1#

Routerv6_2#ping 2001::C0A8:28C8 repeat 3

Type escape sequence to abort.

Sending 3, 100-byte ICMP Echos to 2001::C0A8:28C8, timeout is 2 seconds:

!!!

Success rate is 100 percent (3/3), round-trip min/avg/max = 60/125/164 ms

Routerv6_2#

Routerv6_3#ping 2001::C0A8:28C8 repeat 3

Type escape sequence to abort.

Sending 3, 100-byte ICMP Echos to 2001::C0A8:28C8, timeout is 2 seconds:

!!!

Success rate is 100 percent (3/3), round-trip min/avg/max = 88/134/208 ms

Routerv6_3#

Each traffic from each IPv6 host is translated according to the configured static NAT-PT

NAT-PT#

*Mar 1 04:18:57.446: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.1), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:18:57.502: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.1) -> (2001:A:B:C::1)

*Mar 1 04:18:57.554: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.1), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:18:57.634: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.1) -> (2001:A:B:C::1)

*Mar 1 04:18:57.662: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.1), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:18:57.682: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.1) -> (2001:A:B:C::1)

NAT-PT#

NAT-PT(config)#

*Mar 1 04:25:50.854: IPv6 NAT: icmp src (2001:A:B:C::2) -> (192.168.40.2), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:25:50.962: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.2) -> (2001:A:B:C::2)

*Mar 1 04:25:51.022: IPv6 NAT: icmp src (2001:A:B:C::2) -> (192.168.40.2), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:25:51.038: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.2) -> (2001:A:B:C::2)

*Mar 1 04:25:51.086: IPv6 NAT: icmp src (2001:A:B:C::2) -> (192.168.40.2), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:25:51.178: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.2) -> (2001:A:B:C::2)

NAT-PT(config)#

*Mar 1 04:26:13.274: IPv6 NAT: icmp src (2001:A:B:C::3) -> (192.168.40.3), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:26:13.354: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.3) -> (2001:A:B:C::3)

*Mar 1 04:26:13.398: IPv6 NAT: icmp src (2001:A:B:C::3) -> (192.168.40.3), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:26:13.470: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.3) -> (2001:A:B:C::3)

*Mar 1 04:26:13.494: IPv6 NAT: icmp src (2001:A:B:C::3) -> (192.168.40.3), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:26:13.570: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.3) -> (2001:A:B:C::3)

NAT-PT(config)#

NAT-PT#sh ipv6 nat translations

Prot IPv4 source IPv6 source

IPv4 destination IPv6 destination

— — —

192.168.40.200 2001::C0A8:28C8

— 192.168.40.1 2001:A:B:C::1

192.168.40.200 2001::C0A8:28C8

— 192.168.40.1 2001:A:B:C::1

— —

NAT-PT#

DYNAMIC NAT-PT

With Dynamic translation a specific IPv6 prefix will be translated to a pool of IPv4 address as the source address; and the destination is translated to the static v4v6 entry.

Table 3 :v6v4 Address translation

*v6v4*	*IPv6 network* IPv6	*IPv6 nodes as seen by IPv4 network*	IPv4
	Any 2001:a:b:c::/64 node (3 nodes in our case)	====> will be represented by	192.168.40.1
			192.168.40.2
			192.168.40.3

Any traffic originated from 2001:a:b:c::/64
will trigger v6v4 operations.

Because there is 3 IPv6 nodes and 3 IPv4 addresses a one-to-one translation will occur

Table 4 :v4v6 Address translation

v4v6

IPv4 node

IPv4 nodes as seen by IPv6 network

IPv6 network

IPv6

192.168.40.200

====> will be seen as

2001::c018:28c8/96

interface FastEthernet0/0

no ip address

ipv6 address 2001:A:B:C::4/64

ipv6 nat

interface FastEthernet1/0

ip address 192.168.40.199 255.255.255.0

ipv6 nat

ipv6 nat v4v6 source 192.168.40.200 2001::C0A8:28C8

ipv6 nat v6v4 source list list_to-ipv4 pool ipv4_pool

ipv6 nat v6v4 pool ipv4_pool 192.168.40.1 192.168.40.3 prefix-length 24

ipv6 nat prefix 2001::/96

ipv6 access-list list_to-ipv4

permit ipv6 2001:A:B:C::/64 any

Connectivity check:

NAT-PT(config)#do sh ipv6 nat trans

Prot IPv4 source IPv6 source

IPv4 destination IPv6 destination

— — —

192.168.40.200 2001::C0A8:28C8

— 192.168.40.1 2001:A:B:C::1

192.168.40.200 2001::C0A8:28C8

— 192.168.40.1 2001:A:B:C::1

— —

— 192.168.40.2 2001:A:B:C::2

192.168.40.200 2001::C0A8:28C8

— 192.168.40.2 2001:A:B:C::2

— —

— 192.168.40.3 2001:A:B:C::3

192.168.40.200 2001::C0A8:28C8

— 192.168.40.3 2001:A:B:C::3

— —

NAT-PT(config)#

NAT-PT(config)#do sh ipv6 nat stat

Total active translations: 7 (-5 static, 12 dynamic; 0 extended)

NAT-PT interfaces:

FastEthernet0/0, FastEthernet1/0, NVI0

Hits: 0 Misses: 0

Expired translations: 0

NAT-PT(config)#

debug:

NAT-PT(config)#

*Mar 1 04:44:15.454: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.1), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:44:15.586: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.1) -> (2001:A:B:C::1)

*Mar 1 04:44:15.650: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.1), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:44:15.730: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.1) -> (2001:A:B:C::1)

*Mar 1 04:44:15.794: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.1), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:44:15.810: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.1) -> (2001:A:B:C::1)

NAT-PT(config)#

*Mar 1 04:44:29.122: IPv6 NAT: icmp src (2001:A:B:C::2) -> (192.168.40.2), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:44:29.230: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.2) -> (2001:A:B:C::2)

*Mar 1 04:44:29.262: IPv6 NAT: icmp src (2001:A:B:C::2) -> (192.168.40.2), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:44:29.326: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.2) -> (2001:A:B:C::2)

*Mar 1 04:44:29.386: IPv6 NAT: icmp src (2001:A:B:C::2) -> (192.168.40.2), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:44:29.410: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.2) -> (2001:A:B:C::2)

NAT-PT(config)#

*Mar 1 04:44:42.434: IPv6 NAT: icmp src (2001:A:B:C::3) -> (192.168.40.3), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:44:42.514: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.3) -> (2001:A:B:C::3)

*Mar 1 04:44:42.546: IPv6 NAT: icmp src (2001:A:B:C::3) -> (192.168.40.3), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:44:42.574: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.3) -> (2001:A:B:C::3)

*Mar 1 04:44:42.622: IPv6 NAT: icmp src (2001:A:B:C::3) -> (192.168.40.3), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:44:42.678: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.3) -> (2001:A:B:C::3)

NAT-PT(config)#

PAT NAT-PT

Table 5 :v6v4 Address translation

v6v4

IPv6 network

IPv6

IPv6 nodes as seen by IPv4 network

IPv4

Any 2001:a:b:c::/64 node (3 nodes in our case)

====> will be represented by

192.168.40.199

Any traffic originated from 2001:a:b:c::/64
will trigger v6v4 operations. and will be translated to the unique IPv4 outbound interface

Table 6 :v4v6 Address translation

v4v6

IPv4 node

IPv4 nodes as seen by IPv6 network

IPv6 network

IPv6

192.168.40.200

====> will be seen as

2001::c018:28c8/96

We’re still communicating to IPv4 node 192.168.40.200 represented by 2001::c018:28c8/96

By the way, IOS will not allow you to disable configured commands if their corresponding translations are still active, so you have to clear all translation entries before making any changes in the configuration.

NAT-PT(config)#no ipv6 nat v6v4 source list list_to-ipv4 pool ipv4_pool

NAT-PT(config)#$ ipv4_pool 192.168.40.1 192.168.40.3 prefix-length 24

%Pool ipv4_pool in use, cannot destroy

NAT-PT(config)#

*Mar 1 04:56:14.094: %Dynamic mapping in use, cannot remove

NAT-PT(config)#do clear ipv6 nat trans *

NAT-PT(config)#

NAT-PT(config)#no ipv6 nat v6v4 source list list_to-ipv4 pool ipv4_pool

NAT-PT(config)#no ipv4_pool 192.168.40.1 192.168.40.3 prefix-length 24

NAT-PT(config)#

interface FastEthernet0/0

no ip address

ipv6 address 2001:A:B:C::4/64

ipv6 nat

interface FastEthernet1/0

ip address 192.168.40.199 255.255.255.0

ipv6 nat

ipv6 nat v4v6 source 192.168.40.200 2001::C0A8:28C8

ipv6 nat v6v4 source list list_to-ipv4 interface overload

ipv6 nat prefix 2001::/96

ipv6 access-list list_to-ipv4

permit ipv6 2001:A:B:C::/64 any

NAT-PT(config)#do sh ipv6 nat translation

Prot IPv4 source IPv6 source

IPv4 destination IPv6 destination

— — —

192.168.40.200 2001::C0A8:28C8

icmp 192.168.40.199,7704 2001:A:B:C::1,7704

192.168.40.200,7704 2001::C0A8:28C8,7704

icmp 192.168.40.199,7126 2001:A:B:C::2,7126

192.168.40.200,7126 2001::C0A8:28C8,7126

icmp 192.168.40.199,9979 2001:A:B:C::3,9979

192.168.40.200,9979 2001::C0A8:28C8,9979

NAT-PT(config)#

NAT-PT(config)#do sh ipv6 nat stat

Total active translations: 4 (-5 static, 9 dynamic; 3 extended)

NAT-PT interfaces:

FastEthernet0/0, FastEthernet1/0, NVI0

Hits: 0 Misses: 0

Expired translations: 0

NAT-PT(config)#

*Mar 1 04:59:10.218: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:59:10.310: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::1)

*Mar 1 04:59:10.366: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:59:10.418: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::1)

*Mar 1 04:59:10.466: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:59:10.514: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::1)

NAT-PT(config)#

*Mar 1 04:59:20.674: IPv6 NAT: icmp src (2001:A:B:C::2) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:59:20.766: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::2)

*Mar 1 04:59:20.826: IPv6 NAT: icmp src (2001:A:B:C::2) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:59:20.882: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::2)

*Mar 1 04:59:20.918: IPv6 NAT: icmp src (2001:A:B:C::2) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:59:20.950: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::2)

NAT-PT(config)#

*Mar 1 04:59:24.266: IPv6 NAT: icmp src (2001:A:B:C::3) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:59:24.354: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::3)

*Mar 1 04:59:24.402: IPv6 NAT: icmp src (2001:A:B:C::3) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:59:24.450: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::3)

*Mar 1 04:59:24.482: IPv6 NAT: icmp src (2001:A:B:C::3) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 04:59:24.526: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::3)

NAT-PT(config)#

DNS embedded data (ALG)

Let’s keep previously configured PAT and see how NAT-PT handle application layer data like IPv6 addresses embedded in the DNS traffic.

We a need static translation to access the specific IPv4 node (DNS server).

Name lookup is enabled and DNS IPv6 address configured.

NAT-PT:

ipv6 nat v4v6 source 192.168.40.104
2001::C0A8:2858

ip domain lookup

ip domain name nouri.com

ip name-server 2001::C0A8:2858

On Clients:

ip domain lookup

ip domain name nouri.com

ip name-server 2001::C0A8:2858

The following shows successful connectivity with the DNS server:

Routerv6_1#ping 2001::C0A8:2858 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 2001::C0A8:2858, timeout is 2 seconds:

Success rate is 100 percent (1/1), round-trip min/avg/max = 88/88/88 ms

Routerv6_1#

NAT-PT(config)#

*Mar 1 05:37:46.478: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:2858) -> (192.168.40.104)

*Mar 1 05:37:46.586: IPv6 NAT: src (192.168.40.104) -> (2001::C0A8:2858), dst (192.168.40.199) -> (2001:A:B:C::1)

NAT-PT(config)#

Routerv6_1#ping Routerv4_1.nouri.com

Translating “Routerv4_1.nouri.com”…domain server (2001::C0A8:2858) [OK]

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001::C0A8:28C8, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/111/256 ms

Routerv6_1#

Debug:

The NAT device:

receive a DNS request packet with IPv6 source (2001:A:B:C::1) and IPv6 destination (2001::C0A8:2858).

translate the IPv6 src (2001:A:B:C::1) -> IPv4 src (192.168.40.199)

translate the IPv6 dst (2001::C0A8:2858) -> IPv4 dst (192.168.40.104)

send DNS request AAA to IPv4 DNS server with IPv4 src (192.168.40.199) + IPv4 dst (192.168.40.104)

receive DNS response with IPv4 src (192.168.40.104) + IPv4 dst. (192.168.40.199) + embedded response to AAA IPv4 (192.168.40.200)

translate embedded response IPv4 (192.168.40.200) -> IPv6 (2001::C0A8:28C8)

translate back the IPv4 src (192.168.40.104)-> IPv6 src (2001::C0A8:2858)

translate back the IPv4 dst (192.168.40.199) -> IPv6 dst (2001:A:B:C::1)

send DNS response with IPv6 src (2001::C0A8:2858) + IPv6 dst. (2001:A:B:C::1) + embedded response to AAA IPv6 (2001::C0A8:28C8)

Internal IPv6 node:

send ping with IPv6 src (2001:A:B:C::1) + IPv6 dst (2001::C0A8:28C8)

The NAT device:

translate the IPv6 src (2001:A:B:C::1) -> IPv4 src (192.168.40.199)

translate the IPv6 dst (2001::C0A8:28C8) -> IPv4 dst (192.168.40.200)

send ping with IPv4 src (192.168.40.199) + IPv4 dst (192.168.40.200)

receive ping reply with IPv4 src (192.168.40.200) + IPv4 dst. (192.168.40.199)

translate back the IPv4 src (192.168.40.200) -> IPv6 src (2001::C0A8:28C8)

translate back the IPv4 dst (192.168.40.199) -> IPv6 dst (2001:A:B:C::1)

send ping reply with IPv6 src (2001::C0A8:28C8) + IPv6 dst. (2001:A:B:C::1)

NAT-PT(config)#

*Mar 1 05:46:33.854: IPv6 NAT: udp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:2858) -> (192.168.40.104)

*Mar 1 05:46:33.994: IPv6 NAT: udp src (192.168.40.104) -> (2001::C0A8:2858), dst (192.168.40.199) -> (2001:A:B:C::1)

*Mar 1 05:46:34.166: IPv6 NAT: udp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:2858) -> (192.168.40.104)

*Mar 1 05:46:34.230: IPv6 NAT: udp src (192.168.40.104) -> (2001::C0A8:2858), dst (192.168.40.199) -> (2001:A:B:C::1)

*Mar 1 05:46:34.246: IPv6 NAT: udp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:2858) -> (192.168.40.104)

*Mar 1 05:46:34.278: IPv6 NAT: udp src (192.168.40.104) -> (2001::C0A8:2858), dst (192.168.40.199) -> (2001:A:B:C::1)

*Mar 1 05:46:34.322: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 05:46:34.346: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::1)

*Mar 1 05:46:34.442: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 05:46:34.650: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::1)

*Mar 1 05:46:34.726: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 05:46:34.758: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::1)

*Mar 1 05:46:34.774: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 05:46:34.802: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::1)

*Mar 1 05:46:34.818: IPv6 NAT: icmp src (2001:A:B:C::1) -> (192.168.40.199), dst (2001::C0A8:28C8) -> (192.168.40.200)

*Mar 1 05:46:34.834: IPv6 NAT: src (192.168.40.200) -> (2001::C0A8:28C8), dst (192.168.40.199) -> (2001:A:B:C::1)

NAT-PT(config)#

IPv4 MAPPED

So far, we have been dealing with specific IPv4 hosts inside IPv4 network, but what if we just want to make connections to any IPv4 hosts (ex: to Internet)?

In this case the mapping of destination addresses should be automatic, that is the role of IPv4 mapped:

interface FastEthernet0/0

no ip address

ipv6 address 2001:A:B:C::4/64

ipv6 nat

interface FastEthernet1/0

ip address 192.168.40.199 255.255.255.0

ipv6 nat

! DNS still need Translation

ipv6 nat v4v6 source 192.168.40.104 2001::C0A8:2858

! PAT Translation is the appropriate configuration for this case

ipv6 nat v6v4 source list list_to-ipv4 interface FastEthernet1/0 overload

ipv6 nat prefix 2001::/96 v4-mapped WHAT_to_IPv4

ipv6 access-list list_to-ipv4

permit ipv6 2001:A:B:C::/64 any

ipv6 access-list WHAT_to_IPv4

permit ipv6 any 2001::/96

CONCLUSION

IPv6 NAT-PT as with IPv4 NAT represent a single point of failure in the network and cannot support end-to-end security.

Don’t forget that the primary goal is to build a native IPv6 connectivity, so as transition mechanisms it is recommended to use 6to4 tunneling and ONLY as a last resort NAT-PT

Leave a Comment

July 24, 2009

Automatic 6to4 Transition

Filed under: IPv6 — cciethebeginning @ 1:10 am
Tags: 6to4, IPv6

Unfortunately NOT all Internet Service Providers have switched fully to IPv6 and until a native IPv6 connection is provided to your IPv6 site(s) you will have to use some transition methods like automatic 6to4.

Automatic 6to4 is a point-to-multipoint tunneling method, where the tunnel destination is determined from the border router IPv4 address facing the IPv4 network.

a- The border routers that delimit the 6to4 tunnel must support IPv4 and IPv6 and are not configured in pair.

b- Automatic 6to4 can be used to connect two IPv6 networks as well an IPv6 host to an IPv6 network.

c- IPv6 network is treated as NBMA link.

d- The IPv4 embedded in IPv6 is used to find the other end of the tunnel.

e- Border routers create a tunnel on a per packet basis to other IPv6 Border router.

Don’t share the same tunnel source interface between different tunnels, because it is used for de-multiplex incoming packet to tunnel interface.

Each IPv6 site must have a globally unique IPv4.

The IPv6 address format used for this type of transition method is as follow:

2002	<ipv4 address in HEX>	<subnet_part>	Interface ID
16 bits	32 bits	16 bits	64 bits
		The subnet part can be used to number networks within the site

2002:<ipv4 address in HEX>:<subnet_part>:<interface_ID>/64

The configuration commands are quite simple:

ipv6 unicast-routing

interface Tunnel <X>

ipv6 address 2002:<ipv4 address in HEX>:<subnet>:<int_ID>/64

tunnel source <src_int>

tunnel mode ipv6ip 6to4

ipv6 route 0::0/0 Tunnel<X>

Before start configuring, carefully plan your addressing scheme, all ipv6 addresses are based on the IPv4 addresses assigned to physical interfaces of each site facing the IPv4 network.

IPv6 Addresses is done per-site, NOT in pair (between border routers).

Make sure you have successful connectivity between sites through IPv4 network in place.

Because automatic 6to4 handles tunnel interface as point-to-multipoint and all site traffic (IPv6) should be transported over IPv4 network, a static route to the tunnel interface is required.

In this lab three types of media will be treated : Serial HDLC, Ethernet and Frame Relay.

SERIAL:

Figure 1 depicts the topology used for serial connection:

Figure 1: Topology for serial connection

The ipv4 address of 192.168.0.0/24 is used for the link between East IPv6 site and West IPv6 site:

BWest – serial1/0 ipv4 = 192.168.0.1 = c0a8:0001
Best – serial1/0 ipv4 = 192.168.0.2 = c0a8:0002

Addressing scheme for West IPv6 site:

The IPv6 address format used is as follow:

2002:	C0a8:0001:	0001:/48		Subnet used for tunnel ipv6 address at BWest
2002:	C0a8:0001:	0001:	::1/64	BWest tunnel ipv6 address.
2002:	C0a8:0001:	0002:/48		Subnet used for network inside West site.
2002:	C0a8:0001:	0002:	::1	BWest Fa0/0 ipv6 address.
2002:	C0a8:0001:	0002:	::2	Westv6 Fa0/0 ipv6 address.

Addressing scheme for Est IPv6 site:

The IPv6 address format used is as follow:

2002:	C0a8:0002:	0001:/48		Subnet used for tunnel ipv6 address at BEst
2002:	C0a8:0002:	0001:	::1/64	BEst tunnel ipv6 address.
2002:	C0a8:0002:	0002:/48		Subnet used for network inside Est site.
2002:	C0a8:0002:	0002:	::1	BEst Fa0/0 ipv6 address.
2002:	C0a8:0002:	0002:	::2	Estv6 Fa1/0 ipv6 address.

Do not forget to enable ipv6 unicast routing on All IPv6 routers, not like IPv6 routing protocols, the IOS will not warn you if you are using ipv6 static routing with ipv6 routing disabled.

Make sure you have a static route to all 2002::/16 prefix routes pointed to the tunnel interface.

Configuration commands:

BEast:

ipv6 unicast-routing

interface Tunnel1

ipv6 address 2002:C0A8:2:1::1/64

tunnel source Serial1/0

tunnel mode ipv6ip 6to4

interface FastEthernet0/0

ipv6 address 2002:C0A8:2:2::1/64

interface Serial1/0

ip address 192.168.0.2 255.255.255.0

ipv6 route 2002::/16 Tunnel1

Estv6:

ipv6 unicast-routing

interface FastEthernet0/0

ipv6 address 2001:B:B:B::B/64

ipv6 address FE80:B:B:B::B link-local

interface FastEthernet1/0

ipv6 address 2002:C0A8:2:2::2/64

ipv6 route ::/0 2002:C0A8:2:2::1

BWest:

ipv6 unicast-routing

interface Tunnel1

ipv6 address 2002:C0A8:1:1::1/64

tunnel source Serial1/0

tunnel mode ipv6ip 6to4

interface FastEthernet0/0

ipv6 address 2002:C0A8:1:2::1/64

interface Serial1/0

ip address 192.168.0.1 255.255.255.0

ipv6 route 2002::/16 Tunnel1

Westv6

ipv6 unicast-routing

interface FastEthernet0/0

ipv6 address 2002:C0A8:1:2::2/64

ipv6 route ::/0 2002:C0A8:1:1::1

Troubleshooting:

East6:

Eastv6(config)#do ping 2002:c0a8:1:2::2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2002:C0A8:1:2::2, timeout is 2 seconds:

!!!!!

Success rate is 40 percent (2/5), round-trip min/avg/max = 176/182/188 ms

Eastv6(config)#

BEast:

BEast#sh int tunnel 1

Tunnel1 is up, line protocol is up

Hardware is Tunnel

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive not set

Tunnel source 192.168.0.2 (Serial1/0),
destination UNKNOWN

Tunnel protocol/transport IPv6 6to4

Fast tunneling enabled

Tunnel transmit bandwidth 8000 (kbps)

Tunnel receive bandwidth 8000 (kbps)

…

BEast#

Because 6to4 tunnelling is point-to-multipoint, the tunnel destination is not preconfigured “UNKNOWN”.

BEast(config)#do debug tunnel

Tunnel Interface debugging is on

*Mar 1 09:26:48.445: Tunnel1: IPv6/IP to classify 192.168.0.1->192.168.0.2 (len=120 ttl=254 tos=0×0)

*Mar 1 09:26:48.445: Tunnel1: to decaps IPv6/IP packet 192.168.0.1->192.168.0.2 (len=120, ttl=254)

*Mar 1 09:26:48.449: Tunnel1: decapsulated IPv6/IP packet

*Mar 1 09:26:48.449: 2002:C0A8:1:2::2 -> 2002:C0A8:2:2::2 (len=60 ttl=63)

*Mar 1 09:26:50.605: Tunnel1: IPv6/IP to classify 192.168.0.1->192.168.0.2 (len=120 ttl=254 tos=0×0)

*Mar 1 09:26:50.605: Tunnel1: to decaps IPv6/IP packet 192.168.0.1->192.168.0.2 (len=120, ttl=254)

*Mar 1 09:26:50.609: Tunnel1: decapsulated IPv6/IP packet

*Mar 1 09:26:50.609: 2002:C0A8:1:2::2 -> 2002:C0A8:2:2::2 (len=60 ttl=63)

*Mar 1 09:26:52.777: Tunnel1: IPv6/IP to classify 192.168.0.1->192.168.0.2 (len=120 ttl=254 tos=0×0)

*Mar 1 09:26:52.781: Tunnel1: to decaps IPv6/IP packet 192.168.0.1->192.168.0.2 (len=120, ttl=254)

*Mar 1 09:26:52.781: Tunnel1: decapsulated IPv6/IP packet

*Mar 1 09:26:52.781: 2002:C0A8:1:2::2 -> 2002:C0A8:2:2::2 (len=60 ttl=63)

BEast(config)#

ETHERNET:

Another site (North) is added and all sites are connected through an Ethernet switch like illustrated in Figure2.

Figure2: Topology with Ethernet

The previous East and West site address schemas are kept and a new address scheme is designed for North site:

The ipv4 address of 192.168.0.0/24 is used for Ethernet between North, East, and West IPv6 sites:

BNorth – serial1/0 ipv4 = 192.168.0.3 = c0a8:0003

Addressing scheme for North IPv6 site:

The IPv6 address format used is as follow:

2002:	C0a8:0003:	0001:/48		Subnet used for tunnel ipv6 address at BNorth
2002:	C0a8:0003:	0001:	::1/64	BNorth tunnel ipv6 address.
2002:	C0a8:0003:	0002:/48		Subnet used for network inside North site.
2002:	C0a8:0003:	0002:	::1	BNorth Fa0/0 ipv6 address.
2002:	C0a8:0003:	0002:	::2	Northv6 Fa0/0 ipv6 address.

Configuration commands:

As follow the configuration of the North site, practically nothing changed, this time we are just dealing with Ethernet media.

BNorth:

ipv6 unicast-routing

interface Tunnel1

ipv6 address 2002:C0A8:3:1::1/64

tunnel source FastEthernet1/0

tunnel mode ipv6ip 6to4

interface FastEthernet0/0

ipv6 address 2002:C0A8:3:2::1/64

interface FastEthernet1/0

ip address 192.168.0.3 255.255.255.0

ipv6 route 2002::/16 Tunnel1

Northv6:

ipv6 unicast-routing

interface FastEthernet0/0

ipv6 address 2002:C0A8:3:2::2/64

ipv6 route ::/0 2002:C0A8:3:2::1

BWest:

ipv6 unicast-routing

interface Tunnel1

ipv6 address 2002:C0A8:1:1::1/64

tunnel source FastEthernet1/0

tunnel mode ipv6ip 6to4

interface FastEthernet0/0

ipv6 address 2002:C0A8:1:2::1/64

interface FastEthernet1/0

ip address 192.168.0.1 255.255.255.0

ipv6 route 2002::/16 Tunnel1

BEst:

ipv6 unicast-routing

interface Tunnel1

ipv6 address 2002:C0A8:2:1::1/64

tunnel source FastEthernet1/0

tunnel mode ipv6ip 6to4

interface FastEthernet0/0

ipv6 address 2002:C0A8:2:2::1/64

interface FastEthernet1/0

ip address 192.168.0.2 255.255.255.0

ipv6 route 2002::/16 Tunnel1

Troubleshooting

Northv6:

Northv6(config)#do ping 2002:c0a8:1:2::2 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 2002:C0A8:1:2::2, timeout is 2 seconds:

Success rate is 100 percent (1/1), round-trip min/avg/max = 220/220/220 ms

Northv6(config)#do ping 2002:c0a8:2:2::2 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 2002:C0A8:2:2::2, timeout is 2 seconds:

Success rate is 100 percent (1/1), round-trip min/avg/max = 220/220/220 ms

Northv6(config)#

BNorth:

BNorth(config)#do debug tunnel

Tunnel Interface debugging is on

BNorth(config)#

*Mar 1 01:01:13.351: Tunnel1: IPv6/IP to classify 192.168.0.1->192.168.0.3 (len=120 ttl=254 tos=0×0)

*Mar 1 01:01:13.355: Tunnel1: to decaps IPv6/IP packet 192.168.0.1->192.168.0.3 (len=120, ttl=254)

*Mar 1 01:01:13.359: Tunnel1: decapsulated IPv6/IP packet

*Mar 1 01:01:13.359: 2002:C0A8:1:2::2 -> 2002:C0A8:3:2::2 (len=60 ttl=63)

BNorth(config)#

*Mar 1 01:01:32.979: Tunnel1: IPv6/IP to classify 192.168.0.2->192.168.0.3 (len=120 ttl=254 tos=0×0)

*Mar 1 01:01:32.983: Tunnel1: to decaps IPv6/IP packet 192.168.0.2->192.168.0.3 (len=120, ttl=254)

*Mar 1 01:01:32.987: Tunnel1: decapsulated IPv6/IP packet

*Mar 1 01:01:32.987: 2002:C0A8:2:2::2 -> 2002:C0A8:3:2::2 (len=60 ttl=63)

BNorth(config)#

Note that automatic 6to4 determine each time the needed tunnel destination address and send each packet accordingly.

To reach the Eastern isolated IPv6 network it uses the IP packet with addresses 192.168.0.3->192.168.0.2 that encapsulates IPv6 packet 2002:C0A8:3:2::2 -> 2002:C0A8:2:2::2.

To reach the Western isolated IPv6 network it uses the IP packet with addresses 192.168.0.3->192.168.0.1 that encapsulates IPv6 packet 2002:C0A8:3:2::2 -> 2002:C0A8:1:2::2; and what we see in the previous debug is return traffic.

The following trace command output illustrates the different path taken each time to reach different destination tunnel.

Northv6(config)#do trace 2002:c0a8:2:2::2

Type escape sequence to abort.

Tracing the route to 2002:C0A8:2:2::2

1 2002:C0A8:3:2::1 104 msec 32 msec 56 msec

2 2002:C0A8:2:1::1 232 msec 88 msec 120 msec

3 2002:C0A8:2:2::2 280 msec 168 msec 108 msec

Northv6(config)#

Northv6(config)#do trace 2002:c0a8:1:2::2

Type escape sequence to abort.

Tracing the route to 2002:C0A8:1:2::2

1 2002:C0A8:3:2::1 76 msec 24 msec 40 msec

2 2002:C0A8:1:1::1 200 msec 120 msec 64 msec

3 2002:C0A8:1:2::2 216 msec 152 msec 124 msec

Northv6(config)#

FR NBMA point-to-multipoint(figure3):

The same thing here, except for the FR Connectivity with point-multipoint there is no change to 6to4 configuration, first make sure that FR connectivity is successful and then you can set the 6to4 transition method using the interface ipv4.

Figure3: Topology FR

FR configuration commands:

BNorth:

interface Serial1/0

no ip address

encapsulation frame-relay

serial restart-delay 0

interface Serial1/0.123 multipoint

ip address 192.168.0.3 255.255.255.0

frame-relay map ip 192.168.0.1 102 broadcast

frame-relay map ip 192.168.0.2 101 broadcast

BNorth(config-if)#do sh frame map

Serial1/0.123 (up): ip 192.168.0.1 dlci 102(0×66,0×1860), static,

broadcast,

CISCO, status defined, active

Serial1/0.123 (up): ip 192.168.0.2 dlci 101(0×65,0×1850), static,

broadcast,

CISCO, status defined, active

BNorth(config-if)#

BEast:

interface Serial1/0

no ip address

encapsulation frame-relay

no frame-relay inverse-arp

interface Serial1/0.123 multipoint

ip address 192.168.0.2 255.255.255.0

frame-relay map ip 192.168.0.1 203 broadcast

frame-relay map ip 192.168.0.3 110 broadcast

BEast(config-subif)#do sh frame map

Serial1/0.123 (up): ip 192.168.0.1 dlci 203(0xCB,0×30B0), static,

broadcast,

CISCO, status defined, active

Serial1/0.123 (up): ip 192.168.0.3 dlci 110(0×6E,0×18E0), static,

broadcast,

CISCO, status defined, active

BEast(config-subif)#

BWest:

interface Serial1/0

no ip address

encapsulation frame-relay

no frame-relay inverse-arp

interface Serial1/0.123 multipoint

ip address 192.168.0.1 255.255.255.0

frame-relay map ip 192.168.0.2 302 broadcast

frame-relay map ip 192.168.0.3 201 broadcast

BWest(config-subif)#do sh frame map

Serial1/0.123 (up): ip 192.168.0.2 dlci 302(0×12E,0×48E0), static,

broadcast,

CISCO, status defined, active

Serial1/0.123 (up): ip 192.168.0.3 dlci 201(0xC9,0×3090), static,

broadcast,

CISCO, status defined, active

BWest(config-subif)#

FR Connectivity Check:

BNorth(config-if)#do ping 192.168.0.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/58/96 ms

BNorth(config-if)#do ping 192.168.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/61/108 ms

BNorth(config-if)#

Automatic 6to4 configuration:

BNorth:

ipv6 unicast-routing

interface Tunnel1

ipv6 address 2002:C0A8:3:1::1/64

tunnel source Serial1/0.123

tunnel mode ipv6ip 6to4

ipv6 route 2002::/16 Tunnel1

BNorth(config)#do ping 2002:c0a8:2:1::1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2002:C0A8:2:1::1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/70/112 ms

BNorth(config)#do ping 2002:c0a8:1:1::1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2002:C0A8:1:1::1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/62/112 ms

BNorth(config)#

BEast:

ipv6 unicast-routing

interface Tunnel1

ipv6 address 2002:C0A8:2:1::1/64

tunnel source Serial1/0.123

tunnel mode ipv6ip 6to4

ipv6 route 2002::/16 Tunnel1

BEast(config)# do ping 2002:c0a8:3:1::1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2002:C0A8:3:1::1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 44/71/120 ms

BEast(config)# do ping 2002:c0a8:1:1::1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2002:C0A8:1:1::1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/56/156 ms

BEast(config)#

BWest:

ipv6 unicast-routing

interface Tunnel1

ipv6 address 2002:C0A8:1:1::1/64

tunnel source Serial1/0.123

tunnel mode ipv6ip 6to4

ipv6 route 2002::/16 Tunnel1

BWest(config-if)#do ping 2002:c0a8:3:1::1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2002:C0A8:3:1::1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 40/76/132 ms

BWest(config-if)#do ping 2002:c0a8:2:1::1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2002:C0A8:2:1::1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/62/156 ms

BWest(config-if)#

Now the final check guys!

Ping and trace route from Westv6 and to Eastv6 and Northv6:

Westv6(config)#do ping 2002:c0a8:2:2::2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2002:C0A8:2:2::2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 88/182/428 ms

Westv6(config)#do ping 2002:c0a8:3:2::2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2002:C0A8:3:2::2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 104/164/228 ms

Westv6(config)#do trace 2002:c0a8:2:2::2

Type escape sequence to abort.

Tracing the route to 2002:C0A8:2:2::2

1 2002:C0A8:1:2::1 64 msec 56 msec 32 msec

2 2002:C0A8:2:1::1 228 msec 64 msec 72 msec

3 2002:C0A8:2:2::2 152 msec 124 msec 56 msec

Westv6(config)#do trace 2002:c0a8:3:2::2

Type escape sequence to abort.

Tracing the route to 2002:C0A8:3:2::2

1 2002:C0A8:1:2::1 64 msec 56 msec 28 msec

2 2002:C0A8:3:1::1 136 msec 120 msec 32 msec

3 2002:C0A8:3:2::2 124 msec 72 msec 112 msec

Westv6(config)#

Another opportunity to show you that mastering each technology separately will make your life easier when dealing with many technologies combined together.

Leave a Comment

February 27, 2009

OSPF loopback network type

Filed under: Routing protocols — cciethebeginning @ 3:51 am
Tags: OSPF

The main advantage of OSPF over other IGP protocols is its organizational aspect, it brings routing design efforts down to the infrastructure, providing better stability and faster troubleshooting.

OSPF network type classification is an example of this organization. In production environment you certainly have been dealing with “point-to-point”, “broadcast”, ”NBMA”, “point-to-multipoint” and “point-to-multipoint-non Broadcast” but less with “loopback” type.

“Loopback” type is frequently used in testbeds and lab environments to imitate subnet segments, but there is some limitations related to this network type. The purpose of this lab is enumerate different methods that will help get rid of these limitations to make the lab topology as close as possible to the production environment.

Figure1 shows an example of Lab topology in which a loopback interfaces are used:

Figure1: topology

R3:

R3#sh ip ospf int loo1

Loopback1 is up, line protocol is up

Internet Address 30.0.0.1/24, Area 23

Process ID 10, Router ID 3.3.3.3, Network Type LOOPBACK, Cost: 1

Loopback interface is treated as a stub Host

R3#

R3#sh ip ospf int loo2

Loopback2 is up, line protocol is up

Internet Address 33.33.33.33/16, Area 23

Process ID 10, Router ID 3.3.3.3, Network Type LOOPBACK, Cost: 1

Loopback interface is treated as a stub Host

R3#

All loopback interfaces are considered as OSPF “LOOPBACK” network type and treated as stub host.

Stub hosts are visible to the routing protocols but not used for forwarding.

Loopback interface is advertised as a host with /32 mask as shown below from the routing table of other OSPF routers:

R2:

R2#sh ip route

…

Gateway of last resort is not set

33.0.0.0/32 is subnetted, 1 subnets

O 33.33.33.33 [110/2] via 10.32.129.3, 00:03:48, FastEthernet0/0

10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks

C 10.1.1.0/24 is directly connected, FastEthernet2/0

O 10.0.0.1/32 [110/2] via 10.32.1.1, 00:12:06, FastEthernet1/0

C 10.32.0.0/17 is directly connected, FastEthernet1/0

C 10.32.128.0/17 is directly connected, FastEthernet0/0

30.0.0.0/32 is subnetted, 1 subnets

O 30.0.0.1 [110/2] via 10.32.129.3, 00:03:48, FastEthernet0/0

R2#

To change this and make OSPF advertise routes such 33.33.33.33 with its subnet mask, three methods area used:

1 If the area to which the loopback belongs is contiguous to area 0:

1.1 Change loopback OSPF network type.

1.2 Summarize loopback IP (as from ABR).

2 If the area to which the loopback belongs is non-contiguous to area 0, join the two area using traditional methods (OSPF virtual links or GRE/IPIP tunneling) in addition to either (1.1) or (1.2).

3 Redistribute connected (as from ASBR).

1.1- Directly change OSPF interface type

In this section we consider R3 loopback1 interface as it belongs to area 23 contiguous to area0 (figure2), the interface type is changed to point-to-point and the route to the interface is seen as intra-area route.

Figure2: case1 topology

R3:

R3(config-router)#int loo2

R3(config-if)#ip ospf network point-to-point

R3(config-if)#do sh ip ospf int loo2

Loopback2 is up, line protocol is up

Internet Address 33.33.33.33/16, Area 23

Process ID 10, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 1

Transmit Delay is 1 sec, State POINT_TO_POINT,

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

oob-resync timeout 40

Supports Link-local Signaling (LLS)

Index 3/3, flood queue length 0

Next 0×0(0)/0×0(0)

Last flood scan length is 0, maximum is 0

Last flood scan time is 0 msec, maximum is 0 msec

Neighbor Count is 0, Adjacent neighbor count is 0

Suppress hello for 0 neighbor(s)

R3(config-if)#

Now the interface is recognized as point-to-point and advertised with its configured subnet mask:

R2:

R2#sh ip route

…

Gateway of last resort is not set

33.0.0.0/16 is subnetted, 1 subnets

O 33.33.0.0 [110/2] via 10.32.129.3, 00:09:45, FastEthernet0/0

10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks

C 10.1.1.0/24 is directly connected, FastEthernet2/0

O 10.0.0.1/32 [110/2] via 10.32.1.1, 01:13:14, FastEthernet1/0

C 10.32.0.0/17 is directly connected, FastEthernet1/0

C 10.32.128.0/17 is directly connected, FastEthernet0/0

30.0.0.0/32 is subnetted, 1 subnets

O 30.0.0.1 [110/2] via 10.32.129.3, 00:09:45, FastEthernet0/0

R2#

1.2- Summarize loopback IP:

Let’s consider R2 loopback2:

R2(config-router)#do sh ip ospf int loo1

Loopback1 is up, line protocol is up

Internet Address 22.22.22.22/16, Area 23

Process ID 10, Router ID 2.2.2.2, Network Type LOOPBACK, Cost: 1

Loopback interface is treated as a stub Host

R2(config-router)#

The interface is configured to belong to area 23, and summarized using area range command because R2 is an ABR, consequently it will be advertised as “O IA» an inter-area type route:

R1:

R1(config-router)#do sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

33.0.0.0/32 is subnetted, 1 subnets

O IA 33.33.33.33 [110/3] via 10.32.1.2, 00:20:39, FastEthernet0/0

22.0.0.0/16 is subnetted, 1 subnets

O IA 22.22.0.0 [110/2] via 10.32.1.2, 00:00:10, FastEthernet0/0

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

C 10.1.1.0/24 is directly connected, FastEthernet1/0

C 10.0.0.0/24 is directly connected, Loopback1

C 10.32.0.0/17 is directly connected, FastEthernet0/0

O IA 10.32.128.0/17 [110/2] via 10.32.1.2, 02:05:16, FastEthernet0/0

30.0.0.0/32 is subnetted, 1 subnets

O IA 30.0.0.1 [110/3] via 10.32.1.2, 02:05:16, FastEthernet0/0

R1(config-router)#

However, it is still treated by R2 as STUB host; loopback interface IP address is advertised with its configured subnet mask /16:

R2:

R2(config-router)#do sh ip ospf int loo1

Loopback1 is up, line protocol is up

Internet Address 22.22.22.22/16, Area 23

Process ID 10, Router ID 2.2.2.2, Network Type LOOPBACK, Cost: 1

Loopback interface is treated as a stub Host

R2(config-router)#

R1:

R1(config-router)#do sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

33.0.0.0/32 is subnetted, 1 subnets

O IA 33.33.33.33 [110/3] via 10.32.1.2, 00:20:39, FastEthernet0/0

22.0.0.0/16 is subnetted, 1 subnets

O IA 22.22.0.0 [110/2] via 10.32.1.2, 00:00:10, FastEthernet0/0

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

C 10.1.1.0/24 is directly connected, FastEthernet1/0

C 10.0.0.0/24 is directly connected, Loopback1

C 10.32.0.0/17 is directly connected, FastEthernet0/0

O IA 10.32.128.0/17 [110/2] via 10.32.1.2, 02:05:16, FastEthernet0/0

30.0.0.0/32 is subnetted, 1 subnets

O IA 30.0.0.1 [110/3] via 10.32.1.2, 02:05:16, FastEthernet0/0

R1(config-router)#

2- Non-contiguous area:

a) With R3 loopback IP in a different area than 23 (figure3), we can apply virtual-link to join the non-contiguous area to the backbone through regular area 23.

Figure3: non-contiguous areas

R3:

router ospf 10

network 33.33.0.0 0.0.255.255 area 33

Interface Loopback 2

ip ospf network point-to-point

area 23 virtual-link 2.2.2.2

R2:

area 23 virtual-link 3.3.3.3

R2:

R2#sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

33.0.0.0/16 is subnetted, 1 subnets

O IA 33.33.0.0 [110/2] via 10.32.129.3, 00:00:26, FastEthernet0/0

22.0.0.0/16 is subnetted, 1 subnets

C 22.22.0.0 is directly connected, Loopback1

10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks

C 10.1.1.0/24 is directly connected, FastEthernet2/0

O 10.0.0.1/32 [110/2] via 10.32.1.1, 00:06:10, FastEthernet1/0

C 10.32.0.0/17 is directly connected, FastEthernet1/0

C 10.32.128.0/17 is directly connected, FastEthernet0/0

30.0.0.0/32 is subnetted, 1 subnets

O 30.0.0.1 [110/2] via 10.32.129.3, 00:06:10, FastEthernet0/0

R2#

b) Another alternative to Virtual-links is GRE/IPIP tunneling, whether it is GRE or IPIP it depends on your needs, GRE has the advantage of supporting other layer 3 protocols against only “IP” for IPIP, both cases are presented here:

R2:

interface Tunnel0

ip address 1.1.1.6 255.255.255.252

ip ospf 10 area 33

tunnel source FastEthernet0/0

tunnel destination 10.32.129.3

tunnel mode ipip

Actually, the tunnel subnet belongs to the same area as R3 loopback2 IP, area 33 to make it directly connected to area 0 through R2.

The only difference in configuration with GRE tunneling is mode as shown in the following line:

tunnel mode gre ip

R3 :

interface Tunnel0

ip address 1.1.1.5 255.255.255.252

ip ospf 10 area 33

tunnel source FastEthernet0/0

tunnel destination 10.32.129.2

tunnel mode ipip

Figure3 illustrates the logical topology using GRE/IPIP tunnels

Figure3: logical topology with GRE/IPIP tunnels

R2:

R2#sh int tunn 0

Tunnel0 is up, line protocol is up

Hardware is Tunnel

Internet address is 1.1.1.6/30

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive not set

Tunnel source 10.32.129.2 (FastEthernet0/0), destination 10.32.129.3

Tunnel protocol/transport IP/IP

Tunnel TTL 255

Fast tunneling enabled

Tunnel transmit bandwidth 8000 (kbps)

Tunnel receive bandwidth 8000 (kbps)

…

R2#sh ip route

…

Gateway of last resort is not set

1.0.0.0/30 is subnetted, 1 subnets

C 1.1.1.4 is directly connected, Tunnel0

33.0.0.0/16 is subnetted, 1 subnets

O 33.33.0.0 [110/11112] via 1.1.1.5, 00:56:19, Tunnel0

22.0.0.0/16 is subnetted, 1 subnets

C 22.22.0.0 is directly connected, Loopback1

10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks

C 10.1.1.0/24 is directly connected, FastEthernet2/0

O 10.0.0.1/32 [110/2] via 10.32.1.1, 00:55:59, FastEthernet1/0

C 10.32.0.0/17 is directly connected, FastEthernet1/0

C 10.32.128.0/17 is directly connected, FastEthernet0/0

30.0.0.0/32 is subnetted, 1 subnets

O 30.0.0.1 [110/2] via 10.32.129.3, 00:55:59, FastEthernet0/0

R2#

Do not forget that for R3 Loopback2 subnet to be announced with its subnet mask you have to either change the interface OSPF network type or perform summarization at R2 (the ABR between area 33 and area 0).

R1:

R1#sh ip route

…

Gateway of last resort is not set

1.0.0.0/30 is subnetted, 1 subnets

O IA 1.1.1.4 [110/11112] via 10.32.1.2, 01:06:07, FastEthernet0/0

33.0.0.0/16 is subnetted, 1 subnets

O IA 33.33.0.0 [110/11113] via 10.32.1.2, 01:06:07, FastEthernet0/0

22.0.0.0/16 is subnetted, 1 subnets

O IA 22.22.0.0 [110/2] via 10.32.1.2, 01:06:07, FastEthernet0/0

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

C 10.1.1.0/24 is directly connected, FastEthernet1/0

C 10.0.0.0/24 is directly connected, Loopback1

C 10.32.0.0/17 is directly connected, FastEthernet0/0

O IA 10.32.128.0/17 [110/2] via 10.32.1.2, 01:06:07, FastEthernet0/0

30.0.0.0/32 is subnetted, 1 subnets

O IA 30.0.0.1 [110/3] via 10.32.1.2, 01:06:07, FastEthernet0/0

R1#

Finally, the verification that traffic destined to R2 loopback2 takes the configured tunnel:

R1#trace 33.33.33.33 source 10.0.0.1

Type escape sequence to abort.

Tracing the route to 33.33.33.33

1 10.32.1.2 68 msec 72 msec 44 msec

2 1.1.1.5 88 msec * 104 msec

R1#

3- Route redistribution:

Let’s go back to loopback 2 interface defined in R3, it doesn’t matter whether the loopback interface IP is announced with OSPF or not, as soon as redistribute connected is configured, the route will be announced as external type E2 route and we will lose control over it, though it is configured inside our OSPF domain:

R3:

R3(config-if)#do sh ip ospf int loo2

%OSPF: OSPF not enabled on Loopback2

R3(config-if)#

R3(config-router)#redistribute connected subnet

R2:

R2(config-router)#do sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

33.0.0.0/16 is subnetted, 1 subnets

O E2 33.33.0.0 [110/20] via 10.32.129.3, 00:00:51, FastEthernet0/0

22.0.0.0/16 is subnetted, 1 subnets

C 22.22.0.0 is directly connected, Loopback1

10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks

C 10.1.1.0/24 is directly connected, FastEthernet2/0

O 10.0.0.1/32 [110/2] via 10.32.1.1, 00:32:49, FastEthernet1/0

C 10.32.0.0/17 is directly connected, FastEthernet1/0

C 10.32.128.0/17 is directly connected, FastEthernet0/0

30.0.0.0/32 is subnetted, 1 subnets

O 30.0.0.1 [110/2] via 10.32.129.3, 00:00:56, FastEthernet0/0

R2(config-router)#

R2(config-router)#do sh ip ospf data

OSPF Router with ID (2.2.2.2) (Process ID 10)

…

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

33.33.0.0 3.3.3.3 456 0×80000001 0×005101 0

R2(config-router)#

SUMMARY

The /32 advertisement limitation of loopback interfaces can be overcome by either changing OSPF network type to point-to-point or creating summary route with the desired mask.

In case the loopback interface belongs to a non-contiguous area use either OSPF virtual-links or GRE/IPIP tunnels to join it to area 0.

Tags: OSPF

Comments (3)

January 19, 2009

BGP link-bw & multipath Load Balancing

Filed under: BGP, Routing protocols — cciethebeginning @ 11:41 am
Tags: BGP, Load Balancing

An autonomous system can be connected to another through multiple links and according to the company business and redundancy requirements different schemes can be used:

- Primary/secondary: where the second link is used only when the first link fails.

- Symmetric load-sharing: where the traffic is equally distributed among multiple links in the same time, which provides a high level of redundancy for the enterprise.

But, it’s not always possible to provide equal bandwidth links because of either financial limits or availability of such solution. So the need to engineer traffic through these links according to their bandwidth capacity.

Here comes the solution of BGP link bandwidth.

With the deployment of BGP multipath, generally the decision of using multiple path to deliver the traffic is performed inside the autonomous system by an iBGP according to multiple criteria excluding the eBGP link bandwidth.

BGP link-bw advertise bandwidth of an autonomous system exit link as extended community to iBGP.

Some requirements are to be considered:

- Only between directly connected eBGP peers.

- BGP extended community should be enabled between iBGP.

- CEF should be enabled everywhere.

Figure 1 illustrates the lab topology used to implement BGP link-bw

Figure1: Topology

Inside AS 64540, R1, R2 and R3 establish full mesh iBGP sessions, the same for AS 64550: R4, R5, R6 and R7 establish full mesh iBGP sessions.

Links R2-R4, R5-R3, R6-R3 are direct eBGP sessions using interfaces ip addresses as sources and destinations.

Network default behavior

The network default configuration is as follow:

AS 64540:

R1:

R1(config-router)#do sh ip bgp

BGP table version is 3, local router ID is 10.10.10.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 10.10.10.0/24 0.0.0.0 0 32768 i

* i70.70.70.0/24 3.3.3.3 0 100 0 64550 i

*>i 2.2.2.2 0 100 0 64550 i

R1(config-router)#

R1(config-router)#do sh ip bgp 70.70.70.0

BGP routing table entry for 70.70.70.0/24, version 3

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Not advertised to any peer

64550

3.3.3.3 (metric 2297856) from 3.3.3.3 (3.3.3.3)

Origin IGP, metric 0, localpref 100, valid, internal

64550

2.2.2.2 (metric 2297856) from 2.2.2.2 (2.2.2.2)

Origin IGP, metric 0, localpref 100, valid, internal, best

R1(config-router)#

the default path chosen is through R2-R4:

R1(config-router)#do traceroute 70.70.70.1 source 10.10.10.1

Type escape sequence to abort.

Tracing the route to 70.70.70.1

1 192.168.12.2 24 msec 320 msec 452 msec

2 192.168.24.2 1004 msec 716 msec 484 msec

3 192.168.47.2 292 msec * 556 msec

R1(config-router)#

So the traffic from R1 to R7 takes the path R1-R2-R7

Table1: best path selection for 70.70.70.1/24 from R1

	Attribute	Path1	Path2
1	weight	0	0
2	local preference	100	100
3	originated locally	No	No
4	AS_PATH	64550	64550
5	ORIGIN	i	i
6	MED	0	0
7	eBGP<>iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	2297856	2297856
9	Multipath	No	No
10	oldest path	No	No
11	Lowest neighbor router-ID	3.3.3.3	2.2.2.2 <<<

AS 64550:

R7:

R7(config-router)#do sh ip bgp

BGP table version is 3, local router ID is 70.70.70.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

* i10.10.10.0/24 5.5.5.5 0 100 0 64540 i

*>i 4.4.4.4 0 100 0 64540 i

* i 6.6.6.6 0 100 0 64540 i

*> 70.70.70.0/24 0.0.0.0 0 32768 i

R7(config-router)#

R7(config-router)#do traceroute 10.10.10.1 source 70.70.70.1

Type escape sequence to abort.

Tracing the route to 10.10.10.1

1 192.168.47.1 8 msec 268 msec 104 msec

2 192.168.24.1 164 msec 348 msec 136 msec

3 192.168.12.1 276 msec * 260 msec

R7(config-router)#

So the traffic from R7 to R1 takes the path R7-R4-R2-R1

R7(config-router)#do sh ip bgp 10.10.10.0

BGP routing table entry for 10.10.10.0/24, version 3

Paths: (3 available, best #2, table Default-IP-Routing-Table)

Not advertised to any peer

64540

5.5.5.5 (metric 2297856) from 5.5.5.5 (5.5.5.5)

Origin IGP, metric 0, localpref 100, valid, internal

64540

4.4.4.4 (metric 2297856) from 4.4.4.4 (4.4.4.4)

Origin IGP, metric 0, localpref 100, valid, internal, best

64540

6.6.6.6 (metric 2297856) from 6.6.6.6 (6.6.6.6)

Origin IGP, metric 0, localpref 100, valid, internal

R7(config-router)#

R4-R2 link is chosen as the best path to reach the prefix 10.10.10.1/24:

Table2: best path selection for 10.10.10.1/24 from R7

	Attribute	Path1	Path2	Path3
1	weight	0	0	0
2	local preference	100	100	100
3	originated locally	No	No	No
4	AS_PATH	64540	64540	64540
5	ORIGIN	i	i	i
6	MED	0	0	0
7	eBGP<>iBGP	iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	2297856	2297856	2297856
9	Multipath	No	No	No
10	oldest path	No	No	No
11	Lowest neighbor router-ID	5.5.5.5	4.4.4.4 <<<	6.6.6.6

BGP Link-BW deployment

The best way to utilize BW resources is to load-share the traffic among the three eBGP link according to their BW:

let’s recall the requirements for using BGP link BW:

- Requires BGP multipath configured.

- Enable BGP ext. community between iBGP.

- Enable CEF everywhere.

General configuration:

On each iBGP speaker with multilink ramification, enable iBGP multipath

router bgp <ASnbr>

maximum-paths <n>

maximum-paths ibgp <n>

router bgp <ASnbr>

address-family ipv4

neighbor <iBGP_peer> activate

neighbor <iBGP_peer> send-community extended

!iBGP peer to which extended community is to be send.

neighbor <eBGP_peer> activate

neighbor <eBGP_peer> dmzlink-bw

!Allow eBGP bandwidth to be propagated through link-bw extended community

bgp dmzlink-bw

!“bgp dmzlink-bw” is configured on any router whose eBGP link bandwidth !will be used for load-balancing.

exit-address-family

As 65540:

R1(iBGP):

router bgp 64540

address-family ipv4

neighbor 2.2.2.2 activate

neighbor 3.3.3.3 activate

maximum-paths 3

maximum-paths ibgp 3

exit-address-family

eBGP speaker R2:

router bgp 64540

address-family ipv4

neighbor 1.1.1.1 activate

neighbor 1.1.1.1 send-community extended

neighbor 1.1.1.1 next-hop-self

neighbor 3.3.3.3 activate

neighbor 3.3.3.3 next-hop-self

neighbor 192.168.24.2 activate

neighbor 192.168.24.2 dmzlink-bw

bgp dmzlink-bw

exit-address-family

eBGP speaker R3:

router bgp 64540

address-family ipv4

neighbor 1.1.1.1 activate

neighbor 1.1.1.1 send-community extended

neighbor 1.1.1.1 next-hop-self

neighbor 2.2.2.2 activate

neighbor 2.2.2.2 next-hop-self

neighbor 192.168.35.2 activate

neighbor 192.168.35.2 dmzlink-bw

neighbor 192.168.36.2 activate

neighbor 192.168.36.2 dmzlink-bw

maximum-paths 2

maximum-paths ibgp 2

bgp dmzlink-bw

exit-address-family

Verification:

R1#sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

192.168.12.0/30 is subnetted, 1 subnets

C 192.168.12.0 is directly connected, Serial1/0

1.0.0.0/32 is subnetted, 1 subnets

C 1.1.1.1 is directly connected, Loopback0

192.168.13.0/30 is subnetted, 1 subnets

C 192.168.13.0 is directly connected, Serial1/1

2.0.0.0/32 is subnetted, 1 subnets

D 2.2.2.2 [90/2297856] via 192.168.12.2, 03:20:35, Serial1/0

70.0.0.0/24 is subnetted, 1 subnets

B 70.70.70.0 [200/0] via 3.3.3.3, 01:11:12

[200/0] via 2.2.2.2, 01:11:12

3.0.0.0/32 is subnetted, 1 subnets

D 3.3.3.3 [90/2297856] via 192.168.13.2, 03:20:29, Serial1/1

10.0.0.0/24 is subnetted, 1 subnets

C 10.10.10.0 is directly connected, Loopback1

R1#

R1#sh ip route 70.70.70.1

Routing entry for 70.70.70.0/24

Known via “bgp 64540″, distance 200, metric 0

Tag 64550, type internal

Last update from 2.2.2.2 01:08:48 ago

Routing Descriptor Blocks:

3.3.3.3, from 3.3.3.3, 01:08:48 ago

Route metric is 0, traffic share count is 1

AS Hops 1

Route tag 64550

* 2.2.2.2, from 2.2.2.2, 01:08:48 ago

Route metric is 0, traffic share count is 1

AS Hops 1

Route tag 64550

R1#

R1:

R1#sh ip bgp 70.70.70.1

BGP routing table entry for 70.70.70.0/24, version 7

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Multipath: eBGP iBGP

Not advertised to any peer

64550

3.3.3.3 (metric 2297856) from 3.3.3.3 (3.3.3.3)

Origin IGP, metric 0, localpref 100, valid, internal, multipath

DMZ-Link Bw 1443 kbytes

64550

2.2.2.2 (metric 2297856) from 2.2.2.2 (2.2.2.2)

Origin IGP, metric 0, localpref 100, valid, internal, multipath, best

DMZ-Link Bw 12500 kbytes

R1#

Note the proportion of the link BW of path 2 (through 2.2.2.2) against link BW of path 1 (through 3.3.3.3).

Table3: best path selection for 70.70.70.1/24 from R1 after BGP Link-bw

	Attribute	Path1	Path2
1	weight	0	0
2	local preference	100	100
3	originated locally	No	No
4	AS_PATH	64550	64550
5	ORIGIN	i	i
6	MED	0	0
7	eBGP<>iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	2297856	2297856
9	Multipath	2 <<<<	2 <<<<
10	~~oldest path~~	No	No
11	~~Lowest neighbor router-ID~~	~~3.3.3.3~~	~~2.2.2.2~~

R3:

R3#sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

192.168.12.0/30 is subnetted, 1 subnets

D 192.168.12.0 [90/2681856] via 192.168.13.1, 03:21:04, Serial1/0

1.0.0.0/32 is subnetted, 1 subnets

D 1.1.1.1 [90/2297856] via 192.168.13.1, 03:21:04, Serial1/0

192.168.13.0/30 is subnetted, 1 subnets

C 192.168.13.0 is directly connected, Serial1/0

2.0.0.0/32 is subnetted, 1 subnets

D 2.2.2.2 [90/2809856] via 192.168.13.1, 03:21:04, Serial1/0

70.0.0.0/24 is subnetted, 1 subnets

B 70.70.70.0 [20/0] via 192.168.35.2, 01:11:47

[20/0] via 192.168.36.2, 01:11:47

3.0.0.0/32 is subnetted, 1 subnets

C 3.3.3.3 is directly connected, Loopback0

10.0.0.0/24 is subnetted, 1 subnets

B 10.10.10.0 [200/0] via 1.1.1.1, 01:18:16

192.168.36.0/30 is subnetted, 1 subnets

C 192.168.36.0 is directly connected, Serial1/1

192.168.35.0/30 is subnetted, 1 subnets

C 192.168.35.0 is directly connected, Ethernet0/0

R3#

R3#sh ip route 70.70.70.1

Routing entry for 70.70.70.0/24

Known via “bgp 64540″, distance 20, metric 0

Tag 64550, type external

Last update from 192.168.36.2 01:09:28 ago

Routing Descriptor Blocks:

* 192.168.35.2, from 192.168.35.2, 01:09:28 ago

Route metric is 0, traffic share count is 1

AS Hops 1

Route tag 64550

192.168.36.2, from 192.168.36.2, 01:09:28 ago

Route metric is 0, traffic share count is 1

AS Hops 1

Route tag 64550

R3#

R3#sh ip bgp 70.70.70.1

BGP routing table entry for 70.70.70.0/24, version 6

Paths: (3 available, best #1, table Default-IP-Routing-Table)

Multipath: eBGP iBGP

Advertised to update-groups:

1 2 3

64550

192.168.35.2 from 192.168.35.2 (5.5.5.5)

Origin IGP, localpref 100, valid, external, multipath, best

DMZ-Link Bw 1250 kbytes

64550

2.2.2.2 (metric 2809856) from 2.2.2.2 (2.2.2.2)

Origin IGP, metric 0, localpref 100, valid, internal

64550

192.168.36.2 from 192.168.36.2 (6.6.6.6)

Origin IGP, localpref 100, valid, external, multipath

DMZ-Link Bw 193 kbytes

R3#

Note the proportion of the link BW of path 1 (through 192.168.35.2) against link BW of path 1 (through 192.168.36.2).

AS 64550:

The same configuration can be done for AS 64550 to have a symmetric traffic flow between the two ASs:

R4:

R4#bgpcf

router bgp 64550

address-family ipv4

neighbor 5.5.5.5 activate

neighbor 6.6.6.6 activate

neighbor 7.7.7.7 activate

neighbor 7.7.7.7 send-community extended

neighbor 192.168.24.1 activate

neighbor 192.168.24.1 dmzlink-bw

bgp dmzlink-bw

exit-address-family

R5:

bgp 64550

address-family ipv4

neighbor 4.4.4.4 activate

neighbor 6.6.6.6 activate

neighbor 7.7.7.7 activate

neighbor 7.7.7.7 send-community extended

neighbor 192.168.35.1 activate

neighbor 192.168.35.1 dmzlink-bw

bgp dmzlink-bw

exit-address-family

R6:

router bgp 64550

address-family ipv4

neighbor 4.4.4.4 activate

neighbor 5.5.5.5 activate

neighbor 7.7.7.7 activate

neighbor 7.7.7.7 send-community extended

neighbor 192.168.36.1 activate

neighbor 192.168.36.1 dmzlink-bw

bgp dmzlink-bw

exit-address-family

R7:

router bgp 64550

address-family ipv4

neighbor 4.4.4.4 activate

neighbor 5.5.5.5 activate

neighbor 6.6.6.6 activate

maximum-paths 3

maximum-paths ibgp 3

exit-address-family

R7#sh ip bgp 10.10.10.1

BGP routing table entry for 10.10.10.0/24, version 9

Paths: (3 available, best #3, table Default-IP-Routing-Table)

Multipath: eBGP iBGP

Flag: 0×800

Not advertised to any peer

64540

5.5.5.5 (metric 2297856) from 5.5.5.5 (5.5.5.5)

Origin IGP, metric 0, localpref 100, valid, internal, multipath

DMZ-Link Bw 1250 kbytes

64540

6.6.6.6 (metric 2297856) from 6.6.6.6 (6.6.6.6)

Origin IGP, metric 0, localpref 100, valid, internal, multipath

DMZ-Link Bw 193 kbytes

64540

4.4.4.4 (metric 2297856) from 4.4.4.4 (4.4.4.4)

Origin IGP, metric 0, localpref 100, valid, internal, multipath, best

DMZ-Link Bw 12500 kbytes

R7#

Table4: best path selection for 10.10.10.1/24 from R7 after configuring BGP link-bw

	Attribute	Path1	Path2	Path3
1	weight	0	0	0
2	local preference	100	100	100
3	originated locally	No	No	No
4	AS_PATH	64540	64540	64540
5	ORIGIN	i	i	i
6	MED	0	0	0
7	eBGP<>iBGP	iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	2297856	2297856	2297856
9	Multipath	3 <<<<	3 <<<<	3 <<<<
10	~~oldest path~~	No	No	No
11	~~Lowest neighbor router-ID~~	~~5.5.5.5~~	~~4.4.4.4~~	~~6.6.6.6~~

CONCLUSION

BGP link-bw provides an optimal way to use link bandwidth resources between autonomous systems, make sure CEF is enabled (enabled by default), iBGP multipath is already configured and enable the propagation of the extended community to iBGP neighbors.

Tags: BGP, Load+Balancing

Leave a Comment

January 9, 2009

BGP peer-session and peer-policy templates

Filed under: BGP, Routing protocols — cciethebeginning @ 11:59 am
Tags: BGP, template

A Peer template is a pattern, a model that can be used to facilitate the management of BGP peer configuration. Templates are much more flexible than Peer-group because of the concept of inheritance, in which a common template can be inherited by more specific templates according to a hierarchical scheme.

Two types of templates are available: peer-session templates for session establishment and peer-policy templates for prefix advertisement policies.

Without a prior good planning, peer-templates can turn into a mess, the key is to organize commands by groups from the most common (at the root and nodes of the tree) to the most specific (towards leaves).

Each template in the tree can be applied directly as a configuration pattern for a BGP peer or inherited by an more specific template for more granularity(Figure1).

Figure1: Tree of inheritance

Figure 2 illustrates the topology used to deploy peer-templates: ISPA (AS 56000) connects five customers (AS 56501, 56502, 56503, 56504 and 56505), ISPA is connected in its turn to an upstream ISPB (AS 55000).

Figure2: Topology

The hypothetical policy requirements are as follows:

* One inbound policy is common to all clients, so the root template in the hierarchy of inheritance will contain common policy commands to all categories:

- Receive only Customer prefixes.

- ISPA accept maximum 2 prefixes from each client.

* Outbound policies on ISPA to clients are organized in three categories:

1- Policy1 – Advertise only the default route: “Default_Only” template.

2- Policy2 – Advertise the default route and only ISPA (direct upstream) routes: “Default_n_Local” template.

3- Policy3 – Advertise full BGP (ISPA, ISPB and other clients prefixes): “Full_BGP” template.

The following table resumes the policies and common configurations between ISPA and its downstream customers :

Table 1: configuration and policies

			R1-ISPA	R2-ISPA	R3-ISPA	R4-ISPA	R5-ISPA
Session	BGP version & timers		x
	Direct interface eBGP				x		x
	eBGP between loopback interfaces : - set eBGP TTL to 2 - specify loopback as source of updates			x		x
Policy	Outbound policy	Policy 1 (Only default route)	x	x
		Policy 2 (default route + ISPA local networks)			x	x
		Policy 3 (Full BGP)					x
	Inbound policy	Policy 4 Accept only customer prefixes (max 2).	x
	description		own	own	own	own	own

Configuring Peer-Session Template

Let’s start by configuring BGP sessions with customers.

Under BGP configuration mode ,templates are designed according to table1:

ISPA:

template peer-session Common_Session_Config

version 4

timers 30 90

exit-peer-session

This template is common to all sessions and considered as the root peer-session template.

template peer-session Indirect_eBGP

ebgp-multihop 2

update-source Loopback0

inherit peer-session Common_Session_Config

exit-peer-session

This one inherit commands from the “Common_Session_Config” template in addition to its own commands.

ISPA#sh ip bgp template peer-session

Template:Common_Session_Config, index:1

Local policies:0×22, Inherited polices:0×0

*Inherited by Template Indirect_eBGP, index= 2

Locally configured session commands:

version 4

timers 30 90

Inherited session commands:

Template:Indirect_eBGP, index:2

Local policies:0×88, Inherited polices:0×22

This template inherits:

Common_Session_Config index:1 flags:0×0

Locally configured session commands:

ebgp-multihop 2

update-source Loopback0

Inherited session commands:

version 4

timers 30 90

ISPA#

Now each neighbor will just inherit the template and apply included commands:

router bgp 56000

neighbor 1.1.1.1 remote-as 56501

neighbor 1.1.1.1 inherit peer-session Indirect_eBGP

neighbor 2.2.2.2 remote-as 56502

neighbor 2.2.2.2 inherit peer-session Indirect_eBGP

neighbor 4.4.4.4 remote-as 56504

neighbor 4.4.4.4 inherit peer-session Indirect_eBGP

neighbor 10.1.12.2 remote-as 56503

neighbor 10.1.12.2 inherit peer-session Common_Session_Config

neighbor 10.1.20.2 remote-as 56505

neighbor 10.1.20.2 inherit peer-session Common_Session_Config

BGP sessions are built according to applied templates:

ISPA#sh ip bgp summ

BGP router identifier 100.1.1.1, local AS number 56000

BGP table version is 7, main routing table version 7

6 network entries using 702 bytes of memory

6 path entries using 312 bytes of memory

7/6 BGP path/bestpath attribute entries using 868 bytes of memory

5 BGP AS-PATH entries using 120 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 2002 total bytes of memory

BGP activity 6/0 prefixes, 6/0 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

1.1.1.1 4 56501 26 31 7 0 0 00:10:39 1

2.2.2.2 4 56502 12 18 7 0 0 00:04:11 0

4.4.4.4 4 56504 7 12 7 0 0 00:01:15 1

10.1.12.2 4 56503 7 12 7 0 0 00:02:48 1

10.1.20.2 4 56505 5 10 7 0 0 00:00:29 1

200.2.2.2 4 55000 34 39 7 0 0 00:30:36 1

ISPA#

ISPA(config-router)#do sh ip bgp

BGP table version is 11, local router ID is 100.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 1.1.1.1 0 0 56501 i

*> 11.0.0.0/24 1.1.1.1 0 0 56501 i

*> 12.0.0.0/24 1.1.1.1 0 0 56501 i

*> 13.0.0.0/24 1.1.1.1 0 0 56501 i

*> 20.0.0.0/24 2.2.2.2 0 0 56502 i

*> 30.0.0.0/24 10.1.12.2 0 0 56503 i

*> 40.0.0.0/24 4.4.4.4 0 0 56504 i

*> 50.0.0.0/24 10.1.20.2 0 0 56505 i

*> 55.55.0.0/16 200.2.2.2 0 0 55000 i

*> 56.56.0.0/16 0.0.0.0 0 32768 i

ISPA(config-router)#

Without any policy applied client routers R1, R2, R3, R4 and R5 receive all prefixes (equivalent of full BGP) as shown in the following routing table of R1:

R1#sh ip bgp

BGP table version is 11, local router ID is 10.0.0.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 0.0.0.0 0 32768 i

*> 11.0.0.0/24 0.0.0.0 0 32768 i

*> 12.0.0.0/24 0.0.0.0 0 32768 i

*> 13.0.0.0/24 0.0.0.0 0 32768 i

*> 20.0.0.0/24 100.1.1.1 0 56000 56502 i

*> 30.0.0.0/24 100.1.1.1 0 56000 56503 i

*> 40.0.0.0/24 100.1.1.1 0 56000 56504 i

*> 50.0.0.0/24 100.1.1.1 0 56000 56505 i

*> 55.55.0.0/16 100.1.1.1 0 56000 55000 i

*> 56.56.0.0/16 100.1.1.1 0 0 56000 i

R1#

Peer-policy Template configuration

ISPA:

ip as-path access-list 10 permit ^([0-9]+)$

router bgp 56000

template peer-policy Common_Policy_Config

filter-list 10 in

maximum-prefix 2

exit-peer-policy

ip prefix-list NOTHING_plist seq 5 deny 0.0.0.0/0 le 32

router bgp 56000

template peer-policy Default_Only

prefix-list NOTHING_plist out

default-originate

exit-peer-policy

ip as-path access-list 20 permit ^$

router bgp 56000

template peer-policy Default_n_Local

filter-list 20 out

default-originate

inherit peer-policy Common_Policy_Config 10

exit-peer-policy

access-list 11 permit any

route-map Full_BGP_rmap permit 10

match ip address 11

router bgp 56000

template peer-policy Full_BGP

route-map Full_BGP_rmap out

inherit peer-policy Common_Policy_Config 10

exit-peer-policy

ISPA#sh ip bgp template peer-policy

Template:Default_Only, index:2.

Local policies:0×480, Inherited polices:0×0

Locally configured policies:

prefix-list NOTHING_plist out

default-originate route-map none

Inherited policies:

Template:Common_Policy_Config, index:1.

Local policies:0×80004, Inherited polices:0×0

*Inherited by Template Default_n_Local, index:3

*Inherited by Template Full_BGP, index:4

Locally configured policies:

filter-list 10 in

maximum-prefix 2

Inherited policies:

Template:Default_n_Local, index:3.

Local policies:0×408, Inherited polices:0×80004

This template inherits:

Common_Policy_Config, index:1, seq_no:10, flags:0×408

Locally configured policies:

filter-list 20 out

default-originate route-map none

Inherited policies:

filter-list 10 in

maximum-prefix 2

Template:Full_BGP, index:4.

Local policies:0×2, Inherited polices:0×80004

This template inherits:

Common_Policy_Config, index:1, seq_no:10, flags:0×2

Locally configured policies:

route-map Full_BGP_rmap out

Inherited policies:

filter-list 10 in

maximum-prefix 2

ISPA#

Apply peer-policy-template

ISPA:

router bgp 56000

neighbor 1.1.1.1 inherit peer-policy Default_Only

neighbor 2.2.2.2 inherit peer-policy Default_Only

neighbor 4.4.4.4 inherit peer-policy Default_n_Local

neighbor 10.1.12.2 inherit peer-policy Default_n_Local

neighbor 10.1.20.2 inherit peer-policy Full_BGP

R1 (1.1.1.1) and R2 (2.2.2.2) will receive only default route from ISPA.

R3 (10.1.12.2) and R4 (4.4.4.4) will receive default route and ISPA prefixes.

R5 will receive all routes (full BGP).

ISPA#clear ip bgp *

R1: (After applying peer-policy template on ISPA)

R1#sh ip bgp

BGP table version is 48, local router ID is 10.0.0.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 0.0.0.0 100.1.1.1 0 0 56000 i

*> 10.0.0.0/24 0.0.0.0 0 32768 i

*> 11.0.0.0/24 0.0.0.0 0 32768 i

R1#

R2: (After applying peer-policy template on ISPA)

R2#sh ip bgp

BGP table version is 55, local router ID is 20.0.0.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 0.0.0.0 100.1.1.1 0 0 56000 i

*> 20.0.0.0/24 0.0.0.0 0 32768 i

R2#

R3: (After applying peer-policy template on ISPA)

R3#sh ip bgp

BGP table version is 20, local router ID is 30.0.0.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 0.0.0.0 10.1.12.1 0 0 56000 i

*> 30.0.0.0/24 0.0.0.0 0 32768 i

*> 56.56.0.0/16 10.1.12.1 0 0 56000 i

R3#

R4: (After applying peer-policy template on ISPA)

R4#sh ip bgp

BGP table version is 4, local router ID is 40.0.0.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 0.0.0.0 100.1.1.1 0 0 56000 i

*> 40.0.0.0/24 0.0.0.0 0 32768 i

*> 56.56.0.0/16 100.1.1.1 0 0 56000 i

R4#

R5: (After applying peer-policy template on ISPA)

R5#sh ip bgp

BGP table version is 8, local router ID is 50.0.0.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 10.1.20.1 0 56000 56501 i

*> 20.0.0.0/24 10.1.20.1 0 56000 56502 i

*> 30.0.0.0/24 10.1.20.1 0 56000 56503 i

*> 40.0.0.0/24 10.1.20.1 0 56000 56504 i

*> 50.0.0.0/24 0.0.0.0 0 32768 i

*> 55.55.0.0/16 10.1.20.1 0 56000 55000 i

*> 56.56.0.0/16 10.1.20.1 0 0 56000 i

R5#

And R5 has received the full BGP routing table.

Tags: BGP, Template

Leave a Comment

January 5, 2009

BGP peer groups

Filed under: BGP, Routing protocols — cciethebeginning @ 12:38 pm
Tags: BGP, peer-group

A peer-group is a set of BGP neighbors that shares the same outbound policy, where the inbound policies might be different.

In general iBGP peers receive the same updates all the time, making them ideal for arrangement for a peer group. The main advantage, besides ease of configuration, is the fact that updates are generated only once per peer group.

Figure1: Topology

The lab is structured as follows:

- Peer group policy planning.

- Configuration steps.

- Monitoring peer groups.

- Debugging and analysis the difference in behaviour with and without peer group

Planning

Let’s consider the following hypothetical autonomous system (figure1) policy:

Advertisement policy:

- The router R1 must block odd networks 11.11.11.0/24 and 33.33.33.0/24 from being advertised to its iBGP peers.

- Routers R2 and R4 are not authorized to advertise their inside networks out.

Deployment:

- Tag networks 11.11.11.0/24 and 33.33.33.0/24 with a special community tag 55555:666 and filter them from outbound advertisements at the router R1.

- Networks 20.0.0.0/16 and 40.0.0.0/8 will be filtered through a route-map and bind the route map to outbound advertisement with the neighbour R1.

Configuration steps

Without Peer-groups

Let’s take a closer look at the configuration at R1 without using peer-groups:

Notice that many commands are exactly the same and they are repeated for each iBGP neighbor

R1:

router bgp 55555

neighbor 1.1.2.2 remote-as 55555

neighbor 1.1.3.2 remote-as 55555

neighbor 1.1.4.2 remote-as 55555

neighbor 1.1.5.2 remote-as 55555

neighbor 1.1.2.2 next-hop-self

neighbor 1.1.3.2 next-hop-self

neighbor 1.1.4.2 next-hop-self

neighbor 1.1.5.2 next-hop-self

neighbor 1.1.2.2 route-reflector-client

neighbor 1.1.3.2 route-reflector-client

neighbor 1.1.4.2 route-reflector-client

neighbor 1.1.5.2 route-reflector-client

neighbor 172.16.0.6 remote-as 55556

This is a relevant case to use peer groups because it will save you from repetitive configuration of each peer and save the router itself from the effort of parsing the policy sequentially for each BGP peer and lessen necessary CPU and memory resources when inspecting routing table and generating updates.

With peer groups:

- Create a BGP peer-group:

neighbor ibgp-pgroup peer-group

- Assign BGP neighbor into a peer group:

neighbor 1.1.2.2 peer-group ibgp-pgroup

neighbor 1.1.3.2 peer-group ibgp-pgroup

neighbor 1.1.4.2 peer-group ibgp-pgroup

neighbor 1.1.5.2 peer-group ibgp-pgroup

- Configure needed commands for the peer-group

neighbor ibgp-pgroup remote-as 55555

neighbor ibgp-pgroup route-reflector-client

neighbor ibgp-pgroup next-hop-self

R1:

R1#sh ip bgp peer-group ibgp-pgroup

BGP peer-group is ibgp-pgroup

BGP version 4

Default minimum time between advertisement runs is 5 seconds

For address family: IPv4 Unicast

BGP neighbor is ibgp-pgroup, peer-group internal, members:

1.1.2.2 1.1.3.2 1.1.4.2 1.1.5.2

Index 0, Offset 0, Mask 0×0

Update messages formatted 0, replicated 0

Number of NLRIs in the update sent: max 0, min 0

R1#

“sh ip bgp peer-group ibgp-pgroup summary” is equivalent to “sh ip bgp summary but just for peer-group members”

R1:

R1#sh ip bgp peer-group ibgp-pgroup summ

BGP router identifier 1.1.1.1, local AS number 55555

BGP table version is 35, main routing table version 35

8 network entries using 936 bytes of memory

8 path entries using 416 bytes of memory

3/2 BGP path/bestpath attribute entries using 372 bytes of memory

1 BGP AS-PATH entries using 24 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 1748 total bytes of memory

BGP activity 8/0 prefixes, 21/13 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

1.1.2.2 4 55555 143 173 35 0 0 00:26:28 1

1.1.3.2 4 55555 140 167 35 0 0 00:26:16 1

1.1.4.2 4 55555 140 167 35 0 0 00:26:01 1

1.1.5.2 4 55555 139 165 35 0 0 00:25:49 1

R1#

At R6, let’s tag networks 11.11.11.0/24 and 33.33.33.0/24 with community 55556:666 and include in an outbound filter to R1:

R6:

access-list 10 permit 11.11.11.0 0.0.0.255

access-list 10 permit 33.33.33.0 0.0.0.255

route-map spec_community permit 10

match ip address 10

set community -654048614

router bgp 55556

neighbor 172.16.2.5 send-community

neighbor 172.16.2.5 route-map spec_community out

clear ip bgp 172.16.2.5 soft out

R1:

R1#sh ip bgp 11.11.11.0

BGP routing table entry for 11.11.11.0/24, version 37

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Advertised to update-groups:

55556

172.16.2.6 from 172.16.2.6 (192.168.10.1)

Origin IGP, metric 0, localpref 100, valid, external, best

Community: 55556:666

R1#sh ip bgp 33.33.33.0

BGP routing table entry for 33.33.33.0/24, version 36

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Advertised to update-groups:

55556

172.16.2.6 from 172.16.2.6 (192.168.10.1)

Origin IGP, metric 0, localpref 100, valid, external, best

Community: 55556:666

R1#

Only permitted networks in the access-list 10 will be tagged with 55556:666, the remaining networks are allowed to be advertised through the second route-map statement with sequence number 20.

Here is the route filtering at the router R1

ip bgp-community new-format

ip community-list 10 permit 55556:666

route-map no_community_666 deny 10

match community 10

route-map no_community_666 permit 20

router bgp 55555

neighbor ibgp-pgroup route-map no_community_666 out

R1#clear ip bgp peer-group ibgp-pgroup soft out

The first route-map “deny” statement will block all networks with community that match the community access-list 10 (55555:666)

===> The second route-map “permit” statement will allow advertisement of all remaining networks.

===> Do not forget to allow sending community attribute for the corresponding neighbour.

Let’s check the result from router R2 for instance:

R2#sh ip bgp

BGP table version is 39, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 20.0.0.0/16 0.0.0.0 0 32768 i

*>i22.22.22.0/24 1.1.2.1 0 100 0 55556 i

*>i30.0.0.0/16 1.1.3.2 0 100 0 i

*>i40.0.0.0/16 1.1.4.2 0 100 0 i

*>i44.44.44.0/24 1.1.2.1 0 100 0 55556 i

*>i50.0.0.0/16 1.1.5.2 0 100 0 i

R2#

Networks 11.11.11.0/24 and 33.33.33.0/24 are no more present in all iBGP peers BGP routing table

To implement the second policy statement and demonstrate that peer group members can have different inbound policies, we assigned an access-list that permit networks 20.0.0.0/16 and 40.0.0.0/8 and a new route-map with a first statement that deny the previously defined access-list and a second empty permit statement to allow all other networks, the route-map will be assigned separately to R2 and R4 inbound.

R1:

access-list 10 permit 20.0.0.0 0.0.255.255

access-list 10 permit 40.0.0.0 0.0.255.255

route-map diffrent_in_rmap deny 10

match ip address 10

route-map diffrent_in_rmap permit 20

router bgp 55555

neighbor 1.1.2.2 route-map diffrent_in_rmap in

neighbor 1.1.4.2 route-map diffrent_in_rmap in

BGP routing tables of both R1 and R6 confirm expectations:

R1:

R1#sh ip bgp

BGP table version is 33, local router ID is 1.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 11.11.11.0/24 172.16.0.6 0 0 55556 i

*> 22.22.22.0/24 172.16.0.6 0 0 55556 i

*>i30.0.0.0/16 1.1.3.2 0 100 0 i

*> 33.33.33.0/24 172.16.0.6 0 0 55556 i

*> 44.44.44.0/24 172.16.0.6 0 0 55556 i

*>i50.0.0.0 1.1.5.2 0 100 0 i

*> 192.168.10.0 172.16.0.6 0 0 55556 i

*> 192.168.200.0 172.16.0.6 0 0 55556 i

R1#

R6:

R6#sh ip bgp

BGP table version is 21, local router ID is 6.6.6.6

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 11.11.11.0/24 0.0.0.0 0 32768 i

*> 22.22.22.0/24 0.0.0.0 0 32768 i

*> 30.0.0.0/16 172.16.0.5 0 55555 i

*> 33.33.33.0/24 0.0.0.0 0 32768 i

*> 44.44.44.0/24 0.0.0.0 0 32768 i

*> 50.0.0.0 172.16.0.5 0 55555 i

*> 192.168.10.0 0.0.0.0 0 32768 i

*> 192.168.200.0 0.0.0.0 0 32768 i

R6#

Networks 20.0.0.0/16 and 40.0.0.0/8 disappeared from R1 and R6 BGP routing tables.

Next, we will inspect the difference in behavior between the configuration with and without peer-groups through “debug ip bgp update out” command.

Debug

Debug without peer-group:

R1:

R1#debug ip bgp updates out

BGP updates debugging is on (outbound)

R1#

R1#clear ip bgp 1.1.2.2

R1#clear ip bgp 1.1.3.2

R1#clear ip bgp 1.1.4.2

R1#clear ip bgp 1.1.5.2

R1#

…

*Mar 1 01:20:12.103: BGP(0): 1.1.2.2 send UPDATE (format) 44.44.44.0/24, next 1.1.2.1, metric 0, path 55556

*Mar 1 01:20:12.111: BGP(0): 1.1.2.2 send UPDATE (prepend, chgflags: 0×0) 22.22.22.0/24, next 1.1.2.1, metric 0, path 55556

*Mar 1 01:20:12.115: BGP(0): 1.1.2.2 send UPDATE (prepend, chgflags: 0×0) 33.33.33.0/24, next 1.1.2.1, metric 0, path 55556

*Mar 1 01:20:12.123: BGP(0): 1.1.2.2 send UPDATE (prepend, chgflags: 0×0) 11.11.11.0/24, next 1.1.2.1, metric 0, path 55556

*Mar 1 01:20:12.259: BGP(0): 1.1.2.2 send UPDATE (format) 20.0.0.0/16, next 1.1.2.2, metric 0, path

*Mar 1 01:20:12.267: BGP(0): 1.1.2.2 send UPDATE (format) 30.0.0.0/16, next 1.1.3.2, metric 0, path

*Mar 1 01:20:22.863: BGP(0): 1.1.2.2 send UPDATE (format) 50.0.0.0/16, next 1.1.5.2, metric 0, path

*Mar 1 01:20:22.867: BGP(0): 1.1.2.2 send UPDATE (format) 40.0.0.0/16, next 1.1.4.2, metric 0, path

…

*Mar 1 01:20:12.187: BGP(0): 1.1.4.2 send UPDATE (format) 44.44.44.0/24, next 1.1.4.1, metric 0, path 55556

*Mar 1 01:20:12.195: BGP(0): 1.1.4.2 send UPDATE (prepend, chgflags: 0×0) 22.22.22.0/24, next 1.1.4.1, metric 0, path 55556

*Mar 1 01:20:12.203: BGP(0): 1.1.4.2 send UPDATE (prepend, chgflags: 0×0) 33.33.33.0/24, next 1.1.4.1, metric 0, path 55556

*Mar 1 01:20:12.207: BGP(0): 1.1.4.2 send UPDATE (prepend, chgflags: 0×0) 11.11.11.0/24, next 1.1.4.1, metric 0, path 55556

*Mar 1 01:20:12.215: BGP(0): 1.1.4.2 send UPDATE (format) 30.0.0.0/16, next 1.1.3.2, metric 0, path

*Mar 1 01:20:12.303: BGP(0): 1.1.4.2 send UPDATE (format) 40.0.0.0/16, next 1.1.4.2, metric 0, path

*Mar 1 01:20:12.311: BGP(0): 1.1.4.2 send UPDATE (format) 20.0.0.0/16, next 1.1.2.2, metric 0, path

*Mar 1 01:20:27.979: BGP(0): 1.1.4.2 send UPDATE (format) 50.0.0.0/16, next 1.1.5.2, metric 0, path

…

*Mar 1 01:20:17.719: BGP(0): 1.1.5.2 send UPDATE (format) 44.44.44.0/24, next 1.1.5.1, metric 0, path 55556

*Mar 1 01:20:17.723: BGP(0): 1.1.5.2 send UPDATE (prepend, chgflags: 0×0) 22.22.22.0/24, next 1.1.5.1, metric 0, path 55556

*Mar 1 01:20:17.731: BGP(0): 1.1.5.2 send UPDATE (prepend, chgflags: 0×0) 33.33.33.0/24, next 1.1.5.1, metric 0, path 55556

*Mar 1 01:20:17.739: BGP(0): 1.1.5.2 send UPDATE (prepend, chgflags: 0×0) 11.11.11.0/24, next 1.1.5.1, metric 0, path 55556

*Mar 1 01:20:17.743: BGP(0): 1.1.5.2 send UPDATE (format) 50.0.0.0/16, next 1.1.5.2, metric 0, path

*Mar 1 01:20:17.751: BGP(0): 1.1.5.2 send UPDATE (format) 40.0.0.0/16, next 1.1.4.2, metric 0, path

*Mar 1 01:20:17.755: BGP(0): 1.1.5.2 send UPDATE (format) 20.0.0.0/16, next 1.1.2.2, metric 0, path

*Mar 1 01:20:17.759: BGP(0): 1.1.5.2 send UPDATE (format) 30.0.0.0/16, next 1.1.3.2, metric 0, path

…

R1#

Note that for each neighbor BGP inspect the routing table and advertise the same prefixes separately.

Debug with peer-groups:

R1:

R1#

*Mar 1 04:00:08.019: BGP(0): 172.16.2.6 send UPDATE (format) 50.0.0.0/16, next 172.16.2.5, metric 0, path

*Mar 1 04:00:08.027: BGP(0): 1.1.2.2 send UPDATE (format) 50.0.0.0/16, next 1.1.5.2, metric 0, path

*Mar 1 04:00:08.031: BGP(0): 172.16.2.6 send UPDATE (prepend, chgflags: 0×0) 30.0.0.0/16, next 172.16.2.5, metric 0, path

*Mar 1 04:00:08.039: BGP(0): 1.1.2.2 send UPDATE (format) 30.0.0.0/16, next 1.1.3.2, metric 0, path

*Mar 1 04:00:08.039: BGP(0): 1.1.2.2 send UPDATE (format) 44.44.44.0/24, next 1.1.2.1, metric 0, path 55556

*Mar 1 04:00:08.039: BGP(0): 1.1.2.2 send UPDATE (prepend, chgflags: 0×0) 22.22.22.0/24, next 1.1.2.1, metric 0, path 55556

*Mar 1 04:00:08.139: BGP(0): updgrp 1 – 1.1.2.2 updates replicated for neighbors: 1.1.3.2 1.1.4.2 1.1.5.2

R1#

When advertising updates, the routing table is inspected ONLY ONE TIME, sent to one peer-group member and then duplicated to all other members

Tags: BGP, peer-group

Leave a Comment

January 3, 2009

ORF (Outbound Route Filtering)

Filed under: BGP, Routing protocols — cciethebeginning @ 9:37 am
Tags: BGP, ORF

Generally eBGP speakers filter advertisement separately, the sender applies its outbound filter and the receiver applies its inbound filters to received updates.

The obvious goal of filtering at the receiver is to deny certain prefixes, sent by eBGP peer, according to its own policy… So why send them at all?

ORF (Outbound Route Filtering) is a step further in the cooperation between the two autonomous systems, where the receiver send its inbound filter to the sender to be used as outbound filter, thus avoiding unnecessary updates in the link and CPU resources related to update generation and inbound filtering.

The goal of this LAB is to show the benefit of ORF comparing to the traditional method.

Let’s consider the eBGP connection between R1 and R2 (figure1) , with a an R1 inbound policy allowing only prefix 20.20.10.0/24

Figure1: topology

1) Before Applying ORF:

R1 and R2 configurations look as follows:

R1:

ip prefix-list only_202010 seq 5 permit 20.20.10.0/24

router bgp 65500

neighbor 2.2.2.2 remote-as 65501

neighbor 2.2.2.2 ebgp-multihop 2

neighbor 2.2.2.2 update-source Loopback0

neighbor 2.2.2.2 prefix-list only_202010 in

R2:

router bgp 65501

network 20.20.10.0 mask 255.255.255.0

network 20.20.20.0 mask 255.255.255.0

neighbor 1.1.1.1 remote-as 65500

neighbor 1.1.1.1 ebgp-multihop 2

neighbor 1.1.1.1 update-source Loopback0

1-a) Debug R2 outbound

R2:

R2#debug ip bgp updates out

BGP updates debugging is on (outbound) for address family: IPv4 Unicast

R2#clear ip bgp 1.1.1.1 soft out

R2#

*Mar 1 00:40:43.155: BGP(0): 1.1.1.1 send UPDATE (format) 20.20.20.0/24, next 2.2.2.2, metric 0, path Local

*Mar 1 00:40:43.155: BGP(0): 1.1.1.1 send UPDATE (prepend, chgflags: 0×0) 20.20.10.0/24, next 2.2.2.2, metric 0, path Local

*Mar 1 00:40:43.159: BGP(0): 1.1.1.1 send UPDATE (format) 10.10.10.0/24, next 2.2.2.2, metric 0, path 65500

*Mar 1 00:40:43.159: BGP(0): 1.1.1.1 send UPDATE (prepend, chgflags: 0×820) 10.10.20.0/24, next 2.2.2.2, metric 0, path 65500

*Mar 1 00:40:43.263: BGP(0): updgrp 1 – 1.1.1.1 updates replicated for neighbors:

R2#

1-b) Debug R1 inbound

R1:

R1#debug ip bgp updates in

BGP updates debugging is on (inbound) for address family: IPv4 Unicast

R1#

R1#clear ip bgp 2.2.2.2 soft in

R1#

*Mar 1 00:40:43.487: BGP(0): 2.2.2.2 rcvd UPDATE w/ attr: nexthop 2.2.2.2, origin i, metric 0, path 65501

*Mar 1 00:40:43.487: BGP(0): 2.2.2.2 rcvd 20.20.20.0/24 — DENIED due to: distribute/prefix-list;

*Mar 1 00:40:43.491: BGP(0): 2.2.2.2 rcvd 20.20.10.0/24…duplicate ignored

*Mar 1 00:40:43.491: BGP(0): 2.2.2.2 rcv UPDATE w/ attr: nexthop 2.2.2.2, origin i, originator 0.0.0.0, path 65501 65500, community , extended community

*Mar 1 00:40:43.495: BGP(0): 2.2.2.2 rcv UPDATE about 10.10.10.0/24 — DENIED due to: AS-PATH contains our own AS;

*Mar 1 00:40:43.495: BGP(0): 2.2.2.2 rcv UPDATE about 10.10.20.0/24 — DENIED due to: AS-PATH contains our own AS;

R1#

R1#sh ip bgp

BGP table version is 16, local router ID is 10.10.20.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 10.10.10.0/24 0.0.0.0 0 32768 i

*> 10.10.20.0/24 0.0.0.0 0 32768 i

*> 20.20.10.0/24 2.2.2.2 0 0 65501 i

R1#

2) With ORF feature

2-a) ORF configuration:

R1:

ip prefix-list only_202010 seq 5 permit 20.20.10.0/24

router bgp 65500

neighbor 2.2.2.2 prefix-list only_202010 in

neighbor 2.2.2.2 capability orf prefix-list both

R2:

router bgp 65501

network 20.20.10.0 mask 255.255.255.0

network 20.20.20.0 mask 255.255.255.0

neighbor 1.1.1.1 remote-as 65500

neighbor 1.1.1.1 ebgp-multihop 2

neighbor 1.1.1.1 update-source Loopback0

neighbor 1.1.1.1 capability orf prefix-list both

2-b) debug R2 outbound

R2:

R2#

*Mar 1 00:48:47.367: BGP(0): 1.1.1.1 send UPDATE (format) 20.20.10.0/24, next 2.2.2.2, metric 0, path Local

Note that R2 sent only prefixes allowed in the filter received from R1.

2-c) debug R1 outbound

R1:

R1#

*Mar 1 00:48:47.755: BGP(0): 2.2.2.2 rcvd UPDATE w/ attr: nexthop 2.2.2.2, origin i, metric 0, path 65501

*Mar 1 00:48:47.755: BGP(0): 2.2.2.2 rcvd 20.20.10.0/24

*Mar 1 00:48:47.363: BGP(0): Revise route installing 1 of 1 routes for 20.20.10.0/24 -> 2.2.2.2(main) to main IP table

Note that R1 did not received 20.20.20.0/24 at all.

Tags: BGP

Leave a Comment

December 30, 2008

MED attribute and “hot potato” routing

Filed under: BGP, Routing protocols — cciethebeginning @ 3:11 pm
Tags: Attributes, BGP, Path selection

The purpose of this post is to demonstrates how to use the BGP Best path selection algorithm and manipulate BGP attribute MED (Multi-Exit Discriminator) in the outgoing advertisement traffic to influence the inbound traffic.

Let’s consider the topology depicted in Figure1 under the following conditions:

-Router R7 is the route reflector and R6 and R5 route reflector clients.

- A full mesh iBGP is deployed inside AS65500 between BGP routers R1, R2, R3 and R4.

- Default EIGRP links costs are considered between routers.

- For internal connectivity EIGRP 1234 is the IGP for 65500 and EIGRP 567 is the IGP for 65501.

Figure 1: Lab topology

the network 192.168.10.0/24 is reachable from R7 through 2 paths:

R7:

R7#sh ip bgp 192.168.10.0

BGP routing table entry for 192.168.10.0/24, version 4

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Flag: 0×800

Advertised to update-groups:

65500, (Received from a RR-client)

6.6.6.6 (metric 2297856) from 6.6.6.6 (6.6.6.6)

Origin IGP, metric 0, localpref 100, valid, internal

65500, (Received from a RR-client)

5.5.5.5 (metric 2297856) from 5.5.5.5 (5.5.5.5)

Origin IGP, metric 0, localpref 100, valid, internal, best

R7#

Table1: R7 best path selection for 192.168.10.0/24

	Attribute	Path1	Path2
1	weight	0	0
2	local preference	100	100
3	originated locally	No	No
4	AS_PATH	65500	65500
5	ORIGIN	i	i
6	MED	0	0
7	eBGP<>iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	2297856	2297856
9	Multipath	No	No
10	oldest path	No	No
11	Lowest neighbor router-ID	6.6.6.6	5.5.5.5 <<<

The best route chosen is the route through R5 because of the last criteria (figure2).

R7(config)#do traceroute 192.168.10.1 source 192.168.70.1

Type escape sequence to abort.

Tracing the route to 192.168.10.1

1 192.168.57.1 92 msec 44 msec 160 msec

2 192.168.45.1 256 msec 72 msec 96 msec

3 192.168.14.1 136 msec * 280 msec

R7(config)#

Figure2: paths to 192.168.10.0/24 from R7

In the other side, network 192.168.70.0/24 (AS 65501) is reachable from R1 (AS 65500) through 2 paths (figure3):

R1:

R1#sh ip bgp

BGP table version is 16, local router ID is 192.168.10.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 192.168.10.0 0.0.0.0 0 32768 i

* i192.168.70.0 4.4.4.4 0 100 0 65501 i

*>i 3.3.3.3 0 100 0 65501 i

R1#sh ip bgp 192.168.70.0

BGP routing table entry for 192.168.70.0/24, version 16

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Flag: 0×900

Not advertised to any peer

65501

4.4.4.4 (metric 5639936) from 4.4.4.4 (4.4.4.4)

Origin IGP, metric 0, localpref 100, valid, internal

65501

3.3.3.3 (metric 2809856) from 2.2.2.2 (2.2.2.2)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 3.3.3.3, Cluster list: 2.2.2.2

R1#

Table2: R1 best path selection for 192.168.70.0/24

	Attribute	Path1	Path2
1	weight	0	0
2	local preference	100	100
3	originated locally	No	No
4	AS_PATH	65501	65501
5	ORIGIN	i	I
6	MED	0	0
7	eBGP<>iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	5639936	2809856 <<<
9	~~Multipath~~	No	No
10	~~oldest path~~	No	No
11	~~Lowest neighbor router-ID~~	~~2.2.2.2~~	~~4.4.4.4~~

Links between R1-R2 and R2-R3 are 2mpbs whereas R1 and R4 are connected through a 512kbps link, therefore the tie breaker in the best path selection algorithm was the IGP metric to NEXT-HOP and below attributes are not considered.

figure3: paths to 192.168.70.0/24 from R1

R1#traceroute 192.168.70.1 source 192.168.10.1

Type escape sequence to abort.

Tracing the route to 192.168.70.1

1 192.168.12.2 84 msec 72 msec 96 msec

2 192.168.23.2 104 msec 76 msec 40 msec

3 192.168.36.2 308 msec 184 msec 184 msec

4 192.168.67.2 208 msec * 144 msec

R1#

This type of routing is called “hot potato” or “Early exit” routing, because BGP choose the shortest path to transit traffic through the AS.

Hot potato routing can cause asymmetric routing between the source and the destination (figure4).

Figure4: Asymmetric routing

In case AS 65501 need to send and receive traffic between 192.168.10.0/24 and 192.168.70.0 through R5-R4, we have to manipulate more preferable criteria than IGP metric to NEXT-HOP, MED (Multi Exit Discriminator) for example.

In this case one service provider AS 65501 can SUGGEST to the other to take into account MED criterion so the incoming and the outgoing traffic take the same path, which is a less common practice, this will certainly depend on the policies and negotiations, because each provider goal is to control how traffic enter and exit its AS according to its own needs not other providers needs.

The MED (Multi-Exit-Discriminator) is :

- optional non-transitive attribute.

- an INDICATION, SUGGESTION or a HINT to the neighbor AS about the preferred path for a particular incoming traffic, which is complying with the nature of AUTONOMOUS systems.

- used with dual-homed connections to the same neighbor AS.

Let’s suppose AS65500 will accept to take into account the criterion MED from eBGP peers from 65501 for the prefix 192.168.70.0/24, both border routers R5 and R6 will advertise the internal prefix 192.168.70.0/24 with different MED values (the lowest is the preferred).

R5:

ip prefix-list 70_plist seq 5 permit 192.168.70.0/24

route-map Low_MED_45_pmap permit 10

match ip address prefix-list 70_plist

set metric 10

router bgp 65501

neighbor 4.4.4.4 route-map Low_MED_45_pmap out

R5#clear ip bgp 4.4.4.4 soft out

R6:

ip prefix-list 70_plist seq 5 permit 192.168.70.0/24

route-map High_MED_36_pmap permit 10

match ip address prefix-list 70_plist

set metric 100

router bgp 65501

neighbor 3.3.3.3 route-map High_MED_36_pmap out

R6#clear ip bgp 3.3.3.3 soft out

R4 and R3 has received updates for the prefix 172.168.70.0/24 respectively from R5 and R6 with the different MED which is transmitted further throughout AS 56500 as you can see from R1 routing table:

R1:

R1#sh ip bgp

BGP table version is 21, local router ID is 192.168.10.1

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,

r RIB-failure, S Stale

Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 192.168.10.0 0.0.0.0 0 32768 i

*>i192.168.70.0 4.4.4.4 10 100 0 65501 i

* i 3.3.3.3 100 100 0 65501 i

R1#

R1#sh ip bgp 192.168.70.0

BGP routing table entry for 192.168.70.0/24, version 21

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Flag: 0×920

Not advertised to any peer

65501

4.4.4.4 (metric 5639936) from 4.4.4.4 (4.4.4.4)

Origin IGP, metric 10, localpref 100, valid, internal, best

65501

3.3.3.3 (metric 2809856) from 2.2.2.2 (2.2.2.2)

Origin IGP, metric 100, localpref 100, valid, internal

Originator: 3.3.3.3, Cluster list: 2.2.2.2

R1#

R1#traceroute 192.168.70.1 source 192.168.10.1

Type escape sequence to abort.

Tracing the route to 192.168.70.1

1 192.168.14.2 56 msec 92 msec 64 msec

2 192.168.45.2 108 msec 100 msec 64 msec

3 192.168.57.2 240 msec * 180 msec

R1#

The tie is broken by MED value before reaching the criterion “shortest IGP cost to NEXT-HOP”

Table3: R1 best path selection for 192.168.70.0/24

	Attribute	Path1	Path2
1	Weight	0	0
2	local preference	100	100
3	originated locally	No	No
4	AS_PATH	65501	65501
5	ORIGIN	i	I
6	MED	10 <<<	100
7	~~eBGP<>iBGP~~	~~iBGP~~	~~iBGP~~
8	~~Best IGP metric to NEXT-HOP~~	~~5639936~~	~~2809856~~
9	~~Multipath~~	No	No
10	~~oldest path~~	No	No
11	~~Lowest neighbor router-ID~~	~~2.2.2.2~~	~~4.4.4.4~~

Figure5: symmetric routing

Conclusion:

If your policy doesn’t take into account MED, make sure to explicitly reset it for prefixes received from you multi-homed connection with your peer AS.

Tags: BGP

Comments (1)

CCIE, the beginning!

January 29, 2010

VRF-Lite as an alternative to VPC

November 20, 2009

Interactive BGP troubleshooting

July 27, 2009

Ipv6 NAT-PT Transition

July 24, 2009

Automatic 6to4 Transition

February 27, 2009

OSPF loopback network type

January 19, 2009

BGP link-bw & multipath Load Balancing

January 9, 2009

BGP peer-session and peer-policy templates

January 5, 2009

BGP peer groups

January 3, 2009

ORF (Outbound Route Filtering)

December 30, 2008

MED attribute and “hot potato” routing

Categories

Recent Posts

Tags

Meta

Pages