www.packet-forwarding.net

I have finally moved over to a dedicated webspace instead of wordpress.com. I hope everybody will update their links to point towards: http://www.packet-forwarding.net

Ill see you all over there!

Only last week i attended a mandatory briefing of Lync, Microsofts all-in-all wonder for communicating.

Basically its a PBX, IM-server, Video-conferencing, Outlook-Integrator kind of a product.

Basically they have taken alot of code from alot of different half-done products and thrown them into one big pile and put alot of marketing money behind it.

Going beyond my own personal beliefs about Microsoft, the one big issue i have with Lync was the fact that they dont have a single product for the smartphone market. Not windows mobile/7 OS, not Android and ofcourse not an iOS app.

How do you expect to have a total solution when you are missing out on the device that people have on them constantly? — To me thats insane.

The guy couldnt even confirm whether work was under way for anything even remotely like it. The thing that came closest was the fact that you can log into a web-page and see your contacts. Really, thats it?

I only hope that with the purchase of Skype they will be able to implement a decent client for smartphones.

With that note. I will let you all get on with your day! — Take care.

Having been a consultant for a while now, i am constantly amazed at how solutions are made up and what is sold simply because it has a buzz-word in its title or description.

For example. A salesperson selling a firewall because it has “Intrusion Prevention” listed down the list in its feature-set. Most companies we deal with dont have the resources nor the need to deploy any form of IPS solution.

I know this is what makes a good sales-person, but its what irks me as a technician. Ofcourse i like to play with shiny new toys. But believe it or not, i do have a consciousness…

Another example: “The client must have a QoS policy!” – Why? are there any technical advantages the customer will gain because of it? would it be better to simply buy a bigger pipe for the money saved?

A real life example of this happened to me a few weeks back. A client only used their MPLS network to carry voice traffic. Nothing else! To that extend the provider took the same approach and simply oversold the solution by adding a hefty “fine” for each MPLS VPN location – Read: a fine thats 90% of the cost of the line itself. I noticed this, and asked what good it would do for me. The response was “We give your voice data priority”. While that might be true internal to their backbone, if they have promised me a 10Mbit MPLS and they seem incapable of providing me this with the latency SLA they have signed, then they are breaching their own SLA anyways. Why should the client pay extra to make sure the ISP provides the service they promised in the first place?

So a client, with say, 50 employees. Do they really need a redundant vmware setup with the newest cpu generations, including fiber channel storage and so on and so forth?

Maybe. But would it be better to ask the client to spend the same amount of money and spend more hours with the client, testing with them, make failover scenarios, do a great documentation that both parties can live with?

Often alot of money are poured into the hardware of the solutions instead of spending money where it really matters, namely putting it all together and working like its supposed to, or even better, like the customer expects it to. I know its harder to sell, but its the right thing to do.

Maybe. What im getting at, is that the solution should match the problem. Roughly. Sometimes it really is best to think a bit ahead and make sure that the clients needs are covered for a while. But dont make it any more complex, expensive or redundant than it has to be!

– END OF RANT –

Just thought i would let off some steam

Anyways, there are lots of items on that darn list and going through them all takes alot of time.

I have also been messing around with multicast and using BGP for RPF verification. One thing that i got down was from reading a passage in Developing IP multicast networks, namely that the network advertised in BGP is for the SOURCE only.

Tomorrow is another day of Mock lab. It was supposed to be today, but i overslept, so i had to modify my plan. The plan im trying to follow is a monthly plan that should last until my next lab attempt. I need to follow the structure instead of haphazardly poking a stick at different topics.

Also, Narbiks Vol II labs are pretty good at giving you the fundamentals of a certain technology. To make sure i got the technologies down from the Detailed Blueprint, im using those labs to give some inspiration.

Well, back to the terminal. See you later.

Using frame-relay, bandwidth is especially a concern.
It is possible to optimize this bandwidth in several ways.

I will concentrate this post about compression and fragmentation.

First off, with compression on frame-relay there several methods of accomplishing this.
You can have payload compression, tcp compression and RTP compression. How they are each
configured depends on your interface.

I will show how all of these are configured using a mix of point-to-point and multipoint interfaces.

