Re: [rbridge] merging draft-tissa-trill-oam anddraft-ietf-trill-rbridge-oam

[Santosh Rajagopalan <[e-mail]>]

Hi, Rohit
You could have a packet or two leak to the host, and the host OS will drop 
it because of the invalid checksum (this number of drops would be at the 
level of noise for most systems). A more difficult alternative would be to 
have switches drop packets with an invalid IP checksum from leaving 
host-facing ports.

1) You employ this method only after all your other means of debugging 
have failed to root cause the issue. This means that you've already used 
the means outlined below to trace the path that this packet should  be 
taking (2.a and 2.b below, which use the rbridge channel header and result 
in no leaks). 

2) After you've used 2.a and 2.b, you need to check what the hardware on 
the path is really doing with a packet that looks like the flow you're 
debugging. For this, you cannot change any of the familiar header fields 
to help you capture the packet at the egress, because that could change 
the hash result on the way (This isn't theoretical - I know of asics that 
hash on IP, trill header, tcp/udp, inner ethernet header, outer ethernet 
header). Since you need a probe packet that looks just like a real flow, 
your best bet is to clone the real flow packet, but with an invalid IP 
checksum and then send it out with incrementing ttl values.

--
Sunny Rajagopalan




From:   "Rohit Watve (rwatve)" <[e-mail]>
To:     Santosh Rajagopalan/Santa Clara/IBM@IBMUS, <[e-mail]>
Date:   03/16/2012 06:38 PM
Subject:        Re: [rbridge] merging draft-tissa-trill-oam 
anddraft-ietf-trill-rbridge-oam
Sent by:        [e-mail]



Hi Santosh,
 
I had a question about following:
2. c) Multicast pruned tree discovery for a particular flow: I recommend 
building a packet with an empty payload which looks like the actual flow 
(with the header fields from the flow being tested instead of the rbridge 
channel header). The IP address, mac address, L4 headers etc all match 
with that of the flow you're trying to debug. However, to ensure that any 
leaked packets get dropped, set the IP checksum to be invalid (the IP 
checksum is never used for the ecmp hash). Now send out successive packets 
with the ttl field in incrementing values. Note that you're sending a 
"pseudo-real" packet into the network and relying on received ttl expiry 
messages to figure out the path.
 
How do you prevent OAM packets with Invalid IP checksum from leaking out 
to customers?
 
Thanks
Rohit
 
From: [e-mail] [mailto:[e-mail]] On 
Behalf Of Santosh Rajagopalan
Sent: Tuesday, March 06, 2012 8:49 AM
To: [e-mail]
Cc: Santosh Rajagopalan
Subject: [rbridge] merging draft-tissa-trill-oam 
anddraft-ietf-trill-rbridge-oam
 
 
 
Hi,
We currently have two competing approaches to TRILL OAM, 
draft-ietf-trill-rbridge-oam and draft-tissa-trill-oam. Both have their 
merits, which calls for a revised draft with the best ideas from both.

draft-tissa-trill-oam has a dependancy on IP/ICMP/ARP etc.  The major 
reason for this dependency seems to be for multipath path discovery, and I 
have some suggestions as to how to fix this in 
draft-ietf-trill-rbridge-oam without using IP. draft-tissa-trill-oam also 
has several features which should be rightly queried from a MIB.

I think the OAM draft should concentrate on facilitating actions that 
would be difficult or impossible to perform in its absence. So querying 
counters has no place here, because you could easily figure them out by 
doing an SNMP query or by logging into the switch. I also think it's 
worthwhile to look at the features traditionally supported in ethernet OAM 
and to see if they have a place here.

Using draft-ietf-trill-rbridge-oam as a basis:

1) Ping/loopback: draft-ietf-trill-rbridge-oam handles this well enough 
(it does need a multicast addition). The purpose of ping is to verify 
connectivity between two rbridges, not to discover the various ways of 
connecting the two.  One suggestion I have here is to be able to include a 
cookie in the echo request message which gets reflected back by the 
receiver. This cookie could be used to include the sender's timestamp in 
the ping message. The response could then be used to measure round-trip 
path latency and jitter. If the sender and receiver's clocks are 
synchronized using some external mechanism then this can also be used to 
measure one-way delay and jitter. This is a feature borrowed from ethernet 
OAM.

