Hi Steve,
In my setup, I am using Juniper as a spoke PE and it doesn't have any EBGP
peers.I only have IBGP-peering with HUB (Redback SE).
The problem is, the spoke (JUNO) is not installing those routes which have
generated from othe spoke (spoke 2) but it is installing those routes
generated from HUB CE.
===
I have hub and spoke MPLS/VPN topology, hub as redback SE and spoke as
Juniper. I tried to send exported routes to juno from SE (SE received routes
from another EBGP peer), but somehow Juniper is not installing those routes
which are received from another AS (here AS path is 2,1 when it comes to
Juno) but where as those routes which are coming directly from Hub CE
(static routes whose AS path is 2) are successfully installed.
spoke1 PE(IBGP 1) Hub PE (EBGP 2)Hub CE
|
spoke2 PE ---(IBGP 1) |
hub PE has 2 VRFs export and import. import is recieving routes from Spokes
and export is sending routes to all spokes. These 2 VRFs are EBGPed to Hub
CE.
Ec: In the debugs the route 500:: is not getting installed, the only
difference I saw is, the ASPATH contain its own AS 1 (ASPath(2) length 14:
2000 1 2 )
The other routes generated from HUB CE which has only 2000 got installed
successfully (140::)
===
ug 18 10:49:59.677406 BGP RECV 1.1.1.1+62849 -> 1.1.1.4+179
Aug 18 10:49:59.677412 BGP RECV message type 2 (Update) length 440
Aug 18 10:49:59.677602 BGP RECV flags 0x40 code Origin(1): Incomplete
Aug 18 10:49:59.677612 BGP RECV flags 0x50 code ASPath(2) length 14: 2000 1
2
Aug 18 10:49:59.677617 BGP RECV flags 0x80 code MultiExitDisc(4): 0
Aug 18 10:49:59.677621 BGP RECV flags 0x40 code LocalPref(5): 100
Aug 18 10:49:59.677626 BGP RECV flags 0xd0 code Extended Communities(16):
2:1:1000
Aug 18 10:49:59.677631 BGP RECV flags 0x90 code MP_reach(14): AFI/SAFI 2/128
Aug 18 10:49:59.677637 BGP RECV nhop :::1.1.1.1 len 24
Aug 18 10:49:59.677654 BGP RECV 1.1.1.1:1000:500::d/128 (label
590031) , 1.1.1.1:1000:500::e/128 (label
590031) , 1.1.1.1:1000:500::f/128 (label 590031) , 1.1.1.1:1000:500::10/128
(label 590031)
Aug 18 10:49:59.677674 BGP RECV 1.1.1.1:1000:500::11/128 (label
590031) , 1.1.1.1:1000:500::12/128 (lab
el 590031) , 1.1.1.1:1000:500::13/128 (label 590031) , 1.1.1.1:1000:500::14/128
(label 590031)
Aug 18 10:49:59.677689 BGP RECV 1.1.1.1:1000:500::15/128 (label
590031) , 1.1.1.1:1000:500::16/128 (lab
el 590031) , 1.1.1.1:1000:500::17/128 (label 590031) , 1.1.1.1:1000:500::18/128
(label 590031)
Aug 18 10:49:59.677699 bgp_should_merge_as2_and_as4_path():1837 AS4-Peer
1.1.1.1 (Internal AS 1)(RECV): No merg
e of as-paths required as the peer is 4 byte as capable
Aug 18 10:49:59.677705 bgp_process_aspath_and_aggr_attr():2251 AS4-Peer
1.1.1.1 (Internal AS 1)(RECV): bgp_shou
ld_merge_as2_and_as4_path() says NO
Aug 18 10:49:59.677712 bgp_process_aspath_and_aggr_attr():2288 AS4-Peer
1.1.1.1 (Internal AS 1)(RECV): Merged a
sp: path_len 12, path_seg_len 2, path2_len 0, path2_seg_len 0, path4_len 0,
path4_seg_len 0, path_attr_len 0, p
ath_aggr_len 0, path4_aggr_len 0, path4_flags 0x0, path_flags 0x0
Aug 18 10:49:59.677720 bgp_rcv_nlri: Peer 1.1.1.1 (Internal AS 1)
Aug 18 10:49:59.677727 bgp_rcv_nlri: 1.1.1.1:1000:500::d/192
ug 18 14:39:31.952606 BGP RECV 1.1.1.1+64520 -> 1.1.1.4+179
Aug 18 14:39:31.952612 BGP RECV message type 2 (Update) length 156
Aug 18 14:39:31.952617 BGP RECV flags 0x40 code Origin(1): Incomplete
Aug 18 14:39:31.952622 BGP RECV flags 0x50 code ASPath(2) length 6: 2000
Aug 18 14:39:31.952626 BGP RECV flags 0x80 code MultiExitDisc(4): 0
Aug 18 14:39:31.952630 BGP RECV flags 0x40 code LocalPref(5): 100
Aug 18 14:39:31.952635 BGP RECV flags 0xd0 code Extended Communities(16):
2:1:1000
Aug 18 14:39:31.952639 BGP RECV flags 0x90 code MP_reach(14): AFI/SAFI 2/128
Aug 18 14:39:31.952644 BGP RECV nhop :::1.1.1.1 len 24
Aug 18 14:39:31.952655 BGP RECV 1.1.1.1:1000:140::/64 (label 590029)
, 1.1.1.1:1000:1000::/64 (label 59
0029) , 1.1.1.1:1000:1100::/64 (label 590029)
Aug 18 14:39:31.952667 bgp_should_merge_as2_and_as4_path():1837 AS4-Peer
1.1.1.1 (Internal AS 1)(RECV): No merg
e of as-paths required as the peer is 4 byte as capable
Aug 18 14:39:31.952673 bgp_process_aspath_and_aggr_attr():2251 AS4-Peer
1.1.1.1 (Internal AS 1)(RECV): bgp_shou
ld_merge_as2_and_as4_path() says NO
Aug 18 14:39:31.952683 bgp_process_aspath_and_aggr_attr():2288 AS4-Peer
1.1.1.1 (Internal AS 1)(RECV): Merged a
sp: path_len 4, path_seg_len 2, path2_len 0, path2_seg_len 0, path4_len 0,
path4_seg_len 0, path_attr_len 0, pa
th_aggr_len 0, path4_aggr_len 0, path4_flags 0x0, path_flags 0x0
On Fri, Aug 21, 2009 at 12:59 PM, Steven Brenchley wrote:
> Hi Jana,
>
> I think I may have found a better solution. There is another option,
> which is to pass the iBGP information of your customer transparently across
> the VPN network. i.e. the routes on the customer side will not see the
> AS(es) that are