Re: [rbridge] mergingdraft-tissa-trill-oam anddraft-ietf-trill-rbridge-oam

["Tissa Senevirathne (tsenevir)" <[e-mail]>]

Santosh

 

One  cannot assume when troubleshooting an issue it will be only be
limited to few packets. (we all will be very happy if it was the case
but it never the norm but rather the exception) Secondly in hosting
environments, where network provider has no control on end systems this
kind of things generate unwanted support calls.  We should not be
designing OAM protocol based on this assumption.

 

Also 2.a and 2.b will not allow you to verify IP payload, something
working for 2.a and 2.b does not gurantee that IP is working.

 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Rajagopalan
Sent: Monday, March 19, 2012 10:48 AM
To: Rohit Watve (rwatve)
Cc: [e-mail]; [e-mail]
Subject: Re: [rbridge] mergingdraft-tissa-trill-oam
anddraft-ietf-trill-rbridge-oam

 

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]
<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
<http://mailman.postel.org/mailman/listinfo/rbridge> 

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