{"id":447,"date":"2020-06-26T23:30:58","date_gmt":"2020-06-26T22:30:58","guid":{"rendered":"https:\/\/www.kuncar.net\/blog\/?p=447"},"modified":"2020-06-26T23:37:28","modified_gmt":"2020-06-26T22:37:28","slug":"ex4600-route-leaking-trident-ii","status":"publish","type":"post","link":"https:\/\/www.kuncar.net\/blog\/2020\/ex4600-route-leaking-trident-ii\/","title":{"rendered":"ex4600 route leaking (Trident II)"},"content":{"rendered":"<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif;\"><img loading=\"lazy\" decoding=\"async\" class=\"size-thumbnail wp-image-213 alignleft\" src=\"https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/juniper_logo2-150x150.png\" alt=\"\" width=\"150\" height=\"150\" srcset=\"https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/juniper_logo2-150x150.png 150w, https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/juniper_logo2-100x100.png 100w, https:\/\/www.kuncar.net\/blog\/wp-content\/uploads\/2018\/02\/juniper_logo2.png 195w\" sizes=\"auto, (max-width: 150px) 100vw, 150px\" \/><\/span> <span style=\"font-family: arial, helvetica, sans-serif;\">This is a just a very short article about limitations and options with route leaking on the ex4600 switch. This switch is base on the <a href=\"https:\/\/www.broadcom.com\/products\/ethernet-connectivity\/switching\/strataxgs\/bcm56850-series\">Trident II<\/a> chip manufactured by Broadcom. It is not very new but\u00a0 it is still a solid piece of silicon used by many platforms across the vendors (Arista, Cisco Juniper). In case of Juniper it is used in the QFX5100 and the EX4600. The EX4600 is classified as an aggregation switch for offices or small DCs so there are rather serious limitations on what you could expect from the device as from all the members of EX switch family. <\/span><\/p>\r\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif;\">The obvious intent of the designers of this hip was to have very high throughput and in exchange losing some higher routing functions. This has one rather serious implication &#8211; there is only one route lookup operation available. Unfortunately for some operations you need to perform the route lookup twice specifically if you:<\/span><\/p>\r\n\r\n<ul>\r\n \t<li style=\"list-style-type: none;\">\r\n<ul>\r\n \t<li><span style=\"font-family: arial, helvetica, sans-serif;\">leak routes<\/span><\/li>\r\n \t<li><span style=\"font-family: arial, helvetica, sans-serif;\">double-encapsulate or decapsulate (VTEP\/IRB situation)<\/span><\/li>\r\n<\/ul>\r\n<\/li>\r\n<\/ul>\r\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif;\">There are possibly other examples but I have personally only encountered the two above. <\/span><span style=\"font-family: arial, helvetica, sans-serif;\">The good news is that the double route lookup has been actually added through some tweaks in Junos so you can actually do route leaking. The issue is that there are multiple KB articles that have not been updated (as of writing this article) <a href=\"https:\/\/kb.juniper.net\/InfoCenter\/index?page=content&amp;id=KB19860\">KB19860<\/a> and the more funny one <a href=\"https:\/\/kb.juniper.net\/InfoCenter\/index?page=content&amp;id=KB23027\">KB23027<\/a>. <\/span><\/p>\r\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif;\">The first one (<a href=\"https:\/\/kb.juniper.net\/InfoCenter\/index?page=content&amp;id=KB19860\">KB19860<\/a>) is mostly correct but it is missing missing the crucial information that this is not available on all EX switches &#8211; actually it is not available on quite a few of them and also the KB also misses a release information. The second one (<a href=\"https:\/\/kb.juniper.net\/InfoCenter\/index?page=content&amp;id=KB23027\">KB23027<\/a>) is just plain wrong on many accounts and the proposed solution is to use &#8220;tromboning&#8221; with physical cables between the VRF ports. Fortunately this is note really needed and route leaking actually does work.\u00a0<\/span><\/p>\r\n<span style=\"font-family: arial, helvetica, sans-serif;\">The main issue I&#8217;ve encountered was that when I tried to leak interface lo0.0 I had was getting rather odd results.\u00a0<\/span>\r\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif;\">The situation was that the system services were to be sourced from lo0.0 but as there were limitations and design restrictions in place\u00a0 &#8211; this loopback was not part of the routing instance that was actually providing the transport connectivity and on top there was to be another loopback in the transport routing VRF (called test in the example below).<\/span><\/p>\r\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif;\">So as for the egress traffic the logic was simple just use a 0\/0 static route with a next-table stanza as an egress. There was no other connectivity to the inet.0 (default) instance so this was fine. on the return path I&#8217;ve created a RIB group importing all of the inet.0 into the ri_test.inet.0 which in this case should made the lo0.0 available in the new VRF for the return traffic.\u00a0<\/span><\/p>\r\n\r\n<blockquote>\r\n<pre class=\"_1qeIAgB0cPwnLhDF9XSiJM\"><span style=\"font-family: 'courier new', courier, monospace; font-size: 12px;\">set routing-options static route 0.0.0.0\/0 next-table ri__test.inet.0 \r\nset routing-options interface-routes rib-group inet rg_test <\/span><span style=\"font-family: 'courier new', courier, monospace; font-size: 12px;\">\r\nset routing-options rib-groups <\/span><span style=\"font-family: 'courier new', courier, monospace; font-size: 12px;\">rg_test import-rib inet.0 \r\nset routing-options rib-groups rg_test import-rib ri_test.inet.0<\/span><\/pre>\r\n<\/blockquote>\r\n<span style=\"font-family: arial, helvetica, sans-serif;\">From the test VRF the routes were happily propagated via BGP. But that is where the oddity started.\u00a0<\/span><span style=\"font-family: arial, helvetica, sans-serif;\">The lo0 with an ip of 1.1.1.1 was unreachable using ping with the TTL exceeded ICMP message. But traceroute worked just fine.<\/span>\r\n<pre>PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.\r\nFrom 1.0.0.2 icmp_seq=1 Time to live exceeded\r\nFrom 1.0.0.2 icmp_seq=1 Time to live exceeded\r\nFrom 1.0.0.2 icmp_seq=1 Time to live exceeded<\/pre>\r\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif;\">After long investigation all looked normal &#8211; routing table was populated as expected, forwarding table was showing next-hope as routable (which is expected in route leaking scenario).<\/span><\/p>\r\n\r\n<pre>Routing table: ri_test.inet\r\nInternet:\r\nEnabled protocols: Bridging,\r\nDestination \u00a0 \u00a0 \u00a0 \u00a0Type RtRef Next hop \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Type Index \u00a0 \u00a0NhRef Netif\r\n1.1.1.1\/32 \u00a0 \u00a0     user \u00a0 \u00a0 0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0rtbl \u00a0 \u00a0 \u00a0 \u00a0    1 \u00a0 \u00a0 3<\/pre>\r\n<p style=\"text-align: justify;\">I also got some interesting troubleshooting commands that are not exposed directly in JUNOS. <span style=\"font-family: arial, helvetica, sans-serif;\">Below you can see those command. They are very helpful as they are showing the routing and forwarding tables as understood by the underlying system rather than the interpreted version you can pull through JUNOS.<\/span><\/p>\r\n\r\n<pre>&gt; start shell\r\n% vty fpc0 &lt;&lt;&lt;( in stack VC this needs to be done separately\u00a0 for each fpc)\r\nshow route ip table\r\nshow route ip table index &lt;value&gt;\r\nshow route ip prefix 1.1.1.1\r\nshow shim vrf-table routes\r\nshow shim bridge interface\r\nset dc bc \"l3 egress show\"\r\nset dc bc \"l3 l3table show\"\r\nset dc bc \"l3 defip show\"<\/pre>\r\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif;\">It turned out that there was no next hop for the lo0.0 to respond to the ICMP query as the configuration was hitting the Trident II limitation mentioned at the beginning of this article. On top of this the implementation of the double route lookup was suffering from a <a href=\"https:\/\/prsearch.juniper.net\/InfoCenter\/index?page=prcontent&amp;id=PR1449410\">bug (<\/a><a href=\"https:\/\/prsearch.juniper.net\/InfoCenter\/index?page=prcontent&amp;id=PR1449410\">PR1449410)<\/a> that affects local interfaces and especially loopbacks. <\/span><\/p>\r\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif;\">In summary you can do route leaking on ex4600 as the issue \u00a0has been resolved in JUNOS 18.3 and later (i.e. not in the recommended release at the time of writing). Also the recommended way of actually doing this is described here in an <a href=\"https:\/\/www.juniper.net\/documentation\/en_US\/junos\/topics\/example\/policy-duplicating-routes.html#jd0e727\">updated guide.<\/a><\/span><\/p>\r\n<p style=\"text-align: justify;\"><span style=\"font-family: arial, helvetica, sans-serif;\">In conclusion &#8211; yes route leaking is possible but the double route lookup requires JUNOS 18.3 or never. I would also suspect that this could be rather intense for the CPU on the EXes,but I haven&#8217;t had the opportunity to stress test this so it is just a guess.<\/span><\/p>\r\n<!-- \/wp:post-content -->","protected":false},"excerpt":{"rendered":"<p>This is a just a very short article about limitations and options with route leaking on the ex4600 switch. This switch is base on the Trident II chip manufactured by Broadcom. It is not very new but\u00a0 it is still a solid piece of silicon used by many platforms across the vendors (Arista, Cisco Juniper). &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/www.kuncar.net\/blog\/2020\/ex4600-route-leaking-trident-ii\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;ex4600 route leaking (Trident II)&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,5],"tags":[37,35,36,38],"class_list":["post-447","post","type-post","status-publish","format-standard","hentry","category-juniper","category-networks","tag-ex4600","tag-juniper","tag-route-leaking","tag-trident-ii"],"_links":{"self":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts\/447","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/comments?post=447"}],"version-history":[{"count":13,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts\/447\/revisions"}],"predecessor-version":[{"id":464,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts\/447\/revisions\/464"}],"wp:attachment":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/media?parent=447"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/categories?post=447"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/tags?post=447"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}