Tunneling IPv6 over an IPv4 network using GRE:
The topology used was:
R2->R3->R5->R1->R4
|
R6
1 IPv6 network was between R2 and R3. The IPv4 network ran between R3,R5 and R1. The 2nd IPv6 network was between R1, R4 and R6.
IPv4 network:
R3#sh run int s1/0
Building configuration…
Current configuration : 261 bytes
!
interface Serial1/0
ip address 155.1.0.3 255.255.255.0
encapsulation frame-relay
ip ospf hello-interval 1
serial restart-delay 0
no fair-queue
frame-relay map ip 155.1.0.1 305
frame-relay map ip 155.1.0.5 305 broadcast
no frame-relay inverse-arp
end
R1#sh run int s0/0
Building configuration…
Current configuration : 242 bytes
!
interface Serial0/0
ip address 155.1.0.1 255.255.255.0
encapsulation frame-relay
ip ospf hello-interval 1
ip ospf priority 0
frame-relay map ip 155.1.0.3 105
frame-relay map ip 155.1.0.5 105 broadcast
no frame-relay inverse-arp
end
R5#sh run int s0/0
Building configuration…
Current configuration : 283 bytes
!
interface Serial0/0
ip address 155.1.0.5 255.255.255.0
encapsulation frame-relay
no ip route-cache cef
no ip route-cache
ip ospf hello-interval 1
ip ospf priority 100
no fair-queue
frame-relay map ip 155.1.0.1 501 broadcast
frame-relay map ip 155.1.0.3 503 broadcast
end
Normal IPv4 ospf configuration, I only advertised the IP address of each routers loopback interface as can be seen on the hub of the frame-relay network:
R5#show ip route | in O
O 150.1.3.3 [110/65] via 155.1.0.3, 00:12:44, Serial0/0
O 150.1.1.1 [110/65] via 155.1.0.1, 00:12:44, Serial0/0
I configured IPv6 OSPF between R3 and R2.
I also configured IPv6 OSPF between R1, R4 and R6. All routers advertised the IPv6 address of their loopback interfaces.
The addressing schema for R1,R2 and R6 was -
R1 – ipv6 address 2001:155:1:146::1/64
R4 – ipv6 address 2001:155:1:146::4/64
R6 – ipv6 address 2001:155:1:146::6/64
On R1 the IPv6 network was configured as shown below: (similar config is on R4 and R6)
R1#sh run int fas 0/0
Building configuration…
Current configuration : 130 bytes
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
ipv6 address 2001:155:1:146::1/64
ipv6 ospf 1 area 146
end
On R2 and R3’s IPv6 network the addressing schema was:
R2#sh run int s0/1
Building configuration…
Current configuration : 97 bytes
!
interface Serial0/1
no ip address
ipv6 address 2001:155:1:23::2/64
ipv6 ospf 1 area 23
end
R3#sh run int s1/3
Building configuration…
Current configuration : 139 bytes
!
interface Serial1/3
no ip address
ipv6 address 2001:155:1:23::3/64
ipv6 ospf 1 area 23
serial restart-delay 0
clock rate 64000
end
R3#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
150.1.2.2 1 FULL/ - 00:00:37 6 Serial1/3
The same configuration was put onto R1, R4 and R6. R1’s IPv6 OSPF neighbours can be seen below:
R1#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
150.1.6.6 1 FULL/DR 00:00:35 4 FastEthernet0/0
150.1.4.4 1 FULL/BDR 00:00:35 5 FastEthernet0/0
Now that the 2 IPv6 networks seperated by an IPv4 network are configured, we now need to tunnel IPv6 over IPv4 so that both IPv6 networks can communicate with each other.
The tunnel created on R1 and R3 is as follows:
Manual Tunnel using GRE
R1#sh run int tun 13
Building configuration…
Current configuration : 165 bytes
!
interface Tunnel13
no ip address
ipv6 address 2001:155:1:13::1/64
ipv6 ospf 1 area 0
keepalive 1 3
tunnel source Loopback0
tunnel destination 150.1.3.3
end
R3#sh run int tunnel 13
Building configuration…
Current configuration : 165 bytes
!
interface Tunnel13
no ip address
ipv6 address 2001:155:1:13::3/64
ipv6 ospf 1 area 0
keepalive 1 3
tunnel source Loopback0
tunnel destination 150.1.1.1
end
The tunnel came up and IPv6 OSPF adjacencies were formed over the tunnel:
R1#sh ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
150.1.3.3 1 FULL/ - 00:00:33 14 Tunnel13
150.1.6.6 1 FULL/DR 00:00:39 4 FastEthernet0/0
150.1.4.4 1 FULL/BDR 00:00:39 5 FastEthernet0/0
R3#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
150.1.1.1 1 FULL/ - 00:00:34 10 Tunnel13
150.1.2.2 1 FULL/ - 00:00:30 6 Serial1/3
Now R2 can see and ping the loopbacks of the IPv6 OSPF network on the other side of the IPv4 network:
R2#sh ipv6 route ospf
IPv6 Routing Table – 12 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route
I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
OI 2001:150:1:1::1/128 [110/11175]
via FE80::207:50FF:FE0A:AA20, Serial0/1
O 2001:150:1:3::3/128 [110/64]
via FE80::207:50FF:FE0A:AA20, Serial0/1
OI 2001:150:1:4::4/128 [110/11176]
via FE80::207:50FF:FE0A:AA20, Serial0/1
OI 2001:150:1:6::6/128 [110/11176]
via FE80::207:50FF:FE0A:AA20, Serial0/1
OI 2001:155:1:13::/64 [110/11175]
via FE80::207:50FF:FE0A:AA20, Serial0/1
OI 2001:155:1:146::/64 [110/11176]
via FE80::207:50FF:FE0A:AA20, Serial0/1
R2#ping 2001:150:1:4::4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:150:1:4::4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 176/176/176 ms
SUCCESS!!!!
On the IPv4 network, the only traffic seen by the IPv4 routers will be encapsulated GRE packets. I set up an ACL
on R5 matching GRE packets and debugged these. R5 only sees GRE packets:
IP: s=150.1.3.3 (Serial0/0), d=150.1.1.1 (Serial0/0), g=155.1.0.1, len 48, forward, proto=47
IP: tableid=0, s=150.1.1.1 (Serial0/0), d=150.1.3.3 (Serial0/0), routed via FIB
IP: s=150.1.1.1 (Serial0/0), d=150.1.3.3 (Serial0/0), g=155.1.0.3, len 24, forward, proto=47
IP: tableid=0, s=150.1.1.1 (Serial0/0), d=150.1.3.3 (Serial0/0), routed via FIB
Tunneling IPv6 over an IPv4 network using IPv6IP
IPv6IP has less overhead than GRE but it can ONLY carry IPv6 packets unlike GRE. Exactly the same topology was used, the only thing changed was the tunneling mode:
R3#sh run int tun 13
Building configuration…
Current configuration : 170 bytes
!
interface Tunnel13
no ip address
ipv6 address 2001:155:1:13::3/64
ipv6 ospf 1 area 0
tunnel source Loopback0
tunnel destination 150.1.1.1
tunnel mode ipv6ip
end
R1#sh run int tun 13
Building configuration…
Current configuration : 185 bytes
!
interface Tunnel13
no ip address
ipv6 address 2001:155:1:13::1/64
ipv6 ospf 1 area 0
keepalive 1 3
tunnel source Loopback0
tunnel destination 150.1.3.3
tunnel mode ipv6ip
end
Adjacencies are formed over the tunnel:
R3#sh ipv6 ospf nei
Neighbor ID Pri State Dead Time Interface ID Interface
150.1.1.1 1 FULL/ - 00:00:32 10 Tunnel13
150.1.2.2 1 FULL/ - 00:00:33 6 Serial1/3
R2 can again ping across to the other IPv6 network that is seperated by the IPv4 network:
R2#ping 2001:150:1:4::4 sou lo 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:150:1:4::4, timeout is 2 seconds:
Packet sent with a source address of 2001:150:1:2::2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 168/184/236 ms
SUCCESS AGAIN!!!!
The IPv4 tranist routers will only see IP protocol 41 encapsulated traffic:
IP: tableid=0, s=150.1.1.1 (Serial0/0), d=150.1.3.3 (Serial0/0), routed via FIB
IP: s=150.1.1.1 (Serial0/0), d=150.1.3.3 (Serial0/0), g=155.1.0.3, len 100, forward, proto=41
IP: tableid=0, s=150.1.3.3 (Serial0/0), d=150.1.1.1 (Serial0/0), routed via FIB
IP: s=150.1.3.3 (Serial0/0), d=150.1.1.1 (Serial0/0), g=155.1.0.1, len 96, forward, proto=41
If there is any security in your network, you will have to allow IP Protocol 41 through. This isn’t a well know IP Protocol, it doesn’t show under the ACL if you do a:
R5(config)#access-list 100 permit ?
<0-255> An IP protocol number
ahp Authentication Header Protocol
eigrp Cisco’s EIGRP routing protocol
esp Encapsulation Security Payload
gre Cisco’s GRE tunneling
icmp Internet Control Message Protocol
igmp Internet Gateway Message Protocol
ip Any Internet Protocol
ipinip IP in IP tunneling
nos KA9Q NOS compatible IP over IP tunneling
ospf OSPF routing protocol
pcp Payload Compression Protocol
pim Protocol Independent Multicast
tcp Transmission Control Protocol
udp User Datagram Protocol
Dynamic Tunneling using Automatic 6to4 Tunneling
The trick here is to use the correct IPv4 address on the border routers and then convert this to an IPv6 address.
Whatever you configure as the tunnel SOURCE, this will be the IPv4 address you convert.
The 2 border routers must have connectivity to each others IPv4 address that they are using as the source of the tunnel (exactly like all the other IPv6 over IPv4 tunneling methods)
The exact same topology is used as in all the other tunneling configurations.
For R3, I’m going to use its loopback interface as the source for the tunnel. Therefore, any IPv6 networks that
connect directly to R3 will have to use a subnet of this converted address. So, R3’s loopback IPv4 address is
150.1.3.3. Converted to hex this is:
9601:0303
All IPv6IP 6to4 tunnels always use the Format Prefix of 2002, this FP is reserved just for automatic 6to4 tunnels.
So we now add 2002 to the converted IPv4 address:
2002:9601:0303/48 – This is the network address will we use to subnet down. We need to use this address because the destination of any packet is derived from the converted IPv4 address. This will become a bit clearer (hopefully) further on. It took a while for me to get my head around it!
So for the R3 to R2 link I have used the following IPv6 subnet:
2002:9601:0303:0023::3/64 – For R3
2002:9601:0303:0023::2/64 – For R2
I configure OSPF between these 2, and originate a default route from R3 as this is the border router.
On R1, for the R1, R4, R6 IPv6 network I will base the addressing schema on R1’s loopback address as this is going to be the IPv4 source address of the tunnel between it and R3:
R1’s loopback address is 150.1.1.1. Converted to hex it is:
9601:0101 – I will now add the 2002 FP for automatic 6to4 tunnels:
2002:9601:0101::/48 – This is now used to subnet from for IPv6 networks that connect directly to R1.
So for the R1,R4,R6 IPv6 network the addressing schema is:
2002:9601:0101::0146::1/64 – R1
2002:9601:0101::0146::4/64 – R4
2002:9601:0101::0146::6/64 – R6
I have configured OSPF between these.
Now for the tunnel between R1 and R3:
R3#sh run int tun 13
Building configuration…
Current configuration : 160 bytes
!
interface Tunnel13
no ip address
no ip redirects
ipv6 address 2002:9601:303:13::3/64 – MUST BE BASED ON THE CONVERTED IPV4 ADDRESS (I used the loopback interface)
keepalive 1 3
tunnel source Loopback0
tunnel mode ipv6ip 6to4
end
R1#sh run int tun 13
Building configuration…
Current configuration : 160 bytes
!
interface Tunnel13
no ip address
no ip redirects
ipv6 address 2002:9601:101:13::1/64 – MUST BE BASED ON THE CONVERTED IPV4 ADDRESS (I used the loopback interface)
keepalive 1 3
tunnel source Loopback0
tunnel mode ipv6ip 6to4
end
The tunnel doesn’t need a destination, it gets this from the converted IPv4 address!
On both border routers create a static route for any traffic going to 2002::/16 use tunnel 13.
Now what happens if traffic is sent from R2 to R6. R2 will send to R3 because of the default route. R3 will now
look inside the IPv6 destination address (2002:9601:0101::0146::6) and convert the 32 bits after the 2002 prefix back to the IPv4 address. So this is converted to 150.1.1.1. R3 looks and see’s if it has a route to 150.1.1.1,
it has via OSPFv2. This is R1’s IPv4 address of it’s loopback. This is then sent over the tunnel to R1 who passes it on to R6.
Any IPv4 transit routers will only see IPv4 traffic. Based on the IPv6 destination address the border routers will know it needs to be tunneled within the IPv4 network.
From R2, I can ping/trace across to R6 who is in the IPv6 network that is seperated from R2 by the IPv4 network between R3, R5 and R1
R2#ping 2002:9601:101:146::6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:9601:101:146::6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 168/171/180 ms
R2#traceroute 2002:9601:101:146::6
Type escape sequence to abort.
Tracing the route to 2002:9601:101:146::6
1 2002:9601:303:23::3 20 msec 24 msec 24 msec
2 2002:9601:101:13::1 132 msec 132 msec 132 msec
3 2002:9601:101:146::6 132 msec 132 msec 132 msec
R2#
BGP
BGP Outbound Route Filtering:
This allows the customer to tell the ISP which routes it wants the ISP to send to it. I gives the customer complete control over the received routes, it also saves on the customer’s router resources as it won’t have to filter any unwanted routes itself.
The commands needed:
Customer:
router bgp 3
address-family ipv4
neighbor 155.1.146.1 activate
neighbor 155.1.146.1 capability orf prefix-list send
neighbor 155.1.146.1 prefix-list VLAN5 in
!
ip prefix-list VLAN5 seq 5 deny 155.1.5.0/24
ip prefix-list VLAN5 seq 10 permit 0.0.0.0/0 le 32
ISP
router bgp 2
address-family ipv4
neighbor 155.1.146.4 activate
neighbor 155.1.146.4 capability orf prefix-list receive
With the command “neighbor 155.1.146.1 prefix-list VLAN5 in” on the customer, I was getting a bit confused. What
is the point of using ORF, when this prefix-list alone will filter unwanted routes. It will, but the customer will
receive all routes and THEN filter. With ORF, the prefix-list is sent to the ISP, IT filters and then sends only the permitted prefixes as stated in the prefix list. You can check it is working with the “show ip bgp neighbor 1.2.3.4 advertised-routes” command on the ISP router.
Summary routes
When advertising an aggregate with BGP, even though there is a subnet for the aggregate in the routing table, but not in the BGP table, the aggregate won’t get advertised!! I found this out after wondering why an aggregate wasn’t being advertised!! I thought that it only had to be in the IP routing table…obviously not!!!!
Before I advertised the component subnets out:
R1#show run | s bgp
router bgp 2
bgp log-neighbor-changes
neighbor 155.1.13.3 remote-as 2
neighbor 155.1.146.4 remote-as 1
!
address-family ipv4
neighbor 155.1.13.3 activate
neighbor 155.1.13.3 next-hop-self
neighbor 155.1.146.4 activate
no auto-summary
no synchronization
aggregate-address 10.0.0.0 255.252.0.0
R1#show ip route connected
155.1.0.0/24 is subnetted, 4 subnets
C 155.1.146.0 is directly connected, FastEthernet0/0
C 155.1.13.0 is directly connected, Serial0/1
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.0.0.0/16 is directly connected, Loopback1
C 10.1.0.0/16 is directly connected, Loopback2
R1#show ip bgp
BGP table version is 1, local router ID is 10.1.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
Afterwards:
R1#show ip bgp
BGP table version is 6, local router ID is 10.1.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/16 0.0.0.0 0 32768 i
*> 10.0.0.0/14 0.0.0.0 32768 i
*> 10.1.0.0/16 0.0.0.0 0 32768 i
BGP Suppress-Map
When advertising an aggregate and you want to advertise all or some of the sub-component subnets, use a suppress map.
The used the following config:
R1#show run | s bgp|prefix-list|route-map
router bgp 2
network 10.0.0.0 mask 255.255.0.0
network 10.1.0.0 mask 255.255.0.0
aggregate-address 10.0.0.0 255.252.0.0 suppress-map AGG
!
ip prefix-list AGG seq 5 permit 10.0.0.0
!
route-map AGG permit 10
match ip address prefix-list AGG
What this will do is advertise the sub-component subnet 10.1.0.0/16 along with the aggregate prefix whilst suppressing all other subnets. It can be a bit confusing on what the suppress map will be doing. I think of it as the suppress-map is permitting the subnets to be suppressed. If matched with a deny statement, they will be advertised. If matched with a permit statement, they will be suppressed.
BGP Unsupress-Map
This is configured on a per neighbour basis. You can advertise the summary and specific component subnets. Very useful if you want traffic going to one destination in your AS to use one uplink, and traffic to another destination in your AS to use another uplink.
BGP Advertise Map with Aggregate-Address
If the sub-component prefixes come from different AS’s and the router that is aggregating needs to send the
aggregate back out to some of the AS’s, if the AS-SET is used, those AS’s will not accept the aggregate as they
will see their own AS in the AS-SET.
To get around this you can use an advertise map. Say I have a hub and spoke topology and R5 is the hub with R1,
R2, R3, R4 as spokes. The sub-component prefixes come from these AS’s, I want to include the AS SET but I only
want to send the aggregate to R2 and R4:
R1 is advertising 155.1.0.0
R2 is advertising 155.2.0.0
R3 is advertising 155.3.0.0
R4 is advertising 155.4.0.0
R5 is advertising 155.5.0.0
On R5 I used:
router bgp 5
aggregate-address 155.0.0.0 255.248.0.0 summary-only as-set advertise-map R2_AND_R4
network 155.5.0.0 mask 255.0.0.0
!
ip prefix-list R2_AND_R4 permit 155.2.0.0/16
ip prefix-list R2_AND_R4 permit 155.4.0.0/16
!
route-map R2_AND_R4 deny 10
match ip address prefix R2_AND_R4
route-map R2_AND_R4 permit 20
!
R2 and R4 will receive the aggregate from R5 because their own prefixes are being denied from being sent out.
Therefore their prefixes will not make up part of the aggregate and their AS path won’t show in the AS-SET so they
will accept the summary. R1 and R3 will see their own AS in the AS-SET and discard the route.
Amount of time studying today – 5hrs 56 mins
Total Studying hours so far since starting this blog – 84hrs 23mins
