Cisco to Juniper MPLS interop

[James Lasky]

Hi

I've connected a new Juniper MPLS node to my Cisco MPLS net.

The Juniper M320 is connected as Route Reflector to a Cisco 7206 PE.

Just making some test I see the problem that on the Juniper side I can't see what imported in the l3vpn from the Cisco MPLS world.

On the Cisco MPLS world I see what imported from Juniper but not viceversa.

MBGP is up, LDP is up, IGP is up...

Does anybody have any idea or knows if there is documentation somewhere in the web ? I wasn't able to find out anything on cisco.com and juniper.net

Pls advise

Ric

[sergio.danelli]

Hi,

So is the Juniper a route reflector for the Cisco?

on the Juniper you have a routing instance with matching route targets as the Cisco?

some configuration and show command snippets will be helpful.

thanks

[James Lasky]

Ciao Sergio

Yes Juniper is a route reflector for the Cisco.

I'm quite new on Juniper, but I can paste some config... Keep in mind now I made a lot of test, hence something could be wrong...

Just a brief explaination of the environment: two PE connected via ge, Cisco has an internal vrf tsi already working, Juniper has an active subinterface (ge7/1/0.59) attached to a test vrf (vpn-test) but no active CE connected.

Importing on the M320 the rt 20608:600 (of the Cisco) I expect to see some routes on the table vpn-test, the same on the Cisco side (and I can see it on the Cisco!)

Have a look and feel free to put questions :-)

If you have any interesting document about Cisco to Juniper interop pls advise...

Tks

ric

[sergio.danelli]

Hi Ric,

I can't tell if you are advertising anything on the Cisco.

under router bgp 20608

address-family ipv4 vrf tsi

do a "redistribute connected"

Juniper does this automatically with the connected routes when you have a export target configured

That may do it, let us know if you are still having problems.

thanks

[James Lasky]

I did it, nothing changes...

[sergio.danelli]

hmm, weird just set something up and is working fine.

ON the juniper you have this output:

Table bgp.l3vpn.0

RIB State: BGP restart is complete

RIB State: VPN restart is complete

Send state: not advertising

Active prefixes: 0

Received prefixes: 3 <<< routes received

on the juniper paste a "show route table bgp.l3vpn.0 extensive"

[James Lasky]

That's it:

#> show route table bgp.l3vpn.0 extensive

bgp.l3vpn.0: 3 destinations, 3 routes (0 active, 0 holddown, 3 hidden)

{master}

[Harold Ritter]

Ric,

From the info you provided, it looks the Juniper device does receive 3 VPNv4 routes from the Cisco side:

Table bgp.l3vpn.0

RIB State: BGP restart is complete

RIB State: VPN restart is complete

Send state: not advertising

Active prefixes: 0

Received prefixes: 3 <+++++

Suppressed due to damping: 0

The issue is most probably due to the fact that the next-hop is the directly connected interface between the two routers. JUNOS will consider invalid any VPNv4 routes for which there is not an LSP (route to NH installed in inet.3). In your scenario, there will not be a route in inet.3 for 217.172.8.14 since this is the directly connected interface.

In an MPLS VPN context, the BGP session should always be established to the loopback address of the PE rather than any of its physical interfaces. Many issues can arise if it doesn't.

Hope this helps,

[sergio.danelli]

This is correct, but if the LSP was not built the route will be hidden:

lab@JuniperOlive# run show route table tsi

tsi.inet.0: 2 destinations, 2 routes (1 active, 0 holddown, 1 hidden) <<<<<<

+ = Active Route, - = Last Active, * = Both

30.30.30.30/32 *[Direct/0] 11:03:25

> via lo0.20

[edit protocols bgp]

lab@JuniperOlive# top set protocols ldp interface all

[edit protocols bgp]

lab@JuniperOlive# commit

commit complete

lab@JuniperOlive# run show route table inet.3

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

2.2.2.2/32 *[LDP/9] 00:01:03, metric 1

> to 10.1.6.67 via fxp2.0

No more hidden routes

[edit protocols bgp]

lab@JuniperOlive# run show route table tsi protocol bgp

tsi.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

20.20.20.20/32 *[BGP/170] 00:01:20, MED 0, localpref 100, from 2.2.2.2

AS path: ?

> to 10.1.6.67 via fxp2.0, Push 18

Something else is happening here.

On his output:

# run show route table vpn-test

vpn-test.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.0.96/29 *[Direct/0] 17:52:37 <------- only the local routes!!!

> via ge-7/1/0.59

192.168.0.102/32 *[Local/0] 17:52:37

Local via ge-7/1/0.59

there isn't any hidden routes

[Harold Ritter]

Sergio,

You are correct. There were two issues here.

1. BGP on the physical interface instead of the loopback interface, which caused the routes to be hidden in bgp.l3vpn.0