2) Traceroute: IP traceroute doesn't rely on icmp for the outgoing packet 
(you could use ICMP, but that's a different matter). In fact, UNIX 
implementations usually just send UDP packets with port numbers in the 33K 
range, with appropriate TTL values. Note that traceroute in the IP world 
gives you "a" path to a destination, not "all possible paths". However, 
being able to enumerate all possible paths, as well as to pinpoint the 
particular path a flow would take are good to have features. 
Here're the modifications needed in draft-ietf-trill-rbridge-oam to 
achieve this:
a.      Multicast unpruned tree discovery: you can discover all existing 
unpruned multicast trees by setting the erbridge value of an rbridge 
channel message to the respective roots, M=1 and the dmac to 
"all-egress-rbridges". Just like regular ping, you can send this as an 
echo request message with incrementing ttl values, and the ttl expiry 
messages you get will tell you what the unpruned tree looks like. Changing 
the egress_rbridge will paint you a picture of the different trees.
b.      Multicast pruned tree discovery: just do a), but replace the 
"all-egress-rbridges" multicast address in the inner dmac with the mac 
address of the multicast group. As you vary the egress_rbridge field, this 
will enumerate all possible pruned trees for that group. Note that 
draft-ietf-trill-rbridge-oam uses draft-ietf-trill-rbridge-channel, which 
requires the inner dmac to be all-egress-rbridges. However, the ethertype 
field can be used by itself to classify an OAM packet, and I am advocating 
that the inner dmac requirement in draft-ietf-trill-rbridge-channel be 
relaxed to allow for alternative inner dmacs where needed.
c.      Multicast pruned tree discovery for a particular flow: I recommend 
building a packet with an empty payload which looks like the actual flow 
(with the header fields from the flow being tested instead of the rbridge 
channel header). The IP address, mac address, L4 headers etc all match 
with that of the flow you're trying to debug. However, to ensure that any 
leaked packets get dropped, set the IP checksum to be invalid (the IP 
checksum is never used for the ecmp hash). Now send out successive packets 
with the ttl field in incrementing values. Note that you're sending a 
"pseudo-real" packet into the network and relying on received ttl expiry 
messages to figure out the path.
d.      Unicast path discovery: the erbridge ID is that of the switch 
you're trying to ping. Let's send this echo request message with a fake 
inner DMAC. Construct the dmac so that the U/L bit is 1 and the I/G bit is 
0 (basically, its a local scope unicast mac). Set the last 32 bits to a 
random value. This is a fake mac address, but that's ok because the 
network routes only on the erbridge anyway. The M bit in the TRILL header 
is 0. Send this as an echo request message with incrementing ttl values. 
This gives you "a" path from the source to the destination rbridge. 
Increment the dmac used earlier, and repeat. All rbridges hash at least on 
the inner dmac, so this will allow you to enumerate all possible paths 
from source to destination.
e.      Unicast path discovery for a particular flow: Similar to what we 
did for multicast, construct a real packet of length 0. The IP address, 
mac address, L4 headers etc all match with that of the flow you're trying 
to debug. However, to ensure that any leaked packets get dropped, set the 
IP checksum to be invalid. Now set the ttl field in incrementing values. 
Note that you're sending a "pseudo-real" packet into the network and 
relying on received ttl expiry messages to figure out the path.
Note that doing this eliminates the reliance on IP/ICMP, while preserving 
the objectives of draft-tissa-trill-oam. The fake packets generated are 
technically not OAM packets, just suggestions on how to achieve a certain 
objective.

3) Fault notification: although neither draft talks about this, this is a 
part of the ethernet OAM feature set. I think draft-ietf-trill-rbridge-oam 
needs to mention that the expectation is that BFD will work over the 
rbridge channel to achieve this.

4) draft-tissa-trill-oam  has a big section on TTM. The equivalent in 
Ethernet OAM is performance management by checking counters and 
send/receive delays, etc. We can cover send/receive delay/jitter 
measurements using ping (as described earlier). I frankly don't see the 
benefit to including remote discovery of counters in this OAM proposal. 
The administrator can always just login to the rbridge of interest and get 
a read-out of the counters directly, or use snmp remotely. We shouldnt be 
replicating functionality which is better done elsewhere, and I think this 
entire section on TTM in draft-tissa-trill-oam should be taken out.

5) I don't see any benefits to DRB/AF discovery OAM messages. This is 
probably done most easily by logging into the rbridge in question and 
doing a "show l2 isis", or extending the SNMP MIB. 

6) draft-tissa-trill-oam has a section on MAC discovery (basically, being 
able to query all rbridges to see what their rbridge<->mac binding is). 
This is again something that should be best queried using SNMP - this is a 
classic MIB walk case.

7) Address binding verification should be out of scope for a TRILL OAM 
draft, and besides, should just be queried at the rbridge with the CLI.

8) End-Station Attachment Point Discovery: should be out of scope of this 
draft, and is too vendor specific (it uses VN-tags).

best,
Sunny Rajagopalan_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge