Adding additional loopbacks reachable from the main routing table.

View Only

last person joined: 2 days ago

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.

Back to discussions

Expand all | Collapse all

Adding additional loopbacks reachable from the main routing table.

1. Adding additional loopbacks reachable from the main routing table.

0 Recommend
Jormer
Posted 07-16-2023 12:48

Reply Reply Privately
Hi Guys,

I have the following configuration and outputs. I'm trying to create a loopback 1 interface
and have it reachable from anywhere as if it was in the main routing table. It will not
participate in any dynamic routing but i would do static routing for it. I just want to be able
to ping the routing instance loopback 10.91.29.21 from a hop away and vice-versa.

As you can see below, the main routing table has the lo0.1 route, and the loopbk1-test-vr has
the lo0.0 route. I can ping 10.91.29.21 from the main routing table, by specifying the routing instance,
but I can not ping 10.91.29.1 from the loopbk1-test-vr. I also configured a default route in the routing instance but it did not get installed. Why?

Is this possible? If I'm a hop away, I couldn't specify the routing instance to ping lo0.1 so
should I be able to ping it from another router outside the loopbk1-test-vr with static routing?
If so what am I missing?

10.91.29.1/32 lo0.0 - inet.0
10.91.29.21/32 lo0.1 - loopbk1-test-vr.inet.0

admin@TEST-E4200-SW1>

set interfaces lo0 unit 1 description loopbk1-test
set interfaces lo0 unit 1 family inet address 10.91.29.21/32

set routing-instances loopbk1-test-vr instance-type vrf
set routing-instances loopbk1-test-vr interface lo0.1
set routing-instances loopbk1-test-vr route-distinguisher 1:1
set routing-instances loopbk1-test-vr vrf-target target:1:1
set routing-instances loopbk1-test-vr routing-options static route 0.0.0.0/0 next-hop 10.91.29.1

set routing-options interface-routes rib-group inet vrf-tables
set routing-options rib-groups vrf-tables import-rib inet.0
set routing-options rib-groups vrf-tables import-rib loopbk1-test-vr.inet.0

admin@TEST-E4200-SW1# run show route table loopbk1-test-vr.inet.0

loopbk1-test-vr.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.77.198.0/24 *[Direct/0] 00:05:36
> via vlan.198
10.77.198.4/32 *[Local/0] 00:05:36
Local via vlan.198
10.77.199.0/24 *[Direct/0] 00:05:36
> via vlan.199
10.77.199.4/32 *[Local/0] 00:05:36
Local via vlan.199
10.77.203.4/32 *[Local/0] 00:05:36
Reject
10.77.204.4/32 *[Local/0] 00:05:36
Reject
10.77.205.0/24 *[Direct/0] 00:05:36
> via vlan.205
10.77.205.1/32 *[Local/0] 00:05:36
Local via vlan.205
10.77.205.2/32 *[Local/0] 00:05:36
Local via vlan.205
10.91.29.1/32 *[Direct/0] 00:05:36 <------
> via lo0.0
10.91.29.21/32 *[Direct/0] 00:05:36
> via lo0.1
10.91.29.25/32 *[Local/0] 00:05:36
Reject
192.168.10.0/24 *[Direct/0] 00:05:36
> via vlan.100
192.168.10.1/32 *[Local/0] 00:05:36
Local via vlan.100

{master:0}[edit]
admin@TEST-E4200-SW1#
netadmin@TEST-E4200-SW1> show route table loopbk1-test-vr.inet.0 10.77.198.0

loopbk1-test-vr.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.77.198.0/24 *[Direct/0] 01:31:31
> via vlan.198

{master:0}
netadmin@TEST-E4200-SW1> show route table loopbk1-test-vr.inet.0 10.1.1.1

<------ no default
{master:0}
netadmin@TEST-E4200-SW1>

admin@TEST-E4200-SW1# run show route 10.91.29.21