Fragmentation is fundamentally a method to “chop up” packets when they reach a certain size. This feature is
also configured differently depending on the interface type. Again, i will show this on both types of interfaces.

Topology

R1:
R1#sh run int s0/0
Building configuration...

Current configuration : 117 bytes
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 no frame-relay inverse-arp
end

R1#sh run int s0/0.12
Building configuration...

Current configuration : 140 bytes
!
interface Serial0/0.12 point-to-point
 ip address 12.12.12.1 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 102
end

R1#sh run int s0/0.13
Building configuration...

Current configuration : 146 bytes
!
interface Serial0/0.13 multipoint
 ip address 13.13.13.1 255.255.255.0
 snmp trap link-status
 frame-relay map ip 13.13.13.3 103 broadcast
end

and R2:

R2#sh run int s0/0
Building configuration...

Current configuration : 117 bytes
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 no frame-relay inverse-arp
end

R2#sh run int s0/0.12
Building configuration...

Current configuration : 140 bytes
!
interface Serial0/0.12 point-to-point
 ip address 12.12.12.2 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 201
end

And finally R3:

R3#sh run int s0/0
Building configuration...

Current configuration : 184 bytes
!
interface Serial0/0
 ip address 13.13.13.3 255.255.255.0
 encapsulation frame-relay
 clock rate 2000000
 frame-relay map ip 13.13.13.1 301 broadcast
 no frame-relay inverse-arp
end

And lets verify reachability before we start messing about with things:

R1#ping 12.12.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.12.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/32/76 ms

R1#ping 13.13.13.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13.13.13.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/28/68 ms

Great. Now we are ready to apply some things.

First of, lets add some compression to payload traffic on our p2p interface towards R2.

On the subinterface itself, you can simply specify directly that you want to enable compression.

Check out your options:

R1(config-subif)#frame-relay payload-compression ?
  FRF9              FRF9 encapsulation
  data-stream       cisco proprietary encapsulation
  packet-by-packet  cisco proprietary encapsulation

They each work differently and with varying results. I will leave it up to you to figure out more about the individual algorithms they use.

For now, lets use packet-by-packet compression which is more CPU intensive than the rest of them.

R1(config-subif)#do ping 12.12.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.12.12.2, timeout is 2 seconds:
..

We are getting timeouts. Why?

Well, compression is a two way thing. It must be configured on each side of the PVC in order to maintain reachability.
Verify the compression by using:

R1#sh compress
 Serial0/0
         Software compression enabled
         uncompressed bytes xmt/rcv 500/0
         compressed bytes   xmt/rcv 206/0
         Compressed bytes sent:       206 bytes   0 Kbits/sec  ratio: 2.427
         Compressed bytes recv:         0 bytes   0 Kbits/sec
         1  min avg ratio xmt/rcv 1.633/0.000
         5  min avg ratio xmt/rcv 1.633/0.000
         10 min avg ratio xmt/rcv 1.633/0.000
         no bufs xmt 0 no bufs rcv 0
         resyncs 0
         Additional Stac Stats:
         Transmit bytes:  Uncompressed =        0 Compressed =        206
         Received bytes:  Compressed =          0 Uncompressed =        0
		

So its sending compressed information to the other side, but getting nothing back.

Lets configure R2 to use compression as well.

R2(config)#int s0/0.12
R2(config-subif)#frame-relay payload-compression packet-by-packet

Now, lets try a ping test from R1 again:

R1#ping 12.12.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.12.12.2, timeout is 2 seconds:
!!!!!

Looks great. Lets check out the compression statistics on both R1 and R2:

R1#sh compress
 Serial0/0
         Software compression enabled
         uncompressed bytes xmt/rcv 1400/1000
         compressed bytes   xmt/rcv 581/412
         Compressed bytes sent:       581 bytes   0 Kbits/sec  ratio: 2.409
         Compressed bytes recv:       412 bytes   0 Kbits/sec  ratio: 2.427
         1  min avg ratio xmt/rcv 0.941/0.771
         5  min avg ratio xmt/rcv 0.941/0.771
         10 min avg ratio xmt/rcv 0.941/0.771
         no bufs xmt 0 no bufs rcv 0
         resyncs 0
         Additional Stac Stats:
         Transmit bytes:  Uncompressed =        0 Compressed =        581
         Received bytes:  Compressed =        412 Uncompressed =        0
		

