Messages

Can't we just delete the post and ban the user? Most of these are hit and runs right

Hey just thinking, maybe we should start looking around for a URL that distinguishes us from the old place.

a few that come to mind for example (that are free)

tcpiptalk.com
talkingpackets.com
ipforums.net

I'm not saying we need Dean to waste another weekend recoding / rebranding, but that we keep our eyes open and decide on a new (cheap) URL, then put a simple redirect there for the time being.
Heck if its cheap I'll buy the domain myself if Dean doesn't want to foot any more billz.

1.) Play 18 with an old buddy (carts!!!!! WOOHOO)
2.) Finish labbing VRF route-leaking, RSVP explicit ERO, RSVP-TE with classes and any L2 SP features the vSRXs can handle (not a lot is my understanding.... no VPLS for me!)
3.) Finish reading all the JNCIS-SP PDFs and start on practice exams/re-reading weak points (metro ethernet OAM, ugh)
4.) Steel up for my final week in my god-forsaken current position. FINALLY FINISHED WOOHOO  [size=78%] [/size]

Side note, do not attempt to RSPAN across a Q-in-Q tunnel. BAD IDEA

When even SAN guys say stuff jumbo... https://forums.freenas.org/index.php?threads/jumbo-frames-notes.26064/

Side topic, what is your requirement for GetVPN that is not fulfilled by either traditional IPSEC over GRE (VTI) or DMVPN?
When I last looked @ it, GetVPN was being flogged as a SP technology for customer separation without MPLS so I think of it as the crypto version of a LSP, or maybe I have it completely backwards lol

This topic has been moved to Certifications and Careers.

http://www.networking-forums.com/index.php?topic=87.0

Vwmare allowing Cisco cert holder to bypass prerequisites for VCP-NV (NSX)
Only valid until end of Feb though - not sure if I will make it + haven't really looked at whether you can lab NSX properly @ home (the latter is more or less the key IMO, well, at least if you're the kind of person who takes certs seriously as opposed to doing the unmentionable)

http://mylearn.vmware.com/mgrReg/plan.cfm?plan=51111&ui=www_cert

Awesome, thanks for confirming. So ruling out vrf-target due to lack of options, say we're manually importing/exporting, what are out options?

I tried to manually tag that rte-type community but its rejected. Morever that's a terrible solution, you'd need to match only Type 1/2/3, manually specify the area etc... is this just a limitation of doing OSPF PE-CE on JunOS?


BTW been reading your articles including that one, thanks for taking the time! Going for JNCIS-SP shortly and your articles (and explanation above!) have always been a great help.

loj001@SP-LAB-PE1# set policy-options community domain-b members rte-type:0.0.0.0:1:0     

[edit]
loj001@SP-LAB-PE1# commit
[edit policy-options community domain-b members]
  'rte-type:0.0.0.0:1:0'
    Unknown extended community type
error: configuration check-out failed

Hiya Mellow!


All vSRXs in ESXi.


Question for you SP expertise - given that Juniper doesn't auto export the VRF interfaces if multi-access (FE/GE), and that you need to explicitly export the directly connected interface even with vrf-table-label - whats standard practice in SP land? Do you guys also explicitly export the protocol direct in your export maps?


Also was wondering how the eff does it work if you DON'T export the direct protocol? As in Next Hop resolution once it gets to the egress PE??? (I'm going to turn off the directly connected exports now and see) EDIT It appears that the ingress PE router is using next hop self - when I examine a CE1 router /32 loopback advertised into PE1 vpn-a, the route in the bgp.l3vpn table has the PE1 RID as the next hop - is this something I missed during my reading?

loj001@SP-LAB-P1> show route 192.168.16.1/32 detail


bgp.l3vpn.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
10.0.0.7:1:192.168.16.1/32 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 10.0.0.7:1
                Next hop type: Indirect
                Address: 0x934d2a0
                Next-hop reference count: 2
                Source: 10.0.0.7
                Protocol next hop: 10.0.0.7
                Push 16
                Indirect next hop: 2 no-forward
                State: <Active Int Ext>
                Local AS: 65535 Peer AS: 65535
                Age: 1:28:39    Metric2: 1
                Task: BGP_65535.10.0.0.7+179
                Announcement bits (2): 0-BGP Route Target 1-BGP_RT_Background
                AS path: 1 I
                Communities: target:1:1
                Accepted
                VPN Label: 16
                Localpref: 100
                Router ID: 10.0.0.7


loj001@SP-LAB-P1>

here is the exact route  for PE1's PE-CE /30 coming into the egress PE3 now that I'm using vrf import/export and adding domain-id community.

Note everything pings and traces as expected, its just understanding why I'm getting the OSPF Type 5 instead of the 3 as expected. LIke I said I do suspect in this configuration it is because the interface route is being explicitly exported into OSPF.

