6

I have a simple setup:

  • 2x Juniper MX-Series routers each having one uplink to a transit provider
  • iBGP session between both routers (point-to-point)
  • For testing purposes I've disabled the uplink from R2 to the transit provider. All routes are received from the R1 iBGP session.
  • Trying to figure out why R2 can't utilize R1's routes when it seems to have a route to do so

The configuration is very basic:

R1

protocols {
    bgp {
        group internal-peers {
            type internal;
            description "iBGP between R1 and R2";
            local-address 172.16.20.1; # lo0.0
            export iBGP-send-direct;
            neighbor 172.16.20.2; # R2 lo0.0
        }
    }
    ospf {
        area 0.0.0.0 {
            interface lo0.0 {
                passive;
            }
            interface et-0/0/0.0; # point-to-point to R2
        }
    }
}

R2

protocols {                             
    bgp {
        group internal-peers {
            type internal;
            description "iBGP between R2 and R1";
            local-address 172.16.20.2; # lo0.0
            export iBGP-send-direct;
            neighbor 172.16.20.1; # R1 lo0.0
        }
    }
    ospf {
        area 0.0.0.0 {
            interface lo0.0 {
                passive;
            }
            interface et-0/0/0.0; # point-to-point to R1
        }
    }
}

iBGP-send-direct policy-statement

policy-statement iBGP-send-direct {     
    term 1 {                            
        from protocol direct;           
        then accept;                    
    }                                   
    term 2 {                            
        from protocol static;           
        then accept;                    
    }                                   
}

I'm getting routes properly however when traffic is going from R2 to R1 it's not getting to upstream:

R2

user@r2> show route 1.1.1.1 

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

1.1.1.0/24         *[BGP/170] 00:07:47, MED 2020, localpref 100, from 172.16.20.1
                      AS path: 174 13335 I, validation-state: unverified
                    > to 172.16.25.1 via et-0/0/0.0

When tracing 1.1.1.1 from R2 it goes to 172.16.25.1 (which is can reach) however nothing else. There is a route on R1 for 1.1.1.1.

R1

user@r1> show route 1.1.1.1 

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

1.1.1.0/24         *[BGP/170] 04:07:16, MED 2020, localpref 100
                      AS path: 174 13335 I, validation-state: unverified
                    > to 38.104.XX.XX via xe-0/1/4.0

I'm clearly missing something very obvious here. Can someone shed some insight?

Thank you.

Improve this question
4
  • Can you please add IP configuration details for both routers and all interfaces? A small diagram with the interface names and IP addresses would really help, as would the BGP configuration with your transits.
    – Teun Vink
    Commented Oct 30, 2018 at 5:40
  • 3
    Do you use NAT at router R1? If so: can you post the configuration? If not: the next-hop router from R1 will probably not have a return route to 172.16.0.0/12 networks pointing to R1.
    – RobinG
    Commented Oct 30, 2018 at 6:51
  • @RobinG That was it -- I wasn't thinking that the upstream routers wouldn't be able to get a return path to the 172.16/16 range. Once I made the point-to-point link utilize a range they could get a return path to everything worked as intended. If you'd like to post this as an answer I'll mark it as such. Thanks!
    – WinkyWolly
    Commented Oct 30, 2018 at 16:40
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin ♦
    Commented Jan 5, 2021 at 1:22

2 Answers 2

Reset to default
4

Just for sake of interest I've built a test topology, which displayed in image below:

Little remark: all router's configs are pretty much default. What I did:

  • ISP router with loopback of 1.1.1.1/32. Announcing route 1.1.1.0/24 via BGP to vMX-1. BGP session to vMX-2 not configured;
  • vMX-1 and vMX-2 share virtual IP 198.18.100.3 via VRRP; this IP is set as default gateway for PC1 (198.18.100.5);
  • vMX-1 announces 198.18.100.0/24 to ISP;
  • Connection from vMX-2 to ISP deleted intentionaly.

Router configurations:

ISP

interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 201.100.0.5 255.255.255.248
 duplex auto
 speed auto
!
router bgp 200
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 network 1.1.1.0 mask 255.255.255.0
 neighbor 201.100.0.1 remote-as 100
 neighbor 201.100.0.1 update-source FastEthernet0/0
 no auto-summary
!
ip route 1.1.1.0 255.255.255.0 Null0

Status:

Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
201.100.0.1     4        100      53      50        4    0    0 00:15:01        1

     1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       1.1.1.1/32 is directly connected, Loopback0
S       1.1.1.0/24 is directly connected, Null0
     201.100.0.0/29 is subnetted, 1 subnets
C       201.100.0.0 is directly connected, FastEthernet0/0
B    198.18.100.0/24 [20/0] via 201.100.0.1, 00:07:38

vMX-1

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 201.100.0.1/29;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 172.16.25.1/30;
                address 198.18.100.1/29 {
                    vrrp-group 1 {
                        virtual-address 198.18.100.3;
                        priority 50;
                        accept-data;
                    }
                }
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 172.16.20.1/32;
            }
        }
    }
}
routing-options {
    static {
        route 198.18.100.0/24 {
            discard;
            preference 240;
        }
    }
}
protocols {
    bgp {
        local-as 100;
        group internal-peers {
            type internal;
            local-address 172.16.20.1;
            export ibgp-local-as;
            neighbor 172.16.20.2;
        }
        group isp {
            type external;
            export bgp-local-as;
            neighbor 201.100.0.5 {
                peer-as 200;
            }
        }
    }
    ospf {
        area 0.0.0.0 {
            interface lo0.0 {
                passive;
            }
            interface ge-0/0/1.0;
        }
    }
}
policy-options {
    policy-statement bgp-local-as {
        term t1 {
            from {
                route-filter 198.18.100.0/24 exact;
            }
            then accept;
        }
    }
    policy-statement ibgp-local-as {
        term t1 {
            then {
                next-hop self;
            }
        }
    }
}

