Subject: Re: [Rift] TIE flooding address and port for debugging?

From: Antoni Przygienda <[email-masked]>
Date: Tue, 18 Sep 2018 18:44:20 +0000

Cc”’ing wider list on some internal interop implementation stuff we’re doing & shaking out the spec on real code ;-)

Old routing aficionados will have a drink and enjoy that one. After python open-source implementation started to receive TIEs (without processing any flooding packets really), the observation was that from the 2 initial TIEs (node and south-prefix) node TIE is not being retransmitted. I went looking for that one …

It’s a valid optimization falling out of clever implementation strategy ;-)  Basically when a peer is coming up it does NOT put e’thing immediately on transmission list since the neighbor may tons of stuff already (link flap, from other peers) and with that all the flooding would be overkill. Instead the implementation sends immediately TIDEs to describe its database and waits for the peer to request via TIREs what it doesn’t have, kind of loose OSPF initial sync to speed stuff up.  Again, Python implementation receiving all that does not process TIDEs or TIREs @ this point in time.

Now, why is the prefix-TIE transmitted and the node-TIE not. Well, node-TIE is already around when the peering comes up so it doesn’t go on transmission list. However, the south prefix tie with default gets generated only on certain peering conditions (per spec). This happens after 3-way so the peering puts it on transmission list & start re-transmitting since the initial CSNPs are gone out already … Hence the funky case where node TIE is not re-transmitted & prefix TIE is. All correct ;-)

The moment python implementation starts to process TIDEs and TIREs all should work fine …

--- tony

Thus spake <[email-masked]<mailto:[email-masked]>>:

#1 Thanks for the hint. Using this log, I figured out what the problem was and fixed it (the problem was in my code).

#2 Ok, thanks

I will still need release 0.7.1 with the new Thrift model.  I am getting a TIE packet decode crash on my side, and I don’t know if it is because of the different Thrift models or because of something more serious on my side.

— Bruno

On Sep 13, 2018, at 5:15 PM, Antoni Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

1.       You will be getting the TIEs on the source address of your LIEs. Destination port will be the TIE port you send in your LIEs. Run debug –Cnode,peering and it will tell you which sockets it’s opening like this:

Sep 13 17:13:20.731 DEBG creating TIETX socket on Some(V4(10.104.36.227:20024)) and intf: 20022, subsystem: peering, nodeid: core_1, peer: if_1_202->20022:20023:224.0.255.202/ff02::2
Sep 13 17:13:20.731 DEBG creating TIERX socket on V4(127.0.0.1:20023) and intf: 20022, subsystem: peering, nodeid: core_1, peer: if_1_202->20022:20023:224.0.255.202/ff02::2
Sep 13 17:13:20.731 DEBG creating TIERX socket on V6([::1]:20023) and intf: 20022, subsystem: peering, nodeid: core_1, peer: if_1_202->20022:20023:224.0.255.202/ff02::2

2.       Maybe a bug, I’ll check, there was some heavy flooding optimization work done in 0.7 which may explain the issue. If needed, I’ll try to release bug-fix 0.7.1 over the weekend …

thanks

--- tony

Thus spake <[email-masked]<mailto:[email-masked]>>:

Hi Tony,

I am doing some interop testing between Juniper RIFT (level 1) and Python RIFT (level 0).  I.e. Python RIFT is south of Juniper RIFT.

Is there some way to find out which destination IP address and destination port Juniper RIFT is sending LIE messages to?

I see that Juniper RIFT thinks is sending TIE messages (details below).

But Python RIFT is not receiving any TIE messages, and I also don’t see any TIE messages on the wire with tcpdump (details below)

For debugging, I would like to know which UDP address and port Juniper RIFT is sending the messages to.

In the Juniper logs I see one initial node TIE and one initial prefix TIE going south:

    Sep 13 13:07:18.350 DEBG initial sync, LSDB sent newer TIE: South/1/node/$00000000/#1/600/0.000/true, tie-originator: 1, tie-direction: south, tie-type: node

    Sep 13 13:07:18.352 DEBG LSDB sent new, unknown tie TIE: South/1/prefix/$10000000/#1/600/0.000/true, tie-originator: 1, tie-direction: south, tie-type: prefix