l

oj001@SP-LAB-PE3> show route 172.17.1.0/30 extensive


vpn-b.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
172.17.1.0/30 (1 entry, 1 announced)
TSI:
OSPF area : 0.0.0.0, LSA ID : 172.17.1.0, LSA type : Extern
KRT in-kernel 172.17.1.0/30 -> {indirect(262144)}
        *BGP    Preference: 170/-101
                Route Distinguisher: 10.0.0.7:2
                Next hop type: Indirect
                Address: 0x934d768
                Next-hop reference count: 3
                Source: 10.0.0.1
                Next hop type: Router, Next hop index: 632
                Next hop: 10.2.2.1 via ge-0/0/1.0, selected
                Label operation: Push 17, Push 299824(top)
                Label TTL action: prop-ttl, prop-ttl(top)
                Protocol next hop: 10.0.0.7
                Push 17
                Indirect next hop: 95243a0 262144
                State: <Secondary Active Int Ext>
                Local AS: 65535 Peer AS: 65535
                Age: 1:10:20    Metric2: 1
                Task: BGP_65535.10.0.0.1+52741
                Announcement bits (2): 0-vpn-b-OSPF 1-KRT
                AS path: I (Originator) Cluster list:  10.0.0.1
                AS path:  Originator ID: 10.0.0.7
                Communities: target:2:2 domain-id:17.17.17.17:0
                Import Accepted
                VPN Label: 17
                Localpref: 100
                Router ID: 10.0.0.1
                Primary Routing Table bgp.l3vpn.0
                Indirect next hops: 1
                        Protocol next hop: 10.0.0.7 Metric: 1
                        Push 17
                        Indirect next hop: 95243a0 262144
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: 10.2.2.1 via ge-0/0/1.0
                        10.0.0.7/32 Originating RIB: inet.3
                          Metric: 1                       Node path count: 1
                          Forwarding nexthops: 1
                                Nexthop: 10.2.2.1 via ge-0/0/1.0


bgp.l3vpn.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
                                       