inet.0: 24 destinations, 39 routes (24 active, 0 holddown, 1 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[BGP/170] 2w1d 21:35:48, localpref 300
AS path: 65306 I
> to 10.77.198.6 via vlan.198

loopbk1-test-vr.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.91.29.21/32 *[Direct/0] 00:06:58 <------
> via lo0.1

{master:0}[edit]
admin@TEST-E4200-SW1#

admin@TEST-E4200-SW1# run ping 10.91.29.21 routing-instance loopbk1-test-vr
PING 10.91.29.21 (10.91.29.21): 56 data bytes
64 bytes from 10.91.29.21: icmp_seq=0 ttl=64 time=0.165 ms
64 bytes from 10.91.29.21: icmp_seq=1 ttl=64 time=0.229 ms
64 bytes from 10.91.29.21: icmp_seq=2 ttl=64 time=0.170 ms
^C
--- 10.91.29.21 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.165/0.188/0.229/0.029 ms

{master:0}[edit]
admin@TEST-E4200-SW1#

admin@TEST-E4200-SW1# run ping 10.91.29.1 source 10.91.29.21 routing-instance loopbk1-test-vr
PING 10.91.29.1 (10.91.29.1): 56 data bytes
^C
--- 10.91.29.1 ping statistics ---
16 packets transmitted, 0 packets received, 100% packet loss

{master:0}[edit]
admin@TEST-E4200-SW1#

------------------------------
Jorge Mercado
------------------------------
2. RE: Adding additional loopbacks reachable from the main routing table.

0 Recommend
Sheetanshu
Posted 07-17-2023 04:40

Reply Reply Privately
Hi,

Do you need all the interface routes from the inet.0 table into the loopbk1-test-vr? If the purpose is to point the default-route from the loopbk1-test-vr to the inet.0 table, you can simply use "set routing-instances loopbk1-test-vr routing-options static-route 0/0 next-table inet.0". You can use the rib-group configuration for the loopbk1-test-vrf routing-instance to export the lo0.1 IP from the loopbk1-test-vr.inet.0 table to inet.0. Also, do you really need to configure the loopbk-1-test-vrf routing-instance as a vrf?

Regards

------------------------------
Sheetanshu Shekhar
------------------------------

Original Message
3. RE: Adding additional loopbacks reachable from the main routing table.

0 Recommend
Jormer
Posted 07-17-2023 11:51

Reply Reply Privately
Hi Sheetanshu,

Thank you very much for your message!! I'm relatively new to the use of Junos routing instances. We currently only use the FBF type. I have also tested this lab with the configuration below (instance-type virtual-router), but any instance type that would simply allow me to reach loopback1 from anywhere will suffice. I have not played w/ import policies to not have to deal with restrictions at this point but I would once loopback1 is reachable.

As I showed before, my original configuration showed each routing table is already
sharing routes for lo0.0 and lo0.1. But I still can not ping lo0.0 from within the loopbk1-test-vr and I can not ping lo0.1 from a hop away TEST-E4200-SW2 with a static route pointing to lo0.0 for lo0.1. The E4200's are doing ospf but i dont want lo0.1 to participate in dynamic routing.

It seems as if I have a traffic filtering issue and not a routing one ?

set routing-options interface-routes rib-group inet vrf-tables
set routing-options rib-groups vrf-tables export-rib loopbk1-test-vr.inet.0
set routing-options rib-groups vrf-tables import-rib inet.0
set routing-options rib-groups vrf-tables import-rib loopbk1-test-vr.inet.0

set routing-instances loopbk1-test-vr instance-type virtual-router
set routing-instances loopbk1-test-vr interface lo0.1
set routing-instances loopbk1-test-vr routing-options static route 0.0.0.0/0 next-hop 10.91.29.1

Hostname: TEST-E4200-SW1
Model: ex4200-24t
JUNOS Base OS boot [10.4R9.2]
JUNOS Base OS Software Suite [10.4R9.2]
...

Also, I assume that our OS version is older and that's the reason I dont see next-table as a next hop option.

admin@TEST-E4200-SW1# set routing-instances loopbk1-test-vr routing-options static route 0.0.0.0/0 ?
Possible completions:
active Remove inactive route from forwarding table
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> as-path Autonomous system path
> bfd-liveness-detection Bidirectional Forwarding Detection (BFD) options
> color Color (preference) value
> color2 Color (preference) value 2
+ community BGP community identifier
discard Drop packets to destination; send no ICMP unreachables
install Install route into forwarding table
> metric Metric value
> metric2 Metric value 2
> metric3 Metric value 3
> metric4 Metric value 4
+ next-hop Next hop to destination <--------------------
no-install Don't install route into forwarding table
no-readvertise Don't mark route as eligible to be readvertised
no-resolve Don't allow resolution of indirectly connected next hops
no-retain Don't always keep route in forwarding table
passive Retain inactive route in forwarding table
> preference Preference value
> preference2 Preference value 2
> qualified-next-hop Next hop with qualifiers
readvertise Mark route as eligible to be readvertised
receive Install a receive route for the destination
reject Drop packets to destination; send ICMP unreachables
resolve Allow resolution of indirectly connected next hops
retain Always keep route in forwarding table
> tag Tag string
> tag2 Tag string 2
{master:0}[edit]
netadmin@TEST-E4200-SW1#

Best Regards,
Jorge.

Original Message
4. RE: Adding additional loopbacks reachable from the main routing table.

0 Recommend
Sheetanshu
Posted 07-17-2023 14:45
Edited by Sheetanshu 07-17-2023 14:45

Reply Reply Privately
Hi Jorge,

- "

As I showed before, my original configuration showed each routing table is already

sharing routes for lo0.0 and lo0.1.

"

Per your previous output, the inet.0 had a default-route pointing towards a BGP peer. It didn't have a route towards the lo0.1, which may be why the ping is not working. Also, I don't think that you can have a static route pointed toward a loopback interface.
admin@TEST-E4200-SW1# run show route 10.91.29.21 inet.0: 24 destinations, 39 routes (24 active, 0 holddown, 1 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 2w1d 21:35:48, localpref 300 AS path: 65306 I > to 10.77.198.6 via vlan.198 <---------------- This is a default route pointing towards some BGP peer loopbk1-test-vr.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.91.29.21/32 *[Direct/0] 00:06:58 <-------- This route is not present in the inet.0 routing-table. > via lo0.1

"Also, I assume that our OS version is older and that's the reason I dont see next-table as a next hop option. " ----- Yes, your JUNOS is very old. The next-table option seems to have been introduced later https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/ref/statement/next-table-edit-protocols-mpls.html

The next-table option would have made it very simple, as from the test routing-instance all the lookup would happen in the inet.0 table, which is what you would need to go out to external devices.

"But I still can not ping lo0.0 from within the loopbk1-test-vr and I can not ping lo0.1 from a hop away TEST-E4200-SW2 with a static route pointing to lo0.0 for lo0.1. The E4200's are doing ospf but i dont want lo0.1 to participate in dynamic routing." -------- The ping between loopbacks will work fine if you use the rib-group options correctly (I would stick to import-rib options). The rib-groups need to be applied for the interface routes both in inet.0 and in the loopbk1-test-vr routing-instance (set routing-instances <> routing-options interface-routes rib-group <>)

In addition to the above interface-routes rib-group, you have the following options to get the default-route in the loopk1-test-vr routing-instance.

Apply a filtered rib-group on the routing protocol through which the 0/0 route is learnt in the inet.0 table (Is it via BGP as shown in your first output?) to import the default-route in the test instance. Note that the rib-group is applied in the source routing-table and in the protocol from where the route is to be imported. Also, note that you would need interface-routes rib-group also to resolve the next-hop.

If instance-import is supported on your version, use this option to import the default-route from inet.0 (use from instance master) to loopbk1-test-vr (set routing-instances <> routing-options instance-import <policy-name>)

BTW, How would E4200-SW2 know about the route towards the lo0.1 interface IP?

Regards

------------------------------
Sheetanshu Shekhar
------------------------------

Original Message
5. RE: Adding additional loopbacks reachable from the main routing table.

0 Recommend
Jormer
Posted 07-18-2023 17:16

Reply Reply Privately
Hi Sheetanshu,

Thank you again very much for your time! Since working with rib-groups is new to me I'm following your options
on intuition more than anything else. I will need to read more on this.

That being said I changed my config and this is what i have at the moment with my basic layout.

TEST-E4200-SW1#
1)+set policy-options policy-statement default-to-vr term permit-default from instance master
2)+set policy-options policy-statement default-to-vr term permit-default then accept