Status:

> show bgp summary
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.20.2             100         42         44       0       0       18:28 0/0/0/0              0/0/0/0
201.100.0.5             200         36         41       0       0       17:09 1/1/1/0              0/0/0/0

> show route
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.0/24         *[BGP/170] 00:17:35, MED 0, localpref 100
                      AS path: 200 I, validation-state: unverified
                    > to 201.100.0.5 via ge-0/0/0.0
172.16.20.1/32     *[Direct/0] 00:32:40
                    > via lo0.0
172.16.20.2/32     *[OSPF/10] 00:21:16, metric 1
                    > to 172.16.25.2 via ge-0/0/1.0
                      to 198.18.100.2 via ge-0/0/1.0
172.16.25.0/30     *[Direct/0] 00:22:00
                    > via ge-0/0/1.0
172.16.25.1/32     *[Local/0] 00:22:00
                      Local via ge-0/0/1.0
198.18.100.0/24    *[Static/240] 00:09:57
                      Discard
198.18.100.0/29    *[Direct/0] 00:29:46
                    > via ge-0/0/1.0
198.18.100.1/32    *[Local/0] 00:29:46
                      Local via ge-0/0/1.0
198.18.100.3/32    *[Local/0] 00:22:42
                      Local via ge-0/0/1.0
201.100.0.0/29     *[Direct/0] 00:38:10
                    > via ge-0/0/0.0
201.100.0.1/32     *[Local/0] 00:38:10
                      Local via ge-0/0/0.0
224.0.0.5/32       *[OSPF/10] 00:31:58, metric 1
                      MultiRecv

> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
198.18.100.2     ge-0/0/1.0             Full      172.16.20.2      128    35
172.16.25.2      ge-0/0/1.0             Full      172.16.20.2      128    39

vMX-2

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 201.100.0.2/29;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 172.16.25.2/30;
                address 198.18.100.2/29 {
                    vrrp-group 1 {
                        virtual-address 198.18.100.3;
                        priority 150;
                        accept-data;
                    }
                }
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 172.16.20.2/32;
            }
        }
    }
}
protocols {
    bgp {
        local-as 100;
        group internal-peers {
            type internal;
            local-address 172.16.20.2;
            export ibgp-local-as;
            neighbor 172.16.20.1;
        }
    }
    ospf {
        area 0.0.0.0 {
            interface lo0.0 {
                passive;
            }
            interface ge-0/0/1.0;
        }
    }
}
policy-options {
    policy-statement ibgp-local-as {
        term t1 {
            then {
                next-hop self;
            }
        }
    }
}

Route table from vMX-2:

> show route

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

1.1.1.0/24         *[BGP/170] 00:03:36, MED 0, localpref 100, from 172.16.20.1
                      AS path: 200 I, validation-state: unverified
                    > to 172.16.25.1 via ge-0/0/1.0
                      to 198.18.100.1 via ge-0/0/1.0
172.16.20.1/32     *[OSPF/10] 00:33:17, metric 1
                      to 172.16.25.1 via ge-0/0/1.0
                    > to 198.18.100.1 via ge-0/0/1.0
172.16.20.2/32     *[Direct/0] 00:44:46
                    > via lo0.0
172.16.25.0/30     *[Direct/0] 00:34:22
                    > via ge-0/0/1.0
172.16.25.2/32     *[Local/0] 00:34:22
                      Local via ge-0/0/1.0
198.18.100.0/29    *[Direct/0] 00:41:49
                    > via ge-0/0/1.0
198.18.100.2/32    *[Local/0] 00:41:49
                      Local via ge-0/0/1.0
198.18.100.3/32    *[Local/0] 00:08:33
                      Local via ge-0/0/1.0
201.100.0.0/29     *[Direct/0] 00:49:58
                    > via ge-0/0/0.0
201.100.0.2/32     *[Local/0] 00:49:58
                      Local via ge-0/0/0.0
224.0.0.5/32       *[OSPF/10] 00:43:57, metric 1
                      MultiRecv

Ping from PC1:

PC1> ping 1.1.1.1
84 bytes from 1.1.1.1 icmp_seq=1 ttl=254 time=12.161 ms
84 bytes from 1.1.1.1 icmp_seq=2 ttl=254 time=12.250 ms
84 bytes from 1.1.1.1 icmp_seq=3 ttl=254 time=5.690 ms
84 bytes from 1.1.1.1 icmp_seq=4 ttl=254 time=9.649 ms
84 bytes from 1.1.1.1 icmp_seq=5 ttl=254 time=2.823 ms

Trace:

PC1> trace 1.1.1.1
trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop
 1   172.16.25.2   2.584 ms  0.861 ms  0.645 ms
 2   172.16.25.1   2.450 ms  1.736 ms  1.723 ms
 3   *201.100.0.5   9.231 ms (ICMP type:3, code:3, Destination port unreachable)

I think your configuration is simply lack of next-hop self policy for iBGP.

Improve this answer
0

What is 172.16.25.1? Are you setting next-hop self? By default, IBGP advertised prefixes retain their current next-hop (which would be transit).

You can modify Junos's BGP implementation to retain all routes whether or not they're valid: https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/keep-edit-protocols-bgp.html

But I suspect if you can't traceroute that there's more going on here. Can you provide your traceroute? Can you also include the source address of the traceroute? I see private addresses in the mix, which aren't typically going to be helpful when tracerouting to the internet.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.