Archive

Archive for December, 2011

Happy new year!

December 31, 2011 3 comments

Here is to a great 2012 for everyone reading this blog. I hope all your dreams come true in 2012. I will only make one new years resolution. I will become a CCIE in 2012.

Happy new year!

Advertisements
Categories: Announcement Tags:

Merry X-mas!

December 23, 2011 Leave a comment

Wanted to wish everyone a merry christmas. I’ve been labbing a lot lately and today I finished the Vol1 security section. I have MPLS, IP services and Applications left. I might do some revision of QoS as well. I’m trying hard to be in good shape for the lab but time is not on my side. So far I have spent 800h preparing for the CCIE.

I’m taking a few days off to charge my batteries and I’ll be back next week.

Merry christmas and a happy new year to everyone!

Categories: Announcement, CCIE Tags: ,

Quiz – AAA authorization

December 18, 2011 6 comments

I’m doing the security section of Vol1 right now and this is something I think people might have confused. Look at the following configuration:

! Scenario 1
aaa authentication login default group tacacs+ none
aaa authorization exec default none
!
line console 0
privilege level 15
! Scenario 2
aaa authentication login default group tacacs+ none
aaa authorization exec default if-authenticated
!
line console 0
privilege level 15

Assume that the Tacacs+ servers are unavailable. What will be the result and what is the difference between scenario 1 and 2? Post your answer in comments.

Categories: CCIE, Security Tags: , , ,

Frame-relay IPv6 speed drill

December 13, 2011 4 comments

Going for the lab we need both speed and skills. I made a simple IPv6 frame-relay lab that should test your speed. Time yourself and post your time to configure in the comments. Just by looking at the time I could probably tell if you are typing manually or not. This is the scenario.

Routers R1, R2, R3 and R4 are connected to a frame-relay cloud. They are all spokes connecting to the hub R5. R1 has a DLCI 105 to R5 which is 501 from R5 POV. R2 has a DLCI that is 205 and 502 from R5 POV and so on. This is the task.

Configure all devices with a global address of 2001:1:0:1234::Y where Y is the device number.
Configure static mappings on all devices.
All devices should be able to ping each other.

Download the .net from here and then edit for your IOS version and working dir etc.

I didn’t time myself but I think I could do it in less than 2 minutes for sure. Later I will post some tips on how to improve speed.

Followup on multicast helper map

December 9, 2011 Leave a comment

I had some requests for the final configs so I have fixed those. You can download them here. Also I had some issues getting the traffic through but thanks to my helpful readers like zumzum I now have it figured out.

Lets start on R4 since this is the source of the traffic.

R4 wants to send traffic to 1.1.1.1 with a source of 155.1.12.4. We know that route via RIP and the next-hop is 155.1.12.1. That network is directly connected (secondary). We need to find out the MAC address of 155.1.12.1 for our ARP entry. R3 has proxy arp enabled, which is the default. However it will not respond to R4 ARP request since it does not have the subnet 155.1.12.0/24 connected. R4 must therefore have a static ARP entry. I did an error here earlier by typing in R1 MAC but this should be the MAC of R3 Fa0/0 since that is the link connecting us. We create the static ARP with arp 155.1.12.1 xxxx.xxxx.xxxx arpa. R4 now has all the info needed.

Packet travels to R3. R3 does not have a route for 1.1.1.1. We create a static route, ip route 1.1.1.0 255.255.255.0 155.1.23.2. We also need a static route back to R4 for the 155.1.12.4 IP. Ip route 155.1.12.4 255.255.255.0 155.1.34.4.

Packet now travels to R2. R2 also needs to know about 1.1.1.1 so we add a route there as well. Ip route 1.1.1.0 255.255.255.0 155.1.12.1. R2 also needs to find its way back to R4 so we add a static route, ip route 155.1.12.4 255.255.255.255 155.1.23.2.

Packet goes to R1 which will respond. It will send the packet out Fa0/0. R1 needs to know the MAC address for 155.1.12.4. R2 has proxy ARP enabled so it will reply with its own MAC address to R1. R1 will insert this into ARP cache and adjacency table and then we are good to go.

So except learning a multicast feature we also got to practice how to make connectivitiy in an unusual way and think through the whole process of packet flow.

Categories: CCIE, Multicast Tags: ,

Multicast helper map and how to verify multicast

December 8, 2011 7 comments

The multicast helper map is an interesting feature. It can be used in scenarios where we want to transport broadcast. Routers don’t forward broadcast by default but we can convert this to multicast and transport it across our network and then convert it back to broadcast. Might not be that common in real life if you don’t work at a stock exchange but is fair game for the lab and a topic that we should not be surprised to see at the lab.

So the basic idea is to convert broadcast packets, transport them as multicast and then convert it back to broadcast. First lets look at our topology.

Multicast helper map topology

The idea here is to take broadcast coming from R1 in on R2 Fa0/0, convert it to multicast. Transport it to R3 which then converts it back to broadcast and sends it out to R4. Using this technology we can actually exchange routes between non adjacent routers, pretty cool?

You can download a .net file and initial configs for the routers here.

This is our assigned task:

Create a Loopback99 interface on R1 and assign it an IP address of 1.1.1.1/24; advertise this network on R1 using RIP v1 via FastEthernet0/0.

Configure R4 to receive the RIP advertisements from R1. You must use a multicast solution for this. In other words you may not configure solutions involving tunnel interfaces, enable RIP elsewhere than R1 and R4, use bridging, IPsec, magic, etc.