3)set routing-options interface-routes rib-group inet vrf-tables
4)set routing-options rib-groups vrf-tables import-rib inet.0
5)set routing-options rib-groups vrf-tables import-rib loopbk1-test-vr.inet.0

6)set routing-instances loopbk1-test-vr instance-type virtual-router
7)set routing-instances loopbk1-test-vr interface lo0.1
8)+set routing-instances loopbk1-test-vr routing-options interface-routes rib-group inet vrf-tables
9)+set routing-instances loopbk1-test-vr routing-options static route 0.0.0.0/0 next-hop 10.77.198.4
10)+set routing-instances loopbk1-test-vr routing-options instance-import default-to-vr

I did not want to affect dynamic routing with these changes but I guess that's not possible because, simply
adding a static route, line 9, in the loopbk1-test-vr instance does not get installed even if its next-hop is reachable.
Also line 8 makes lo0.1 available to BGP as a directly connected network.

Any reason why I can make the static route config but the route doesn't install?

-
Line 8 allowed the "injection" of the lo0.1 route from instance loopbk1-test-vr into inet.0, thank you for that!
Am I missing another statement here? You mentioned " The rib-groups need to be applied for the interface routes
both in inet.0 and in the loopbk1-test-vr routing-instance. " I'm not sure if I'm missing a rib-group config for inet.0?
What would it look like?

admin@TEST-E4200-SW1> show route 10.91.29.21