2. Imcomplete import policy, which caused the routes nor to be imported in vpn-test.inet.0.

Regards,

[James Lasky]

Hi

I tried to use the loopback, something changes!! I've now the routes in the bgp.l3vpn but not in the vrf vpn-test...

Cisco

#sh ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

217.172.8.245 4 20608 12 67 0 0 0 00:03:30 (NoNeg)

#sh mpls ldp nei

Peer LDP Ident: 217.172.8.245:0; Local LDP Ident 217.172.8.251:0

TCP connection: 217.172.8.245.646 - 217.172.8.251.38821

State: Oper; Msgs sent/rcvd: 17464/15268; Downstream

Up time: 1d18h

LDP discovery sources:

GigabitEthernet0/0.308, Src IP addr: 217.172.8.1

Addresses bound to peer LDP Ident:

217.172.8.1 217.172.8.134 217.172.8.245

Juniper

# run show bgp neighbor

Peer: 217.172.8.251+38937 AS 20608 Local: 217.172.8.245+179 AS 20608

Type: Internal State: Established Flags:

Last State: OpenConfirm Last Event: RecvKeepAlive

Last Error: None

Options:

Address families configured: inet-vpn-unicast

Holdtime: 90 Preference: 170 Local AS: 20608 Local System AS: 0

Number of flaps: 0

Peer ID: 217.172.8.251 Local ID: 217.172.8.245 Active Holdtime: 90

Keepalive Interval: 30 Peer index: 0

BFD: disabled, down

NLRI advertised by peer: inet-unicast inet-vpn-unicast

NLRI for this session: inet-vpn-unicast

Peer supports Refresh capability (2)

Table bgp.l3vpn.0

RIB State: BGP restart is complete

RIB State: VPN restart is complete

Send state: not advertising

Active prefixes: 3

Received prefixes: 3

Suppressed due to damping: 0

Table vpn-test.inet.0 Bit: 30000

RIB State: BGP restart is complete

RIB State: VPN restart is complete

Send state: in sync

Active prefixes: 0

Received prefixes: 0

Suppressed due to damping: 0

Advertised prefixes: 1

Last traffic (seconds): Received 4 Sent 13 Checked 4

Input messages: Total 67 Updates 47 Refreshes 0 Octets 7270

Output messages: Total 23 Updates 1 Refreshes 0 Octets 529

Output Queue[1]: 0

Output Queue[2]: 0

# run show ldp neighbor

Address Interface Label space ID Hold time

217.172.8.14 ge-7/1/0.308 217.172.8.251:0 12

# run show route table vpn-test (always only the local...)

vpn-test.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.0.96/29 *[Direct/0] 1d 18:31:09

> via ge-7/1/0.59

192.168.0.102/32 *[Local/0] 1d 18:31:09

Local via ge-7/1/0.59

# run show route table bgp.l3vpn.0

bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

20608:600:53.212.0.0/21

*[BGP/170] 00:18:39, MED 0, localpref 100, from 217.172.8.251

AS path: ?

> to 217.172.8.14 via ge-7/1/0.308, Push 36

20608:600:217.172.1.248/32

*[BGP/170] 00:18:39, MED 0, localpref 100, from 217.172.8.251

AS path: ?

> to 217.172.8.14 via ge-7/1/0.308, Push 37

20608:600:217.172.28.0/24

*[BGP/170] 00:18:39, MED 0, localpref 100, from 217.172.8.251

AS path: ?

> to 217.172.8.14 via ge-7/1/0.308, Push 19

[Harold Ritter · Accepted solution]

Ric,

You now see the routes in bgp.l3vpn.0, which confirms my theory. The reason they are not imported in vpn-test.inet.0 is that your import policy is imcomplete. You are actually missing the accept action in term a. It should look like this:

policy-options {

policy-statement vpn-test-import {

term a {

from {

protocol bgp;

community vpn-test;

}

then accept;

}

term b {

then reject;

}

}

This should take care of it.

Hope this helps,

[James Lasky]

Thanks both of u a lot for your efforts.

Now it's working.

Tks

Ric

[sergio.danelli]

Harold,

Nice catch on the policy, totally missed that.

Ric,

by having the vrf-target command it makes it so you don't need the vrf-import in there.

vrf-import vpn-test-import; <<< redudant

vrf-target {

import target:20608:600; << of this, or vice-versa

export target:20608:4120;

}

vrf-table-label;

vrf-import gives you flexibility with policy, but vrf-target shortens the steps necessary in configuration, and imports all the routes with the route-targets configured.

anyway, im glad you got it fixed.

[Harold Ritter]

Ric,

Just to add to Sergio's point, vrf-import actually overrides the vrf-target import when both are configured.

Regards,