Interestingly, I noticed that Juniper RIFT only retransmits the prefix TIE and not the node TIE.  Should it not retransmit both, given that Python RIFT does not ack either one of them?

    Sep 13 13:07:18.352 DEBG queuing TIE transmission TIE: South/1/prefix/$10000000/#1/600/0.000/true, tie-originator: 1, tie-direction: south, tie-type: prefix

    Sep 13 13:07:18.352 DEBG sent TIE: South/1/prefix/$10000000/#1/600/0.000/true, tie-originator: 1, tie-direction: south, tie-type: prefix

    Sep 13 13:07:19.280 DEBG sent TIE: South/1/prefix/$10000000/#1/600/0.000/true, tie-originator: 1, tie-direction: south, tie-type: prefix

    Sep 13 13:07:20.308 DEBG sent TIE: South/1/prefix/$10000000/#1/599/0.000/true, tie-originator: 1, tie-direction: south, tie-type: prefix

Python RIFT does not receive them. I log a message when I receive any message on the TIE flooding port, and I don’t see that message.

Python RIFT advertised port 22001 as the rx_tie_port / TIE UDP flood port (I added a nitpick to the Google doc about the terminology needing to be more consistent):

node2> show interface if1
Interface:
+--------------------------------------+---------------------------------------------------------+
| Interface Name                       | if1                                                     |
| Advertised Name                      | node2-if1                                               |
| Interface IPv4 Address               |                                                         |
| Metric                               | 100                                                     |
| Receive LIE IPv4 Multicast Address   | 224.0.1.2                                               |
| Transmit LIE IPv4 Multicast Address  | 224.0.1.1                                               |
| Receive LIE IPv6 Multicast Address   | FF02::0078                                              |
| Transmit LIE IPv6 Multicast Address  | FF02::0078                                              |
| Receive LIE Port                     | 20002                                                   |
| Transmit LIE Port                    | 20001                                                   |
| Receive TIE Port                     | 22001                                                   |
| System ID                            | 2                                                       |
| Local ID                             | 1                                                       |
| MTU                                  | 1400                                                    |
| POD                                  | 0                                                       |
| Failure                              | ok                                                      |
| State                                | THREE_WAY                                               |
| Received LIE Accepted or Rejected    | Accepted                                                |
| Received LIE Accept or Reject Reason | This node is leaf and HAT not greater than remote level |
| Neighbor                             | True                                                    |
+--------------------------------------+---------------------------------------------------------+

Neighbor:
+----------------------------------+--------------+
| Name                             | None         |
| System ID                        | 1            |
| IPv4 Address                     | 192.168.1.18 |
| LIE UDP Source Port              | 20002        |
| Link ID                          | 28672        |
| Level                            | 1            |
| Flood UDP Port                   | 22000        |
| MTU                              | 1400         |
| POD                              | 0            |
| Hold Time                        | 3            |
| Not a ZTP Offer                  | False        |
| You Are Not a ZTP Flood Repeater | False        |
| Your System ID                   | 2            |
| Your Local ID                    | 1            |
+----------------------------------+--------------+

However, neither tcpdump nor Wireshark report any UDP traffic on any port in range 22000-22999:

$ sudo tcpdump -n udp "portrange 22000-22999"
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
[…nothing here…]

I know tcpdump works because I can see the LIE packets which are in UDP port range 20000-20999:

$ sudo tcpdump -n udp "portrange 20000-20999"
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
13:16:45.828175 IP 192.168.1.18.20002 > 224.0.1.2.20002: UDP, length 93
13:16:45.828674 IP 192.168.1.18.52624 > 224.0.1.1.20001: UDP, length 149
13:16:45.829130 IP 192.168.1.18.20002 > 224.0.1.2.20002: UDP, length 93
13:16:45.830459 IP 192.168.1.18.52624 > 224.0.1.1.20001: UDP, length 149
13:16:46.829127 IP 192.168.1.18.52624 > 224.0.1.1.20001: UDP, length 149

---

From: Bruno Rijsman <[email-masked]>
Date: Wed, 19 Sep 2018 17:33:19 +0000

Ah, yes, that explains the observed behavior and I agree this is not a bug.  I think the TIDE/TIRE processing in rift-python is a couple of weeks away (Thrift issues slowing me down).

On Sep 18, 2018, at 11:44 AM, Antoni Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

--- tony

#2 Ok, thanks

— Bruno

thanks

--- tony

Hi Tony,

Neighbor:

_______________________________________________
RIFT mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rift