inet.0: 25 destinations, 40 routes (25 active, 0 holddown, 1 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

10.91.29.21/32 *[Direct/0] 21:44:39 <----------------------- now it's in.
> via lo0.1

loopbk1-test-vr.inet.0: 22 destinations, 35 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.91.29.21/32 *[Direct/0] 3d 19:42:34
> via lo0.1

{master:0}
admin@TEST-E4200-SW1>

-
Lines 1,2,10 were needed to import directly connected routes from inet.0 to instance loopbk1-test-vr, as you suggested,
as well as the default route. The default route is a discard route from a hop away in an SRX240. I didnt really like
this because it had to "route on a stick" from the firewall. I'd prefer the E4200-SW1 to be the "default gateway"
for its instance loopbk1-test-vr.

admin@TEST-E4200-SW1> show route table loopbk1-test-vr.inet.0 0.0.0.0

loopbk1-test-vr.inet.0: 22 destinations, 35 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[BGP/170] 19:40:19, localpref 300 <----------------------- now it's in.
AS path: 65306 I
> to 10.77.198.6 via vlan.198

{master:0}
admin@TEST-E4200-SW1> show route table loopbk1-test-vr.inet.0 10.77.198.6

loopbk1-test-vr.inet.0: 22 destinations, 35 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.77.198.0/24 *[Direct/0] 22:36:54
> via vlan.198
[Direct/0] 19:40:43
> via vlan.198

{master:0}
admin@TEST-E4200-SW1>

The 10.77.198.0/24 subnet is the primary subnet that anything else is reachable through.
One hop away from E4200-SW1 I see routes for its lo0.0 & lo0.1, but only lo0.0 is reachable.

-
admin@TEST-E4200-SW2> show route 10.91.29.1 (E4200-SW1 lo0.0)

inet.0: 22 destinations, 38 routes (22 active, 0 holddown, 1 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

10.91.29.1/32 *[OSPF/10] 00:00:42, metric 1
to 10.77.198.4 via vlan.198
> to 10.77.199.4 via vlan.199
[BGP/170] 05:20:16, localpref 100, from 10.91.29.1
AS path: I
to 10.77.198.4 via vlan.198
> to 10.77.199.4 via vlan.199

{master:0}
admin@TEST-E4200-SW2>

admin@TEST-E4200-SW2> show route 10.91.29.21 (E4200-SW1 lo0.1)

inet.0: 22 destinations, 38 routes (22 active, 0 holddown, 1 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

10.91.29.21/32 *[BGP/170] 05:22:37, localpref 100, from 10.91.29.1
AS path: I
to 10.77.198.4 via vlan.198
> to 10.77.199.4 via vlan.199

{master:0}
admin@TEST-E4200-SW2>

-
admin@TEST-SRX240> show route 10.91.29.1

inet.0: 18 destinations, 31 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.91.29.1/32 *[BGP/170] 2w6d 01:32:39, localpref 300
AS path: 65006 I
> to 10.77.198.4 via vlan.198
[BGP/170] 2w5d 21:42:10, MED 1, localpref 100
AS path: 65006 I
> to 10.77.199.5 via vlan.199

admin@TEST-SRX240> show route 10.91.29.21

inet.0: 18 destinations, 31 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.91.29.21/32 *[BGP/170] 23:18:03, localpref 300
AS path: 65006 I
> to 10.77.198.4 via vlan.198
[BGP/170] 05:27:55, localpref 100
AS path: 65006 I
> to 10.77.199.5 via vlan.199

admin@TEST-SRX240>

-

admin@TEST-E4200-SW2> ping 10.91.29.1
PING 10.91.29.1 (10.91.29.1): 56 data bytes
64 bytes from 10.91.29.1: icmp_seq=0 ttl=64 time=1.962 ms
64 bytes from 10.91.29.1: icmp_seq=1 ttl=64 time=1.335 ms
64 bytes from 10.91.29.1: icmp_seq=2 ttl=64 time=6.511 ms
^C
--- 10.91.29.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.335/3.269/6.511/2.306 ms

{master:0}
admin@TEST-E4200-SW2> ping 10.91.29.21
PING 10.91.29.21 (10.91.29.21): 56 data bytes
36 bytes from 10.77.198.6: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 09ab 0 0000 01 01 b73c 10.77.199.5 10.91.29.21

36 bytes from 10.77.198.6: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 09cd 0 0000 01 01 b71a 10.77.199.5 10.91.29.21

36 bytes from 10.77.198.6: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 09ef 0 0000 01 01 b6f8 10.77.199.5 10.91.29.21

^C
--- 10.91.29.21 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

{master:0}
admin@TEST-E4200-SW2>

-

admin@TEST-SRX240> ping 10.91.29.1
PING 10.91.29.1 (10.91.29.1): 56 data bytes
64 bytes from 10.91.29.1: icmp_seq=0 ttl=64 time=4.130 ms
64 bytes from 10.91.29.1: icmp_seq=1 ttl=64 time=4.227 ms
^C
--- 10.91.29.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.130/4.178/4.227/0.049 ms

admin@TEST-SRX240> ping 10.91.29.21
PING 10.91.29.21 (10.91.29.21): 56 data bytes
36 bytes from 10.77.198.6: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 ab08 0 0000 01 01 16de 10.77.198.6 10.91.29.21

36 bytes from 10.77.198.6: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 ab0b 0 0000 01 01 16db 10.77.198.6 10.91.29.21

^C
admin@TEST-SRX240>

-

lo0.1 is only reachable from it's host E4200-SW1.

admin@TEST-E4200-SW1> ping 10.91.29.21 source 10.91.29.1
PING 10.91.29.21 (10.91.29.21): 56 data bytes
64 bytes from 10.91.29.21: icmp_seq=0 ttl=64 time=0.177 ms <-------- pinging lo0.1 from lo0.0
64 bytes from 10.91.29.21: icmp_seq=1 ttl=64 time=0.238 ms
64 bytes from 10.91.29.21: icmp_seq=2 ttl=64 time=0.131 ms
64 bytes from 10.91.29.21: icmp_seq=3 ttl=64 time=0.191 ms
^C
--- 10.91.29.21 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.131/0.184/0.238/0.038 ms

{master:0}
admin@TEST-E4200-SW1>

{master:0}
admin@TEST-E4200-SW1> ping 10.91.29.1 source 10.91.29.21 routing-instance loopbk1-test-vr
PING 10.91.29.1 (10.91.29.1): 56 data bytes
64 bytes from 10.91.29.1: icmp_seq=0 ttl=64 time=0.291 ms <-------- pinging lo0.0 from lo0.1
64 bytes from 10.91.29.1: icmp_seq=1 ttl=64 time=0.132 ms
64 bytes from 10.91.29.1: icmp_seq=2 ttl=64 time=0.142 ms
64 bytes from 10.91.29.1: icmp_seq=3 ttl=64 time=0.192 ms
^C
--- 10.91.29.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.132/0.189/0.291/0.063 ms

{master:0}
admin@TEST-E4200-SW1> ping 10.77.198.4 source 10.91.29.21 routing-instan
PING 10.77.198.4 (10.77.198.4): 56 data bytes
64 bytes from 10.77.198.4: icmp_seq=0 ttl=64 time=0.293 ms <-------- pinging E4200-SW1 vlan.198 gw from lo0.1
64 bytes from 10.77.198.4: icmp_seq=1 ttl=64 time=0.190 ms
64 bytes from 10.77.198.4: icmp_seq=2 ttl=64 time=0.132 ms
64 bytes from 10.77.198.4: icmp_seq=3 ttl=64 time=0.196 ms
^C
--- 10.77.198.4 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.132/0.203/0.293/0.058 ms

{master:0}
admin@TEST-E4200-SW1> ping 10.77.198.5 source 10.91.29.21 routing-instanc
PING 10.77.198.5 (10.77.198.5): 56 data bytes
^C
--- 10.77.198.5 ping statistics ---
34 packets transmitted, 0 packets received, 100% packet loss <-------- pinging E4200-SW2 vlan.198 gw from lo0.1

{master:0}
admin@TEST-E4200-SW1> ping 10.77.198.6 source 10.91.29.21 routing-instanc
PING 10.77.198.6 (10.77.198.6): 56 data bytes
^C
--- 10.77.198.6 ping statistics ---
13 packets transmitted, 0 packets received, 100% packet loss <-------- pinging SRX240 vlan.198 gw from lo0.1

{master:0}
admin@TEST-E4200-SW1>

Routing tables:

admin@TEST-E4200-SW1> show route

inet.0: 24 destinations, 38 routes (24 active, 0 holddown, 1 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[BGP/170] 2w6d 02:03:40, localpref 300
AS path: 65306 I
> to 10.77.198.6 via vlan.198
10.77.198.0/24 *[Direct/0] 3w3d 21:48:17
> via vlan.198
[BGP/170] 05:55:37, localpref 100, from 10.91.29.2
AS path: I
> to 10.77.198.5 via vlan.198
to 10.77.199.5 via vlan.199
[BGP/170] 2w6d 03:06:22, MED 0, localpref 100, from 10.91.29.10
AS path: ?
> to 10.77.198.1 via vlan.198
10.77.198.4/32 *[Local/0] 3w3d 21:48:17
Local via vlan.198
10.77.199.0/24 *[Direct/0] 3w3d 21:48:16
> via vlan.199
[BGP/170] 05:55:37, localpref 100, from 10.91.29.2
AS path: I
> to 10.77.198.5 via vlan.198
to 10.77.199.5 via vlan.199
[BGP/170] 1w1d 00:28:12, MED 0, localpref 100, from 10.91.29.11
AS path: ?
> to 10.77.199.1 via vlan.199
10.77.199.4/32 *[Local/0] 3w3d 21:48:16
Local via vlan.199
10.77.202.0/24 *[OSPF/10] 1w1d 00:28:26, metric 41
to 10.77.198.1 via vlan.198
> to 10.77.199.1 via vlan.199
[BGP/170] 1w1d 00:28:26, MED 41, localpref 100, from 10.91.29.2
AS path: I
> to 10.77.199.1 via vlan.199
[BGP/170] 3w3d 23:50:26, MED 0, localpref 100, from 10.91.29.10
AS path: ?
> to 10.77.198.1 via vlan.198
[BGP/170] 1w1d 00:28:12, MED 0, localpref 100, from 10.91.29.11
AS path: ?
> to 10.77.199.1 via vlan.199
10.77.203.4/32 *[Local/0] 3w6d 00:29:22
Reject
10.77.204.4/32 *[Local/0] 3w6d 00:29:22
Reject
10.77.205.0/24 *[Direct/0] 3w6d 00:29:02
> via vlan.205
[BGP/170] 05:55:37, localpref 100, from 10.91.29.2
AS path: I
to 10.77.198.5 via vlan.198
> to 10.77.199.5 via vlan.199
10.77.205.1/32 *[Local/0] 3w6d 00:28:57
Local via vlan.205
10.77.205.2/32 *[Local/0] 3w6d 00:29:22
Local via vlan.205
10.91.24.121/32 *[BGP/170] 2w6d 02:03:40, localpref 300
AS path: 65306 I
> to 10.77.198.6 via vlan.198
10.91.29.1/32 *[Direct/0] 3w6d 00:29:27
> via lo0.0
10.91.29.2/32 *[OSPF/10] 00:38:28, metric 1
> to 10.77.198.5 via vlan.198
to 10.77.199.5 via vlan.199
[BGP/170] 05:55:37, localpref 100, from 10.91.29.2
AS path: I
to 10.77.198.5 via vlan.198
> to 10.77.199.5 via vlan.199
10.91.29.10/32 *[OSPF/10] 3w3d 17:12:27, metric 2
> to 10.77.198.1 via vlan.198
[BGP/170] 2w5d 20:45:18, MED 2, localpref 100, from 10.91.29.2
AS path: I
> to 10.77.198.1 via vlan.198
[BGP/170] 3w3d 23:50:26, MED 0, localpref 100, from 10.91.29.10
AS path: ?
> to 10.77.198.1 via vlan.198
10.91.29.11/32 *[OSPF/10] 1w1d 00:29:51, metric 2
> to 10.77.199.1 via vlan.199
[BGP/170] 1w1d 00:29:51, MED 2, localpref 100, from 10.91.29.2
AS path: I
> to 10.77.199.1 via vlan.199
[BGP/170] 1w1d 00:28:12, MED 0, localpref 100, from 10.91.29.11
AS path: ?
> to 10.77.199.1 via vlan.199
10.91.29.21/32 *[Direct/0] 23:48:13
> via lo0.1
10.91.29.25/32 *[Local/0] 4d 20:37:23
Reject
192.168.10.1/32 *[Local/0] 3w6d 00:29:22
Reject
192.168.11.0/24 *[Static/5] 3w4d 17:43:37
Discard
192.168.12.0/24 *[BGP/170] 2w5d 20:52:33, localpref 100, from 10.91.29.2
AS path: I
> to 10.77.198.5 via vlan.198
to 10.77.199.5 via vlan.199
224.0.0.2/32 *[PIM/0] 3w6d 00:29:27
MultiRecv
224.0.0.5/32 *[OSPF/10] 3w6d 00:29:27, metric 1
MultiRecv
224.0.0.13/32 *[PIM/0] 3w6d 00:29:27
MultiRecv

loopbk1-test-vr.inet.0: 21 destinations, 33 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[BGP/170] 21:40:10, localpref 300
AS path: 65306 I
> to 10.77.198.6 via vlan.198
10.77.198.0/24 *[Direct/0] 1d 00:36:21
> via vlan.198
[Direct/0] 21:40:10
> via vlan.198
10.77.198.4/32 *[Local/0] 1d 00:36:21
Local via vlan.198
[Local/0] 21:40:10
Local via vlan.198
10.77.199.0/24 *[Direct/0] 1d 00:36:21
> via vlan.199
[Direct/0] 21:40:10
> via vlan.199
10.77.199.4/32 *[Local/0] 1d 00:36:21
Local via vlan.199
[Local/0] 21:40:10
Local via vlan.199
10.77.202.0/24 *[OSPF/10] 21:40:10, metric 41
to 10.77.198.1 via vlan.198
> to 10.77.199.1 via vlan.199
10.77.203.4/32 *[Local/0] 1d 00:36:21
Reject
[Local/0] 21:40:10
Reject
10.77.204.4/32 *[Local/0] 1d 00:36:21
Reject
[Local/0] 21:40:10
Reject
10.77.205.0/24 *[Direct/0] 1d 00:36:21
> via vlan.205
[Direct/0] 21:40:10
> via vlan.205
10.77.205.1/32 *[Local/0] 1d 00:36:21
Local via vlan.205
[Local/0] 21:40:10
Local via vlan.205
10.77.205.2/32 *[Local/0] 1d 00:36:21
Local via vlan.205
[Local/0] 21:40:10
Local via vlan.205
10.91.24.121/32 *[BGP/170] 21:40:10, localpref 300
AS path: 65306 I
> to 10.77.198.6 via vlan.198
10.91.29.1/32 *[Direct/0] 1d 00:36:21
> via lo0.0
[Direct/0] 21:40:10
> via lo0.0
10.91.29.2/32 *[OSPF/10] 00:38:28, metric 1
> to 10.77.198.5 via vlan.198
to 10.77.199.5 via vlan.199
10.91.29.10/32 *[OSPF/10] 21:40:10, metric 2
> to 10.77.198.1 via vlan.198
10.91.29.11/32 *[OSPF/10] 21:40:10, metric 2
> to 10.77.199.1 via vlan.199
10.91.29.21/32 *[Direct/0] 3d 21:46:08
> via lo0.1
10.91.29.25/32 *[Local/0] 1d 00:36:21
Reject
[Local/0] 21:40:10
Reject
192.168.10.1/32 *[Local/0] 00:38:28
Reject
[Local/0] 21:40:10
Reject
192.168.11.0/24 *[Static/5] 21:40:10
Discard
192.168.12.0/24 *[BGP/170] 21:40:10, localpref 100, from 10.91.29.2
AS path: I
> to 10.77.198.5 via vlan.198
to 10.77.199.5 via vlan.199

inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

ff02::2/128 *[PIM/0] 3w6d 00:29:28
MultiRecv
ff02::d/128 *[PIM/0] 3w6d 00:29:28
MultiRecv

{master:0}
admin@TEST-E4200-SW1>

Routing protocos are fine..

admin@TEST-E4200-SW1> show ospf neighbor
Address Interface State ID Pri Dead
10.77.198.1 vlan.198 Full 10.91.29.10 1 38 -- n/a
10.77.198.5 vlan.198 Full 10.91.29.2 128 32 -- E4200-SW2
10.77.199.1 vlan.199 Full 10.91.29.11 1 35 -- n/a
10.77.199.5 vlan.199 Full 10.91.29.2 128 31 -- E4200-SW2

{master:0}
admin@TEST-E4200-SW1>

admin@TEST-E4200-SW1> show bgp summary
Groups: 2 Peers: 4 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 17 3 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.77.198.6 65306 64063 64136 0 0 2w6d2h 2/2/2/0 0/0/0/0 -- SRX240
10.91.29.2 65006 82222 82225 0 0 3w4d18h 1/9/8/0 0/0/0/0 -- E4200-SW2
10.91.29.10 65006 222437 246307 0 1 3w4d0h 0/3/3/0 0/0/0/0 -- n/a
10.91.29.11 65006 222435 246304 0 1 1w1d1h 0/3/3/0 0/0/0/0 -- n/a

{master:0}
admin@TEST-E4200-SW1>

I hope I'm just missing config. I have general questions about your suggestions below. I went with the second one because I saw the commands and the syntax seemed simpler but im not sure if I may be missing additional config. The option to apply the rib-group to BGP is interesting, I guess I'll need an example.

-----

In addition to the above interface-routes rib-group, you have the following options to get the default-route in the loopk1-test-vr routing-instance.

Apply a filtered rib-group on the routing protocol through which the 0/0 route is learnt in the inet.0 table (Is it via BGP as shown in your first output?) to import the default-route in the test instance. Note that the rib-group is applied in the source routing-table and in the protocol from where the route is to be imported. Also, note that you would need interface-routes rib-group also to resolve the next-hop.

If instance-import is supported on your version, use this option to import the default-route from inet.0 (use from instance master) to loopbk1-test-vr (set routing-instances <> routing-options instance-import <policy-name>)

----

Thanks
Jorge.

------------------------------
Jorge Mercado
------------------------------

Original Message
6. RE: Adding additional loopbacks reachable from the main routing table.

0 Recommend
Sheetanshu
Posted 07-20-2023 06:01

Reply Reply Privately
"I did not want to affect dynamic routing with these changes but I guess that's not possible because, simply
adding a static route, line 9, in the loopbk1-test-vr instance does not get installed even if its next-hop is reachable.
Also line 8 makes lo0.1 available to BGP as a directly connected network.

Any reason why I can make the static route config but the route doesn't install?"

In step 9, you have pointed the default-route towards 10.77.198.4, which is a local interface IP on the same switch SW1. Could you try pointing it to .5 instead?

For line 8 making lo0.1 available to BGP, you can use export policy to suppress this route from being advertised to BGP peers. But, then how would the external devices know the route back to the lo0.1 IP?

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

"Line 8 allowed the "injection" of the lo0.1 route from instance loopbk1-test-vr into inet.0, thank you for that!
Am I missing another statement here? You mentioned " The rib-groups need to be applied for the interface routes
both in inet.0 and in the loopbk1-test-vr routing-instance. " I'm not sure if I'm missing a rib-group config for inet.0?
What would it look like?"

You already took care of it in line 8, as in the previous configuration inet.0 table didn't have a route towards lo0.1 Also, you can try removing line 3, as that is used to import the interface routes from inet.0 to loopbk1-test-vr.inet.0. This is redundant as with lines 1 and 2, you are importing all the routes from inet.0 to loopbk1-test-vr.inet.0 anyway. This should clean-up the routing-table for loopbk1-test-vr.inet.0 as there are duplicate local and connected routes in that table.

OR

you could just use line 3 (without using instance import at all, as you do not want to use the inherited default route anyway) to populate the directly connected and local routes from inet.0 into loopbk1-test-vr.inet.0 and use a static default route in loopbk1-test-vr.inet.0 with a proper next-hop (as suggested in the previous point).

We get the routes imported either via rib-groups or instance-import. Also, would recommend using policies to control which routes to import only the required routes.

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

"Lines 1,2,10 were needed to import directly connected routes from inet.0 to instance loopbk1-test-vr, as you suggested,
as well as the default route. The default route is a discard route from a hop away in an SRX240. I didnt really like
this because it had to "route on a stick" from the firewall. I'd prefer the E4200-SW1 to be the "default gateway"
for its instance loopbk1-test-vr."

The directly connected and interface routes are imported from the rib-group and instance-import both in the configuration. If you don't intend to import the default-route from inet.0 and create a static route in loopback1-test-vr, I don't really see a point in the instance-import configuration

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

"The 10.77.198.0/24 subnet is the primary subnet that anything else is reachable through.
One hop away from E4200-SW1 I see routes for its lo0.0 & lo0.1, but only lo0.0 is reachable."

The one difference I see is that the route for lo0.0 is an OSPF route and the route for lo0.1 is a BGP route on SW-2. Would that have an impact in anyway?

Also, in the pings from SW-2 and SRX could you please specify the source-address. Do you intend to ping from the lo0.1 IP from the lo0.0 IP of SW2?

With the present state, from the loopbk1-test-vr instance, the traffic to an external IP (e.g. 10.91.29.2) will be sent towards the SRX (0/0 next hop is SRX), but the return traffic from 10.91.29.2 to 10.91.29.21 would be sent directly to SW1. This won't work. Having said that, the ping to the irb, interface IPs should have worked.

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

"The option to apply the rib-group to BGP is interesting, I guess I'll need an example."

A normal rib-group needs to be created under routing options ( set routing-options rib-group <> import-rib [ source-table destination-table] ). Then apply the rib-group to the bgp protocol of the source-table ( set protocols bgp group <> neighbor <> family inet unicast rib-group <>). This would import the BGP routes from the source-table into the destination-table. Note that the routes that are to be imported can be controlled, by using import-policy in the rib-group configuration, in case only selected routes from BGP are to be imported.

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

Is it possible to upgrade your switch? The version running is very old.

Regards

------------------------------
Sheetanshu Shekhar
------------------------------

Original Message
7. RE: Adding additional loopbacks reachable from the main routing table.

0 Recommend
Olivier Benghozi
Posted 07-19-2023 05:43

Reply Reply Privately
Not sure if relevant for your case, but I remember that on those older EX4200 there was some serious limitations about rib route leaking, notably with direct routes (connected: interfaces, loopbacks). It wasn't supported actually (but last time I discussed this was a very long time ago).

The documentation still mentions this kind of things:

https://www.juniper.net/documentation/us/en/software/junos/static-routing/topics/ref/statement/import-rib-edit-routing-options.html

NOTE: On EX Series switches, only dynamically learned routes can be imported from one routing table group to another.

------------------------------
Olivier Benghozi
------------------------------

Original Message
8. RE: Adding additional loopbacks reachable from the main routing table.

0 Recommend
Jormer
Posted 07-19-2023 11:40

Reply Reply Privately
Hi Olivier,

From the instance table loopbk1-test-vr.inet.0 above looks like I got bgp, ospf & direct routes. I can ping from the instance the directly connected IP's on host E4200-SW1, but I cant reach one hop away hosts on the primary subnet 10.77.198.0/24. That said, I just checked and I can reach routes coming from 10.77.198.1 & 10.77.199.1 from the instance. I'm not sure why I can reach 10.77.198.1 but not 10.77.198.5 (SW2) nor 10.77.198.6 (SRX). I will double check my config. Btw I made a typo on my network sketch, the SRX lo0 is 10.91.24.121/32 learned via 10.77.198.6 which i can not reach..

Regards,

Jorge.

------------------------------
Jorge Mercado
------------------------------

Original Message
9. RE: Adding additional loopbacks reachable from the main routing table.

0 Recommend
Jormer
Posted 07-19-2023 12:02

Reply Reply Privately
Sorry just to clarify, I can reach all the available networks outside the instance. You can see that OSPF / BGP neighbors are stable. I'm just having odd behavior reaching networks from the instance.

------------------------------
Jorge Mercado
------------------------------

Original Message
10. RE: Adding additional loopbacks reachable from the main routing table.

0 Recommend
Jormer
Posted 07-24-2023 12:18

Reply Reply Privately
Hi Sheetanshu,

Thank you again for your suggestions!

Responding to your questions:

-In line 9, you have pointed the default-route towards 10.77.198.4, which is a local interface IP on the same switch SW1.
Could you try pointing it to .5 instead?

Ok I pointed it to 10.77.198.1 for additional tests.

-For line 8 making lo0.1 available to BGP, you can use export policy to suppress this route from being advertised to BGP peers.
But, then how would the external devices know the route back to the lo0.1 IP?

In the meantime I'll leave it reachable thru dynamic routing until reachability is resolved, then I'll play w/ bgp export policies,
what i want to do next is play with static routing to lo0.1, although in general I want to learn to manipulate routing instances, rib-groups etc..

-

Ok I removed lines 1,2,10 for instance import, and changed the default and im left with the below config and the loopbk1-test-vr's route table
is what i needed.

1b)set routing-options interface-routes rib-group inet vrf-tables

2b)set routing-options rib-groups vrf-tables import-rib inet.0
3b)set routing-options rib-groups vrf-tables import-rib loopbk1-test-vr.inet.0

4b)set routing-instances loopbk1-test-vr instance-type virtual-router
5b)set routing-instances loopbk1-test-vr interface lo0.1
6b)set routing-instances loopbk1-test-vr routing-options interface-routes rib-group inet vrf-tables
7b)set routing-instances loopbk1-test-vr routing-options static route 0.0.0.0/0 next-hop 10.77.198.1