And R2:

R2#sh compress
 Serial0/0
         Software compression enabled
         uncompressed bytes xmt/rcv 1000/1000
         compressed bytes   xmt/rcv 412/415
         Compressed bytes sent:       412 bytes   0 Kbits/sec  ratio: 2.427
         Compressed bytes recv:       415 bytes   0 Kbits/sec  ratio: 2.409
         1  min avg ratio xmt/rcv 0.758/0.741
         5  min avg ratio xmt/rcv 0.801/1.063
         10 min avg ratio xmt/rcv 0.801/1.063
         no bufs xmt 0 no bufs rcv 0
         resyncs 0
         Additional Stac Stats:
         Transmit bytes:  Uncompressed =        0 Compressed =        412
         Received bytes:  Compressed =        415 Uncompressed =        0
		

We can actually see that the routers have not transmitted anything that is not being compressed.

Before we move on, lets verify R1s connectivity to R3 again, just to be sure:

R1#ping 13.13.13.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13.13.13.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/24 ms

Everything seems to be in working order.

Remember that R1s interface towards R3 is a multipoint subinterface and R3s interface towards R1 is the physical frame-relay interface.

Now if you just use the same command set as we did on the P2P interface, you will get the following error:

R1(config-subif)#frame-relay payload-compression packet-by-packet
couldn't find map! Compression state not changed!

We need to apply this on our frame-relay map command in order for it to be working:

R1(config)#int s0/0.13
R1(config-subif)# frame-relay map ip 13.13.13.3 103 broadcast payload-compression packet-by-packet

And on R3s s0/0 interface as well:

R3(config-if)#int s0/0
R3(config-if)# frame-relay map ip 13.13.13.1 301 broadcast payload-compression packet-by-packet

Lets verify with a ping from R1:

R1#ping 13.13.13.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13.13.13.3, timeout is 2 seconds:
!!!!!

And show the compression:

R1#sh compress
 Serial0/0
         Software compression enabled
         uncompressed bytes xmt/rcv 2900/2000
         compressed bytes   xmt/rcv 1205/824
         Compressed bytes sent:      1205 bytes   0 Kbits/sec  ratio: 2.406
         Compressed bytes recv:       824 bytes   0 Kbits/sec  ratio: 2.427
         1  min avg ratio xmt/rcv 1.084/1.076
         5  min avg ratio xmt/rcv 0.529/0.383
         10 min avg ratio xmt/rcv 0.475/0.352
         no bufs xmt 0 no bufs rcv 0
         resyncs 0
         Additional Stac Stats:
         Transmit bytes:  Uncompressed =        0 Compressed =       1205
         Received bytes:  Compressed =        824 Uncompressed =        0
		

Note that we dont see individual compression statistics for each dlci or subinterface.

Now lets change pace and look at some fragmentation. First off, i want to configure fragmentation on the link between
R1 and R2. Lets do it!

One very important thing to note, is the fact that fragmentation is part of the “traffic-shaping” command set.
We cannot do fragmentation without having frame-relay traffic-shaping enabled. This ofcourse has some consequences on our dlcis, but i will leave this unexplored in this post.

So, on R1, we need to create a map-class and apply this to our P2P interface.

R1(config)#map-class frame TST
R1(config-map-class)#frame-relay fragment 400

Next, we need to apply this to our interface:

R1(config-map-class)#int s0/0.12
R1(config-subif)#frame-relay class TST

Lets verify without having traffic-shaping enabled:

R1#sh frame-relay fragment
interface                dlci frag-type  size in-frag    out-frag   dropped-frag

And then lets enable traffic-shaping:

R1(config)#int s0/0
R1(config-if)#frame-relay traffic-sha
R1(config-if)#^Z
R1#sh
*Mar  1 00:20:32.203: %SYS-5-CONFIG_I: Configured from console by console
R1#sh frame-relay frag
interface                dlci frag-type  size in-frag    out-frag   dropped-frag
Se0/0.12                 102  end-to-end 400  0          0          0