10.0.0.7:2:172.17.1.0/30 (1 entry, 0 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 10.0.0.7:2
                Next hop type: Indirect
                Address: 0x934d768
                Next-hop reference count: 3
                Source: 10.0.0.1
                Next hop type: Router, Next hop index: 632
                Next hop: 10.2.2.1 via ge-0/0/1.0, selected
                Label operation: Push 17, Push 299824(top)
                Label TTL action: prop-ttl, prop-ttl(top)
                Protocol next hop: 10.0.0.7
                Push 17
                Indirect next hop: 95243a0 262144
                State: <Active Int Ext>
                Local AS: 65535 Peer AS: 65535
                Age: 1:10:21    Metric2: 1
                Task: BGP_65535.10.0.0.1+52741
                AS path: I (Originator) Cluster list:  10.0.0.1
                AS path:  Originator ID: 10.0.0.7
                Communities: target:2:2 domain-id:17.17.17.17:0
                Import Accepted
                VPN Label: 17
                Localpref: 100
                Router ID: 10.0.0.1
                Secondary Tables: vpn-b.inet.0
                Indirect next hops: 1
                        Protocol next hop: 10.0.0.7 Metric: 1
                        Push 17
                        Indirect next hop: 95243a0 262144
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: 10.2.2.1 via ge-0/0/1.0
                        10.0.0.7/32 Originating RIB: inet.3
                          Metric: 1                       Node path count: 1
                          Forwarding nexthops: 1
                                Nexthop: 10.2.2.1 via ge-0/0/1.0

my relevant PE config is here, all 3 are the same more or less. Note vpn-a is using standard PE-CE BGP which his working hunky dory.

protocols {
    mpls {
        icmp-tunneling;
        interface all;
        interface ge-0/0/0.0 {
            disable;
        }
        interface ge-0/0/4.0 {
            disable;
        }
        interface ge-0/0/5.0 {
            disable;
        }
    }
    bgp {
        group SP-LAB {
            type internal;
            local-address 10.0.0.9;
            family inet {
                unicast;
            }
            family inet-vpn {
                unicast;               
            }
            family route-target;
            peer-as 65535;
            bfd-liveness-detection {
                minimum-interval 1000;
            }
            neighbor 10.0.0.1;
        }
    }
    isis {
        traceoptions {
            file debug-isis size 65535 files 10;
            flag general;
            flag normal;
            flag error;
            flag policy;
            flag ldp-synchronization;
        }
        interface ge-0/0/1.0 {
            level 1 disable;
            level 2 {
                enable;
                metric 5;
            }
        }
        interface ge-0/0/2.0 {
            level 1 disable;
            level 2 enable;
        }
        interface lo0.0 {
            passive;
            level 1 disable;
        }
    }
    ldp {
        interface all;
    }
}
policy-options {
    policy-statement policy-export-customer-b {
        term bgp-networks {
            from protocol bgp;
            then {
                community add domain-b;
                accept;                 
            }
        }
        term end {
            then reject;
        }
    }
    policy-statement policy-export-vpn-a {
        term export-bgp {
            from protocol bgp;
            then {
                community add vpn-a;
                accept;
            }
        }
        term export-direct {
            from protocol direct;
            then {
                community add vpn-a;
                accept;
            }
        }
        term end {
            then reject;
        }
    }
    policy-statement policy-export-vpn-b {
        term export-ospf {
            from protocol ospf;
            then {
                community add vpn-b;
                community add domain-b;
                accept;
            }
        }
        term export-direct {
            from protocol direct;
            then {
                community add vpn-b;
                community add domain-b;
                accept;
            }
        }
        term end {
            then reject;
        }                               
    }
    policy-statement policy-import-vpn-a {
        term import-bgp {
            from {
                protocol bgp;
                community vpn-a;
            }
            then accept;
        }
        term end {
            then reject;
        }
    }
    policy-statement policy-import-vpn-b {
        term import-bgp {
            from {
                protocol bgp;
                community vpn-b;
            }
            then accept;
        }
        term end {
            then reject;
        }
    }
    community domain-b members domain-id:17.17.17.17:0;
    community vpn-a members target:1:1;
    community vpn-b members target:2:2;
}


routing-instances {
    vpn-a {
        instance-type vrf;
        interface ge-0/0/4.0;
        route-distinguisher 10.0.0.9:1;
        vrf-import policy-import-vpn-a;
        vrf-export policy-export-vpn-a;
        vrf-table-label;
        protocols {
            bgp {
                group customer-a {
                    type external;
                    peer-as 1;
                    as-override;
                    neighbor 172.16.3.2;
                }
            }
        }
    }
    vpn-b {
        instance-type vrf;
        interface ge-0/0/5.0;
        route-distinguisher 10.0.0.9:2;
        vrf-import policy-import-vpn-b;
        vrf-export policy-export-vpn-b;
        vrf-table-label;
        protocols {
            ospf {
                domain-id 17.17.17.17;
                export policy-export-customer-b;
                area 0.0.0.0 {
                    interface ge-0/0/5.0;
                }
            }                           
        }
    }
}

awesome. WIll try to look on the weekend. Tied up on a combination of my JNCIS-SP labbing / stupid work faults rite now!

It gets worse.
I moved from using vrf-target (the auto import/export way) to manual import/export policies (which I had to lab anyway later lol so I could practice VRF route leaking).
Using manual policies I was able to set the domain ID and have it clearly visible... but its still coming through my CEs as External. I guess this is because I'm explicitly exporting the route?
It would also appear that export policies don't work if using vrf-target method.    Thanks JNCIS-SP textbook for mentioning this!!!

Finally, another side effect of NOT using vrf-target is that ethernet interfaces do not get advertised into routing and you have to explicitly export them in policy and use a special command vrf-table-label.....

And just when I was loving the JunOS way they start hammering me with these WTF curveballs....


Oh well, at least IRL, nobody allows OSPF PE-CE peering... I've only ever seen it once in production. BGP or GTFO (So looking forwards to having to learn EIGRP PE-CE quirks for CCIEv5 syllabus!)

[10.0.0.7:1:172.16.1.0/30]

Good pickup That1guy, it is the RD. In the bgp.l3vpn table (i.e. show ip bgp vpnv4)  that's pretty clear

bgp.l3vpn.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both


10.0.0.7:1:172.16.1.0/30               
                   *[BGP/170] 00:14:08, localpref 100, from 10.0.0.7
                      AS path: I
                    > to 10.8.8.2 via ge-0/0/3.0, Push 16, Push 299824(top)

Same OSPF area 0. I was actually going to lab up sham-link, but I got sidetracked on this goodie. Its certainly given me good practice crawling the various MPLS/VRF layers the JunOS way. I'm still struggling to see the OSPF extended community in the BGP info, where its so clear and obvious in IOS.


I did try to set the instance-ID  but I'm afraid my Juniper import/export knowledge is not as good as I thought! That's what I'm working on now.


lol yeah Mellow would probably know this in a snap, that crazy double CCIE/JNCIE-SP!!!! I've actually been using his Juniper SP articles.

ditto to what javentre says, curious as well

Do you have the GNS3 topology handy for quick look-see?

I only run a single SSD for my iSCSI, but 90% of my hosts are virtual routers and I have the show runs.
For my DC/Vcenter/linux server, I just veeam them monthly and/or clone them to local storage.