configuring L2TP TOS byte

stumble into this command:

pseudowire-class t59

encapsulation l2tpv3

ip local interface Loopback0

ip tos value 160

the intention was to set the IP Precedence bit in TOS byte of the IP header carrying the L2TPV3 packet manually. Well sniffing tells otherwise:

traffic from 9.9.0.9 to 9.9.0.7 is carrying ICMP traffic from R1 to R5, although i did not get wireshark to decode the payload properly. But check the IP header, the TOS is still 0.

Checked command reference and notice the following:

IP ToS byte reflection functions only if traffic in an L2TPv3 session carries IP packets as its payload.

Apparently there is another option under IP TOS:

pseudowire-class t59

encapsulation l2tpv3

ip local interface Loopback0

ip tos reflect

And this "reflect" thing actually copy the payload's TOS to the outer IP header. Well it is understandable that if the payload is NOT ip then this "copy" thing will not happen.

Hmm.. i am not using reflect but my payload is NOT IP (ICMP).. could it be...

Ok try again telnet from R1 to R5... ah ha there it is..

we can see the IP precedence is now at 5.

So it seems like even we manually set the TOS byte under pseudo-wire class, if the payload is NOT ip, the TOS byte is not set properly.

Bug? ios version (C7200-K91P-M), Version 12.2(25)S15.

multicast.. forever pain in the ass

now this is getting a bit irritating.. stuck for a few days.. today managed to zoom in to the culprit router. below is the diagram

R7, R8 and R9 is running MPLS VPN backbone with multicast backbone as well. Multicast VPN has been configured over.. control plan works fine.. R5 join address 225.5.5.5. Ping 225.5.5.5 from R4 is not happening.

Sniffing shows R7 is sending traffic to 225.5.5.5 using multicast tunnel address 239.0.0.1, and this is captured by R9. From R9, the multicast route table looks like this:

R9#

00:14:19: %SYS-5-CONFIG_I: Configured from console by console

R9# sh ip mroute vrf ABC2

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel

Y - Joined MDT-data group, y - Sending to MDT-data group

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 225.5.5.5), 00:23:21/00:02:48, RP 172.16.0.7, flags: S

Incoming interface: Tunnel0, RPF nbr 12.12.0.7

Outgoing interface list:

FastEthernet0/0.59, Forward/Sparse, 00:23:21/00:02:48

(172.16.48.4, 225.5.5.5), 00:01:57/00:01:03, flags: TY

Incoming interface: Tunnel0, RPF nbr 12.12.0.8, MDT:239.0.8.0/00:02:03

Outgoing interface list:

FastEthernet0/0.59, Forward/Sparse, 00:01:57/00:02:48

(*, 224.0.1.40), 00:23:27/00:02:56, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Loopback1, Forward/Sparse, 00:23:27/00:02:56

ok now already switched to MDT data group.. Cos R7 is happily sending the traffic.. fine. R9 is not sending anything out:

R9# sh ip mroute vrf ABC2 cou

IP Multicast Statistics

3 routes using 1720 bytes of memory

2 groups, 0.50 average sources per group

Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second

Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 225.5.5.5, Source count: 1, Packets forwarded: 2, Packets received: 2

RP-tree: Forwarding: 2/0/100/0, Other: 2/0/0

Source: 172.16.48.4/32, Forwarding: 0/0/0/0, Other: 0/0/0

Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0

Debug ip mpacket detail tells why:

R9# deb ip mpa de

IP multicast packets debugging is on (detailed)

R9#

00:33:41: IP(0): MAC sa=*Tunnel* (Tunnel0)

00:33:41: IP(0): IP tos=0x0, len=100, id=1280, ttl=252, prot=1

00:33:41: IP(0): s=172.16.48.4 (Tunnel0) d=225.5.5.5 (FastEthernet0/0.69) id=1280, ttl=252, prot=1, len=100(100), not RPF interface

R9#

00:33:43: IP(0): MAC sa=ca08.1a44.0008 (FastEthernet0/0.79), IP last-hop=12.12.79.7

00:33:43: IP(0): IP tos=0x0, len=124, id=14896, ttl=254, prot=47

00:33:43: IP(0): MAC sa=ca08.1a44.0008 (FastEthernet0/0.79), IP last-hop=12.12.79.7

00:33:43: IP(0): IP tos=0x0, len=124, id=14897, ttl=254, prot=47

00:33:43: IP(0): MAC sa=*Tunnel* (Tunnel0)

00:33:43: IP(0): IP tos=0x0, len=100, id=1280, ttl=253, prot=1

00:33:43: IP(0): s=172.16.47.4 (Tunnel0) d=225.5.5.5 (FastEthernet0/0.69) id=1280, ttl=253, prot=1, len=100(100), not RPF interface

00:33:43: IP(0): MAC sa=*Tunnel* (Tunnel0)

00:33:43: IP(0): IP tos=0x0, len=100, id=1280, ttl=252, prot=1

00:33:43: IP(0): s=172.16.0.4 (Tunnel0) d=225.5.5.5 (FastEthernet0/0.69) id=1280, ttl=252, prot=1, len=100(100), not RPF interface

00:33:43: IP(0): MAC sa=ca08.1a44.0008 (FastEthernet0/0.79), IP last-hop=12.12.79.7

00:33:43: IP(0): IP tos=0x0, len=124, id=14898, ttl=254, prot=47

00:33:43: IP(0): MAC sa=*Tunnel* (Tunnel0)

This is where things start not to make sense. We see the OIL listed fa0/0.59 as the egress interface for group 225.5.5.5, however debug shows that R9 is trying to forward it to fa0/0.69 and gives a "not rpf interface" error?!

