IPv6 6to4 Tunnels

Today I configured another type of IPv6 tunnels used to alleviate the headaches of switching to an entirely different IP format in a network! It's called a 6to4 tunnel and it does exactly what the name says. It encapsulates a Ipv6 address within a IPv4 packet so that it can use the IPv6 address locally and still travel across a IPv4 network. Do to the nature of this type of tunnel, it doesn't need to be configured on both ends of the tunnel since it's not considered a point-to-point link. To configure a 6to4 tunnel I used this simple command:

First I configured the logical tunnel:

R1 (config)# interface tunnel 0
R1 (config-if)# tunnel mode ipv6ip 6to4
R1 (config-if)# ipv6 address ipv6 address
R1 (config-if)# tunnel source interface
R1 (config-if)# exit

Second I configured a static route to point towards my tunnel:

R1 (config)# ipv6 route ipv6 address tunnel 0

This tells the router to send this particular IPv6 address out tunnel 0 and tunnel 0 routes this interface out of the source interface.

Using IPv6 Tunnels

Today's study session consisted of creating a Ipv6 Tunnel connection between two routers. OSPF IPv6 was also configured for the loopback interfaces on routers R1 and R3 to talk to each other. This lab was fairly straightforeward and allowed for me to play around with tunnel interfaces a little bit. I come across tunnel interfaces quite a bit in my current job role so it was good getting some practice in with configuring them even if they were IPv6 tunnels which aren't to common yet in most networks! My next IPv6 lab will be on configuring 6 to 4 tunnels which is a tunnel that allows you to encapsulate IPv6 address into a IPv4 packet to traverse over a network. This is particularly useful in networks that haven't migrated to IPv6 completely yet (which is most networks).

Configuring OSPF for IPv6

I'm finally on the last chapter in the CCNP Portfolio book which covers IPv6 topics. Today's lab was dealt with configuring the many types of IPv6 address (link-local, EUI-64, etc). The lab ended with configuring OSPF over IPv6 along with a challenge lab. The challenge lab consisted of summarizing two IPv6 addresses over OSPF. All in all it was very straight foreword, when it comes to configuring IPv6 I noticed that it's very similar to it's older brother IPv4 except the order you place commands and the way you implement them on your router device. I was very surprised honestly that it worked over the switch as well, I figured the GNS3 switch wouldn't understand how to interpret the IPv6 address in its MAC table but I was wrong thankfully.

Multilinks Revisted

So I wasn't able to work through one of my CCNP Portfolio labs this morning so I subsituted with something I deal with commonly..multilinks. I've posted on this topic before and it's really straight forward to configure. Basically your load-balancing data across all of your T1 links in a simple but effective manner. You do this through the use of the PPP protocol and a logical interface called a Multilink (go figure). Say you have a business that wants to use 3 Mb of data rather than the standard 1.5 Mb, you can take their 2 serial interfaces and bundle them into one with two simple commands:

ppp multilink
ppp multilink group

You also have to create the multilink interface and assign the multilink the designate IP address as shown above. Thanks to GNS3-labs and Evil Routers for today's lab.

Multicasting Dense Mode

I spent a good part of my morning working my way through the second multicast lab in the CCNP portfolio book the best I could. Since I didn't have a real switch that could emulate SVI (I don't think) I had to use GNS3 the best I could for the IGMP snooping. Multicast is by far the hardest topic for me so far and I still don't understand it honestly. I know enough to get by but it's still very confusing and works differently then any of the routing protocols. I did understand a little more about how the multicast tree is built however using other routing protocols are RPF (reverse-path forwarding). this will for sure be a topic I'll have to spend extra time on understanding, tomorrow is another multicast lab using PIM sparse mode instead of dense mode.

BGP Policy Based Routing

I had a lot of trouble with this lab and was very confused and overwhelmed quickly trying to get the BGP routes to traverse correctly through the main SanJose router. The SaneJose2 router was supposed to be the back T1 and all traffic coming in and out should only flow through the main SanJose router. While I was able to get mostly everything working, I had problems getting the local preference settings to work right and I had RIB failures on top of that in my routes which is never a good thing lol. I'll have to come back to this lab or work through some other BGP labs to figure out what I was missing or doing wrong.

BGP AS_PATH Attribute

I've been working through the BGP section in the CCNP Lab Portfolio book over the past week. This morning I went over a short lab regarding the AS_PATH Attribute. It's kind of strange that the BGP labs have been the shortest labs so far, you would've thought BGP would of been a pretty big section.

As other people mentioned, this chapter has a lot of mistakes and it makes the configuration of the labs confusing. You don't know if it's you not configuring the routers right or the book giving the wrong information.

Even still I managed to get through this chapter which consisted of created a special BGP access list with the use of "regular expressions".

I configured the following regular expression access list on the ISP router:

ISP(config)#ip as-path access-list 1 deny ^100$
ISP(config)#ip as-path access-list 1 permit .*

ISP(config)#router bgp 300
ISP(config)#neighbor 172.24.1.18 filter-list 1 out

Tomorrow's BGP lab seems to be longer than the other labs so we'll see just how much material I'll have to work through. I shouldn't be able to finish a full BGP lab in 15 minutes...not yet anyways :)