admin@TEST-E4200-SW1> show route terse
...
loopbk1-test-vr.inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 0.0.0.0/0 S 5 >10.77.198.1
* 10.77.198.0/24 D 0 >vlan.198
* 10.77.198.4/32 L 0 Local
* 10.77.199.0/24 D 0 >vlan.199
* 10.77.199.4/32 L 0 Local
* 10.77.203.4/32 L 0 Reject
* 10.77.204.4/32 L 0 Reject
* 10.77.205.0/24 D 0 >vlan.205
* 10.77.205.1/32 L 0 Local
* 10.77.205.2/32 L 0 Local
* 10.91.29.1/32 D 0 >lo0.0
* 10.91.29.3/32 D 0 >lo0.0
* 10.91.29.21/32 D 0 >lo0.1
* 10.91.29.25/32 L 0 Reject
* 192.168.10.1/32 L 0 Reject

-Also, in the pings from SW-2 and SRX could you please specify the source-address.
Do you intend to ping from the lo0.1 IP from the lo0.0 IP of SW2?

Interesting, when pinging lo0.1 from SW2 I now get replies from SW1's vlan 198 gw. Any ideas why this would happen?
When pinging 10.91.29.21 from the SRX (any IP for now) I still get TTL exceeded. I will check my config.

netadmin@TEST-E4200-SW2> ping 10.91.29.21 source 10.91.29.2
PING 10.91.29.21 (10.91.29.21): 56 data bytes
64 bytes from 10.77.198.4: icmp_seq=0 ttl=64 time=3.374 ms
64 bytes from 10.77.198.4: icmp_seq=1 ttl=64 time=3.629 ms
64 bytes from 10.77.198.4: icmp_seq=2 ttl=64 time=6.410 ms
64 bytes from 10.77.198.4: icmp_seq=3 ttl=64 time=6.504 ms
^C
--- 10.91.29.21 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.374/4.979/6.504/1.481 ms

