03-15-2022 03:00 AM
Got a pair of Palo Alto in HA active/passive mode. Need to configure BDI on the Cisco 4431 so as to team up two gigaethernet interface with a virtual IP address and maintain connectivity when active palo alto fail and it failover to the passive device
I replicate it on my GNS lab using IOS (BVI) and works fine with my OSPF and BGP, but most notes and examples I'm reading is between Cisco router and switch or cisco routers using dot1q encapsulations. Here is my desired result with the Palo alto acting as perimeter firewall and also participating in iBGP. Hope someone point me to the right direction for the desired result
Thanks
Solved! Go to Solution.
03-15-2022
05:29 AM
- last edited on
03-16-2022
02:24 PM
by
Translator
Been a little while since I did this in IOS-XE, but you will need to build the bridge-domain on the ISR4K using a config that looks something like the following (excuse the syntax, as I am typing from my memory because don't have a chassis to try it out - and I have a brain like a sieve these days).
interface GigabitEthernet0/0/0
service instance 100
encapsulation dot1q 100 <-- if you need to have a VLAN tag on the link to the Firewall
rewrite ingress tag pop 1 symmetric <-- pop the tag on ingress
interface GigabitEthernet0/0/1
service instance 100
encapsulation dot1q 100
rewrite ingress tag pop 1 symmetric
l2vpn bdi 100 <-- I forget the cli here, but if you can't work it out from your router cli "?" then I'll do some digging
interface GigabitEthernet0/0/0
interface GigabitEthernet0/0/1
interface bdi 100
interface bdi 100
ip address 10.1.85.1 255.255.255.254
03-15-2022
05:40 AM
- last edited on
03-16-2022
02:25 PM
by
Translator
l2vpn bdi 100 <-- I forget the cli here, but if you can't work it out from your router cli "?" then I'll do some digging
interface GigabitEthernet0/0/0
interface GigabitEthernet0/0/1
interface bdi 100
It could be mixing up this config-section above (from the IOS-XR l2vpn) and the IOS-XE construct just has the association of the interface with the bridge-domain directly, so config just looks like
interface GigabitEthernet0/0/0
service instance 100
encapsulation dot1q 100 (or "untagged")
rewrite ingress tag pop 1 symmetric
bridge-domain 100
03-16-2022
02:52 AM
- last edited on
03-16-2022
03:01 PM
by
Translator
Yea I think that the tagging may only be applicable to a dot1q sub-interface (interface gig0/0/1.202) were you have stated the
encapsulation dot1q <vlan-id>
, because what that
rewrite
command does is when an ethernet frame arrives on the matching sub-interface it will pop 1 VLAN tag and the "symmetric" part of the command tells the box to push 1 dot1q tag in the egress direction (the tag matching the VLAN-id in the encapsulation command).
If you have a bridge-domain or XConnect where the ingress and egress interfaces use the same VLAN tag then you don't actually need to pop or push any tag as the frame enters and leaves the box because the same dot1q id is valid on both access-circuits...............however, if the dot1q tag on each access-circuit is locally significant (ie you need to do a translation of VLAN-id between ingress and egress links) then you need to get rid of the "old" tag and replace with the "new" one. Similarly, a Layer3 bridge-domain interface does not understand VLAN-tagging and expects to receive/transmit everything as an untagged frame and so if your access-circuits are forwarding the frames onto a BDI then you have no option but to remove the dot1q header upon ingress, hence the use of that command.
03-15-2022
05:29 AM
- last edited on
03-16-2022
02:24 PM
by
Translator
Been a little while since I did this in IOS-XE, but you will need to build the bridge-domain on the ISR4K using a config that looks something like the following (excuse the syntax, as I am typing from my memory because don't have a chassis to try it out - and I have a brain like a sieve these days).
interface GigabitEthernet0/0/0
service instance 100
encapsulation dot1q 100 <-- if you need to have a VLAN tag on the link to the Firewall
rewrite ingress tag pop 1 symmetric <-- pop the tag on ingress
interface GigabitEthernet0/0/1
service instance 100
encapsulation dot1q 100
rewrite ingress tag pop 1 symmetric
l2vpn bdi 100 <-- I forget the cli here, but if you can't work it out from your router cli "?" then I'll do some digging
interface GigabitEthernet0/0/0
interface GigabitEthernet0/0/1
interface bdi 100
interface bdi 100
ip address 10.1.85.1 255.255.255.254
03-15-2022
05:40 AM
- last edited on
03-16-2022
02:25 PM
by
Translator
l2vpn bdi 100 <-- I forget the cli here, but if you can't work it out from your router cli "?" then I'll do some digging
interface GigabitEthernet0/0/0
interface GigabitEthernet0/0/1
interface bdi 100
It could be mixing up this config-section above (from the IOS-XR l2vpn) and the IOS-XE construct just has the association of the interface with the bridge-domain directly, so config just looks like
interface GigabitEthernet0/0/0
service instance 100
encapsulation dot1q 100 (or "untagged")
rewrite ingress tag pop 1 symmetric
bridge-domain 100
03-15-2022
03:49 PM
- last edited on
03-16-2022
02:26 PM
by
Translator
Thanks @JimWicks Got it working now. Got this configured and working with my iBGP peering well.
interface GigabitEthernet0/0/1
no ip address
negotiation auto
service instance 202 ethernet
encapsulation untagged
bridge-domain 202
interface BDI202
ip address x.x.x.x 255.255.255.254
The rewrite ingress command doesn't seem to work on the service instance
This is what I got. What does that do btw ?
#rewrite ingress tag pop 1 symmetric
Rewrite change is not logically valid on ServInst 202(Gi0/0/1
03-16-2022
02:52 AM
- last edited on
03-16-2022
03:01 PM
by
Translator
Yea I think that the tagging may only be applicable to a dot1q sub-interface (interface gig0/0/1.202) were you have stated the
encapsulation dot1q <vlan-id>
, because what that
rewrite
command does is when an ethernet frame arrives on the matching sub-interface it will pop 1 VLAN tag and the "symmetric" part of the command tells the box to push 1 dot1q tag in the egress direction (the tag matching the VLAN-id in the encapsulation command).
If you have a bridge-domain or XConnect where the ingress and egress interfaces use the same VLAN tag then you don't actually need to pop or push any tag as the frame enters and leaves the box because the same dot1q id is valid on both access-circuits...............however, if the dot1q tag on each access-circuit is locally significant (ie you need to do a translation of VLAN-id between ingress and egress links) then you need to get rid of the "old" tag and replace with the "new" one. Similarly, a Layer3 bridge-domain interface does not understand VLAN-tagging and expects to receive/transmit everything as an untagged frame and so if your access-circuits are forwarding the frames onto a BDI then you have no option but to remove the dot1q header upon ingress, hence the use of that command.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide