With iBGP running between all four PE routers, this video adds the external BGP session between PE1 and CE1 — establishing the first eBGP peering in the topology and explaining the key differences between how internal and external BGP sessions are configured on JunOS.

The first step is completing the full iBGP mesh — configuring PE4 with BGP group internal, autonomous system 65000, loopback 4.4.4.4 as local address, and neighbours pointing to PE2 and PE3. Once PE4 is configured all four PE routers have iBGP sessions established with each other, giving us the full core iBGP mesh we need before adding external peers.

The eBGP session between PE1 and CE1 requires a separate BGP group — in this topology named EXT with the type set to external. The critical difference from iBGP is the local address. Where iBGP sessions are sourced from loopback addresses, eBGP sessions must use the physical interface addresses facing the peer. This is because eBGP has a default TTL of 1 — BGP packets that need to travel more than one hop are automatically dropped. Sourcing the session from an interface address rather than a loopback ensures the TTL-1 restriction doesn’t cause problems.

The video includes a realistic troubleshooting moment — the initial neighbour address configured on PE1 is incorrect, causing the BGP session to sit in Connect state unable to establish. We use the JunOS replace pattern command to update the neighbour address cleanly without having to delete and recreate the configuration. CE1’s BGP group is configured with autonomous system 65001 as its own AS and 65000 as the peer AS for PE1.

Once both ends are correctly configured the eBGP session comes up as Established. However the active, received and advertised prefix counts all show zero — eBGP sessions don’t advertise anything until explicit route policy is applied. Unlike OSPF, BGP never automatically shares routing information. Policy configuration to start advertising prefixes is covered in the next video.