{master:0}
netadmin@TEST-E4200-SW2> ping 10.91.29.21 source 10.77.198.5
PING 10.91.29.21 (10.91.29.21): 56 data bytes
64 bytes from 10.77.198.4: icmp_seq=0 ttl=64 time=5.365 ms
64 bytes from 10.77.198.4: icmp_seq=1 ttl=64 time=3.420 ms
64 bytes from 10.77.198.4: icmp_seq=2 ttl=64 time=3.724 ms
64 bytes from 10.77.198.4: icmp_seq=3 ttl=64 time=3.611 ms
^C
--- 10.91.29.21 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.420/4.030/5.365/0.778 ms

{master:0}
netadmin@TEST-E4200-SW2>

--

netadmin@TEST-SRX240> ping 10.91.29.21 source 10.91.24.121
PING 10.91.29.21 (10.91.29.21): 56 data bytes
36 bytes from 10.77.199.5: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 d431 0 0000 01 01 9b34 10.91.24.121 10.91.29.21

^C
netadmin@TEST-SRX240> ping 10.91.29.21 source 10.77.198.6
PING 10.91.29.21 (10.91.29.21): 56 data bytes
36 bytes from 10.77.199.5: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 d477 0 0000 01 01 ed6e 10.77.198.6 10.91.29.21