Now we can see that it has been enabled.

We are actually faced with a dilemma at the moment. Right now we have compression enabled on our interfaces which makes it very hard to test things out. Even if we did a ping with a size of 400 bytes, it would be compressed very heavily and thus not be fragmented. I have opted for disabling our compression to keep everything simple:

R1#sh run int s0/0.12
interface Serial0/0.12 point-to-point
 ip address 12.12.12.1 255.255.255.0
 snmp trap link-status
 frame-relay class TST
 frame-relay interface-dlci 102
end

And R2:

R2(config-subif)#do sh run int s0/0.12
interface Serial0/0.12 point-to-point
 ip address 12.12.12.2 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 201
end

Now remember that a ping command adds 2 bytes of “overhead”, so lets ping from R1 to R2 with a payload of 398 bytes, which will make the packet 400 bytes in total:

R1#ping 12.12.12.2 size 398

Type escape sequence to abort.
Sending 5, 398-byte ICMP Echos to 12.12.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/27/60 ms

R1#sh frame frag
interface                dlci frag-type  size in-frag    out-frag   dropped-frag
Se0/0.12                 102  end-to-end 400  0          0          0

Nothing has been fragmented yet.
Lets say 400 instead of 398:

R1#ping 12.12.12.2 size 400

Type escape sequence to abort.
Sending 5, 400-byte ICMP Echos to 12.12.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#sh frame frag
interface                dlci frag-type  size in-frag    out-frag   dropped-frag
Se0/0.12                 102  end-to-end 400  0          10         0

We can see that we are now fragmenting our packets, but since R2 is not doing the same, the ping fails.
Lets add the same on R2:

R2(config)#map-class fra TST
R2(config-map-class)#frame-relay fragment 400
R2(config-map-class)#
R2(config-map-class)#int s0/0.12
R2(config-subif)#frame-relay class TST
R2(config-subif)#int s0/0
R2(config-if)#frame-relay traffic-shaping

And verify:

R2#sh frame-relay fragment
interface                dlci frag-type  size in-frag    out-frag   dropped-frag
Se0/0.12                 201  end-to-end 400  0          0          0

Lets try out the ping from R1 again:

R1#ping 12.12.12.2 size 400

Type escape sequence to abort.
Sending 5, 400-byte ICMP Echos to 12.12.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/50/104 ms
R1#sh frame frag
interface                dlci frag-type  size in-frag    out-frag   dropped-frag
Se0/0.12                 102  end-to-end 400  10         20         0

And lets verify from R2:

R2#sh frame-relay fragment
interface                dlci frag-type  size in-frag    out-frag   dropped-frag
Se0/0.12                 201  end-to-end 400  10         10         0

Awesome. Our fragmentation is now working as it should between R1 and R2.

This will have to do for the first segment of the post. Next time i will cover some of the RTP and TCP compression methods.
Take care!!

Total Layout

More detailed view

Thats all there is to it

The concern i voiced about the 3640 was enough to make me figure out a way to have that one as the bottom piece of equipment.

This is what i ended up with:

It worked out pretty well. All the cables were long enough to accomplish the design above. On top of it all i have my remote power switch so i can power it all on/off remotely.

I also configured the access-server (2511) so i can access all the devices directly. For some reason the first configuration i did on this didnt work at all. Deleting all config and starting over fixed the problem. Dont ask, i dont have an explanation for this

Power wise, i was pleasently surprised. When the entire thing is on it takes about 620Watts, which is far less than i expected. Obviously the 3640 router is the power hungry beast of them all.

Noise…. Yes, it makes alot of noise. Its actually the 2811 router that has a bad fan which makes the most noise. If/When i replace this fan, it will calm down quite alot.

I will post a picture of the final setup once im done doing the cables.

As you can see i have most of the routers on top, with only 3 backbone routers in the lower section (16U section). I need to have the Frame Switch pretty centralized as my cables for this are not very long.

Anyways, i might run into issues that will change this, but so far, thats what i got