-----------------------------------------------------------

Action:

-- add 'bgp next-hop loopback', cos R9 is peering ebgp over fa0/0.69, no good.

-- shutdown loopback 2, no good.

-- shutdown fa0/0.69, everything works. Well this is not a solution

------------------------------------------------------------------

thought:

-- R9 has two loopback address in global table.. i seem to remember that could give some sort of problem when the backbone multicast is not using MDT address family, even through in my case, i use PIM BSR instead of PIM SSM to build the backbone. Research this more tomorrow.. anyway my code does not support MDT address family. XD

-- there is a l2tp tunnel forming through fa0/0.69, related?

今天没有读书

啊我废了今天。。

Strong heart

兵败悉尼， 其实还真有点失望。 人品太差， 不能怪谁。 眼看CCIE SP 2.0应该是没戏了， 今天早上无聊在思科网站翻翻， 竟然发现有3月18号的SP 2.0， 在 SAN JOSE。

有点不能理解为什么还有DATE， 虽然自己心里一直希望有个DATE。 SAN JOSE还真不好去， 要飞22个小时。 机票要两千六百多， 加上考试费和住宿， 又是一个5千。 所以即使是眼前放着这个奇迹般的日期， 鼠标的左键一直点不下去。

打给老贼婆咨询一下吧， 每次买东西太大件下不了手都找她的。

“你。。。你。。。疯了！”

“我。。。我。。。说真的。”

似乎老贼婆对这个提议很有意见。哈， 这不是， 电话刚挂一个洋洋洒洒的SMS就来了。 看气势就知道是兴兵问罪来的。

“I really need strong heart to take your decision. Anyway if you are ready just go."

嗯。。 strong heart 是个key word. 我比老贼婆更需要stong heart to make this decision: do i really want to go through this again?

-- 每天做8个钟头的LAB

-- 每天读4个钟头的书

-- 做22小时飞机

-- 很有可能两天内完全睡不着

-- 以一具行尸走肉的形态度过8小时的实验时间， 希望运气好一点就过了

-- 人品差点搞不好结果和悉尼是一样的

×× 这次可不是full time study, 没假了。

-----------------------------------------------------------------------------------

好吧， 我是贱人。 伤口好了就不记得疼难受。 不过最重要的似乎还是那种不知道是执着还是偏执。 眼前有机会怎么可以放过？ 再说。。 SP 的技术点我是喜欢的。 准备考试的过程是enjoyable的。

离考试还有45天， 抓紧每天吧。

IEWB SP VOL1 LAB 3 debrief

This lab is at grade 8, well well.. not so impressive but tricky. Stuck at task 5.4 back to back VRF for a few days.. Configuration was easy.. and i can't find anything different from the solution guide..

From R1 VRF 100, able to see R6's connected interface in VRF 100..

Rack1R1#sh ip route v 100 | i 54.

54.0.0.0/24 is subnetted, 1 subnets

B 54.1.1.0 [200/1] via 150.1.3.3, 02:15:45

Ping is not working, debug on R6 shows echo request received and sending echo reply. I traced echo reply all the way back to R1. Debug mpls packet on R1 shows it is receiving the packet with LC-ATM label as well as VPN label..

Rack1R1#ping vrf 100 54.1.1.6 rep 1000 size 1000

Type escape sequence to abort.

Sending 1000, 1000-byte ICMP Echos to 54.1.1.6, timeout is 2 seconds:

1d03h: MPLS turbo: AT3/0.1: rx: Len 1012 Stack {0 0 251} {27 0 253} - ipv4 data.

1d03h: MPLS turbo: AT3/0.1: rx: Len 1012 Stack {0 0 251} {27 0 253} - ipv4 data.

1d03h: MPLS turbo: AT3/0.1: rx: Len 1012 Stack {0 0 251} {27 0 253} - ipv4 data.

1d03h: MPLS turbo: AT3/0.1: rx: Len 1012 Stack {0 0 251} {27 0 253} - ipv4 data

1d03h: MPLS turbo: AT3/0.1: rx: Len 67 Stack {0 6 253} - ipv4 data.

1d03h: MPLS turbo: AT3/0.1: rx: Len 1012 Stack {0 0 251} {27 0 253} - ipv4 data.

1d03h: MPLS turbo: AT3/0.1: rx: Len 1012 Stack {0 0 251} {27 0 253} - ipv4 data..

but it seems like it is having trouble to pop the LC-ATM label and then pop the VPN label. I don't have the same issue with VPNs terminated on R4 where R4 runs a frame mode MPLS, in fact when R4 receives a label packet it has only the VPN label left due to the penuntimate hop thing.. well LC-ATM does not do penuntimate hop, not sure whether that is the reason...

So after much time i concluded this to be dynamips bugs, will try this out again on real rack.

Other than this, the multicast is kinda fun for this lab. This is the first time i see ppl use "igmp static group" to achieve Inter-AS multicast connectivity, happy that i work it out myself. :) So R3 is emulating a multicast receiver on AS100 to pull multicast feed. Then once the multicast feed reaches AS100, it is forwarded in dense so everyone have a chance to get it. Of course this will only allow feed from AS12349 to AS100.

wishlist

iPad: 1400

iPhone4: 400?

Bose Companion 5: 750

Bose Dockable : 750

Qnap 8 Bay NAS: 2800

2T HD X8 : 1600

---------------------------

SUM: 7700

How to install dynagen in Ubuntu

Quoted from http://www.blindhog.net/cisco-dynamips-and-dynagen-install-on-linux/

Strictly not for commercial use