Routing

Hello folks,

I have two MX routers.  One currently has a single internet connection on which it receives the full BGP routing table, and the other has no connection up at the moment.  I have configured IBGP between the two, and the second router is getting BGP routes, but I can't send traffic (such as pings) to valid IP addresses from it.  Here is what I have configured and what I am seeing:

Router 1:

# show protocols bgp 
group internal {
    type internal;
    export [ ibgp-nhs send-direct ];
    neighbor 172.28.30.10 {
        local-address 172.28.30.9;
    }
}

# show policy-options policy-statement ibgp-nhs 
term next-hop-self {
    then {
        next-hop self;
    }
}

# show policy-options policy-statement send-direct 
term 2 {
    from protocol direct;
    then accept;
}

# run show route 8.8.8.8 

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

8.8.8.0/24         *[BGP/170] 03:11:24, localpref 100
                      AS path: 10913 701 15169 I, validation-state: unverified
                    > to 123.123.123.89 via ge-1/0/0.0

# run ping 8.8.8.8 
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=50 time=16.715 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=50 time=16.710 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=50 time=16.721 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=50 time=16.713 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 16.710/16.715/16.721/0.004 ms

Router 2:

# show protocols bgp 
group internal {
    type internal;
    export [ ibgp-nhs send-direct ];
    neighbor 172.28.30.9 {
        local-address 172.28.30.10;
    }
}

# show policy-options policy-statement ibgp-nhs 
term next-hop-self {
    then {
        next-hop self;
    }
}

# show policy-options policy-statement send-direct 
term 2 {
    from protocol direct;
    then accept;
}

# run show route 8.8.8.8 

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

8.8.8.0/24         *[BGP/170] 05:12:07, localpref 100
                      AS path: 10913 701 15169 I, validation-state: unverified
                    > to 172.28.30.9 via ae1.0

# run ping 8.8.8.8 
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

 NOTE: on the "show route" command from Router 1, I changed the peer's IP address.

The only difference I see is that Router 1 shows the route as being the BGP peer's IP and Router 2's being the IP of the interface it shares with R1.  Is this because it is passing over an IP address on a private IP space?  Any help is appreciated.

>show configuration interface ae1.0

>show interfaces terse ae1

on both MX. I suspect is a trunk interface is enabled to carry all traffic? Any firewall filters beween them? Also, unless MX2 will also be peering with other eBGP peers, the nhs-self policy is not necessary.

Yes the address 172.28.30.9 for 8.8.8.8 is correct on MX2; when you use the nhs-self policy, all eBGP routes advertised to iBGP peers will have the next-hop changed to address that was used to establish the iBGP session.

On MX-1:

> show configuration interfaces ae1 
description "Connection to mx-2";
unit 0 {
    family inet {
        address 172.28.30.9/30;
    }
}

> show interfaces ae1 terse 
Interface               Admin Link Proto    Local                 Remote
ae1                     up    up
ae1.0                   up    up   inet     172.28.30.9/30  
                                   multiservice

 And on MX-2:

> show configuration interfaces ae1 
description "Connection to mx-1";
unit 0 {
    family inet {
        address 172.28.30.10/30;
    }
}

> show interfaces ae1 terse 
Interface               Admin Link Proto    Local                 Remote
ae1                     up    up
ae1.0                   up    up   inet     172.28.30.10/30 
                                   multiservice

 It isn't a trunk link, just a point-to-point link.  My thought was to have MX2 also peer with the eBGP peer that MX1 is connected to, but given that MX2 will also have its own eBGP peers that isn't absolutely necessary.

EDIT: No firewall filters at the moment.

There are no physical interfaces in the aggregated interface. You need to add physical interfaces in the link.

http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/link-aggregation-cli.html

http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/interfaces-lag-overview.html

Enable LACP also

http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/lacp-cli.html

There are physical interfaces on the aggregated interface.

MX-1:

> show interfaces terse | match ae1 
ge-1/0/4.0              up    up   aenet    --> ae1.0
ge-1/0/5.0              up    down aenet    --> ae1.0
ae1                     up    up
ae1.0                   up    up   inet     172.28.30.9/30  

 MX-2:

2> show interfaces terse | match ae1 
ge-1/0/4.0              up    up   aenet    --> ae1.0
ge-1/1/5.0              up    down aenet    --> ae1.0
ae1                     up    up
ae1.0                   up    up   inet     172.28.30.10/30 

 I don't have LACP enabled and I'll do so.  However, I can ping and ssh across the link, and OSPF and IBGP neighbor relationships are forming as expected, so I do think that is working.

EDIT: I enabled LACP but to no avail.  Please note only one physical connection - ge-1/0/4 -  on the AE is currently connected.

MX-1:

> show configuration interfaces ae1 
description "Connection to mx-2";
aggregated-ether-options {
    minimum-links 1;
    lacp {
        active;
        periodic fast;
    }
}
unit 0 {
    family inet {
        address 172.28.30.9/30;
    }
}

> show lacp interfaces 
Aggregated interface: ae1
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      ge-1/0/4       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-1/0/4     Partner    No    No   Yes  Yes  Yes   Yes     Fast   Passive
      ge-1/0/5       Actor    No   Yes    No   No   No   Yes     Fast    Active
      ge-1/0/5     Partner    No   Yes    No   No   No   Yes     Fast   Passive
    LACP protocol:        Receive State  Transmit State          Mux State 
      ge-1/0/4                  Current   Fast periodic Collecting distributing
      ge-1/0/5            Port disabled     No periodic           Detached

 MX-2:

> show configuration interfaces ae1  
description "Connection to mx-1";
aggregated-ether-options {
    minimum-links 1;
    lacp {
        passive;
    }
}
unit 0 {
    family inet {
        address 172.28.30.10/30;
    }
}

> show lacp interfaces 
Aggregated interface: ae1
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      ge-1/0/4       Actor    No    No   Yes  Yes  Yes   Yes     Fast   Passive
      ge-1/0/4     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-1/1/5       Actor    No   Yes    No   No   No   Yes     Fast   Passive
      ge-1/1/5     Partner    No   Yes    No   No   No   Yes     Fast   Passive
    LACP protocol:        Receive State  Transmit State          Mux State 
      ge-1/0/4                  Current   Fast periodic Collecting distributing
      ge-1/1/5            Port disabled     No periodic           Detached

That is a strange one. Can you ping the gateway to 8.8.8.8 whiich I believe is 123.123.123.89 from MX2? This is a hard measure but I have seen where a reboot resolves communication issue like this. It is a severe step to take, but since you are in a lab, I would try that also.

The other thing you can do is to also create a static route on MX2 to 8.8.8.8 with next-hop 123.123.123.89 and see if that works.  Oh, and before you restart check what the forwarding table in the pfe shows for the route to 8.8.8.8.

I believe the problem here is due to the source address 172.28.30.10 ; the outgoing ICMP packets will have source address as the one configured on the link by default. As its not globally routable, so I don't expect to see a reply.

What I suggest is, configure a public loopback on MX-2, put it as passive in IGP or create a static to it on MX1. Then use the loopback as source for ICMP. Let us know how you get on.

The problem here was user error.  The IP I was trying to ping from wasn't publicly routable yet; once I switched to a routable IP, it came up just fine.  Sorry.