[j-nsp] OSPF Sham link question
Daniel Lete
daniel.lete at heanet.ie
Thu Dec 6 10:04:03 EST 2007
Hello David,
Your comment below:
> (NB: is it normal that the routes PE2 is learning from the m10 are 'Extern' ?)
may not be related at all with sham links or even with rfc2547/rfc4364. If you
are injecting prefixes into OSPF (redistribute in Cisco or export in Juniper)
in your CE, then those prefixes will appear as LSA Type-5 (external if you want).
Daniel
David Ball wrote:
> Should have mentioned earlier (in case it's relevant), the reason
> for sham-link requirement is that there 'will' be a slow backup link
> between the cisco and the m10, but it'll be direct, so the cisco and
> m10 will think that's the better link (due to intra-area). So, was
> hoping to use sham-link across T640s to bring things closer to 'par'
> and have those routes appear as intra-area and ultimately prefer the
> sham-link.
> I was, but am no longer, explicitly exporting routes from BGP into
> OSPF on the PEs. As requested, more configs and show cmd output
> included. I appreciate the feedback so far by the way....thanks
> again.
>
> m10's loopback is 172.16.0.3
> cisco's loopback is 172.16.0.4
>
> Pertinent configs from PE1 (T640 facing Cisco):
> lo0 {
> unit 800 {
> description "sham-link testing";
> family inet {
> filter {
> input secure-router-shamlink-test;
> }
> address 172.16.0.2/32;
> }
> }
> }
>
> ge-7/0/0 { <---- int facing Cisco
> unit 0 {
> family inet {
> address 172.16.2.1/30;
> }
> }
> }
>
> sham-link-test {
> instance-type vrf;
> interface ge-7/0/0.0;
> interface lo0.800;
> vrf-target target:25983:800;
> vrf-table-label;
> protocols {
> ospf {
> sham-link local 172.16.0.2;
> area 0.0.0.0 {
> sham-link-remote 172.16.0.1 metric 1;
> interface ge-7/0/0.0 {
> metric 1;
> }
> }
> }
> }
> }
>
>
> Pertinent configs from PE2 (T640 facing M10):
>
> lo0 {
> unit 800 {
> description "sham-link test";
> family inet {
> filter {
> input secure-router-shamlink-test;
> }
> address 172.16.0.1/32;
> }
> }
> }
>
> ge-7/2/1 { <--------facing m10
> unit 0 {
> family inet {
> address 172.16.1.1/30;
> }
> }
> }
>
> sham-link-test {
> instance-type vrf;
> interface ge-7/2/1.0;
> interface lo0.800;
> vrf-target target:25983:800;
> vrf-table-label;
> protocols {
> ospf {
> sham-link local 172.16.0.1;
> area 0.0.0.0 {
> sham-link-remote 172.16.0.2 metric 1;
> interface ge-7/2/1.0 {
> metric 1;
> }
> }
> }
> }
> }
>
> OSPF neighbors as seen from PE1:
>> show ospf neighbor instance sham-link-test
> Address Interface State ID Pri Dead
> 172.16.2.2 ge-7/0/0.0 Full 172.16.0.4 1 36
>
> OSPF neighbors as seen from PE2:
>> show ospf neighbor instance sham-link-test
> Address Interface State ID Pri Dead
> 172.16.1.2 ge-7/2/1.0 Full 172.16.0.3 128 31
>
> Proof that PE1 is learning PE2's loopback via BGP:
>> show route table sham-link-test
>
> sham-link-test.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 172.16.0.1/32 *[BGP/170] 12:43:03, localpref 100, from 1.7.1.43
> AS path: I
> > to 1.7.2.18 via ge-0/2/0.0, label-switched-path
> NCP-LSP-00819-005-043
> to 1.7.2.1 via ge-0/0/0.0, label-switched-path
> NCP-LSP-00819-005-043
> 172.16.0.2/32 *[Direct/0] 20:29:55
> > via lo0.800
>
> Proof that PE2 is learning PE1's loopback via BGP:
>> show route table sham-link-test
>
> sham-link-test.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 172.16.0.1/32 *[Direct/0] 21:04:41
> > via lo0.800
> 172.16.0.2/32 *[BGP/170] 18:50:17, localpref 100, from 1.7.1.5
> AS path: I
> > to 1.7.2.17 via ge-0/2/0.0, label-switched-path
> NCP-LSP-00829-043-005
> to 1.7.2.5 via ge-0/0/0.0, label-switched-path
> NCP-LSP-00829-043-005
>
> OSPF database according to PE1 (Cisco isn't sending much/anything...my
> current goal is for the Cisco to learn what the m10 sends, then I'll
> move on):
>> show ospf database instance sham-link-test
>
> OSPF link state database, Area 0.0.0.0
> Type ID Adv Rtr Seq Age Opt Cksum Len
> Router *172.16.0.2 172.16.0.2 0x80000037 876 0x22 0xfdff 36
> Router 172.16.0.4 172.16.0.4 0x80000029 1111 0x22 0xa757 36
> Network 172.16.2.2 172.16.0.4 0x80000022 1372 0x22 0x9a80 32
>
>
> OSPF database according to PE2:
>> show ospf database instance sham-link-test
>
> OSPF link state database, Area 0.0.0.0
> Type ID Adv Rtr Seq Age Opt Cksum Len
> Router *172.16.0.1 172.16.0.1 0x80000024 1912 0x22 0x1ef6 36
> Router 172.16.0.3 172.16.0.3 0x80000425 735 0x22 0xc475 48
> Network 172.16.1.2 172.16.0.3 0x8000002e 435 0x22 0x7b97 32
> OpaqArea 1.0.0.1 172.16.0.3 0x80000413 1335 0x22 0xaeea 28
> OSPF AS SCOPE link state database
> Type ID Adv Rtr Seq Age Opt Cksum Len
> Extern 172.16.16.0 172.16.0.3 0x80000034 1035 0x22 0xbf33 36
> Extern 192.168.101.0 172.16.0.3 0x80000036 135 0x22 0xe40a 36
>
> (NB: is it normal that the routes PE2 is learning from the m10 are 'Extern' ?)
>
> Here is Cisco's current routing table (learning nothing via OSPF):
> lab-2651#sho ip route
> Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
> N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
> E1 - OSPF external type 1, E2 - OSPF external type 2
> i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
> ia - IS-IS inter area, * - candidate default, U - per-user static route
> o - ODR, P - periodic downloaded static route
>
> Gateway of last resort is not set
>
> C 172.17.0.0/16 is directly connected, FastEthernet0/1
> 172.16.0.0/30 is subnetted, 1 subnets
> C 172.16.2.0 is directly connected, FastEthernet0/0
> C 208.98.239.0/24 is directly connected, FastEthernet0/1
> lab-2651#
>
>
> Here is M10's inet.0 routing table:
>> show route
>
> inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
> Restart Complete
> + = Active Route, - = Last Active, * = Both
>
> 0.0.0.0/0 *[Static/5] 5w4d 23:37:59
> Reject
> 172.16.0.3/32 *[Direct/0] 2w0d 19:06:21
> > via lo0.0
> 172.16.1.0/30 *[Direct/0] 21:05:30
> > via ge-0/1/0.0
> 172.16.1.2/32 *[Local/0] 21:05:30
> Local via ge-0/1/0.0
> 172.16.16.0/24 *[Static/5] 21:02:54
> Discard
> 192.168.8.0/24 *[Static/5] 5w4d 23:37:59
> > to 192.168.101.252 via fxp0.0
> 192.168.9.0/24 *[Static/5] 5w4d 23:37:59
> > to 192.168.101.252 via fxp0.0
> 192.168.101.0/24 *[Direct/0] 5w4d 23:37:59
> > via fxp0.0
> 192.168.101.33/32 *[Local/0] 5w4d 23:37:59
> Local via fxp0.0
> 224.0.0.5/32 *[OSPF/10] 5w4d 23:38:00, metric 1
> MultiRecv
>
>
>
> On 05/12/2007, Peter E. Fry <pfry-lists at redsword.com> wrote:
>> ----- Original Message -----
>> From: Daniel Lete <daniel.lete at heanet.ie>
>>
>> [...]
>>> In relation to your sham-link. You need a loopback IP
>>> within your VRF to act as source/destination of the sham
>>> link and these loopbacks are NOT to be announced to your
>>> CE.
>> I was going to make that point -- that is, I would not
>> expect to see:
>>
>>> O IA 172.16.0.3/32 [110/11] via 172.16.2.1, 04:31:29,
>> FastEthernet0/0
>>
>> ...(although I could be wrong -- I don't get many looks into
>> CPE). Also, I'd expect the sham-link neighbor to show up on
>> the PE. You can see them on Cisco PEs, for instance:
>>
>> CiscoPE#show ip ospf [process] neighbor
>>
>> Neighbor ID Pri State Dead Time Address
>> Interface
>> [...]
>> [Remote ID IP] 0 FULL/ - - [Remote LB
>> IP] OSPF_SLn
>> [...]
>> CiscoPE#
>>
>> ...so there's no confusion as to the state of the sham link.
>> I don't have a Juniper L3 VPN PE or a Cisco CE handy.
>>
>> Peter E. Fry
>>
>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Daniel Lete Murugarren
HEAnet Limited, Ireland's Education and Research Network
1st Floor, 5 George's Dock, IFSC, Dublin 1
Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666
web: http://www.heanet.ie/
More information about the juniper-nsp
mailing list