^C
netadmin@TEST-SRX240>

############

As a separate lab track for my other tests I have also added an IP to lo0.0 per the below config and made it reachable.
I'll just need to place statics where needed and filters to separate from dynamic routing. I will use this as my new "test loopback"
for my other labs and will keep the routing instance for lo0.1 as a separate lab to learn more about instances, rib-groups etc.

admin@TEST-E4200-SW1#
set interfaces lo0 unit 0 family inet address 10.91.29.1/32
+set interfaces lo0 unit 0 family inet address 10.91.29.3/32

-set protocols ospf area 0.0.0.10 interface lo0.0 passive
+set protocols ospf area 0.0.0.10 interface 10.91.29.1 passive

...
set policy-options policy-statement ibgp_out term direct from protocol direct
set policy-options policy-statement ibgp_out term direct from route-filter 10.91.29.3/32 exact
set policy-options policy-statement ibgp_out term direct then reject
set policy-options policy-statement ibgp_out term direct2 from protocol direct
set policy-options policy-statement ibgp_out term direct2 then accept

admin@TEST-E4200-SW2#

+set routing-options static route 10.91.29.3/32 next-hop 10.77.198.4

admin@TEST-E4200-SW2> ping 10.91.29.3
PING 10.91.29.3 (10.91.29.3): 56 data bytes
64 bytes from 10.91.29.3: icmp_seq=0 ttl=64 time=1.398 ms
64 bytes from 10.91.29.3: icmp_seq=1 ttl=64 time=4.239 ms
64 bytes from 10.91.29.3: icmp_seq=2 ttl=64 time=4.245 ms
64 bytes from 10.91.29.3: icmp_seq=3 ttl=64 time=4.229 ms
^C
--- 10.91.29.3 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.398/3.528/4.245/1.230 ms

{master:0}
netadmin@TEST-E4200-SW2>

Regards,
Jorge.

------------------------------
Jorge Mercado
------------------------------

Original Message

Routing

Adding additional loopbacks reachable from the main routing table.

Jormer07-16-2023 12:48

Sheetanshu07-17-2023 04:40

Jormer07-17-2023 11:51

Sheetanshu07-17-2023 14:45

Jormer07-18-2023 17:16

Sheetanshu07-20-2023 06:01

Olivier Benghozi07-19-2023 05:43

Jormer07-19-2023 11:40

Jormer07-19-2023 12:02

Jormer07-24-2023 12:18

1. Adding additional loopbacks reachable from the main routing table.

2. RE: Adding additional loopbacks reachable from the main routing table.

3. RE: Adding additional loopbacks reachable from the main routing table.

4. RE: Adding additional loopbacks reachable from the main routing table.

5. RE: Adding additional loopbacks reachable from the main routing table.

6. RE: Adding additional loopbacks reachable from the main routing table.

7. RE: Adding additional loopbacks reachable from the main routing table.

8. RE: Adding additional loopbacks reachable from the main routing table.

9. RE: Adding additional loopbacks reachable from the main routing table.

10. RE: Adding additional loopbacks reachable from the main routing table.