· Use PIM dense mode only.

· You may use a secondary IP address of 155.12.1.4/24 as part of your solution.

· Use access list 120 for any lists you need.

· You do not need to be able to ping 1.1.1.1 from R4

· Use the multicast group 224.9.9.9

So we start by configuring R1. RIP version 1 is broadcast only and it does not include the subnet mask. All we need to do on R1 is configure RIP. We simply announce the network and leave the default settings which is to announce with version 1 and receive version 1 or 2. All the magic will happen on R2 and R3.

Then we proceed to configure R2. This is where most of the magic happens. We need to enable PIM dense mode on both Fa0/0 and S0/0. To be able to process switch the UDP RIP packets coming in we need to configure ip forward-protocol udp rip. Then we will configure the multicast helper map. Lets have a look.

So broadcast coming in on Fa0/0 matching access-list 120 is converted to multicast with a destination of 224.9.9.9. We are running PIM dense mode so later we should be able to see (S,G) entries in the mroute table.

We proceed to configure R3. The config will be very similar to R2.

On R3 we convert back 224.9.9.9 to the broadcast address of the segment between R3 and R4. We need to turn on directed broadcast otherwise we will not be allowed to send this packet out.

On R4 we simply turn on RIP. We were allowed to create a second subnet but lets wait with that.

So now everything should be running. However, we will have some issues. I am not running any IGP between R2 and R3. R3 will not know how to reach the source 155.1.12.1 so we will have a RPF failure which you can see below.

We can also see this if we check the mroute counters.

So how can we fix the RPF failure? We have a few different options. Either we need to run an IGP between R2 and R3 or we could add a static route or we could add a static mroute. This time I chose to use a static mroute because it is easy. Lets add that.

Now the traffic should be reaching R4. However the RIP rout will not be installed. This is because RIP validates the update source. If we receive an update from a non locally connected source the update will not be accepted. We can configure RIP to not validate the update source or we can configure a secondary IP address in same subnet as the source (we were allowed to do this according to the task).

Now we have the route installed. What will the multicast routing table look like? Lets look at R2 and R3. Since we are running dense mode we should only have (S,G) entries.

R2 has the (S,G) entry as expected. It has a flag of T since it is a SPT tree. We don’t have an incoming RPF neighbor since R1 is not running PIM.

Now we will look at R3.

We have R2 as the incoming RPF neighbor. RPF is done via static mroute. We have no outgoing interface. This is usually bad but since we are converting back to broadcast this is OK. If we do a debug of mpacket we will see an error message that OIL is null.

We have completed our task and if this was the lab we would stop here. To take it to the next step lets think what we would need to be able to have reachability from R4 to R1 loopback.

As we can see route recursion fails since we don’t know how to reach 155.1.12.1. Earlier we used a hack to not validate the update source. Lets remove this and add the secondary subnet to R4 instead.

Now the route recursion is working. R4 is using outgoing interface Fa0/0. This is Ethernet so we need to encapsulate the packet and send it to R1 MAC address. Usually we would send ARP request but the devices are not locally connected. Lets try adding a static ARP entry.

Traffic should be able to reach R3. R3 will not know how to reach 1.1.1.1 though. I’ll add static routes on R3 and R2.

Finally I’ll also add a static ARP entry on R1.

Now lets try a ping. It didn’t work. No matter how I try by adding static ARP entries and the correct routes I could not get the ping to succeed. I even tried on R4 to source traffic from 155.1.12.4 but that did not work either. I could see the traffic leaving R4 but not entering on R3. Very strange. If you have any suggestions post them in the comments section.

Categories: CCIE, Multicast Tags: , , ,

Common misconceptions about the ip mroute command

December 2, 2011 Leave a comment

Almost all of us know the difference between a static route and a dynamic one, longer match wins. If same length then AD decides and so on.

I have noticed that there are some misconceptions about the equivalent to ip route in multicast, the ip mroute command. One would assume that it works the same way as ip route but it does not.

First, when we are talking about multicast it is pretty much the opposite of regular routing since we care about the source of the packet instead of the destination. In multicast we check that incoming packets are coming in on the interface we would use to send traffic back to the source, the RPF check. It’s basically the same check that can be used for security reasons to avoid spoofing.

Sometimes we have assymmetric routing meaning that the source send traffic in on an interface we are not using to send traffic back to the source. This means we will have a RPF failure and traffic will be dropped. We can solve this by reconfiguring IGP or putting in a static mroute.

So many people think, “Oh I’ll just put in a mroute and traffic MAY come in that interface as well”. The error here is that mroute tells that traffic MUST come in on that interface. So it might not be the quick fix you thought it would be. Another common error is that you put a broad mask or a default route like 0.0.0.0 0.0.0.0. In regular routing anything with a longer match would override the static default but with the mroute the default route takes precedence over IGP routes. The reason is that the AD is lower and the longest match does not apply here. So maybe you just had problems with one source before and now you have problems with all sources except for that one which you just fixed.

If you put several mroute statements in then longest match will apply since the AD will be the same. The easiest way of checking what interface is the RPF interface for a source is to use the show ip rpf command. This command will show what is the RPF interface and where the information was sourced from (IGP or static).

I hope this post has cleared some of the common misconceptions of the static mroute.

Categories: CCIE, Multicast Tags: , , ,